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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,a84eaf8fb2470909 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Newsgroups: comp.lang.ada Subject: Re: Ada generics References: <1166710494.869393.108730@a3g2000cwd.googlegroups.com> <17fe4xfogg7p5.1dcyc5nyc2gsl.dlg@40tude.net> <1166805696.291429.239590@48g2000cwx.googlegroups.com> <1166811980.980627.270680@a3g2000cwd.googlegroups.com> From: Markus E Leypold Organization: N/A Date: Fri, 22 Dec 2006 21:59:35 +0100 Message-ID: <06tzznwsso.fsf@hod.lan.m-e-leypold.de> User-Agent: Some cool user agent (SCUG) Cancel-Lock: sha1:acj5unqg6HchvWVO80UwU8QyYo4= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 88.72.224.204 X-Trace: news.arcor-ip.de 1166820956 88.72.224.204 (22 Dec 2006 21:55:56 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor-ip.de!news.arcor-ip.de!not-for-mail Xref: g2news2.google.com comp.lang.ada:7995 Date: 2006-12-22T21:59:35+01:00 List-Id: "Hyman Rosen" writes: > Markus E Leypold wrote: >> I think the purpose is not "catching errors" but more likely delivering abstraction. > > True enough. Right now, that has to be handled in C++ by documentation. > But the effect is just to let some things work that otherwise would be > stopped. But that is not enough. A language specification essentially provides a vocabulary to describe interfaces between system components. It talks about types, language objects that are in interfaces, which parts of them are visible and what might be the permitted usage. If that framework is missing you simply don't have the tools to document the contract. Look at the empirical evidence how well components occuring "in the wild" are documented in various languages. My impression is, that languages with language mechanisms for modularization (like Ada, Modula, Ocaml, ...) have a much better track record. YMMV. > >> Which just goes to show how evil that approach is. > > Nonsense. C++'s approach to identifying instantiations serves it > excellently well in a variety of ways - traits classes, > metaprogramming, optimized specializations, and best of all, automatic > instantiation of function templates. You only have to do all that if you "instantiate" templates in header files. If on the other side you have a separation into bodies and interfaces there is a place where the package gets instantiated (basically a place where the open parameters describing the data sizes and stackframe layout are recorded). And that simply is the package instance -- no need to generate code and no need to fold multiple instantiation with the same parameters into one. In Ada -- as I understand it -- an instantiation is simply identified by the place where the This approach is of cause not possible with header files (inclusion vs. usage). I do not want offer flame bait here, but ... -- I'm programming and have been programming in a really wide range of languages, from assembly to pure functional languages, and the older I become, the more I'm appalled what a mess C++ is conceptually. You say, the right way in C++ is not types or interface constraints, but "to handle it by documentation". I suggest, that the very, I'd say, "openness" of most template definitions, make it just impossible to define an abstract interface (i.e. to establish a contract between component provider and component user). Of course one can always employ "coding standards" top enforce the required discipline. But that simply amounts to double work: First write the component, then document it (or the other way round). Instead of making a core part of the documentation into a part of the language: The interface. And double work just results in the "unnecessary" part being dropped under pressure. I've compiled 20 years old Ada 83 code with Gnat after renaming just some files. Have you ever tried to rebuild a C++-projekt from last year or from 5 years ago? > You are simply displaying the > usual comp.lang.ada parochialism of "if Ada doesn't have it then you No, I don't. Indeed, I can (in the mean time :-) point out very well, where Ada misses the train for "the 21st century", except perhaps for embedded programming. But C++ simply is atrocious. Of course, now that there is so much code around written in C++, a lot of people can earn their daily bread by applying "social" and technical fixes to the language specification bugs, like, coding standards, reading and applying the lessons from Scott Meyers books and using memory debugger like valgrind. So overall, and given the global employment situation it's perhaps a good thing :-). Not that coding standards are necessarily a bad thing: But they shouldn't be cluttered with preaching ad-hoc fixes to something that is actually a language problem. Dito valgrind is a good tool: But why would I have to apply that to a desktop application? > don't need it". A non-type template parameter can be a reference to a The point is more about the things C++ doesn't have. :-) > floating point object, by the way, so the lack isn't all that serious > extern double sin(double); > extern double const epsilon = 1e-6; > template > double integrate(double from, double to) { ... } > int main() { integrate(0.0, 3.14); } I fear you're proving my point here :-). I'm not talking about wether things can be done at all. I'm mostly concerned how they are done, and wether code written today can be read and understood in a finite amount of time by the maintenance programmer who checks it out from version control in 10 years time. Just to support my case: I think, the ARM and the Barnes book is good enough to learn most of Ada if you got some background in "strongly" statically typed languages (Pascal, ML, maybe Java) and some in procedural languages (like C or Pascal). The Barnes book could be at tiny bit more precise and complete in some points, but overall, it makes a really good read. C++ on the other side cannot be learned from the standard and book X. Of course that might be my inability. The only good C++ book (IMHO) are those "smart" hackish books like those of Scott Meyer. They make good conversation pieces, but only highlight "intresting" corners of the language. There is no book from which you can learn to read C++. But as I said: YMVV. Regards -- Markus