www.digitalmars.com         C & C++   DMDScript  

D - RAII take 2

reply "Walter" <walter digitalmars.com> writes:
The 'auto' idea was looking more and more like a way to simply put class
objects on the stack. Ok, so I smack my forehead, and think why not allow
destructors for structs? This would provide the automatic destruction of
structs when they go out of scope. Some other properties talked about with
auto are implicit with structs:

1) they cannot be derived from or inherited
2) the 'auto' is implicit
3) can't implicitly convert to Object

Furthermore, to make things easier, the following can be disallowed:

1) arrays of structs with destructors
2) structs with destructors as class or struct fields
3) assignment of structs with destructors

A class can be 'auto-ized' by wrapping it in a struct:

    struct AutoA
    {    A a;
        ~this() { delete a; }
    }

and can even be templatized:

    template AutoClass(T)
    {
        T t;
        ~this() { delete t; }
    }
Aug 27 2002
next sibling parent reply Patrick Down <pat codemoon.com> writes:
"Walter" <walter digitalmars.com> wrote in
news:akgsaf$aog$1 digitaldaemon.com: 


 3) assignment of structs with destructors

struct Foo { ~this() { } } void Bar(Foo a) { } Foo a; Bar(a); // Is this allowed?
Aug 27 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Patrick Down" <pat codemoon.com> wrote in message
news:Xns9277B119511Bpatcodemooncom 63.105.9.61...
 "Walter" <walter digitalmars.com> wrote in
 news:akgsaf$aog$1 digitaldaemon.com:
 3) assignment of structs with destructors

{ ~this() { } } void Bar(Foo a) { } Foo a; Bar(a); // Is this allowed?

No. I should add that copy-initializers are not allowed, either.
Aug 27 2002
parent reply Patrick Down <pat codemoon.com> writes:
"Walter" <walter digitalmars.com> wrote in news:akh8id$p90$1
 digitaldaemon.com:

 
 "Patrick Down" <pat codemoon.com> wrote in message
 news:Xns9277B119511Bpatcodemooncom 63.105.9.61...
 "Walter" <walter digitalmars.com> wrote in
 news:akgsaf$aog$1 digitaldaemon.com:
 3) assignment of structs with destructors

{ ~this() { } } void Bar(Foo a) { } Foo a; Bar(a); // Is this allowed?

No. I should add that copy-initializers are not allowed, either.

With the previous method I could. auto fload = new File(name); LoadObjects(fload); Now it looks like I need to do this... instance AutoClass(File) AutoFile; AutoFile fload; fload.t = new File(name); LoadObjects(fload.t); If you put constructors on structs too then it could work like this. struct AutoFile { File f; this(char[] name) { f = new File(name); } ~this() { if(f) f.close(); } } Autofile fload(name); LoadObjects(fload.f);
Aug 27 2002
next sibling parent "Walter" <walter digitalmars.com> writes:
You're right. I know supporting struct constructors is an attractive notion,
but I'd like to try avoiding them for the moment.
Aug 28 2002
prev sibling parent "Sandor Hojtsy" <hojtsy index.hu> writes:
"Patrick Down" <pat codemoon.com> wrote in message
news:Xns927810D18195Dpatcodemooncom 63.105.9.61...
 "Walter" <walter digitalmars.com> wrote in news:akh8id$p90$1
  digitaldaemon.com:

 "Patrick Down" <pat codemoon.com> wrote in message
 news:Xns9277B119511Bpatcodemooncom 63.105.9.61...
 "Walter" <walter digitalmars.com> wrote in
 news:akgsaf$aog$1 digitaldaemon.com:
 3) assignment of structs with destructors

{ ~this() { } } void Bar(Foo a) { } Foo a; Bar(a); // Is this allowed?

No. I should add that copy-initializers are not allowed, either.

With the previous method I could. auto fload = new File(name); LoadObjects(fload);

Every problem can be solved by adding a level of indirection. auto fload = new File(name); LoadObjects(&fload); If File is a struct you should not pass it by value, but by address.
Aug 28 2002
prev sibling next sibling parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
That sounds like a fine plan.

I don't see how any of your second 3 points (to make things easier) would
seem daunting to someone like you who has implemented a C++ compiler or
three.  ;)

They seem like simple enough concepts.  What do you find so difficult about
it?  Seems templates and exceptions are far more of a challenge.

Sean

"Walter" <walter digitalmars.com> wrote in message
news:akgsaf$aog$1 digitaldaemon.com...
 The 'auto' idea was looking more and more like a way to simply put class
 objects on the stack. Ok, so I smack my forehead, and think why not allow
 destructors for structs? This would provide the automatic destruction of
 structs when they go out of scope. Some other properties talked about with
 auto are implicit with structs:

 1) they cannot be derived from or inherited
 2) the 'auto' is implicit
 3) can't implicitly convert to Object

 Furthermore, to make things easier, the following can be disallowed:

 1) arrays of structs with destructors
 2) structs with destructors as class or struct fields
 3) assignment of structs with destructors

 A class can be 'auto-ized' by wrapping it in a struct:

     struct AutoA
     {    A a;
         ~this() { delete a; }
     }

 and can even be templatized:

     template AutoClass(T)
     {
         T t;
         ~this() { delete t; }
     }

Aug 27 2002
parent "Walter" <walter digitalmars.com> writes:
Making them work is a substantial increase in the complexity of the
compiler, bugs in the compiler (!), attempting to explain to programmers all
the noise going on behind the scenes for something simple-appearing like
passing a struct value to a function, etc. It brings to the fore confusing
notions like the difference between assignment and initialization,
overloading assignment operators and copy constructors start becoming
necessary, etc.

In short, many things I was trying to leave behind <g>.

If the territory can be covered without needing that stuff, I sure want to
give it a try.
Aug 28 2002
prev sibling next sibling parent reply Patrick Down <pat codemoon.com> writes:
"Walter" <walter digitalmars.com> wrote in
news:akgsaf$aog$1 digitaldaemon.com: 

 The 'auto' idea was looking more and more like a way to simply put
 class objects on the stack. Ok, so I smack my forehead, and think why
 not allow destructors for structs? This would provide the automatic
 destruction of structs when they go out of scope. Some other
 properties talked about with auto are implicit with structs:
 
 1) they cannot be derived from or inherited
 2) the 'auto' is implicit
 3) can't implicitly convert to Object
 
 Furthermore, to make things easier, the following can be disallowed:
 
 1) arrays of structs with destructors
 2) structs with destructors as class or struct fields
 3) assignment of structs with destructors

