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: 109fba,582dff0b3f065a52 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,582dff0b3f065a52 X-Google-Attributes: gid1014db,public X-Google-ArrivalTime: 2001-08-09 15:53:56 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!195.238.2.15!skynet.be!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> <9kp9n7$ivm$1@nh.pace.co.uk> User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.2.17-21mdksecure (i686)) Date: Thu, 9 Aug 2001 21:07:39 +0200 Message-ID: NNTP-Posting-Host: 194.78.202.248 X-Trace: 997397635 reader0.news.skynet.be 54315 194.78.202.248 X-Complaints-To: abuse@skynet.be Xref: archiver1.google.com comp.lang.ada:11718 comp.lang.c:73277 comp.lang.c++:81388 Date: 2001-08-09T21:07:39+02:00 List-Id: Ted Dennison wrote: >>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". :-) I use it all the time (and love it) > o In the Ada version, "i" would not be assignable within the loop. This allows > the compiler to optimize things a lot more easily. I am not really sure, why do you think that? > 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. This depends on the implementation of the STL of course. It certainly is not a virtual function call. std::vector::iterator is a either a wrapper around an int or a pointer to What. In both cases it translates to just pre-incrementing the pointer or the integer. Modern compilers have no trouble optimizing this. > 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. True. Some compilers don't hoist the call to v.end(). If you feel pathetic about it you can always do it by hand. I think for a non-trivial loop it is lost in the noise. Better compilers optimize this completly away of course. > 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 I guess that's why you use Ada and I use C++? Best tool for the job and all that? > 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. Probably. I don't know anything about system programming. However, predictability is achievable in C++ just as well as in C. For example all containers in the STL have an allocator as template argument. So if you need predictable memory allocation you can override the standard allocator and for example use memory from a pre-allocated pool. > Systems software is pretty much what this thread is about. In particular, one Is it? I approached this thread from the application programming side. cu bart -- http://www.irule.be/bvh/