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,8a402d78988bdf2b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-12-19 07:51:02 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!news-out.visi.com!petbe.visi.com!news.tele.dk!news.tele.dk!small.news.tele.dk!npeer.de.kpn-eurorings.net!rz.uni-karlsruhe.de!feed.news.schlund.de!schlund.de!news.online.de!not-for-mail From: "Ekkehard Morgenstern" Newsgroups: comp.lang.ada Subject: Re: [announcement] SYSAPI and SYSSVC for Windows Date: Fri, 19 Dec 2003 16:50:53 +0100 Organization: 1&1 Internet AG Message-ID: References: <1071846912.728815@master.nyc.kbcfp.com> NNTP-Posting-Host: p508c0c52.dip0.t-ipconnect.de Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: online.de 1071849061 7791 80.140.12.82 (19 Dec 2003 15:51:01 GMT) X-Complaints-To: abuse@einsundeins.com NNTP-Posting-Date: Fri, 19 Dec 2003 15:51:01 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Xref: archiver1.google.com comp.lang.ada:3559 Date: 2003-12-19T16:50:53+01:00 List-Id: "Hyman Rosen" wrote: > Ekkehard Morgenstern wrote: > > For example, in Ada I can simply use a limited type when I want to prevent > > assignment to it. In C++ I have to declare a private copy constructor and > > a private copy assignment, which makes no sense really, in a logical way. > > It makes a great deal of sense. You wish to prevent assignment, > and therefore you make the assignment operator inaccessible. If you are writing a lot of tiny classes that require two or three extra lines of declaration, then it can and will be extra cumbersome. In Ada, you just declare the type as limited and done with. Also, in C++ you cannot prevent derivation! Everybody can derive from your classes. > > And if I do want to support copying in C++, I have to write at least a > > copy constructor and a copy assignment for every class. > > No, you need to do this only when the default of memberwise-assignment > is not suitable. Which can, depending on the project, be a 100% of the cases. > That implies that class is holding onto some resource > that must not be shared (such as a pointer). Exactly. > It's easier and better to > push down the semantics of copying that shared resource into a class of > its own (generically known as a smart pointer) I used this since 1995, and called it "AutoPointer". It is still wrong to omit the declaration of a copy constructor or copy assignment, because someone could try to copy or assign the object being pointed to. So that only moves the problem. Also, if an AutoPointer is copied, it also has to copy the object it is point to, or at least update a reference counter. Work over work over work that really need not be. > instead of repeating the > code to copy it everywhere. That's BS anyway. You write a copy constructor / copy assignment only once for the class it affects. > If you find yourself creating assignment > operators and copy constructors for many classes then you are probably > designing them incorrectly. If you have a lot of objects that cannot be copied by default copy assignment, then you have to do that. Especially when all of the classes are independent from each other and held by pointers mostly. > > Template classes have nonsensical limitations > > I know of several limitations, none of them particularly nonsensical. > (Here are three: 1)Floating point template parameters 2)String literal > template parameters 3)Virtual template methods.) > What exactly do you mean by this? String literal template parameters could be very useful, for example. And floating-point template parameters as well, for numerics, for example. And template classes CAN have virtual methods, or are you referring to something else? > > (like no goto over initialization) are nonsensical > > What exactly would be the semantics of a goto over an initialization? > Do you think you can jump into the middle of a scope in Ada and bypass > the elaboration of the declarations of that scope? I haven't tried with Ada yet, but in C++, it seems nonsensical to disallow skipping a declaration block with goto, especially since you can simulate it using break / continue, where it works!! Going over an object instantiation could be implemented very easily by calling the initialization block(s) being skipped first, and then jumping to the target location. That's a no-brainer, really, requiring only little extra code in the compiler. > > To use exceptions in C++, I have to create a real exception class, > > while in Ada I can simply declare it, which greatly speeds up > > implementation of code supporting exceptions. > > So we have an Ada proponent bashing C++ for requiring more typing > (in both senses!)? In any case, the claim is false. In Ada one writes > Joe : exception; > raise Joe; > exception when Joe => ... > If you want the same thing in C++, you say > struct Joe { }; > throw Joe(); > try { ... } catch (Joe) { ... } That's similarly short, however, in practice you would pass parameters to the exception object in C++, and then the class declaration for the exception gets more complicated. Since in Ada that's not possible, Ada is shorter! ;) Also, in Ada, exceptions are clearly marked "exception". In C++, you can supply any object as an exception. > > Especially the concurrency aspects of Ada make it ideal as a systems > > programming and implementation language. > > Except that the Ada concurrency system isn't portable either, > except to people who know exactly what they're doing. For > example, scheduling may not be pre-emptive and doing I/O may > block all tasks. And it's not especially clear that you want > to use the concurrency features of a programming language in > an operating system, which after all is there to implement this > concurrency. Your latter statement is true for the core task switching kernel only. For all other parts of the OS, using the concurrency features of Ada can be beneficial. That portability thing is true also, since Ada does not define that tasking must be pre-emptive. However, for my own OS (DELOS) that will not matter since it'll be pre-emptive anyway (or, if operated on top of another OS, use the pre-emptive scheduler of that). My own version of Ada will be pre-emptive in any case. (I'll write an Ada compiler that generates virtual machine code for my OS, that will translate it to the host CPU format upon initialization) > > The whole OO stuff isn't really necessary for an OS. Abstraction (using types) > > and black-boxing (information hiding) is more important than proper OO > > inheritance schemes. > > What does "really necessary" mean? OO stuff is useful when it's > useful. Certainly driver interfaces tend to be chock full of tables > of function pointers, which suggests that they should be implemented > through inheritance. The simple forms of inheritance provided by Ada should be sufficient for that purpose. For my own OS, I will use a message-based driver system (probably using the task/entry scheme in Ada). In fact, I learnt about Ada only a couple of weeks ago. Before that, I wanted to create my own programming language for my OS, and then I realized that Ada 95 provides exactly what I wanted. :)