From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b0d68c502c0ae6 X-Google-Attributes: gid103376,public From: "Michael Young" Subject: Re: Printing Enum Variable Re: Linux World Date: 1999/03/07 Message-ID: <7btj81$j0d$1@remarQ.com>#1/1 X-Deja-AN: 452173628 Content-Transfer-Encoding: 7bit References: <7bfc2n$jl9@dfw-ixnews5.ix.netcom.com> <7bhh26$r7c$1@remarQ.com> <36DCAC1F.430E2C5E@aasaa.ofe.org> <7bk4v8$kl8$1@remarQ.com> <36DDA761.7B4E8099@aasaa.ofe.org> <7bkrmm$ao1$1@nnrp1.dejanews.com> <36DE0007.5236CEA2@aasaa.ofe.org> <7bmmu2$n0h@news1.newsguy.com> X-Priority: 3 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 X-Complaints-To: newsabuse@remarQ.com X-Trace: 920801345 Z.COWSAII8C4ACFD0C usenet78.supernews.com Organization: Posted via RemarQ, http://www.remarQ.com - Discussions start here! X-MSMail-Priority: Normal Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-03-07T00:00:00+00:00 List-Id: There are many good things to be said about strong typing. I fail to see your point, however, in comparing type safety in C to that in Ada. A more appropriate comparison would be Ada to C++. In your (narrow) example, the differences in implementation would be next to indistinguishable. It's also worth noting that C++ destructors formalize resource deallocation, addressing the resource leak issue very effectively. (I never did understand dewar's strong admonition to avoid using finalize for performance reasons. I'd love to hear a capsule summary if that's possible.) While I'm not especially fond of the old SDK, its structure looks surprisingly like object use in Ada today. Instead of the more succinct C++/Java style aWindow.GetDC(), we see GetDC(aWindow). Anyway, I'm not sure which you were bashing: C in its infancy, or the old SDK. Both were laudable in their days. I expect I might say the same of Ada95 in some not so distant future. Michael. Florian Weimer wrote in message news:m3k8wufayz.fsf@deneb.cygnus.stuttgart.netsurf.de... > Samuel Mize writes: > > > /* one of these must be right, the other wrong */ > > SetWindow (W1, color, attribs); > > SetWindow (W1, attribs, color); > > This reminds me of another C problem which is related to some point. > For example, there once was a function called ReleaseDC(HWND hwnd, > HDC hdc) on Microsoft Windows (don't know if still exists), which had > to be called to release one of the five system-wide per-window drawing > contexts. Of course, the `types' HWND and HDC were defined like this: > > typedef unsigned int HWND; > typedef unsigned int HDC; > > Nothing prevented you from calling ReleaseDC(hdc, hwnd), thus not > releasing the drawing context. This was especially annoying during > software development---the machine froze if no more drawing contexts > where available. But I've seen software which had this drawing context > leak and was delivered, too. > > In the final days of Win16, Microsoft used the following trick to make > HWND and HDC (and the other handle types) distinct types: > > struct tagHWND { int dummy; }; > struct tagHDC { int dummy; }; > > typedef struct tagHWND *HWND; > typedef struct tagHDC *HDC; > > Of course, this extremely ugly and platform dependent, but in fact, > it's quite helpful if you are programming with C (and not Ada ;). > AFAIK it is still used with Win32.