I think I still like the auto idea better. With the struct solution it seems like you would end back at the old problem of having duplicate class and struct variants of the same objects. As you suggest we can wrap a class reference in a struct. However this just seems like a more complicated version of the auto keyword.
Aug 28 2002
parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Yes, my gut feeling is that the struct solution causes more problems than
it solves.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]
Aug 28 2002
prev sibling next sibling parent reply Mac Reiter <Mac_member pathlink.com> writes:
Let me start by saying that the struct solution would work for me.  I can't
resist the urge to ramble on, however.

Just for comment:

1. Since structs don't participate in inheritance, D already has variable types
that cannot participate in Stream solutions or solutions that leverage the
Object interface.  Which suggests that arguments against non-convertible
auto/scoped/counted classes can also be made against the structs that have been
there since day one...

2. Presence of a destructor will tend to make people wonder why there isn't a
constructor.  I know that the answer has to do with reducing complexity, but the
question will continue to come up.

3. This kinda pushes an implementation detail up into user cognitive space.
Prior to this suggestion, the major benefits of structs were alignment control
and lightweight allocation (stack).  Now the second benefit (stack) turns into
two benefits - lightweight allocation and scoping/d.o.f.  This feels slightly
wrong, somehow.

4. I know that the impetus for using struct this way would be to minimize the
marginal added complexity of d.o.f. behavior.  However, looking at the end
result, I kinda feel the same way I do when I look at the 'static' keyword in
C++ and have to stop and wonder if it is referring to a static thing or to a
file-scope-restricted thing.  Or when I look at the 'const' keyword and have to
stop and figure out if it is referring to the thing being constant, or claiming
that it is legal for the thing to be called on a constant instance (For C++
programmers that may not have seen the usage I am talking about: 'const' after a
member function declaration means that it is legal for a user to call that
member function if they have a constant instance of that class.  Functions
without this decoration cannot be called on a constant instance because the
function might change the state of the class, which would violate the const-ness
of the instance.  Of course, const functions can also change the state of the
instance, but they're not *supposed* to...)  (Sorry for the tangential rambling)


Having said all of that, I have been thinking about how to use RAII.v2.  Since
all classes derive (directly or indirectly) from Object, you could make:

struct Scoped
{
Object obj;
~this() {delete obj;}
}

and put that somewhere in Phobos.  Then, to scope something, I can just:

void MyFunc()
{
Scoped s;
s.obj = new MyClass;
// proceed willy-nilly
} // s.obj gets deleted here.

Since the scoping struct doesn't need any interface of the scoped object other
than Object, this polymorphism works, and can be done once and for all inside
the standard library.

I would like some form of initializer.  It would be great if we could use the
"static initializer" syntax from struct.html for non-static structs:

void MyFunc()
{
Scoped s = {obj:new MyClass};
// proceed willy-nilly
} // s.obj gets deleted here.

Actually, there are nicer (or at least easier to type/read) syntaxes for this,
but this would be consistent with existing language.

How bad would it be to allow initializer-only constructors for structs?  In C++,
a constructor can use an initializer list to store incoming parameters in data
members during creation.  Since that would be the only use for a struct
constructor anyway, initializer-only constructors should be sufficient for
anything anyone needs in a struct (more complicated stuff gets done in a class,
like it should).  This would make the syntax something more like:

struct Scoped
{
Object obj;
this(Object o) : obj(o); // or pick a better syntax, this is "like" C++
~this() {delete obj;}
}

void MyFunc()
{
Scoped s(new MyClass);
// proceed willy-nilly
} // s.obj gets deleted here.

I don't know if limiting the nature of the constructor helps any or not.  An
initializer-based constructor may cause just as many problems as a full-fledged
constructor.

Mac
Aug 28 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Mac Reiter" <Mac_member pathlink.com> wrote in message
news:akj7dl$nc$1 digitaldaemon.com...
 1. Since structs don't participate in inheritance, D already has variable

 that cannot participate in Stream solutions or solutions that leverage the
 Object interface.  Which suggests that arguments against non-convertible
 auto/scoped/counted classes can also be made against the structs that have

 there since day one...

Yes, but with this scheme there are only 2 kinds of objects instead of 3.
 2. Presence of a destructor will tend to make people wonder why there

 constructor.  I know that the answer has to do with reducing complexity,

 question will continue to come up.

You're right. We'll have to see how this goes.
 3. This kinda pushes an implementation detail up into user cognitive

 Prior to this suggestion, the major benefits of structs were alignment

 and lightweight allocation (stack).  Now the second benefit (stack) turns

 two benefits - lightweight allocation and scoping/d.o.f.  This feels

 wrong, somehow.

It seems natural to me <g>.
 4. I know that the impetus for using struct this way would be to minimize

 marginal added complexity of d.o.f. behavior.  However, looking at the end
 result, I kinda feel the same way I do when I look at the 'static' keyword

 C++ and have to stop and wonder if it is referring to a static thing or to

 file-scope-restricted thing.  Or when I look at the 'const' keyword and

 stop and figure out if it is referring to the thing being constant, or

 that it is legal for the thing to be called on a constant instance

Structs were already scoped, they just didn't have destructors.
 Having said all of that, I have been thinking about how to use RAII.v2.

 all classes derive (directly or indirectly) from Object, you could make:

 struct Scoped
 {
 Object obj;
 ~this() {delete obj;}
 }

 and put that somewhere in Phobos.  Then, to scope something, I can just:

 void MyFunc()
 {
 Scoped s;
 s.obj = new MyClass;
 // proceed willy-nilly
 } // s.obj gets deleted here.

 Since the scoping struct doesn't need any interface of the scoped object

 than Object, this polymorphism works, and can be done once and for all

 the standard library.

Yes, although Scoped can be made a template.
 I would like some form of initializer.  It would be great if we could use

 "static initializer" syntax from struct.html for non-static structs:

 void MyFunc()
 {
 Scoped s = {obj:new MyClass};
 // proceed willy-nilly
 } // s.obj gets deleted here.

 Actually, there are nicer (or at least easier to type/read) syntaxes for

 but this would be consistent with existing language.

Yes.
 How bad would it be to allow initializer-only constructors for structs?

 a constructor can use an initializer list to store incoming parameters in

 members during creation.  Since that would be the only use for a struct
 constructor anyway, initializer-only constructors should be sufficient for
 anything anyone needs in a struct (more complicated stuff gets done in a

 like it should).  This would make the syntax something more like:

 struct Scoped
 {
 Object obj;
 this(Object o) : obj(o); // or pick a better syntax, this is "like" C++
 ~this() {delete obj;}
 }

 void MyFunc()
 {
 Scoped s(new MyClass);
 // proceed willy-nilly
 } // s.obj gets deleted here.

 I don't know if limiting the nature of the constructor helps any or not.

 initializer-based constructor may cause just as many problems as a

 constructor.

Initializer lists are a bug in C++ <g>.
Aug 28 2002
next sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:

 "Mac Reiter" <Mac_member pathlink.com> wrote in message
 news:akj7dl$nc$1 digitaldaemon.com...
 1. Since structs don't participate in inheritance, D already has variable

 that cannot participate in Stream solutions or solutions that leverage the
 Object interface.  Which suggests that arguments against non-convertible
 auto/scoped/counted classes can also be made against the structs that have

 there since day one...

Yes, but with this scheme there are only 2 kinds of objects instead of 3.

I think that that is an argument FOR the other style. As I see it, there are (at least) three types of usage: * struct (pure data map) * garbage collected class (arbitrary lifespan) * raii class (d.o.f.) Those 3 should be well distinguished. -- The Villagers are Online! villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
Aug 28 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D6D4905.4BAF1C5C deming-os.org...
 I think that that is an argument FOR the other style.  As I see it, there

 (at least) three types of usage:
 * struct (pure data map)
 * garbage collected class (arbitrary lifespan)
 * raii class (d.o.f.)

 Those 3 should be well distinguished.

They are: 1) struct 2) class 3) struct with destructor The distinction between 1 and 3 should be comfortable for anyone used to destructors in C++.
Aug 28 2002
next sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:

 They are:
 1) struct
 2) class
 3) struct with destructor

 The distinction between 1 and 3 should be comfortable for anyone used to
 destructors in C++.

