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: 109fba,582dff0b3f065a52 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-08-09 15:53:57 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!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++ 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> <1exve0j.1lboe8gneysd0N%clarkcox3@yahoo.com> User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.2.17-21mdksecure (i686)) Date: Thu, 9 Aug 2001 21:23:39 +0200 Message-ID: NNTP-Posting-Host: 194.78.202.248 X-Trace: 997397636 reader0.news.skynet.be 54315 194.78.202.248 X-Complaints-To: abuse@skynet.be Xref: archiver1.google.com comp.lang.ada:11719 comp.lang.c++:81389 Date: 2001-08-09T21:23:39+02:00 List-Id: Ted Dennison wrote: > 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? In C++ the programmer explicitly tells the compiler if a member function needs to be dynamically-dispatchable. (virtual). Overloaded operators however are never dynamically-dispatchable. And anyway, even if we didn't use the pre-increment operator but our own do_incr() member which we did make virtual, dynamic- dispatch wouldn't be applicable since the control variable is not a pointer to an object or a reference but an object. In that case runtime type = compiletime type and hence the compiler knows which member to call. > Well, that's easy to *say*. But if your compiler can't inline dispatching calls, > and "++" is a dispatching call, 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 Well, it is easy to *say* if you know how it works. There is no dynamic dispatch here and thus inlining is perfectly possible. > "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++. 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). Exactly for cases as this, you can put implementations of potentially inlineable members in the headers. That way the compiler has seen all information it needs to easily decide when (and how) to inline. > 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 There is no question that writing a good optimizing C++ compiler is a VERY difficult task. Some come close but none are optimal. However, this is one of the easier cases to optimize. You are not doing your case any good by insisting that this might be a problem in the real world. There are a lot of things which are a lot harder and where a critique for C++ as a difficult to optimize language is much more appropriate. > at compile time. For instance, its tough to fully unroll a loop, if you don't Given modern CPU's it is actually a loss to agressively unroll or inline. ichache pressure and such does that to you. In a lot of cases a missed cache hit is much more costly than a simple, easy to branch predict call. cu bart -- http://www.irule.be/bvh/