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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,582dff0b3f065a52 X-Google-Attributes: gid1014db,public X-Google-Thread: 109fba,582dff0b3f065a52 X-Google-Attributes: gid109fba,public X-Google-ArrivalTime: 2001-08-07 14:34:09 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!195.238.2.15!skynet.be!louie!not-for-mail Sender: - From: Bart.Vanhauwaert@nowhere.be Subject: Re: How Ada could have prevented the Red Code distributed denial of service attack. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++ References: <3b690498.1111845720@news.worldonline.nl> <9kbu15$9bj@augusta.math.psu.edu> <9kbvsr$a02@augusta.math.psu.edu> <3B69DB35.4412459E@home.com> <3B6F312F.DA4E178E@home.com> User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.2.17-21mdksecure (i686)) Date: Tue, 7 Aug 2001 13:57:22 +0200 Message-ID: <23lok9.ioi.ln@10.0.0.2> NNTP-Posting-Host: 194.78.202.248 X-Trace: 997220047 reader0.news.skynet.be 54318 194.78.202.248 X-Complaints-To: abuse@skynet.be Xref: archiver1.google.com comp.lang.ada:11533 comp.lang.c:72757 comp.lang.c++:80783 Date: 2001-08-07T13:57:22+02:00 List-Id: Warren W. Gay VE3WWG wrote: > Well, what can I say? Others consider it to be at least a two-fold > advantage: Let's just call it taste. > And BTW, knowing the array bounds is not a problem. That is why Ada > provides convenient attributes like My_Array'First and My_Array'Last > (PL/I did it with builtin functions like lbound(My_Array) and hbound(My_Array) > IIRC). And as we all know, lazy programmers will not use 'First and 'Last, but will assume it's 0. >> Again, minor advantage. The compiler will warn you if you make mistakes. > Yes, this is "minor", but it is "more convenient", which was my point. My point it is minor. >> In C++ you just use virtual member funcs. Or template functions if >> speed is primordial. Easier, cleaner. Comparable mechanisms exist >> in C. > Virtual functions do not address this issue. You clearly do not understand > the problem here. Well, why don't you explain the problem than? (In a modern C++ program the only need for variants is interfacing with legacy API's btw) >> Minor advantage. Totally ofset by the fact that serious software needs >> internationalization anyway. If really needed, a gross #define hack >> does the trick. > You said it best -- "gross". ;-) It is also "error prone", which is one > reason why Ada makes this service available. And you left out the beef of my argument of course : real software needs internationalization anyway, rendering this feature totally useless. >> Read up on the STL. It does that and more (like sticking a transformation >> in between, copying from stdin directly to a slice, etc...) > The STL is not used in all contexts (it's just not practical). If you call The STL is practical and in use in major projects. > pipe(2), you will not be using a vector from the STL. You'll use a naked > int[2] array. This is only one example. That's why the STL has special provisions to deal with legacy C-style arrays. Recommended reading for you : (I am sure you'll find it on amazon) The C++ Standard Library -- A tutorial and reference Nicolai M. Josuttis, Addison Wesley Longman >> Again, this seems mostly syntactical sugar. I don't understand the >> physical/logical argument. > Exactly.. you don't have it in C/C++, so you don't understand its advantages. > I don't mean to be condescending in that, just that you are used to defining > macros to do the same work. But this is something you should not have to do, I have never felt the need to know the size of a certain struct. Why don't you give an example where it is needed? > since it is error prone, and adds unnecessary "software clutter". Let the > computer do what it does best -- keep track of the implementation details. Ada > does precisely that. I prefer a programming style where implementation details don't matter so that the code is portable. > They often don't get it right the first time. Sure experienced developers > eventually learn this. But I've seen this mistake made regularly by > people who work in C/C++ every day. What's worse, is that a developer > may code a sizeof expression that happens to work for his current > platform X. Then when the code is ported to platform Y where the > padding is different -- SURPRISE! Porting problem! I write code that runs on windows/unix for living. I just grepped through my current project (rather small, 500k lines) there is not one single sizeof in the code. > BTW, this orignal post was not meant to be the reasons "Ada is best". The > posted comments are "these are some conveniences of Ada". If I wanted > to do a "sales job" for Ada, I would not start with these points, nor > use these alone. There are so many better reasons for using Ada. ;-) Well, let's bring them to the table then! A bit of valuable discussion in a thread full of trolls won't hurt anybody. cu bart -- http://www.irule.be/bvh/