I hear you, but (from my perspective), the key difference between a struct and a class is not the stack/heap question, but the active/inactive and binary layout issues. As I think of them, a struct is a primarily a binary layout mechanism - its purpose is to give a portable, definable, C-interoperable design for the data. That it can be laid out on the stack is very much secondary in that view. Since it is primarily a binary layout mechanism, it is an "inactive" mechanism - it doesn't contain any virtualization or implicit code (constructors and destructors are implicit code, since they run without us explicitly calling them). Member functions of structs, IMHO, are just (good) syntax sugar - they simply serve to encapsulate common operations on the structure. A class, on the other hand, is fundamentally an active mechanism. It has implicit code (constructors, destructors, operator overloading, etc.) and does a lot of virtualization. It explicitly does NOT allow you to define binary layout. In this view, an active property of the object (raii) fits far better with a class than a struct. -- The Villagers are Online! villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
Aug 29 2002
next sibling parent "Walter" <walter digitalmars.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D6E5614.E9ACCEE9 deming-os.org...
 Walter wrote:

 They are:
 1) struct
 2) class
 3) struct with destructor

 The distinction between 1 and 3 should be comfortable for anyone used to
 destructors in C++.

I hear you, but (from my perspective), the key difference between a struct

 a class is not the stack/heap question, but the active/inactive and binary
 layout issues.

 As I think of them, a struct is a primarily a binary layout mechanism -

 purpose is to give a portable, definable, C-interoperable design for the

 That it can be laid out on the stack is very much secondary in that view.
 Since it is primarily a binary layout mechanism, it is an "inactive"

 - it doesn't contain any virtualization or implicit code (constructors and
 destructors are implicit code, since they run without us explicitly

 them).  Member functions of structs, IMHO, are just (good) syntax sugar -

 simply serve to encapsulate common operations on the structure.

 A class, on the other hand, is fundamentally an active mechanism.  It has
 implicit code (constructors, destructors, operator overloading, etc.) and

 a lot of virtualization.  It explicitly does NOT allow you to define

 layout.

 In this view, an active property of the object (raii) fits far better with

 class than a struct.

A struct also provides a mechanism for lightweight objects intended to be on the stack. (The absense of these is a large burden in Java.) Providing a destructor for raii is a natural extension of that.
Aug 29 2002
prev sibling parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
If I had a choice, I'd *much* rather have operator overloading for structs
than for classes.  I guess for both wouldn't hurt.

And I'd prefer if the stack allocation policy be explicit in the spec.
Although I suppose arrays of structs and very large structs can come from
the heap if necessary.

I don't know what everybody's problem with implicit code is.  Every function
ever compiled comes with hidden entry and exit code.  A lot of stuff goes on
behind the scenes that most people never know about, even in C.  The chance
to contribute to that general madness can make alot of programming tasks a
lot easier.

If I can't get the compiler to write my program for me, at least I should be
able to get it to do a good portion of the redundant grunt work.  ;)

Sean

"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D6E5614.E9ACCEE9 deming-os.org...
 Walter wrote:

 They are:
 1) struct
 2) class
 3) struct with destructor

 The distinction between 1 and 3 should be comfortable for anyone used to
 destructors in C++.

I hear you, but (from my perspective), the key difference between a struct

 a class is not the stack/heap question, but the active/inactive and binary
 layout issues.

 As I think of them, a struct is a primarily a binary layout mechanism -

 purpose is to give a portable, definable, C-interoperable design for the

 That it can be laid out on the stack is very much secondary in that view.
 Since it is primarily a binary layout mechanism, it is an "inactive"

 - it doesn't contain any virtualization or implicit code (constructors and
 destructors are implicit code, since they run without us explicitly

 them).  Member functions of structs, IMHO, are just (good) syntax sugar -

 simply serve to encapsulate common operations on the structure.

 A class, on the other hand, is fundamentally an active mechanism.  It has
 implicit code (constructors, destructors, operator overloading, etc.) and

 a lot of virtualization.  It explicitly does NOT allow you to define

 layout.

 In this view, an active property of the object (raii) fits far better with

 class than a struct.

 --
 The Villagers are Online! villagersonline.com

 .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
 .[ (a version.of(English).(precise.more)) is(possible) ]
 ?[ you want.to(help(develop(it))) ]

Aug 30 2002
parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
"Sean L. Palmer" wrote:

 If I had a choice, I'd *much* rather have operator overloading for structs
 than for classes.  I guess for both wouldn't hurt.

 And I'd prefer if the stack allocation policy be explicit in the spec.
 Although I suppose arrays of structs and very large structs can come from
 the heap if necessary.

 I don't know what everybody's problem with implicit code is.  Every function
 ever compiled comes with hidden entry and exit code.  A lot of stuff goes on
 behind the scenes that most people never know about, even in C.  The chance
 to contribute to that general madness can make alot of programming tasks a
 lot easier.

 If I can't get the compiler to write my program for me, at least I should be
 able to get it to do a good portion of the redundant grunt work.  ;)

