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=0.6 required=5.0 tests=BAYES_00,TO_NO_BRKTS_FROM_MSSP autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,582dff0b3f065a52 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,582dff0b3f065a52 X-Google-Attributes: gid1014db,public X-Google-ArrivalTime: 2001-08-09 07:18:12 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!feed.textport.net!newsranger.com!www.newsranger.com!not-for-mail Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++ From: Ted Dennison References: <3b690498.1111845720@news.worldonline.nl> <9kbu15$9bj@augusta.math.psu.edu> <9kbvsr$a02@augusta.math.psu.edu> <3B69DB35.4412459E@home.com> <9kp9n7$ivm$1@nh.pace.co.uk> Subject: Re: How Ada could have prevented the Red Code distributed denial of service attack. Message-ID: X-Abuse-Info: When contacting newsranger.com regarding abuse please X-Abuse-Info: forward the entire news article including headers or X-Abuse-Info: else we will not be able to process your request X-Complaints-To: abuse@newsranger.com NNTP-Posting-Date: Thu, 09 Aug 2001 10:18:00 EDT Organization: http://www.newsranger.com Date: Thu, 09 Aug 2001 14:18:00 GMT Xref: archiver1.google.com comp.lang.ada:11683 comp.lang.c:73174 comp.lang.c++:81216 Date: 2001-08-09T14:18:00+00:00 List-Id: In article , Bart.Vanhauwaert@nowhere.be says... > >Marin David Condic wrote: >> And don't forget 'Range - very useful for "for" loops. And the same thing >I am not really sure where this is fundamentally different from > >for (std::vector::iterator i=v.begin(); i!=v.end(); ++i) That's actually pretty close, and seems to have all the benifits Marin was touting. Its a shame I've never seen it "in the wild". :-) There are some differences, though: o In the Ada version, "i" would not be assignable within the loop. This allows the compiler to optimize things a lot more easily. o I'm not to sure how C++ compilers implement calls to the iterator's "++" operator, but it looks like a function call to me (perhaps even a dispatching one?). The Ada for loop is going to use whatever hardware incrementation method is fastest (assuming it doesn't just unroll some or all of the loop). In a tight loop, the speed difference could be significant. o In the Ada version, the range of "i" is much more likely (almost certian actually) to be discernable at compile time. Again, this allows the compiler to optimize things a lot more easily. It also means that there won't be extra code (and time) used to figure out the bounds at runtime. The first issue is due to the fact that C went for maximum "hackability", and thus doesn't have a constrained loop form for optimizing compilers to work with. The last two are due to C leaving type safety issues up to library writers, rather than properly addressing them in the language itself. >(Btw, as an application programmar, I get supicious whenever I see >a fixed size array. It means some arbitrary limit (or arbitrary >waste of resources) that some user eventually will stumble upon and >of course complain) Actually, in Ada a fixed sized array does not always mean that. You can go figure out what the size needs to be (at startup time or runtime), and then perform the array declaration. Also, remember that all of us are not application programmers. Marin and I are systems programmers. I get quite suspicous of any *dynamic* data structure, as its liable to consume time that I don't have to spare. Sometimes the time *variability* of dynamic memory operations can be a big problem too (eg: when updating a display, your time between updates has to be *exact*, or things look weird). There's a trade-off involved with choosing any particular data structure, and you have to balance your requirements against those trade-offs. Arbitrary limits may be annoying for your average GUI app, but device drivers and OS kernels (especially RTOS's) are chock full of them, and for good reason. Systems software is pretty much what this thread is about. In particular, one *shouldn't* have to balance safety and execution speed as much as C++ system programmers have to. Given the choice, many systems programmers are naturally going to decide that they just can't take the speed hit of using the safe abtract classes (and some are just perverse and prefer not to either way). By putting type safety in the language, rather than pushing it off into tacked-on libraries, Ada allows safe code that can optimize much better and run much faster than equivalently safe C++ code. With a little work, it can even be faster than *unsafe* C++ code (due to issues like less aliasing and the too-flexible for loop I mentioned above). --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com