Re: [announcement] SYSAPI and SYSSVC for Windows

["Ekkehard Morgenstern" <ekkehard.morgenstern@onlinehome.de>]

"Hyman Rosen" <hyrosen@mail.com> wrote:
>      struct also_uncopyable
>      {
>          uncopyable u;
>      };

That's a really good idea! I haven't thought of that yet! 
(*hides in shame*) ;)

If "uncopyable" has zero members, it doesn't even affect structure 
layout. :)

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

OK. Noted! :)

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

Yeah, say, you have hundreds of classes that use pointers. 

Like,

    class X {
        A*     a;
        B*     b;
        C*     c;
        ...
    };

If the object needs to be copied, then you have to provide a copy 
constructor and copy assignment, right?

This is something that is elegantly solved in Ada with the access type.
You simply assign and Ada keeps track of the reference.

In C++, you either have to have your own reference counting scheme,
or do a full copy of all enclosed objects.

Or are there other ways to do that that I'm unaware of?

> > Work over work over work that really need not be.
> 
> I don't see it. Perhaps you have examples?

Like, the one I mentioned before. Don't you agree that with Ada access 
types, you have much less overhead than with C++?

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

But if all your classes depend on pointers, then you have to write
copy assignment and copy constructor for all of your classes,
no matter whether you use smart pointers.

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

For not permitting string literals or floating-point values in
templates, there's no excuse, really.

These values are not uncomparable per se, a distinct string constant
or a distinct floating-point value is still distinct.

In many compilers, template instantiation identifiers are strings
anyway, so that should really be no problem.

Ada for example permits variant records on those kinds of values, right? :)

> > And template classes CAN have virtual methods, or are you referring
> > to something else?
> 
> Template methods of a class cannot be virtual.

What is a "template method of a class" for you?

Something like

    class X {

        template <int a, int b> void func( ... );
    };

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

That's true. Break and Continue bypass _entire_ scopes. 

As in

    while (1) {
        int a = 5, b = 6;
        if ( cond ) break;
        int c = a + b;
        ...
    }
 
> > 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.

Yeah, now I can see what you mean.

Something like:

    while (1) {
        int a = 5, b = 6;
        if ( cond ) goto L;
        extern void prepare( int&, int& );
        prepare( a, b );
        int c = a + b;
    L:  func( c );
    }

In this case, "goto" would skip both the "prepare" call and the 
computation of "c".

But what about all the other cases in which that doesn't happen?

Like in:

    while (1) {
        int a = 5, b = 6;
        if ( cond ) goto L;
        int c = a + b;
        if ( c == 4711 ) break;
    L:  int d = b + 9;
        func( d );
    }

In this case, skipping the "c" computation block entirely wouldn't
matter at all. But still, C++ doesn't allow it.

Since the compiler knows the source code, it could decide on
an individual basis whether goto was legal.

Or there could be rules on how to handle the goto in such a case.
Like, all declarations are moved to the beginning of the scope
by the compiler if a goto is used inside a scope block. 

Or some other rule.

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

Well, if I complete mine, it'll not be the only one! :)
 
> > 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."

LOL!! :)

It's true, my Ada compiler is still vaporware. But I've written
some compilers already for other languages, so it's not entirely ruled
out. :)

I've also written various compiler-compiler toolkits, and I plan to
use one of these or a new Ada one for my new Ada compiler.

(I think writing my own will be quicker than making an existing one
do what I want)

My Ada development-system will have its own database engine and hence
project management will be a piece of cake. Plus, it will probably be
freeware or shareware or open-source.

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

The programming language isn't what matters. All that matters is the
OS concept itself, whether it will be successful.

Since my project (DELOS) is only my own endeavour so far, I don't think
it'll have any impact on the software industry. For what it's worth,
even if it's just satisfying my own curiousity and ideas, it might 
serve as an example on how to implement such a system.

If it takes me another couple of years, the software industry will
have overtaken me anyway (unless of course I continue updating its
design).

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

Well, you'd be surprised how fast I learn. ;)

I bought the book "Programming in Ada 95" (2nd ed.) by Barnes,
and it arrived a couple of days ago, and I'll have to do a lot of 
reading. It's a marvellous book btw, ideal for people like me who
want to get an in-depth look at Ada. :)

I had already designed my own language(s) with constrained data types
and stuff. But if Ada works for my project, I don't need a different
language, and Ada is well-known already.

Some of Ada's concepts seemed weird to me at first, but they do
indeed make sense after you let them seep in deeply enough. ;)

Perhaps I'll ask those AdaOS guys what they're doing, perhaps we
can combine our concepts. :)