Amen. I'm not against having the compiler insert implicit code - in fact, I'm generally very much in favor of it. But if we make structs too much like classes, then why do we have two types at all? Either unify them in one program element, or give them noticable (useful) differences. -- The Villagers are Online! villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
Sep 04 2002
prev sibling parent reply "Sandor Hojtsy" <hojtsy index.hu> writes:
"Walter" <walter digitalmars.com> wrote in message
news:akjm07$urk$1 digitaldaemon.com...
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3D6D4905.4BAF1C5C deming-os.org...
 I think that that is an argument FOR the other style.  As I see it,


 are
 (at least) three types of usage:
 * struct (pure data map)
 * garbage collected class (arbitrary lifespan)
 * raii class (d.o.f.)

 Those 3 should be well distinguished.

They are: 1) struct 2) class 3) struct with destructor The distinction between 1 and 3 should be comfortable for anyone used to destructors in C++.

I have used C++ destructors for a few years now. I usually think of (1) as a struct with an empty destructor. So the list becomes: 1) struct with empty destructor 2) class 3) struct with non-empty destructor Now that distinction between raii and non-raii is not clear enough for me. The problem is that you want to pass raii objects into other functions before releasing them. With structs that is quite uncomfortable. I think we should pick the example of a File, find a solution, and that solution will be OK for every other raii object. Struct destructors, (and constructors) are usefull on their own right, and they should be implemented, but using them for raii, means or requires workarounds. Please do not force workarounds in or with the language. As I have already written raii is the property of the class not of the instance. BUT: It doesn't mean I want every reference to a raii object to release the instance! Only the OWNER reference: void foo() { owner File f = new File(); f.doSomething(); bar(f); } void bar(File f2) { ... } So the when the "f" reference is "lost", the instance is deleted. But not with the "f2" reference. Yes I realize that this is exactly the same that was suggested by Walter the first time, but with another keyword (raii). I also would like to point out that this is almost the same as constructing a wrapper struct with a destructor at "f", and passing the wrapped reference to "bar". See the same with desturcted struct : void foo { instance RaiiWrapper(File).RaiiWrapper fw; fw.f = new File(); fw.f.doSomething(); bar(fw.f); } Which one do you like better? What you see is unneccessary indirection in the source code and the binary too. Not talking about the wrapper contruct which is hard to read out. So please return to the original idea. Use a keyword to signal that a certain reference is owner of the instance. If operator overloading would be <Sigh> nice enough (dot operator, cast overloading, struct constructors), you could make a transparent wrapper struct here. That way source code complexity would match the first example. But binary code will be still a bit slower. Please don't say: that way referenced instances can be deleted. Yes, but with structs there are the same problem if you store the address of a struct. Or the wrapped reference. Either way this has to be left to the programmers good will. Future plans: 1) References stored inside class members can be owners too. This should mean, that after the finalyzer of a class runs, owned instances should be deleted. Seems easy to me. 2) Ownership can be made transferable. (implementation problems) 3) Asignment to an owner reference should delete the old instance. (implementation problems) For the 3) problem I propose a solution. If owner references are a separate "type" from normal references, the compiler could generate special code when assigment to an owner reference happens. For 2) you need a special field in each reference, and complex code for each assignment to any reference. I don't see an elegant solution for this. Yours, Sandor
Sep 02 2002
parent Pavel Minayev <evilone omen.ru> writes:
"Sandor Hojtsy" <hojtsy index.hu> wrote in
news:akva29$2uju$1 digitaldaemon.com: 

 Now that distinction between raii and non-raii is not clear enough for
 me. 
 
 The problem is that you want to pass raii objects into other functions
 before releasing them. With structs that is quite uncomfortable.
 I think we should pick the example of a File, find a solution, and
 that solution will be OK for every other raii object.
 
 Struct destructors, (and constructors) are usefull on their own right,
 and they should be implemented, but using them for raii, means or
 requires workarounds. Please do not force workarounds in or with the
 language. As I have already written raii is the property of the class

I wholeheartedly agree. Using structs for raii is not very practical, since we actually want _classes_ to be such.
Sep 02 2002
prev sibling parent reply "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> writes:
Hi,

"Walter" <walter digitalmars.com> wrote in message
news:akjh94$k4g$1 digitaldaemon.com...
 2. Presence of a destructor will tend to make people wonder why there
 isn't a constructor.


Constructors are nice, but not really that important. They do not offer functionality, that could not be realized using regular methods. Destructors, on the other hand, are a gift to man-kind. Deterministic destructors makes them even more so. Concentrating on destructors first seems very right to me. I have a thought about constructors, though: A new object is often created like this: SomeClass a = new SomeClass(args); You wrote yourself sometime ago, that it was clumsy. I agree. How about: SomeClass a(args); meaning that if an argument list was present, it was to be instantiated, and the constructor called. The argument list could be omitted like today like this: SomeClass a; // initialized to null The destinction between null initialization and initialization using a constructor without arguments would be: SomeClass a; // null SomeClass a(); // allocates new object and initializes it using this() The existing syntax would still have to be supported in cases like this: SomeClass a = new DerivedClass(args); Regards, Martin M. Pedersen
Aug 28 2002
next sibling parent reply "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> writes:
Hi,

"Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
news:akjir7$ns6$1 digitaldaemon.com...
    SomeClass a(); // allocates new object and initializes it using this()

I might add, that this might conflict with prototypes as we know them from C. However, prototypes belongs at global scope, object instantiation do not. So, there does not need to be a conflict. Regards, Martin M. Pedersen
Aug 28 2002
parent "Walter" <walter digitalmars.com> writes:
"Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
news:akjj57$odk$1 digitaldaemon.com...
 "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
 news:akjir7$ns6$1 digitaldaemon.com...
    SomeClass a(); // allocates new object and initializes it using


 I might add, that this might conflict with prototypes as we know them from
 C. However, prototypes belongs at global scope, object instantiation do

 So, there does not need to be a conflict.

You're right, but it would be better if the syntax for constructors was unique without relying on scope context. In C++, as things got added to the language, fairly simple ambiguity problems just got worse and worse. It's so bad now that even if the compiler parses it correctly, it is unable to generate a reasonable error message for any goofs. Syntactical redundancy is the key to being able to generate good error diagnostics.
Aug 28 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
news:akjir7$ns6$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:akjh94$k4g$1 digitaldaemon.com...
 2. Presence of a destructor will tend to make people wonder why there
 isn't a constructor.


