* Re: Ada vs C++ [not found] ` <Pine.SGI.3.95.970831115842.17664A-100000@shellx.best.com> @ 1997-09-02 0:00 ` James B. White, III (Trey) [not found] ` <Pine.SGI.3.95.970904201703.13590A-100000@shellx.best.com> ` (3 more replies) 0 siblings, 4 replies; 18+ messages in thread From: James B. White, III (Trey) @ 1997-09-02 0:00 UTC (permalink / raw) The ability of C++ compilers to infer template instantiations may be dangerous, but it allows the construction of incredibly powerful interfaces. Combined with the ability to inline functions, you can write strange constructions called "expression templates" and "template metaprograms" that perform optimizations that are extremely difficult or impossible for a compiler to perform on its own. Ada may have advantages over C++, but only C++ allows these incredibly powerful programming techniques. Unfortunately, the techniques are also incredibly complicated and incredibly ugly. The resulting interface, however, can be elegant. For more information, see the following references by the inventor, Todd Veldhuizen. <http://monet.uwaterloo.ca/blitz/#papers> I would love for Ada to provide the same level of power, preferably in a more elegant and straightforward way! -- James B. White, III (Trey) Ohio Supercomputer Center trey@osc.edu <http://www.osc.edu/~trey/> Phone: (614)292-9291 Fax: (614)292-7168 ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <Pine.SGI.3.95.970904201703.13590A-100000@shellx.best.com>]
* Re: Ada vs C++ [not found] ` <Pine.SGI.3.95.970904201703.13590A-100000@shellx.best.com> @ 1997-09-05 0:00 ` Jon S Anthony 0 siblings, 0 replies; 18+ messages in thread From: Jon S Anthony @ 1997-09-05 0:00 UTC (permalink / raw) In article <Pine.SGI.3.95.970904201703.13590A-100000@shellx.best.com> Brian Rogoff <bpr@shellx.best.com> writes: > > Ada may have advantages over C++, but only C++ allows these incredibly > > powerful programming techniques. Unfortunately, the techniques are also > > I believe you can do all of this stuff with Common Lisp macros. Actually, CL macros seem much more generally capable than C++ templates. For one thing, they aren't tied to the type system. For another, they can avail themselves of the full capabilities of CL (including closures). And, I still think you could write the C++ template facility (such as it is) in CL macros as an embedded langauge (not that this would actually be useful or worth anything - just a demonstration). It would likely even be relatively straightforward, but to be fair, I haven't looked at the possibility that closely. > automatic instantiation, but that won't be able to do what you want. What > *you* want seems to be macros. Most Ada-philes seem to be macro-phobic, > but don't let that stop you. Right. I'm pretty skeptical of macros (real ones ala' CL) in something like Ada (or C++ or anything like them). They just don't seem to fit the spirit of the language. /Jon -- Jon Anthony OMI, Belmont, MA 02178, 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada vs C++ 1997-09-02 0:00 ` Ada vs C++ James B. White, III (Trey) [not found] ` <Pine.SGI.3.95.970904201703.13590A-100000@shellx.best.com> @ 1997-09-05 0:00 ` Robert Dewar 1997-09-05 0:00 ` Brian Rogoff ` (2 more replies) 1997-09-08 0:00 ` Ada vs C++ Richard A. O'Keefe 1997-09-09 0:00 ` Ada vs C++ Joerg Rodemann 3 siblings, 3 replies; 18+ messages in thread From: Robert Dewar @ 1997-09-05 0:00 UTC (permalink / raw) James White says <<The ability of C++ compilers to infer template instantiations may be dangerous, but it allows the construction of incredibly powerful interfaces. Combined with the ability to inline functions, you can write strange constructions called "expression templates" and "template metaprograms" that perform optimizations that are extremely difficult or impossible for a compiler to perform on its own. Ada may have advantages over C++, but only C++ allows these incredibly powerful programming techniques. Unfortunately, the techniques are also incredibly complicated and incredibly ugly.>> So, we see from the above (if you believe it), that C++ is the way to go if you want something that is incredibly powerful, incredibly complicated and incredibly ugly. Sometimes ones friends are ones worst enemies :-) Seriously, I think this quest after "power" in languages, rather than basic functionality, is misguided. An important ingrediant in achieving reliability is to keep things simple at all levels. You say that you can produce wonderful interfaces with this amazing capability. What is interesting is to look at such an interface, and then ask how that interface would be reflected and implemented in other languages. Specific examples typically show that such claims are simply inflated and have little substance! ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada vs C++ 1997-09-05 0:00 ` Robert Dewar @ 1997-09-05 0:00 ` Brian Rogoff 1997-09-05 0:00 ` Larry Kilgallen 1997-09-08 0:00 ` Ada vs C++ (Expression Templates) James B. White, III (Trey) 2 siblings, 0 replies; 18+ messages in thread From: Brian Rogoff @ 1997-09-05 0:00 UTC (permalink / raw) On 5 Sep 1997, Robert Dewar wrote: <... discussion of C++ template metaprograms deleted...> > So, we see from the above (if you believe it), that C++ is the way to > go if you want something that is incredibly powerful, incredibly complicated > and incredibly ugly. Lets not forget that there are lots of other features of C++ that interact to make it complicated and ugly, from an Ada perspective. So the experience of C++ templates, while helpful, is not entirely convincing. There are some good ideas in C++, though I agree that this (very specific case of embedding a little language in the template system) is not one of them. > Seriously, I think this quest after "power" in languages, rather than > basic functionality, is misguided. I agree that you can waste a lot of time playing with features that may seem powerful but may end up not being worthwhile for practical development. However, I don't know of any good way other than experience to decide what is "basic functionality", and even then we'll always have disagreements (modules, MI, assertions, ...). > An important ingrediant in achieving reliability is to keep things simple > at all levels. You are the last person in the world who needs to be reminded that the concept of "simplicity" is heavily overloaded! What do you think about the idea of automatically instantiating generic subprograms by inferring parameters but *not* values, i.e., none of this "template metaprogram" stuff, but a simple :-) generalization of Ada overloading? Any difference in perspective as a user vs as a compiler writer? -- Brian ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada vs C++ 1997-09-05 0:00 ` Robert Dewar 1997-09-05 0:00 ` Brian Rogoff @ 1997-09-05 0:00 ` Larry Kilgallen 1997-09-08 0:00 ` Ada vs C++ (Expression Templates) James B. White, III (Trey) 2 siblings, 0 replies; 18+ messages in thread From: Larry Kilgallen @ 1997-09-05 0:00 UTC (permalink / raw) In article <dewar.873461400@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes: > James White says > > << > Ada may have advantages over C++, but only C++ allows these incredibly > powerful programming techniques. Unfortunately, the techniques are also > incredibly complicated and incredibly ugly.>> > Seriously, I think this quest after "power" in languages, rather than > basic functionality, is misguided. An important ingrediant in achieving > reliability is to keep things simple at all levels. Real "power" makes it easier to shoot oneself in the foot. With multiuser computers, one can even get the feet of neighbors. "Power" seems the opposite of safety. Larry Kilgallen ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada vs C++ (Expression Templates) 1997-09-05 0:00 ` Robert Dewar 1997-09-05 0:00 ` Brian Rogoff 1997-09-05 0:00 ` Larry Kilgallen @ 1997-09-08 0:00 ` James B. White, III (Trey) 1997-09-08 0:00 ` Matthew Heaney 2 siblings, 1 reply; 18+ messages in thread From: James B. White, III (Trey) @ 1997-09-08 0:00 UTC (permalink / raw) Robert Dewar wrote: > You say that you can produce wonderful interfaces with this amazing > capability. What is interesting is to look at such an interface, and > then ask how that interface would be reflected and implemented in > other languages. I have done exactly this. I started with a small sample calculation used as an example in an article on expression templates. I implemented the example in Ada using many techniques. I'll be giving a talk at Tri-Ada on the results. > Specific examples typically show that such claims > are simply inflated and have little substance! This is what I hoped to prove! I *wanted* to show that these ugly expression templates were either unnecessary or easier to implement in Ada. Unfortunately, neither was the case. In my field, high-performance computing, an order of two difference in performance is significant. For Ada implementations that created the desired interface, the execution times were more like three times those of C++ with expression templates. And the nature of the example calculation would tend to minimizes differences between compilers, so other examples could perform even worse! In other fields, the relative priority of performance versus ease of development isn't so skewed towards performance. I, however, am in the unfortunate situation where the performance benefits of expression templates probably outweigh the other benefits of Ada over C++. -- James B. White, III (Trey) Ohio Supercomputer Center trey@osc.edu <http://www.osc.edu/~trey/> Phone: (614)292-9291 Fax: (614)292-7168 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada vs C++ (Expression Templates) 1997-09-08 0:00 ` Ada vs C++ (Expression Templates) James B. White, III (Trey) @ 1997-09-08 0:00 ` Matthew Heaney 0 siblings, 0 replies; 18+ messages in thread From: Matthew Heaney @ 1997-09-08 0:00 UTC (permalink / raw) In article <3413FFA6.D4D@osc.edu>, "James B. White, III (Trey)" <trey@osc.edu> wrote: >In other fields, the relative priority of performance versus ease of >development isn't so skewed towards performance. I, however, am in the >unfortunate situation where the performance benefits of expression >templates probably outweigh the other benefits of Ada over C++. I have only a reading knowledge of C++. Can you explain what an "expression template" is? -------------------------------------------------------------------- Matthew Heaney Software Development Consultant <mailto:matthew_heaney@acm.org> (818) 985-1271 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada vs C++ 1997-09-02 0:00 ` Ada vs C++ James B. White, III (Trey) [not found] ` <Pine.SGI.3.95.970904201703.13590A-100000@shellx.best.com> 1997-09-05 0:00 ` Robert Dewar @ 1997-09-08 0:00 ` Richard A. O'Keefe 1997-09-08 0:00 ` Ada vs C++ (vs Lisp) James B. White, III (Trey) 1997-09-09 0:00 ` Ada vs C++ Joerg Rodemann 3 siblings, 1 reply; 18+ messages in thread From: Richard A. O'Keefe @ 1997-09-08 0:00 UTC (permalink / raw) "James B. White, III (Trey)" <trey@osc.edu> writes: >Ada may have advantages over C++, but only C++ allows these incredibly >powerful programming techniques. False. Lisp people know this kind of meta-programming as a very old technique indeed. -- Unsolicited commercial E-mail to this account is prohibited; see section 76E of the Commonwealth Crimes Act 1914 as amended by the Crimes Legislation Amendment Act No 108 of 1989. Maximum penalty: 10 years in gaol. Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada vs C++ (vs Lisp) 1997-09-08 0:00 ` Ada vs C++ Richard A. O'Keefe @ 1997-09-08 0:00 ` James B. White, III (Trey) 1997-09-08 0:00 ` Brian Rogoff 0 siblings, 1 reply; 18+ messages in thread From: James B. White, III (Trey) @ 1997-09-08 0:00 UTC (permalink / raw) Richard A. O'Keefe wrote: > > "James B. White, III (Trey)" <trey@osc.edu> writes: > >Ada may have advantages over C++, but only C++ allows these incredibly > >powerful programming techniques. > > False. Lisp people know this kind of meta-programming as a very old > technique indeed. Let me clarify my statement. The combination of expression templates *and* operator overloading *and* function inlining *and* efficient compilers allows the creation of elegant interfaces that result in code that rivals optimized hand-coded FORTRAN in performance. As far as I know, this is true only of C++. If it is true of Lisp or anything else (like Ada), I'd like to know! -- James B. White, III (Trey) Ohio Supercomputer Center trey@osc.edu <http://www.osc.edu/~trey/> Phone: (614)292-9291 Fax: (614)292-7168 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada vs C++ (vs Lisp) 1997-09-08 0:00 ` Ada vs C++ (vs Lisp) James B. White, III (Trey) @ 1997-09-08 0:00 ` Brian Rogoff 1997-09-09 0:00 ` Ada vs C++ (Ada 0X) James B. White, III (Trey) 1997-09-09 0:00 ` Ada vs C++ (vs Lisp) Robert A Duff 0 siblings, 2 replies; 18+ messages in thread From: Brian Rogoff @ 1997-09-08 0:00 UTC (permalink / raw) On Mon, 8 Sep 1997, James B. White, III (Trey) wrote: > Richard A. O'Keefe wrote: > > "James B. White, III (Trey)" <trey@osc.edu> writes: > > >Ada may have advantages over C++, but only C++ allows these incredibly > > >powerful programming techniques. > > > > False. Lisp people know this kind of meta-programming as a very old > > technique indeed. > > Let me clarify my statement. The combination of expression templates > *and* operator overloading *and* function inlining *and* efficient > compilers allows the creation of elegant interfaces that result in code > that rivals optimized hand-coded FORTRAN in performance. As far as I > know, this is true only of C++. If it is true of Lisp or anything else > (like Ada), I'd like to know! I think it is obvious that you can't do this stuff with Ada generics because Ada generic instantiation is not primitive recursive function calculation (what a mouthful, was that clear?). Lisp macros can do arbitrary computation during expansion, so given a decent Lisp compiler you should be able to get the same effect. Ask nicely on the Lisp newsgroup and I bet you'll even get code. My question is whether it is necessary for your purposes to have this capability directly supported in the language, or if some source to source transformation tool would suffice; i.e., an Ada aware macro system or some other such tool. I recall reading about such a macro system (M5?) but I forget where... (In case anyone missed it, the C++ techniques being discussed can be found at http://monet.uwaterloo.ca/blitz/ ) -- Brian ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada vs C++ (Ada 0X) 1997-09-08 0:00 ` Brian Rogoff @ 1997-09-09 0:00 ` James B. White, III (Trey) 1997-09-09 0:00 ` Brian Rogoff 1997-09-10 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB 1997-09-09 0:00 ` Ada vs C++ (vs Lisp) Robert A Duff 1 sibling, 2 replies; 18+ messages in thread From: James B. White, III (Trey) @ 1997-09-09 0:00 UTC (permalink / raw) Brian Rogoff wrote: > I think it is obvious that you can't do this stuff with Ada generics > because Ada generic instantiation is not primitive recursive function > calculation (what a mouthful, was that clear?). Clear. More about this below. > Lisp macros can do > arbitrary computation during expansion, so given a decent Lisp compiler > you should be able to get the same effect. Ask nicely on the Lisp newsgroup > and I bet you'll even get code. Finding code is easy. The trick is finding a decent Lisp compiler! > My question is whether it is necessary for your purposes to have this > capability directly supported in the language, or if some source to source > transformation tool would suffice; i.e., an Ada aware macro system or some > other such tool. I recall reading about such a macro system (M5?) but I > forget where... If it's supported in the language, it is portable. Before anyone starts slamming the portability of C++ and templates, realize the situation has changed dramatically over the last few months. > (In case anyone missed it, the C++ techniques being discussed can be found > at http://monet.uwaterloo.ca/blitz/ ) I guess my real point is the following. Expression templates in C++ demonstrate a level of functionality absent from Ada. If the Ada standard is updated again (Ada 0X?), perhaps the Ada community should consider ways of including the capabilities of expression templates (and template metaprograms) in the new standard. I certainly don't advocate supporting C++-style templates. What I would like to see is the *capabilities* of these techniques added to Ada, but with a better implementation. -- James B. White, III (Trey) Ohio Supercomputer Center trey@osc.edu <http://www.osc.edu/~trey/> Phone: (614)292-9291 Fax: (614)292-7168 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada vs C++ (Ada 0X) 1997-09-09 0:00 ` Ada vs C++ (Ada 0X) James B. White, III (Trey) @ 1997-09-09 0:00 ` Brian Rogoff 1997-09-10 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB 1 sibling, 0 replies; 18+ messages in thread From: Brian Rogoff @ 1997-09-09 0:00 UTC (permalink / raw) On Tue, 9 Sep 1997, James B. White, III (Trey) wrote: > Brian Rogoff wrote: > > > My question is whether it is necessary for your purposes to have this > > capability directly supported in the language, or if some source to source > > transformation tool would suffice; i.e., an Ada aware macro system or some > > other such tool. I recall reading about such a macro system (M5?) but I > > forget where... > > If it's supported in the language, it is portable. Before anyone starts > slamming the portability of C++ and templates, realize the situation has > changed dramatically over the last few months. Well, "portable", like "simple", is overloaded. If you had (for example) an Ada aware macro processor written in Ada 95 (so it can be ported), why is that not portable? Bob Duff comments that it would interfere with other tools, which is true, but I guess I was thinking of ways to solve your problem before "0X". > I guess my real point is the following. Expression templates in C++ > demonstrate a level of functionality absent from Ada. I think this level of functionality was deliberately omitted from Ada. Perhaps the ban on "macro" like features should be re-examined. > I certainly don't advocate supporting C++-style templates. Whoa, C++ style templates have lots of things in common with Ada generics, and some other things in common with macros. Whether this is unification or confusion I don't know. Some of the aspects of C++ templates which are for parametric polymorphism, say especially automatic instantiation of generic subprograms :-), seem like they make sense in an Ada context. Consider the following relaxations of Ada rules (which have *nothing* to do with the macro stuff) (1) The name of a generic subprogram is allowed to appear anywhere that a non-generic subprogram name is allowed. (2) Non-generic subprograms may overload generic ones. (3) A subprogram component of a generic package may appear anywhere that a non-generic subprogram name is allowed. (4) A generic package name may be specified in a "use" clause, allowing subprogram components to be specified without qualification according to (3). (5) Some or all real parameters may be omitted in an explicit instantiation. These relaxations of restrictions would be in the spirit of the C++ template mechanism, yet they wouldn't allow the kind of macro-like computing you are discussing. Ada generics strike me as being a mechanism for parametric polymorphism, not macro instantiation, so I would hope any Ada 0X proposal you want to try out on the net would not try to stuff all sorts of compile time computation onto generics. OTOH, I see no problem with changes to allow automatic instantiation, at least not in the sense of doing violence to Ada generics. -- Brian ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada vs C++ (Ada 0X) 1997-09-09 0:00 ` Ada vs C++ (Ada 0X) James B. White, III (Trey) 1997-09-09 0:00 ` Brian Rogoff @ 1997-09-10 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB 1997-09-11 0:00 ` Anonymous 1 sibling, 1 reply; 18+ messages in thread From: Ole-Hjalmar Kristensen FOU.TD/DELAB @ 1997-09-10 0:00 UTC (permalink / raw) "James B. White, III (Trey)" <trey@osc.edu> writes: > > > Brian Rogoff wrote: > > I think it is obvious that you can't do this stuff with Ada generics > > because Ada generic instantiation is not primitive recursive function > > calculation (what a mouthful, was that clear?). > > Clear. More about this below. > > > Lisp macros can do > > arbitrary computation during expansion, so given a decent Lisp compiler > > you should be able to get the same effect. Ask nicely on the Lisp newsgroup > > and I bet you'll even get code. > > Finding code is easy. The trick is finding a decent Lisp compiler! > > > My question is whether it is necessary for your purposes to have this > > capability directly supported in the language, or if some source to source > > transformation tool would suffice; i.e., an Ada aware macro system or some > > other such tool. I recall reading about such a macro system (M5?) but I > > forget where... > > If it's supported in the language, it is portable. Before anyone starts > slamming the portability of C++ and templates, realize the situation has > changed dramatically over the last few months. > Don't bet on that. We still have template classes which are legal C++, but which in practice can only be compiled by CenterLine CC (and probably other Cfront derivates), but not by g++, and not by Sun CC, because of different strategies for instantiating the templates. > > (In case anyone missed it, the C++ techniques being discussed can be found > > at http://monet.uwaterloo.ca/blitz/ ) > > I guess my real point is the following. Expression templates in C++ > demonstrate a level of functionality absent from Ada. If the Ada > standard is updated again (Ada 0X?), perhaps the Ada community should > consider ways of including the capabilities of expression templates (and > template metaprograms) in the new standard. I certainly don't advocate > supporting C++-style templates. What I would like to see is the > *capabilities* of these techniques added to Ada, but with a better > implementation. > -- > James B. White, III (Trey) > Ohio Supercomputer Center > trey@osc.edu > <http://www.osc.edu/~trey/> > Phone: (614)292-9291 Fax: (614)292-7168 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada vs C++ (Ada 0X) 1997-09-10 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB @ 1997-09-11 0:00 ` Anonymous 1997-09-11 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB 0 siblings, 1 reply; 18+ messages in thread From: Anonymous @ 1997-09-11 0:00 UTC (permalink / raw) On 10 Sep 1997 13:28:47 +0200, ohk@tfdt-o.nta.no (Ole-Hjalmar Kristensen FOU.TD/DELAB) wrote: > "James B. White, III (Trey)" <trey@osc.edu> writes: .. > > Brian Rogoff wrote: .. > > If it's supported in the language, it is portable. Before anyone starts > > slamming the portability of C++ and templates, realize the situation has > > changed dramatically over the last few months. > > > > Don't bet on that. We still have template classes which are legal C++, > but which in practice can only be compiled by CenterLine CC (and > probably other Cfront derivates), but not by g++, and not by Sun CC, > because of different strategies for instantiating the templates. "Legal C++"? Since there is no C++ standard, legal C++ is whatever a compiler that calls itself a C++ compiler supports. To look at it another way, every "C++" compiler supports a different language. Ada: The only internationally standardized OOP language. Jeff Carter PGP:1024/440FBE21 My real e-mail address: ( carter @ innocon . com ) "English bed-wetting types." Monty Python & the Holy Grail Posted with Spam Hater - see http://www.compulink.co.uk/~net-services/spam/ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada vs C++ (Ada 0X) 1997-09-11 0:00 ` Anonymous @ 1997-09-11 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB 0 siblings, 0 replies; 18+ messages in thread From: Ole-Hjalmar Kristensen FOU.TD/DELAB @ 1997-09-11 0:00 UTC (permalink / raw) nobody@REPLAY.COM (Anonymous) writes: > > On 10 Sep 1997 13:28:47 +0200, ohk@tfdt-o.nta.no (Ole-Hjalmar Kristensen > FOU.TD/DELAB) wrote: > > > "James B. White, III (Trey)" <trey@osc.edu> writes: > .. > > > Brian Rogoff wrote: > .. > > > If it's supported in the language, it is portable. Before anyone starts > > > slamming the portability of C++ and templates, realize the situation has > > > changed dramatically over the last few months. > > > > > > > Don't bet on that. We still have template classes which are legal C++, > > but which in practice can only be compiled by CenterLine CC (and > > probably other Cfront derivates), but not by g++, and not by Sun CC, > > because of different strategies for instantiating the templates. > > "Legal C++"? Since there is no C++ standard, legal C++ is whatever a > compiler that calls itself a C++ compiler supports. To look at it > another way, every "C++" compiler supports a different language. > Well, that's exactly the problem with C++. Istead of just "legal", I should have said "legal according to the draft ISO standard". > Ada: The only internationally standardized OOP language. > Yes. > > Jeff Carter PGP:1024/440FBE21 > My real e-mail address: ( carter @ innocon . com ) > "English bed-wetting types." > Monty Python & the Holy Grail > > Posted with Spam Hater - see > http://www.compulink.co.uk/~net-services/spam/ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada vs C++ (vs Lisp) 1997-09-08 0:00 ` Brian Rogoff 1997-09-09 0:00 ` Ada vs C++ (Ada 0X) James B. White, III (Trey) @ 1997-09-09 0:00 ` Robert A Duff 1 sibling, 0 replies; 18+ messages in thread From: Robert A Duff @ 1997-09-09 0:00 UTC (permalink / raw) In article <Pine.SGI.3.95.970908203001.11288C-100000@shellx.best.com>, Brian Rogoff <bpr@shellx.best.com> wrote: >My question is whether it is necessary for your purposes to have this >capability directly supported in the language, or if some source to source >transformation tool would suffice; ... The problem is that such a tool would probably not be standard, and would probably get in the way of other tools. - Bob ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada vs C++ 1997-09-02 0:00 ` Ada vs C++ James B. White, III (Trey) ` (2 preceding siblings ...) 1997-09-08 0:00 ` Ada vs C++ Richard A. O'Keefe @ 1997-09-09 0:00 ` Joerg Rodemann 1997-09-09 0:00 ` Ada vs C++ (high-performance libraries) James B. White, III (Trey) 3 siblings, 1 reply; 18+ messages in thread From: Joerg Rodemann @ 1997-09-09 0:00 UTC (permalink / raw) James B. White, III (Trey) (trey@osc.edu) wrote: > The ability of C++ compilers to infer template instantiations may be > dangerous, but it allows the construction of incredibly powerful > interfaces. Combined with the ability to inline functions, you can write > strange constructions called "expression templates" and "template > metaprograms" that perform optimizations that are extremely difficult or > impossible for a compiler to perform on its own. > Ada may have advantages over C++, but only C++ allows these incredibly > powerful programming techniques. Unfortunately, the techniques are also > incredibly complicated and incredibly ugly. The resulting interface, > however, can be elegant. For more information, see the following > references by the inventor, Todd Veldhuizen. I wonder how this will work on non-standard highend machines. As far as I can see --- if all you need is a) very high computational power (number crunching) b) use of already existing numerical libraries c) good support by the vendor on such machines you most of the time are left with f77 or maybe f90 or even HPF. Perhaps the C compiler does work properly too. If you use C++ and desire at least a bit of portability forget about nested librarie and i.e. templates. Template instantiation still seems to be a serious problem for compiler writers her --- and although normal desktop machines are already capable of get this thing right...on the highend machines I worked on this left us with a real mess. Sure, there are workarounds available but they neither increase readability nor are they portable at all (all those pragmas concerning instantiation.) The more complex your templates are the more likely is it that they will fail. On desktop machines I think this power hunting does not make much sense. A factor of 2 or 3 in speed is clearly serious but only if you intend to run the code for a long time (months to years). Otherwise a gain in shorter development time may prove much more important than anything else. (I saw people spending weeks with number crunching just to throw away the results because the discovered a missing - in -= or a = instead of a == or some similiar silly bug. (Many were related to memory leaks and faulty vector access. Multi-dimensional arrays are not that easy in C as one would guess. :-) ). Those template constructs seem be similarly errorprone to me. And --- which debugger will help you there? Sorry for my sceptical view here, it's of course just my opinion. Yours Joerg -- rodemann@mathematik.uni-ulm.de | Dipl.-Phys. Joerg S. Rodemann Phone: ++49-(0)711-5090670 | Flurstrasse 21, D-70372 Stuttgart, Germany -------------------------------+--------------------------------------------- rodemann@rus.uni-stuttgart.de | University of Stuttgart, Computing Center Phone: ++49-(0)711-685-5815 | Visualization Department, Office: 0.304 Fax: ++49-(0)711-678-7626 | Allmandring 30a, D-70550 Stuttgart, Germany ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada vs C++ (high-performance libraries) 1997-09-09 0:00 ` Ada vs C++ Joerg Rodemann @ 1997-09-09 0:00 ` James B. White, III (Trey) 0 siblings, 0 replies; 18+ messages in thread From: James B. White, III (Trey) @ 1997-09-09 0:00 UTC (permalink / raw) Joerg Rodemann wrote: > I wonder how this [expression templates] will work on non-standard highend machines. High-end C++ compilers are now starting to handle templates quite well -- KCC (www.kai.com) and Cray C++, for example. The techniques use only (draft) standard C++. Indeed, C++ compilers of the recent past have been nowhere near the standard, but because of all the investment in C++, things are moving *very* quickly. The whole point is that you *can* (or *will*) get portable high-performance. You can build portable optimizations into the template library that you can't build into Fortran libraries -- or even Fortran compilers! As you say, there are issues of complexity and debugging. But the additional effort in development and quality control may be worth it for high-performance computing -- particularly if this extra effort appears at the level of library development and not application development. -- James B. White, III (Trey) Ohio Supercomputer Center trey@osc.edu <http://www.osc.edu/~trey/> Phone: (614)292-9291 Fax: (614)292-7168 ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~1997-09-11 0:00 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <md5:DB04B9CCA20E8EB6142C50D2DE055239> [not found] ` <34090462.4652@easystreet.com> [not found] ` <Pine.SGI.3.95.970831115842.17664A-100000@shellx.best.com> 1997-09-02 0:00 ` Ada vs C++ James B. White, III (Trey) [not found] ` <Pine.SGI.3.95.970904201703.13590A-100000@shellx.best.com> 1997-09-05 0:00 ` Jon S Anthony 1997-09-05 0:00 ` Robert Dewar 1997-09-05 0:00 ` Brian Rogoff 1997-09-05 0:00 ` Larry Kilgallen 1997-09-08 0:00 ` Ada vs C++ (Expression Templates) James B. White, III (Trey) 1997-09-08 0:00 ` Matthew Heaney 1997-09-08 0:00 ` Ada vs C++ Richard A. O'Keefe 1997-09-08 0:00 ` Ada vs C++ (vs Lisp) James B. White, III (Trey) 1997-09-08 0:00 ` Brian Rogoff 1997-09-09 0:00 ` Ada vs C++ (Ada 0X) James B. White, III (Trey) 1997-09-09 0:00 ` Brian Rogoff 1997-09-10 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB 1997-09-11 0:00 ` Anonymous 1997-09-11 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB 1997-09-09 0:00 ` Ada vs C++ (vs Lisp) Robert A Duff 1997-09-09 0:00 ` Ada vs C++ Joerg Rodemann 1997-09-09 0:00 ` Ada vs C++ (high-performance libraries) James B. White, III (Trey)
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox