"Pavel Minayev" <evilone@omen.ru> wrote in message news:a6a8jv$quo$1@digitaldaemon.com...
> "Immanuel Scholz" <digitals-mars@kutzsche.net> wrote in message news:a6a72b$q9c$1@digitaldaemon.com...
> > Isn't it a disadvantage to loose the type safety provided by declaring something const? What was the reason for this decission?
> I don't really see much reason in it. In C++, the most obvious
> reason for const would be const references (const Object& foo),
> to allow passing of temporaries created in the process of type
> conversions. Since there are no such things in D, the need for
> const is not high.
> I'm sure Walter might add something to this... =)

My experience with const as a type modifier is it:

1) has confusing syntax & semantics
2) does not enable any better code to be generated (for various technical
reasons)
3) needs to be subverted anyway with "mutable"
4) adds a lot of complexity to overload resolution
5) causes declarations to be peppered with "const", reducing readability
6) I haven't seen any convincing data that using them reduces bugs
7) adds unreasonable complexity to the typing system

So, it is not in D.

const *is* useful as a storage class, as it:

1) enables compile time constant folding
2) enables data to be placed in ROM

So, D supports const as a storage class, not as a type modifier.

One consequence of this is, as Pavel pointed out, that class objects cannot be const, because class objects can only be created on the garbage collected heap.

"Richard Krehbiel" <rich@kastle.com> wrote in message news:a65rol$1aio$1@digitaldaemon.com...
> So - the way an object in D is built is:
> 1. Allocate the needed memory.
> 2. Copy a compiler-built static image, which includes the final vtbl
> pointer, into the new memory.
> 3. Call the constructor of the actual "outermost" instance type.
> 4. The instance's constructor calls superclass constructors at it's
> convenience.

Yes.

> This is philosophically different from C++, which believes it's wrong to touch the methods of a descendant object until it's superclass is fully constructed.  C++ calls constructors in the opposite order,
innermost-first.

The point is to enable the most derived constructor to completely control the construction of the base classes. I find the base class initialization syntax of C++ to be inflexible. If you've ever tried to call a base constructor with a non-trivial computation on its arguments, you know what I mean.


> Now, Walter says (unless I'm mistaken) that this is okay because there are never any uninitialized areas of storage.  All of A's and B's and C's
static
> constructors "happen" before any .this() is called.

Yes.

> Now, as a long-time C programmer, I'm willing to sacrifice some safety for power.  But frankly, I'm not seeing how this adds power.  If anyone can
come
> up with a concrete example that shows the power of calling base class methods before calling the base class constructor, I'd appreciate it.

Ok, here's an example:

    this(int a, int b, int c)
    {
        ... computation ...
        if (condition)
            super(a,b);
        else
            super(c,d);
    }

Or how about:

    this()
    {
            ... basic construction ...
    }

    this(int a)
    {
            this();        // do basic construction
            ... more advanced construction ...
    }

Neither can be done without some falderal in C++.

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C8698CB.61C5ECAC@deming-os.org...
>  I intended to replace
> Worker...but never realized how hard it would be :(

I've heard that some european laws make that very difficult <g>.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a659o0$12u2$1@digitaldaemon.com...
> I believe assertions on expressions with side effects are forbidden
> by the language, and the compiler should do its best to catch
> such things.

A probably more accurate statement would be that the assert expression must be written so that its removal or insertion has no effect on the proper operation of the program. Unfortunately, I see no way for the compiler to enforce this beyond trivial cases.

Writing good asserts and invariants is a learned skill, and I'm still learning it myself. I do know that the combination of asserts, invariants, and unittests have significantly speeded up my own production of quality code.

"Walter" <walter@digitalmars.com> wrote in message news:a6f0t2$2som$1@digitaldaemon.com...

> A probably more accurate statement would be that the assert expression
must
> be written so that its removal or insertion has no effect on the proper operation of the program. Unfortunately, I see no way for the compiler to enforce this beyond trivial cases.

At least it should forbid assignments and function calls there.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a6f11t$2sp1$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:a6f0t2$2som$1@digitaldaemon.com...
>
> > A probably more accurate statement would be that the assert expression
> must
> > be written so that its removal or insertion has no effect on the proper operation of the program. Unfortunately, I see no way for the compiler
to
> > enforce this beyond trivial cases.
>
> At least it should forbid assignments and function calls there.

I have many function calls in my own asserts (like IsEmpty(...),
Initialized(),
and so on).

I suggest you can call only _const_ functions :-)

Ciao

"Roberto Mariottini" <rmariottini@lycosmail.com> wrote in message news:a6ido2$1agt$1@digitaldaemon.com...

> I suggest you can call only _const_ functions :-)

There are no const functions...

"Walter" <walter@digitalmars.com> wrote in message news:a6dp5h$2e8g$1@digitaldaemon.com...
>
> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C8698CB.61C5ECAC@deming-os.org...
> >  I intended to replace
> > Worker...but never realized how hard it would be :(
>
> I've heard that some european laws make that very difficult <g>.
>
>

LOL!

:)  Especially Dutch labour laws  :)


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
__________________________________________
Remove _XYZ from my address when replying by mail