functionality, that could not be realized using regular methods.

I agree. Also, constructors for stack objects have wretched parsing ambiguity problems. (Is it a declaration? Is it a function call? Is it a bird? Is it a plane? <g>)
 Destructors, on the other hand, are a gift to man-kind. Deterministic
 destructors makes them even more so. Concentrating on destructors first
 seems very right to me.

Yes.
 I have a thought about constructors, though:
 A new object is often created like this:
     SomeClass a = new SomeClass(args);
 You wrote yourself sometime ago, that it was clumsy. I agree. How about:
    SomeClass a(args);
 meaning that if an argument list was present, it was to be instantiated,

 the constructor called. The argument list could be omitted like today like
 this:
    SomeClass a; // initialized to null
 The destinction between null initialization and initialization using a
 constructor without arguments would be:
    SomeClass a; // null
    SomeClass a(); // allocates new object and initializes it using this()
 The existing syntax would still have to be supported in cases like this:
    SomeClass a = new DerivedClass(args);

That's the "is it a function declaration or a declaration with constructor".
Aug 28 2002
prev sibling next sibling parent reply "Matthew Wilson" <matthew thedjournal.com> writes:
Guys

It seems to be the case that this debate is trying to reconcile keeping the
simpler semantics and implementation of Java, whilst bringing back the
essential constructs of C++ which (IMO) make it a more powerful, robust and
object-oriented (supporting) language than its weakened offspring. I have a
couple of thoughts:

1. struct

The struct keyword remains what most people assume it to imply, an
"inactive" type definition that doesn't contain constructor/destructor.

The programmer can specify the layout of the structure.

Arrays of structs are valid.

Structs can be on the heap or on the frame (see below).

Structs can have static methods. If it is feasible (from a compiler Walter's
perspective), they may contain instance methods.

Structs can have contain other structs (as members), but cannot contain
references to classes (since they don't have destructors).

2. class

The class keyword remains what most people assume it to imply, an "active"
type definition, that contains constructors and destructors (although they
can be omitted, in which case the compiler can provide them, or simply omit
them, as it chooses).

The default nature of a class is that of the current D class, ie. it is on
the heap, and is garbage collected.

class Normal
{
};

Normal n = new Normal(... some params ...);

The raii (or auto) keyword can be applied to a class instance declaration,
in which case the instance is placed on the frame, and is doffed when it
goes out of scope. The syntax for such declarations do not use the new
keyword, further disambiguating the syntax.

class ToDofOrNotToDof
{
};

auto ToDofOrNotToDof    dof(... args ...);
// Dof'ed at the end of this scope.
ToDofOrNotToDof    nodof = new ToDofOrNotToDof(... args ...);    //
Destructor called when garbage collected.

The raii (or auto) keyword can also be applied to a class definition, in
which case all instances of the class _must_ be placed on the frame, and are
doffed when they go out of scope. All instances use the raii declaration
syntax.

auto class AlwaysDof
{
};

AlwaysDof            adof1(... args ...); // Dof'ed at the end of this scope
auto AlwaysDof     adof2(... args ...); // Identical to previous line - auto
is redundant on an auto class
AlwaysDof            adof3 = new AlwaysDof(... args ...); // ERROR!

The question of whether a doffing instance can be passed to a function
taking a non-doffing instance can be resolved by either (i) disallowing it
for any doffed instance, or (ii) allowing this at the programmer's own risk.
I prefer the latter, but can live with the former quite happily.

3. Function declarations are at global scope, whereas object
default-construction is not. Nevetheless, if Walter wants to distinguish
between the two, the former could bear the "function" keyword, or the latter
can be required to omit (as in C++) the empty braces:

AlwaysDof     adof();   // invalid
AlwaysDOf     adof;    // valid


I'm not sure this isn't only a summary of all the points made on this topic,
but thought I'd mention it.

One important implication for all this, that I don't know if anyone's yet
addressed, is the impact of generics/templates. Perhaps this needs to be
discussed before a final DOF decision is made.

Matthew

"Walter" <walter digitalmars.com> wrote in message
news:akgsaf$aog$1 digitaldaemon.com...
 The 'auto' idea was looking more and more like a way to simply put class
 objects on the stack. Ok, so I smack my forehead, and think why not allow
 destructors for structs? This would provide the automatic destruction of
 structs when they go out of scope. Some other properties talked about with
 auto are implicit with structs:

 1) they cannot be derived from or inherited
 2) the 'auto' is implicit
 3) can't implicitly convert to Object

 Furthermore, to make things easier, the following can be disallowed:

 1) arrays of structs with destructors
 2) structs with destructors as class or struct fields
 3) assignment of structs with destructors

 A class can be 'auto-ized' by wrapping it in a struct:

     struct AutoA
     {    A a;
         ~this() { delete a; }
     }

 and can even be templatized:

     template AutoClass(T)
     {
         T t;
         ~this() { delete t; }
     }

Sep 02 2002
next sibling parent Pavel Minayev <evilone omen.ru> writes:
Matthew Wilson wrote:

 The raii (or auto) keyword can also be applied to a class definition, in
 which case all instances of the class _must_ be placed on the frame, and are
 doffed when they go out of scope. All instances use the raii declaration
 syntax.
 
 auto class AlwaysDof
 {
 };
 
 AlwaysDof            adof1(... args ...); // Dof'ed at the end of this scope
 auto AlwaysDof     adof2(... args ...); // Identical to previous line - auto

I think that "auto" should also be _required_.
 The question of whether a doffing instance can be passed to a function
 taking a non-doffing instance can be resolved by either (i) disallowing it
 for any doffed instance, or (ii) allowing this at the programmer's own risk.
 I prefer the latter, but can live with the former quite happily.

I think the latter is much better... just to remind my example with Stream/File: class Stream; // not all Streams are auto, auto class File; // but File definitely is uint crc32(Stream str); // Stream is not auto! auto File f("foo.bar"); crc32(f); Now if you forbid passing auto objects to functions expecting non-auto reference, the last line is invalid. But I don't see any reasons why it shouldn't be allowed...
 3. Function declarations are at global scope, whereas object
 default-construction is not. Nevetheless, if Walter wants to distinguish
 between the two, the former could bear the "function" keyword, or the latter
 can be required to omit (as in C++) the empty braces:
 
 AlwaysDof     adof();   // invalid
 AlwaysDOf     adof;    // valid

