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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1014db,582dff0b3f065a52 X-Google-Attributes: gid1014db,public 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-07 22:31:54 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!newsfeed.berkeley.edu!news-hog.berkeley.edu!ucberkeley!enews.sgi.com!newshub2.rdc1.sfba.home.com!news.home.com!news1.rdc1.bc.home.com.POSTED!not-for-mail From: kaz@ashi.footprints.net (Kaz Kylheku) Newsgroups: comp.lang.ada,comp.lang.c++,comp.lang.c Subject: Re: How Ada could have prevented the Red Code distributed denial of service attack. References: <3b690498.1111845720@news.worldonline.nl> <9kbu15$9bj@augusta.math.psu.edu> <3b6a453c.1193942215@news.worldonline.nl> <9keejl$fhj@augusta.math.psu.edu> <3c30da40.0108060848.796d9bd9@posting.google.com> <3B6F3216.F410BBFF@home.com> <3B6F3FAE.B9B9FFCF@globetrotter.qc.ca> <3B6F5BB2.A879B933@worldnet.att.net> <3B7077A3.77D2BBE5@globetrotter.qc.ca> <3B70C621.DC9A8F35@worldnet.att.net> Organization: Psycho-Neurotic Institute for the Very, Very Nervous Reply-To: kaz@ashi.footprints.net User-Agent: slrn/0.9.6.3 (Linux) Message-ID: Date: Wed, 08 Aug 2001 05:31:53 GMT NNTP-Posting-Host: 24.68.85.82 X-Complaints-To: abuse@home.net X-Trace: news1.rdc1.bc.home.com 997248713 24.68.85.82 (Tue, 07 Aug 2001 22:31:53 PDT) NNTP-Posting-Date: Tue, 07 Aug 2001 22:31:53 PDT Xref: archiver1.google.com comp.lang.ada:11580 comp.lang.c++:80860 comp.lang.c:72834 Date: 2001-08-08T05:31:53+00:00 List-Id: In article <3B70C621.DC9A8F35@worldnet.att.net>, James Rogers wrote: >Chris Wolfe wrote: >> >> So you are sort of correct, there are some features of Ada that >> would require minor changes to the 'default' C++ compiler >> behaviors to provide with the same level of hand-holding provided >> by Ada. I have already encountered compilers that do most of >> these, and I would bet that the rest have been implemented >> somewhere. > >And none of these extensions are actually standard C++. They are not >part of the standard or the standard libraries. If some platform was only targetted by an Ada compiler that was missing some diagnostic features, would take the high road, and not compile your programs for that platform, even if the compiler could translate and execute correct Ada programs? >This means that you >will need to re-implement them if you are forced to switch to another >compiler because you are porting your code to another system. Or you just leave the code the same and lose the diagnostic capabilities. You can still use the other compiler for diagnosing the code. You don't lose anything by porting. >Your example and explanation clearly convinces me that the C++ >effort to produce an equivalent to an Ada protected object >would require a significant effort. Standard Ada has multitasking built in, and standard C++ other doesn't. So writing a protected object does not require signficant effort in standard C++, but is simply impossible. >This is not an argument >against C++. This is merely an set of capabilities not yet >implemented as part of the C++ standard. Achieving similar >capabilities is difficult in most languages. Achieving things in languages is sometimes just paperwork. It wouldn't take much to define some standard C++ library for multithreading. The difficulty lies in implementations. If you add difficult things into languages, two things happen. They get implemented less, or sometimes they get implemented incompletely. We see this with C++: poor support for templates here and there, lack of support for exception handling here and there. Some things should be left to the open market, at least for a while. C++ was only standardized in 1998 for the first time. Thus far, there hasn't emerged a *de facto* standard library for multithreading that could serve as a candidate for becoming standard. So the C++ committee will perhaps have to invent one, (assuming they want to add multithreading). The problem with multithreading is that there are so many ways to hack it on a given platform. If you have standard threading, but C++ implementors cop out with lame implementations, nobody will want to use it. Or they will use it, but programs will only work well on a few quality implementations, in essence rendering the standard threading portable only on paper. Any decent C++ threading will have to interoperate nicely with a platform's ``native'' threading, because real-world C++ programs are rarely developed in a vacuum. People will do things like create threads using some platform-specific mechanism, and have it execute parts of the C++ program along side C++ threads --- kind of hard to avoid, for instance, if using some third party library which wants to invoke callbacks in your program, using its own threads.