"Sean L. Palmer" <spalmer@iname.com> wrote in message news:9r1s8a$2fbv$1@digitaldaemon.com...
> If you have a class
>
> class A
> {
>   this() { ... }
>   ~this() { ... }
> }
>
> Is a struct that contains one of these possible?
>
> struct S
> {
>   A a;
> }
>
> If so, that makes structs have implicit destructors.

What happens is that the "A a;" creates a reference to an A, not an instance of A. So, no implicit destructors are required.

Something I'm really going to miss I think in D is guaranteed order of destruction.  I oftentimes use a class as a convenient way to automatically run ctor and dtor code for initialization and cleanup.  I have to use smart pointer classes to get that, but it's worth it.  In D order of destruction cannot be guaranteed at all.  Maybe I'll get used to it... calling explicit Init and Exit functions instead of ctors/dtors etc.  But it sure was nice to have all that cleanup work done automatically by the compiler, especially what with exceptions going off and everything, you don't have to put as much work into each function exit point because you know the state of the system will be consistent at each step.

An automated refcounting system could do that.  I don't think GC every will be able to reliably give me that.  And I have many other resources to worry about than just memory.

I'd hate for D to make this kind of thing worse instead of better.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:9vf5q9$cq4$1@digitaldaemon.com...
>
> "Sean L. Palmer" <spalmer@iname.com> wrote in message news:9r1s8a$2fbv$1@digitaldaemon.com...
> > If you have a class
> >
> > class A
> > {
> >   this() { ... }
> >   ~this() { ... }
> > }
> >
> > Is a struct that contains one of these possible?
> >
> > struct S
> > {
> >   A a;
> > }
> >
> > If so, that makes structs have implicit destructors.
>
> What happens is that the "A a;" creates a reference to an A, not an
instance
> of A. So, no implicit destructors are required.
>
>

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:9vfc86$g7k$1@digitaldaemon.com...

> Something I'm really going to miss I think in D is guaranteed order of destruction.  I oftentimes use a class as a convenient way to
automatically
> run ctor and dtor code for initialization and cleanup.  I have to use
smart
> pointer classes to get that, but it's worth it.  In D order of destruction cannot be guaranteed at all.  Maybe I'll get used to it... calling
explicit
> Init and Exit functions instead of ctors/dtors etc.  But it sure was nice
to
> have all that cleanup work done automatically by the compiler, especially what with exceptions going off and everything, you don't have to put as
much
> work into each function exit point because you know the state of the
system
> will be consistent at each step.

Don't forget about static constructors/destructors. They do exactly what you want, and the latest spec (one with the alpha) defines strict order of their execution:

"The order of static initialization is implicitly determined by the import declarations in each module. Each module is assumed to depend on any imported modules being statically constructed first. Other than following that rule, there is no imposed order on executing the module static constructors."

Since static constructors for modules you depend on are always called first, it should be exactly what's needed to initialize a module.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:9vfhhd$j5q$1@digitaldaemon.com...
> Don't forget about static constructors/destructors. They do exactly what you want, and the latest spec (one with the alpha) defines strict order of their execution:
>
> "The order of static initialization is implicitly determined by the import declarations in each module. Each module is assumed to depend on any imported modules being statically constructed first. Other than following that rule, there is no imposed order on executing the module static constructors."
>
> Since static constructors for modules you depend on are always called first, it should be exactly what's needed to initialize a module.

At first I had thought that this problem could not be solved, as I was too stuck in a rut thinking about them the C++ #include way. Then I realized the solution was staring me in the face <g> and the implementation almost wrote itself.

One irritant about C++ (for me) was that in order to even have a module constructor, I had to wrap it in a dummy class and then create a static instance of that class. In D, I can just write what is intended - "run this code on startup, and this code on termination".

"Walter" <walter@digitalmars.com> wrote in message news:9vg29o$s9o$2@digitaldaemon.com...

> One irritant about C++ (for me) was that in order to even have a module constructor, I had to wrap it in a dummy class and then create a static instance of that class. In D, I can just write what is intended - "run
this
> code on startup, and this code on termination".

Now the question is, is it possible to run it without any class
at all? As far as I could understand from the docs, constructors -
even static - can only reside in classes. So your statement about
"wrapping it in a dummy class" still applies. Didn't you consider
enabling module-level constructors & finalizers - say, two _global_
functions called this() and ~this(), for consistency. Or maybe
initialization() & finalization(), as seen in Delphi. Whatever,
it would be just cool.


P.S. I want more bugs - give me a new alpha! =)

"Pavel Minayev" <evilone@omen.ru> wrote in message news:9vg3rr$sue$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:9vg29o$s9o$2@digitaldaemon.com...
> > One irritant about C++ (for me) was that in order to even have a module constructor, I had to wrap it in a dummy class and then create a static instance of that class. In D, I can just write what is intended - "run
> this
> > code on startup, and this code on termination".
> Now the question is, is it possible to run it without any class at all?

Yes! Just call them "static  this() { }" and "static ~this() { }" at the
module level.

> P.S. I want more bugs - give me a new alpha! =)

I'm working on it. I took some time off to put out 8.25 of the C++ compiler, basically an accumulation of various fixes.

----- Original Message -----
From: "Walter" <walter@digitalmars.com>
Newsgroups: D
Sent: Saturday, December 15, 2001 11:35 PM
Subject: Re: D vs. LX - Exceptions


> Yes! Just call them "static  this() { }" and "static ~this() { }" at the
> module level.

And what if I omit "static"?

You should get an error message.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:9vgd4n$12as$1@digitaldaemon.com...
> ----- Original Message -----
> From: "Walter" <walter@digitalmars.com>
> Newsgroups: D
> Sent: Saturday, December 15, 2001 11:35 PM
> Subject: Re: D vs. LX - Exceptions
>
>
> > Yes! Just call them "static  this() { }" and "static ~this() { }" at the
> > module level.
>
> And what if I omit "static"?
>
>
>
>

"Walter" <walter@digitalmars.com> wrote in message news:9vglbk$16vc$1@digitaldaemon.com...

> You should get an error message.

Then why "static" is needed, since there are no non-static module constructors?

"Pavel Minayev" <evilone@omen.ru> wrote in message news:9vhkt5$1pfv$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:9vglbk$16vc$1@digitaldaemon.com...
>
> > You should get an error message.
>
> Then why "static" is needed, since there are no non-static module constructors?

For consistency with the way they are defined for classes.