As long as you require to use "auto", there is no ambiguity. Overall, I must say that I really like this proposal, and would vote for it should the voting take place. It seems like the best approach to me, enabling power of C++ while preserving D's simplicity
Sep 02 2002
prev sibling parent reply "Sandor Hojtsy" <hojtsy index.hu> writes:
"Matthew Wilson" <matthew thedjournal.com> wrote in message
 Guys

 It seems to be the case that this debate is trying to reconcile keeping

 simpler semantics and implementation of Java, whilst bringing back the
 essential constructs of C++ which (IMO) make it a more powerful, robust

 object-oriented (supporting) language than its weakened offspring. I have

 couple of thoughts:

 1. struct

 The struct keyword remains what most people assume it to imply, an
 "inactive" type definition that doesn't contain constructor/destructor.

 The programmer can specify the layout of the structure.

 Arrays of structs are valid.

 Structs can be on the heap or on the frame (see below).

 Structs can have static methods. If it is feasible (from a compiler

 perspective), they may contain instance methods.

 Structs can have contain other structs (as members), but cannot contain
 references to classes (since they don't have destructors).

I don't think destructors and contained references are connected.
 2. class

 The class keyword remains what most people assume it to imply, an "active"
 type definition, that contains constructors and destructors (although they
 can be omitted, in which case the compiler can provide them, or simply

 them, as it chooses).

 The default nature of a class is that of the current D class, ie. it is on
 the heap, and is garbage collected.

 class Normal
 {
 };

 Normal n = new Normal(... some params ...);

 The raii (or auto) keyword can be applied to a class instance declaration,
 in which case the instance is placed on the frame, and is doffed when it
 goes out of scope. The syntax for such declarations do not use the new
 keyword, further disambiguating the syntax.

 class ToDofOrNotToDof
 {
 };

 auto ToDofOrNotToDof    dof(... args ...);
 // Dof'ed at the end of this scope.
 ToDofOrNotToDof    nodof = new ToDofOrNotToDof(... args ...);    //
 Destructor called when garbage collected.

I like this syntax. Could you please remind me, what this DOF word stands for?
 The raii (or auto) keyword can also be applied to a class definition, in
 which case all instances of the class _must_ be placed on the frame, and

 doffed when they go out of scope. All instances use the raii declaration
 syntax.

I don't think the language specification should say whether raii is on the stack, or the heap. The only important point is that it's lifetime is the scope.
 auto class AlwaysDof
 {
 };

 AlwaysDof            adof1(... args ...); // Dof'ed at the end of this

 auto AlwaysDof     adof2(... args ...); // Identical to previous line -

 is redundant on an auto class
 AlwaysDof            adof3 = new AlwaysDof(... args ...); // ERROR!

 The question of whether a doffing instance can be passed to a function
 taking a non-doffing instance can be resolved by either (i) disallowing it
 for any doffed instance, or (ii) allowing this at the programmer's own

 I prefer the latter, but can live with the former quite happily.

Incorrect. The raii is not the property of the object instance! It is the property of the reference instance. This is very important. You cannot ever pass a class instance. Only copy the reference. Now, would you like the copied reference to destroy your original object before the caller function ends? In 99 cases out of 100, no. So the real problem is copying an raii reference to an other raii reference. There is simply no risk with copying a raii reference into a non-raii reference. Why would someone disallow it? Because I want functions which take a reference to a File object, and don't close the File, you cannot have File as a raii class. Only specific references to File-s can be raii. Can you please provide a class which requires all references to it, to be raii? Because that is what you are suggesting. So I agree with you in most points, but think there is no need for this "auto class", but only for the individual "auto"s. Yours, Sandor
Sep 04 2002
parent reply Mac Reiter <Mac_member pathlink.com> writes:
In article <al4j79$2s6p$1 digitaldaemon.com>, Sandor Hojtsy says...
"Matthew Wilson" <matthew thedjournal.com> wrote in message
Incorrect. The raii is not the property of the object instance! It is the
property of the reference instance.
This is very important. You cannot ever pass a class instance. Only copy the
reference. Now, would you like the copied reference to destroy your original
object before the caller function ends? In 99 cases out of 100, no. So the
real problem is copying an raii reference to an other raii reference. There
is simply no risk with copying a raii reference into a non-raii reference.
Why would someone disallow it?

There is a risk if the non-raii reference will be holding on past the function invocation lifetime -- if it is storing it away in a cache or something. Of course, such a situation will blow up anything that isn't reference counted, so we'll ignore that case for the time being...
Because I want functions which take a reference to a File object, and don't
close the File, you cannot have File as a raii class. Only specific
references to File-s can be raii.
Can you please provide a class which requires all references to it, to be
raii? Because that is what you are suggesting.

So I agree with you in most points, but think there is no need for this
"auto class", but only for the individual "auto"s.

Yours,
Sandor

My personal preference is not to require the per-instance keyword, because it is easy to forget it and then lose all of the benefits of raii. If I make a Lock class, I know that in 99.99% of the cases I want it to be raii. Why require someone to type an extra keyword for all of those cases? Why add the debugging risk of forgetting to type it to the most common case? C++ requires you to flag each and every member function as virtual if you want polymorphism to work. How many class hierarchies are subtly broken because somebody forgot to add that word? 'virtual' is the most common case, so it should be what you get if you don't go out of your way to specify otherwise. Because C++ broke that rule, lots of C++ code is broken as well. I would prefer to avoid a similar mistake in D (which does do 'virtual' by default, by the way, because Walter realized this problem). Because there will always be the odd case of needing a non-raii instance of a class that is "almost always" raii, I recommend having a keyword that *stops* raii behavior for a particular instance. That way, the keyword is only used to flag the special cases, not the common cases. With this, you signal your class that all of its instances are raii unless otherwise noted, and then let people switch individual special cases back to normal GC'ed instances. Another argument for having the raii per-instance keyword is that it signifies at the local code that this instance is used differently. I'm not a big believer in this, but I see the validity of the issue. If that is a desirable property, then I would keep the raii for classes, and then whenever you make an instance of that class, you are then required to explicitly state whether you want raii or gc behavior. More typing than I prefer, but it is explicit about these classes and their use. Mac
Sep 04 2002
next sibling parent Pavel Minayev <evilone omen.ru> writes:
Mac Reiter wrote:

 Another argument for having the raii per-instance keyword is that it signifies
 at the local code that this instance is used differently.  I'm not a big
 believer in this, but I see the validity of the issue.  If that is a desirable
 property, then I would keep the raii for classes, and then whenever you make an
 instance of that class, you are then required to explicitly state whether you
 want raii or gc behavior.  More typing than I prefer, but it is explicit about
 these classes and their use.

Yes, exactly. I think it would be the best approach.
Sep 04 2002
prev sibling next sibling parent reply "Sandor Hojtsy" <hojtsy index.hu> writes:
 There is a risk if the non-raii reference will be holding on past the

 invocation lifetime -- if it is storing it away in a cache or something.

 course, such a situation will blow up anything that isn't reference

 we'll ignore that case for the time being...

Yes that kind of trickery can also ruin the "struct destructors" concept. And of course you will need non-raii references to Lock and File objects, to enable function calls (including member functions of Lock and File). Would you disable member function calls of Lock and File? The secret parameter, the reference to itself will be non-raii, and can be stored anywhere you like. But let me start a new line of discussion here. You don't really need to *delete* the instance. Memory is not important. You only need to release other resources. Finalyzing or "disposing" would do. Then the old references may remain valid. Like references to an existing but closed File object. All i/o operations would produce exceptions. I think it is more elegant than possibly having "dangling references".
Because I want functions which take a reference to a File object, and


close the File, you cannot have File as a raii class. Only specific
references to File-s can be raii.
Can you please provide a class which requires all references to it, to be
raii? Because that is what you are suggesting.

My personal preference is not to require the per-instance keyword, because

 easy to forget it and then lose all of the benefits of raii.  If I make a

 class, I know that in 99.99% of the cases I want it to be raii.  Why

 someone to type an extra keyword for all of those cases?  Why add the

 risk of forgetting to type it to the most common case?  C++ requires you

 each and every member function as virtual if you want polymorphism to

 many class hierarchies are subtly broken because somebody forgot to add

 word?  'virtual' is the most common case, so it should be what you get if

 don't go out of your way to specify otherwise.  Because C++ broke that

 lots of C++ code is broken as well.  I would prefer to avoid a similar

 in D (which does do 'virtual' by default, by the way, because Walter

 this problem).

 Because there will always be the odd case of needing a non-raii instance

 class that is "almost always" raii, I recommend having a keyword that

 raii behavior for a particular instance.  That way, the keyword is only

 flag the special cases, not the common cases.  With this, you signal your

 that all of its instances are raii unless otherwise noted, and then let

 switch individual special cases back to normal GC'ed instances.

The *instances* of Lock and File can (<sigh> almost) always be raii. But you are associating the raii property with the *references* to Lock and File. In this discussion there was no mentioning of keywords to require or stop raii "for a particular instance". How would you accomplish that?
 "you signal your class that all of its instances are raii unless otherwise

Put it this way: "you signal your class that all *references* to its instances are raii unless otherwise noted" And signaling that doesn't make sense.
 Another argument for having the raii per-instance keyword is that it

 at the local code that this instance is used differently.

The reference is used differently. Actually it is the *owner* reference of the instance, as compared to other references to the same instance. The owner reference deletes the instance, when itself is "scoped out". Other references to the same instance don't do it. Raii is the property of the class. Ownership is the property of the reference. Nothing special is property of the instance. Raii classes differ from non-raii classes that: - an instance of a raii class has exaclty one owner reference pointing to it, - an instance of a non-raii class has exaclty zero owner reference pointing to it. This can be easily achieved if - owner references can be assigned to non-owners without limitation, and - owner references can be overwritten by both kinds of reference, automagically deleting the old owned instance (if there is any).
  I'm not a big
 believer in this, but I see the validity of the issue.  If that is a

 property, then I would keep the raii for classes, and then whenever you

 instance of that class,

You mean inside the "new" operator?
 you are then required to explicitly state whether you
 want raii or gc behavior.  More typing than I prefer, but it is explicit

 these classes and their use.

Sep 05 2002
next sibling parent Mac Reiter <Mac_member pathlink.com> writes:
OK, there are two things that I need to point out that will help tremendously:

1. I apologize, I was sloppy with my terminology.  When reading my earlier
posts, please replace "instance" with "reference".  At no point was I actually
intentionally referring to the instance (chunk of memory, allocated with new, to
which there may be multiple references).  I was always referring to the
reference variable.  Please take my posts, put 'em in an editor, and do a global
search and replace, then see if they make any more sense.  This was an
incredibly bad mistake on my part, because without precision in our words, we
can't communicate effectively.

2. I am strongly in favor of reference counting instead of simple scoping.  I
think that the only reliable and safe deterministic finalization technique is
reference counting (assuming the presence of a GC that can come through and
gather up the cycles that refcounting leaves behind).  Scoping falls out as the
simplest case of reference counting.  However, I have beaten that horse until it
is not only dead, but has now been chopped up, processed, cured, canned, fed to
dogs around the country, and gone to its final (though ignoble and somewhat
disgusting) resting place(s).  It isn't going to happen, at least not in the
foreseeable future.  So, I have turned my attentions to trying to make the raii
system as safe as I can envision it.  

The safest form that I can imagine, because it requires the least continuous
attention and effort from the programmer, is one where classes are flagged so
that any references to their instances are raii by default.  Then two exceptions
are made: 

1. References that are function arguments are not raii -- the function isn't
creating the instance (I meant it that time :-), so the argument reference is
not the owning reference, so it must not exhibit raii destruction behavior.

2. A keyword is introduced to allow a particular owner reference (the one that
was used in the statement "MyRef = new MyRaiiClass") to not exhibit raii
behaviors.  Thus, if a function is going to create an instance (meant that one,
too) and attach a reference to it, but it also expects to hand that instance to
somewhere else and then exit (which would finalize the instance, normally), it
can declare its reference to be a nonraii reference.  The following is
contrived, but I'm trying to keep it short...

raii class Lock{/*...*/}

void func1()
{
Lock lockFromElsewhere; // reference is raii, because no keyword

lockFromElsewhere = func2();
} // lockFromElsewhere reference will finalize instance that is returned
// from func2 at this point

Lock func2()
{
nonraii Lock notMine = new Lock; // notMine is a nonraii reference
return notMine;
} // Since notMine is nonraii, nothing magical happens here.

Looking at that code, I'm not sure if a third exception needs to be made for
function return types or not.  I certainly don't want to have to type:

nonraii Lock func2() {/*...*/}

although that might not be a bad thing...  It would signify that the Lock that
is being returned does not have the normal raii semantics and will need to be
handled some other way.  Of course, any return value will "not have the normal
raii semantics", so the nonraii keyword there should not technically be
necessary.

Functions like those above are not common, but it is possible that a subfunction
could start doing some work for which it needed to acquire a resource, and then
reached a point where it needed to let the caller finish the work, but it
doesn't want to release the resource because that would open a window of
opportunity for other threads/processes/tasks/whatever to affect the resource.
Of the few cases where this comes up, most can probably be handled by
redesigning the two functions in question.  But there are still some cases that
simply need that design.

Just to forestall any comments, I wish to point out that Lock can usually be
fixed through other means.  If a function has to return a locked resource, the
programmer must take the responsibility for tracking who owns the lock and who
should finally unlock it.  Most Lock classes do not actually contain the locking
mechanism -- they usually just contain a reference to a Mutex or Semaphore.  The
purpose of the Lock class is to remove responsibility from the programmer for
remembering to unlock the Mutex/Semaphore.  If the programmer has taken that
responsibility back upon him/herself, then there is no need to use the Lock, and
the Mutex/Semaphore (which are non-raii classes anyway) can be directly managed.
I mention this to show that I understand that Lock is probably a poor choice for
demonstrating some of the more contorted cases that occasionally arise.  A
better example would probably be File or Printer or Port, where the raii'd class
also actually "is" the resource, from a programming standpoint, rather than a
simple convenience wrapper around another class.

In article <al7dih$2oaq$1 digitaldaemon.com>, Sandor Hojtsy says...
The *instances* of Lock and File can (<sigh> almost) always be raii. But you
are associating the raii property with the *references* to Lock and File. In
this discussion there was no mentioning of keywords to require or stop raii
"for a particular instance". How would you accomplish that?

 "you signal your class that all of its instances are raii unless otherwise

Put it this way: "you signal your class that all *references* to its instances are raii unless otherwise noted" And signaling that doesn't make sense.

OK, given the exceptions mentioned above (function parameter references and keyword marked references), does it now make sense to signal that all non-exceptional references to the raii class are raii references? Mac
Sep 05 2002
prev sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Sandor Hojtsy wrote:

 There is a risk if the non-raii reference will be holding on past the

 invocation lifetime -- if it is storing it away in a cache or something.

 course, such a situation will blow up anything that isn't reference

 we'll ignore that case for the time being...

Yes that kind of trickery can also ruin the "struct destructors" concept. And of course you will need non-raii references to Lock and File objects, to enable function calls (including member functions of Lock and File). Would you disable member function calls of Lock and File? The secret parameter, the reference to itself will be non-raii, and can be stored anywhere you like. But let me start a new line of discussion here. You don't really need to *delete* the instance. Memory is not important. You only need to release other resources. Finalyzing or "disposing" would do. Then the old references may remain valid. Like references to an existing but closed File object. All i/o operations would produce exceptions. I think it is more elegant than possibly having "dangling references".

Interesting idea. But maybe you could build it into the compile: There could be a "valid" bool variable (allocated along with the object?) that marked whether or not the object had been finalized. Each call on a member function would include an implicit "in" contract that "valid==true". So use after the object had been "finalized" would result in a contract failure exception. Of course, you could also code this individually into each class that needs it. Perhaps a special template for raii classes: template Raii(X : Object) { class Raii_Wrapper : X { X ref; bool raii_valid = true; void finalize() { ref.finalize(); raii_valid = false; }; invariant() { assert raii_valid; } } } Now, each time that somebody declares an raii object: void func() { auto MyClass raii_ref; // blah } the compiler turns it into an instance of the template, with the implicit finally clause: void func() { instance Raii(MyClass) raii_ref; try { // blah } finally { raii_ref.finalize(); } } Thoughts? -- The Villagers are Online! villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
Sep 05 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D77A06B.ACD19741 deming-os.org...
 Interesting idea.  But maybe you could build it into the compile: There

 a "valid" bool variable (allocated along with the object?) that marked

 or not the object had been finalized.  Each call on a member function

 include an implicit "in" contract that "valid==true".  So use after the

 had been "finalized" would result in a contract failure exception.

That is handilly handled (!) by zeroing the vptr after finalization.
Sep 05 2002
next sibling parent Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3D77A06B.ACD19741 deming-os.org...
 
Interesting idea.  But maybe you could build it into the compile: There

could be
a "valid" bool variable (allocated along with the object?) that marked

whether
or not the object had been finalized.  Each call on a member function

would
include an implicit "in" contract that "valid==true".  So use after the

object
had been "finalized" would result in a contract failure exception.

That is handilly handled (!) by zeroing the vptr after finalization.

(Shudder) Well, I suppose any error is better than none. It's a good point, though, that raii finalization should NOT drop the object out of the garbage collection map. Finalize it, but don't mark it as garbage until you're sure there are no dangling references. It will make for easier-to-debug programs.
Sep 05 2002
prev sibling parent "Sandor Hojtsy" <hojtsy index.hu> writes:
"Walter" <walter digitalmars.com> wrote in message
news:al8nql$2ejr$1 digitaldaemon.com...
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3D77A06B.ACD19741 deming-os.org...
 Interesting idea.  But maybe you could build it into the compile: There

 a "valid" bool variable (allocated along with the object?) that marked

 or not the object had been finalized.  Each call on a member function

 include an implicit "in" contract that "valid==true".  So use after the

 had been "finalized" would result in a contract failure exception.

That is handilly handled (!) by zeroing the vptr after finalization.

Good. In that case, releasing raii objects should call finalyze, and not delete. Theoretically a wrapper object of a released resource may still have usable member functions, such as statistical data of usage, or filename an such. Calling these functions are still disabled, but at least dangling references are better handled. Sandor
Sep 09 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Mac Reiter" <Mac_member pathlink.com> wrote in message
news:al5kgm$1ud8$1 digitaldaemon.com...
 In article <al4j79$2s6p$1 digitaldaemon.com>, Sandor Hojtsy says...
 I would prefer to avoid a similar mistake
 in D (which does do 'virtual' by default, by the way, because Walter

 this problem).

LOL. I suffered from subtle bugs caused by that exact issue over and over. When you have a large app, the tedium of trying to verify the correctness of the virtual use is boggling. There was just no way to prove your program was free of such. It's a maddening timewaster. The correct way is to have virtual by default, and allow no overrides of final functions.
Sep 05 2002
prev sibling parent Juarez Rudsatz <juarez nowhere.com> writes:
"Walter" <walter digitalmars.com> wrote in
news:akgsaf$aog$1 digitaldaemon.com: 

 The 'auto' idea was looking more and more like a way to simply put
 class objects on the stack.

A example of code being converted for user RAII: http://sourceforge.net/docman/display_doc.php?docid=8673&group_id=9028 This is the Firebird SQL DB Server converted from C to C++
Sep 05 2002