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,FREEMAIL_FROM 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-ArrivalTime: 2001-08-09 10:34:56 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.frii.net!easynews!e420r-sjo4.usenetserver.com!usenetserver.com!e3500-atl1.usenetserver.com.POSTED!clarkcox3 Newsgroups: comp.lang.ada,comp.lang.c++ Subject: Re: How Ada could have prevented the Red Code distributed denial of service attack. From: clarkcox3@yahoo.com (Clark S. Cox III) Message-ID: <1exvjvr.10y6ab91y4t9eN%clarkcox3@yahoo.com> References: <3B6555ED.9B0B0420@sneakemail.com> <87n15lxzzv.fsf@deneb.enyo.de> <3B672322.B5EA1B66@home.com> <5ee5b646.0108010949.5abab7fe@posting.google.com> <%CX97.14134$ar1.47393@www.newsranger.com> <9ka1jc$mgd@augusta.math.psu.edu> <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> <1exve0j.1lboe8gneysd0N%clarkcox3@yahoo.com> User-Agent: MacSOUP/2.4.6 X-Complaints-To: abuse@usenetserver.com X-Abuse-Info: Please be sure to forward a copy of ALL headers X-Abuse-Info: Otherwise we will be unable to process your complaint properly. NNTP-Posting-Date: Thu, 09 Aug 2001 13:28:37 EDT Organization: BELLSOUTH.net Date: Thu, 9 Aug 2001 13:34:54 -0400 Xref: archiver1.google.com comp.lang.ada:11697 comp.lang.c++:81282 Date: 2001-08-09T13:34:54-04:00 List-Id: Ted Dennison wrote: > Clark S. Cox III says... > > > > What happens when you want to skip over an element of the vector? > >delete an item from the vector? > > You do it some other way than modifying the loop control variable, or you > use a different kind of loop structure where the lcv *can* be modified. > The option is still there, its just that the standard "for" is something > safer and easier to optimize. :-) > > > It can be, but it can also be an inline function, or a simple > >call-through to the built in operator++, in both cases, any compiler > > Can it? In Ada at least, I understand that potentially dynamic-dispatching > operations are really tough to inline. I suppose there could be something > I don't know about C++ that gets rid of that issue. Is there? However, it is unlikely that any of the STL would be implemented as virtual functions (dynamic-dispatching as you call it). The STL are not abstract in any way, and have no need for virtual functions. > >worth it's salt would only use a single machine instruction (unless, of > > Well, that's easy to *say*. And, it's appearantly easy to *do* as most compilers do. > But if your compiler can't inline dispatching calls, and "++" is a > dispatching call, See above. Since the STL is defined completely in the header files (it must be, since it is made up of templates), *any* code from the STL could theoretically be inlined. > then it won't get inlined, and you will have procedure call overhead for > every increment. This isn't an issue at all for Ada "for" loops, because > the incrementing is *implicit*. Well...to be truthful, you'd have the same > issue with Ada if you used some abstract tagged private type in a "while" > loop instead, which would be a direct translation of what you've done in > C++. No, it wouldn't, because there is nothing "abstract" about the STL classes. > But in Ada you don't need to do that just to get type safety. The > base types already have it (if you don't disable it). > > > > >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 is no different from what a decent C++ compiler would do. > > Quite true. The difference is that its much *easier* for an Ada compiler > to do this, becuse far more of the nessecary information is available to > the optimizer at compile time. For instance, its tough to fully unroll a > loop, if you don't know until runtime how many iterations it is going to > have. In your C example, It was a C++ example. There is a difference (and in this case, a *huge* difference) > there's no easy way the compiler could figure that out, as it is > determined by whether you modify "i" anywhere else in the body of the loop > (including potentially within called subprograms via an alias), and by the > implementation of that library "++" routine (which you could have even > overridden, for all it knows). No, you can't overload an operator that is already defined. I couldn't overload vector::iterator::operator++(), even if I wanted to. > None of this is an issue for an Ada compiler, because "i" *can't* be > (legally) modified at all. -- Clark S. Cox III clarkcox3@yahoo.com http://www.whereismyhead.com/clark/