Re: [announcement] SYSAPI and SYSSVC for Windows

[Hyman Rosen <hyrosen@mail.com>]

Ekkehard Morgenstern wrote:
> 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.

If those classes contain an unassignable member (and if they don't,
why do you need to prevent assignment of the containing class?), then
using the default assignment operator and copy constructor is not
legal, and will be flagged as a compile-time error. You don't need
any extra declarations.
     struct uncopyable
     {
         uncopyable() { }
     private:
         uncopyable(const uncopyable &);
         uncopyable &operator=(const uncopyable &);
     };

     struct also_uncopyable
     {
         uncopyable u;
     };

> Also, in C++ you cannot prevent derivation!
 > Everybody can derive from your classes.

False. Using the following idiom, no class can be derived from Joe.
     class JoeF { friend class Joe; JoeF() { } };
     class Joe : virtual JoeFinalizer { ... };

> 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.

Huh? If you omit declaring your own, you get the language-specified
default ones, and then attempts to use them will cause compilation
errors, just as you want. Perhaps you have an example which you think
demonstrates the issue?

> 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.

Well, of course. If you actually want to have the item copied in some
fashion defined for the particular object, you must do the work! But
the point is that you only have to do this work in one place,, and if
you want it to be uncopyable, that only has to be done in one place too.

> Work over work over work that really need not be.

I don't see it. Perhaps you have examples?

> That's BS anyway. You write a copy constructor / copy assignment only
> once for the class it affects.

My point is that, done correctly, you can write this zero times
instead of one time.

> 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.

Those objects should be held by smart pointers, and only the
smart pointers need to implement the assignment operator and
copy constructor. The holding classes will then use these
operations without having to mention them explicitly.

> String literal template parameters could be very useful, for example.
> And floating-point template parameters as well, for numerics, for example.

There's no argument that they can be useful, but the restrictions
are not "nonsensical". There are valid reasons for them, even if
it's possible to envision the restrictions being lifted.

> And template classes CAN have virtual methods, or are you referring
> to something else?

Template methods of a class cannot be virtual.

> 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!!

I don't know what you think you can do, but you are wrong.
You cannot ever bypass the initialization of objects in a
scope, except by bypassing that scope entirely. Care to post
examples?

> 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.

No, because declarations can appear anywhere in a block,
and initialization can therefore depend on other things
computed earlier.

> Since in Ada that's not possible, Ada is shorter! ;)

No comment.

> 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.

I anxiously await AdaOS which will demonstrate this.

> I'll write an Ada compiler

Yeah, you and Nick Roberts. Your vaporware does not constitute
evidence in the debate of programming language suitability.

In the New York City subway system there's currently a sequence of
ads running for the School of Visual Arts making fun of people who
say things like "Is his art better than the stuff I'm always talking
about doing?" and "She's much too prolific to be any good."

Windows, Unix, and Linux are all wildly successful operating systems
and are written in C and C++. I disregard all claims that Ada can do
as well or better until I actually see an operating system written in
Ada doing as well or better.

> 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. :)

Sigh.