www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Walter: Before you go and implement the new RAII syntax..

reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
This is what I'm talking about:

Foo f = Foo(); // RAII
Foo g = new Foo(); // Normal

Can we all discuss this?  I'm sorry, but that syntax is just too easy to 
mess up / miss.  I'm surprised that you, someone who is very much against 
"secret things happening" would be a proponent of this syntax.  It's just 
too nonobvious.  (And as a minor point, this also makes it impossible to 
make a static opCall with a class.)


route for type inference and come up with a "var" keyword which would be a 
"type placeholder".  That is:

var f = new Foo(); // Normal
auto var g = new Foo(); // RAII

And as you can see, this gets rid of thee "auto auto" problem.  Not to 
mention it gets rid of the very common misunderstanding that currently, 
"auto" is somehow used for type inference, when in fact it's simply the use 
of a storage class without a type that invokes type inference.

This, or maybe we could use a "stack" or "local" or "raii" keyword in place 
of the "new":

Foo f = stack Foo();
Foo g = local Foo();
Foo h = raii Foo();

Something.  Anything would be better than the "new or nothing" syntax.
Sep 04 2006
next sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Tue, 5 Sep 2006 00:55:56 -0400, Jarrett Billingsley wrote:


 This is what I'm talking about:
 
 Foo f = Foo(); // RAII
 Foo g = new Foo(); // Normal
 
 Can we all discuss this?  I'm sorry, but that syntax is just too easy to 
 mess up / miss.  I'm surprised that you, someone who is very much against 
 "secret things happening" would be a proponent of this syntax.  It's just 
 too nonobvious.  (And as a minor point, this also makes it impossible to 
 make a static opCall with a class.)
 

 route for type inference and come up with a "var" keyword which would be a 
 "type placeholder".  That is:
 
 var f = new Foo(); // Normal
 auto var g = new Foo(); // RAII
 
 And as you can see, this gets rid of thee "auto auto" problem.  Not to 
 mention it gets rid of the very common misunderstanding that currently, 
 "auto" is somehow used for type inference, when in fact it's simply the use 
 of a storage class without a type that invokes type inference.
 
 This, or maybe we could use a "stack" or "local" or "raii" keyword in place 
 of the "new":
 
 Foo f = stack Foo();
 Foo g = local Foo();
 Foo h = raii Foo();
 
 Something.  Anything would be better than the "new or nothing" syntax.


I strongly agree with Jarrett. 

     Foo f = <NEW> Foo();

  where <NEW> can be either 'new' or 'local', or even 'new local' but never
omitted, when invoking the class constructor. The static opCall is probably
not valuable and if removed I wouldn't mind, but this still would not
justify omitting 'new' either.

BTW, I'm not wedded to 'local' but something, ... anything, that explicitly
informs the reader that the object will be destroyed when it goes out of
scope is needed. Leaving it out is not a good user interface.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
5/09/2006 2:57:59 PM
Sep 04 2006
next sibling parent Sean Kelly <sean f4.ca> writes:
Derek Parnell wrote:

 
 I strongly agree with Jarrett. 
 
      Foo f = <NEW> Foo();
 
   where <NEW> can be either 'new' or 'local', or even 'new local' but never
 omitted, when invoking the class constructor. The static opCall is probably
 not valuable and if removed I wouldn't mind, but this still would not
 justify omitting 'new' either.
 
 BTW, I'm not wedded to 'local' but something, ... anything, that explicitly
 informs the reader that the object will be destroyed when it goes out of
 scope is needed. Leaving it out is not a good user interface.


If there's to be a symbol to signify "stack allocation" then it should 
be in place of <NEW> as Derek suggests and not preceding the entire 
declaration as 'auto' does now.  I'll admit I prefer this idea to having 
nothing there, but I could live with either.


Sean
Sep 04 2006
prev sibling next sibling parent reply Jeff <psychobrat gmail.com> writes:
+1 :)

I'm terrified of 'auto auto' making it into 1.0; it just -screams- "ugly 
and confusing" to me.
Sep 06 2006
parent Garett Bass <garettbass studiotekne.com> writes:
Agreed, this overload of the meaning of 'auto' has made me uncomfortable since
it was introduced.  It needlessly complicates things.

Jeff wrote:

 +1 :)
 
 I'm terrified of 'auto auto' making it into 1.0; it just -screams- "ugly 
 and confusing" to me.
Sep 06 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Derek Parnell wrote:

 BTW, I'm not wedded to 'local' but something, ... anything, that explicitly
 informs the reader that the object will be destroyed when it goes out of
 scope is needed. Leaving it out is not a good user interface.


Why? It's implicit in C style programming languages that things 
disappear when they go out of scope. It's the original meaning of 'auto' 
in C and C++, it's also the default behavior.
Sep 06 2006
parent Derek Parnell <derek nomail.afraid.org> writes:
On Wed, 06 Sep 2006 21:07:15 -0700, Walter Bright wrote:


 Derek Parnell wrote:

 BTW, I'm not wedded to 'local' but something, ... anything, that explicitly
 informs the reader that the object will be destroyed when it goes out of
 scope is needed. Leaving it out is not a good user interface.


 
 Why? It's implicit in C style programming languages that things 
 disappear when they go out of scope. It's the original meaning of 'auto' 
 in C and C++, it's also the default behavior.


(N.B: I'm talking about the proposed situation where the D 'auto' keyword
is *not* used to implement RAII.)

Because D doesn't work that way. Sometimes, even when the object goes out
of scope, the object is not destroyed - that is, the dtor is not guaranteed
to be called. However, if you use a 'auto' object the dtor is called.


 import std.stdio;
 class Foo
 {
  static int s_cnt;
  int m_cnt;
  char[] m_id;

  this(char[] id) { m_id = id.dup; 
                    s_cnt++; m_cnt = s_cnt; 
                    writefln(m_id," CTOR", m_cnt); }
  ~this() { writefln(m_id, " DTOR", m_cnt);}
 }

 void func(char[] id)
 {
   Foo a =  new Foo(id);
   auto Foo b = new Foo(id);


   // the dtor for 'a' is not necessarily called on func exit.
   // the dtor for 'b' is always called on func exit.
 }


 void main()
 {

    func("A");
    func("B");
    func("C");
    func("D");

 } 

The output from this is ...

A CTOR1
A CTOR2
A DTOR2
B CTOR3
B CTOR4
B DTOR4
C CTOR5
C CTOR6
C DTOR6
D CTOR7
D CTOR8
D DTOR8
D DTOR7
C DTOR5
B DTOR3
A DTOR1

which clearly shows that the currently 'auto' objects are destroyed on
scope exit but non-auto ones are not.

My earlier discussion was focused on replacing the 'auto' keyword for RAII
with a more meaningful keyword, such as 'local'. All I was saying was that
I don't care so much which new keyword is used to replace 'auto' so long as
it gives a better clue to the reader that a variable so decorated *WILL* be
destroyed at scope end, as will its referenced object if any.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
7/09/2006 2:38:38 PM
Sep 06 2006
prev sibling next sibling parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
Jarrett Billingsley wrote:

 This is what I'm talking about:
 
 Foo f = Foo(); // RAII
 Foo g = new Foo(); // Normal
 
 Can we all discuss this?  I'm sorry, but that syntax is just too easy to 
 mess up / miss.  I'm surprised that you, someone who is very much against 
 "secret things happening" would be a proponent of this syntax.  It's just 
 too nonobvious.  (And as a minor point, this also makes it impossible to 
 make a static opCall with a class.)
 

 route for type inference and come up with a "var" keyword which would be a 
 "type placeholder".  That is:
 
 var f = new Foo(); // Normal
 auto var g = new Foo(); // RAII
 
 And as you can see, this gets rid of thee "auto auto" problem.  Not to 
 mention it gets rid of the very common misunderstanding that currently, 
 "auto" is somehow used for type inference, when in fact it's simply the use 
 of a storage class without a type that invokes type inference.
 
 This, or maybe we could use a "stack" or "local" or "raii" keyword in place 
 of the "new":
 
 Foo f = stack Foo();
 Foo g = local Foo();
 Foo h = raii Foo();
 
 Something.  Anything would be better than the "new or nothing" syntax. 
 
 


I agree.

It also makes sense to me to use various keywords to determine what kind 
of allocation is done:

Foo a = new   Foo(); // compiler optimized allocation
Foo b = heap  Foo(); // allocate on heap
Foo c = stack Foo(); // allocate on stack
Foo d = scope Foo(); // raii

Also, it may be wise to make the keyword prefix the lvalue rather than 
be the allocator, for a reason I saw pointed out by Bruno Medeiros in a 
previous discussion:

You can't make auto objects out of objects allocated with a function
(like a factory method) instead of inline allocation. For example, the
following cannot be made with a no-allocator-keyword syntax:
   auto Foo foo = SomeFactory.newFoo(..); // can't make an auto here
   auto char[] a = read(filename); // can't make an auto here

... so we'd have
scope Foo f = new Foo();
and I don't know why anyone would want to, but someday you could
scope Foo f = heap Foo();
Sep 04 2006
parent reply Brad Roberts <braddr puremagic.com> writes:
Chad J wrote:

 Jarrett Billingsley wrote:

 This is what I'm talking about:

 Foo f = Foo(); // RAII
 Foo g = new Foo(); // Normal

 Can we all discuss this?  I'm sorry, but that syntax is just too easy 
 to mess up / miss.  I'm surprised that you, someone who is very much 
 against "secret things happening" would be a proponent of this 
 syntax.  It's just too nonobvious.  (And as a minor point, this also 
 makes it impossible to make a static opCall with a class.)

 How about instead, we keep auto to mean a RAII reference, and we take 

 would be a "type placeholder".  That is:

 var f = new Foo(); // Normal
 auto var g = new Foo(); // RAII

 And as you can see, this gets rid of thee "auto auto" problem.  Not to 
 mention it gets rid of the very common misunderstanding that 
 currently, "auto" is somehow used for type inference, when in fact 
 it's simply the use of a storage class without a type that invokes 
 type inference.

 This, or maybe we could use a "stack" or "local" or "raii" keyword in 
 place of the "new":

 Foo f = stack Foo();
 Foo g = local Foo();
 Foo h = raii Foo();

 Something.  Anything would be better than the "new or nothing" syntax.


 
 I agree.
 
 It also makes sense to me to use various keywords to determine what kind 
 of allocation is done:
 
 Foo a = new   Foo(); // compiler optimized allocation
 Foo b = heap  Foo(); // allocate on heap
 Foo c = stack Foo(); // allocate on stack
 Foo d = scope Foo(); // raii
 
 Also, it may be wise to make the keyword prefix the lvalue rather than 
 be the allocator, for a reason I saw pointed out by Bruno Medeiros in a 
 previous discussion:
 
 You can't make auto objects out of objects allocated with a function
 (like a factory method) instead of inline allocation. For example, the
 following cannot be made with a no-allocator-keyword syntax:
   auto Foo foo = SomeFactory.newFoo(..); // can't make an auto here
   auto char[] a = read(filename); // can't make an auto here
 
 ... so we'd have
 scope Foo f = new Foo();
 and I don't know why anyone would want to, but someday you could
 scope Foo f = heap Foo();


Specifying storage mechanism seems like unnecessary compiler 
hamstringing.  Specify behavior and give the compiler authors the 
freedom to detect and optimize the storage.  See previous discussions on 
escape analysis.

Ages ago it was realized in the C language and descendants that the 
'register' keyword was pointless and, as far as I know, no compiler 
today obeys it.  Let's not repeat that misfeature.

Later,
Brad
Sep 04 2006
parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Brad Roberts wrote:

 Chad J wrote:
 

 Jarrett Billingsley wrote:


 This is what I'm talking about:

 Foo f = Foo(); // RAII
 Foo g = new Foo(); // Normal

 Can we all discuss this?  I'm sorry, but that syntax is just too easy 
 to mess up / miss.  I'm surprised that you, someone who is very much 
 against "secret things happening" would be a proponent of this 
 syntax.  It's just too nonobvious.  (And as a minor point, this also 
 makes it impossible to make a static opCall with a class.)

 How about instead, we keep auto to mean a RAII reference, and we take 

 which would be a "type placeholder".  That is:

 var f = new Foo(); // Normal
 auto var g = new Foo(); // RAII

 And as you can see, this gets rid of thee "auto auto" problem.  Not 
 to mention it gets rid of the very common misunderstanding that 
 currently, "auto" is somehow used for type inference, when in fact 
 it's simply the use of a storage class without a type that invokes 
 type inference.

 This, or maybe we could use a "stack" or "local" or "raii" keyword in 
 place of the "new":

 Foo f = stack Foo();
 Foo g = local Foo();
 Foo h = raii Foo();

 Something.  Anything would be better than the "new or nothing" syntax.


 I agree.

 It also makes sense to me to use various keywords to determine what 
 kind of allocation is done:

 Foo a = new   Foo(); // compiler optimized allocation
 Foo b = heap  Foo(); // allocate on heap
 Foo c = stack Foo(); // allocate on stack
 Foo d = scope Foo(); // raii

 Also, it may be wise to make the keyword prefix the lvalue rather than 
 be the allocator, for a reason I saw pointed out by Bruno Medeiros in 
 a previous discussion:

 You can't make auto objects out of objects allocated with a function
 (like a factory method) instead of inline allocation. For example, the
 following cannot be made with a no-allocator-keyword syntax:
   auto Foo foo = SomeFactory.newFoo(..); // can't make an auto here
   auto char[] a = read(filename); // can't make an auto here

 ... so we'd have
 scope Foo f = new Foo();
 and I don't know why anyone would want to, but someday you could
 scope Foo f = heap Foo();


 


The following works right now, and does so just fine:
     Foo foo = SomeFactory.newFoo(...); scope(exit) delete foo;
     char[] a = read(filename); scope(exit) delete a;

-- Chris Nicholson-Sauls
Sep 04 2006
parent reply Garett Bass <garettbass studiotekne.com> writes:
I wasn't aware of that, pretty cool!  In this case, perhaps do away with the
old local-scope meaning of 'auto' altogether.

Chris Nicholson-Sauls wrote:

 
 The following works right now, and does so just fine:
     Foo foo = SomeFactory.newFoo(...); scope(exit) delete foo;
     char[] a = read(filename); scope(exit) delete a;
 
 -- Chris Nicholson-Sauls
Sep 06 2006
parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
No.  The advantage of auto is that you can enforce this behaviour at the 
class declaration.
Example:

auto class Foo
{
   int member;
   this() {}
}

void main()
{
   auto Foo foo = new Foo(); // ok
   Foo bar = new Foo(); // error: reference to auto class must be auto
}

Of course, what Chris pointed out is cool from the standpoint that we 
could probably have the 'auto' keyword (or whatever may replace it) be 
in the allocator position without losing too much.

Garett Bass wrote:

 I wasn't aware of that, pretty cool!  In this case, perhaps do away with 
 the old local-scope meaning of 'auto' altogether.
 
 Chris Nicholson-Sauls wrote:
 

 The following works right now, and does so just fine:
     Foo foo = SomeFactory.newFoo(...); scope(exit) delete foo;
     char[] a = read(filename); scope(exit) delete a;

 -- Chris Nicholson-Sauls
Sep 06 2006
parent Sean Kelly <sean f4.ca> writes:
Chad J wrote:

 No.  The advantage of auto is that you can enforce this behaviour at the 
 class declaration.
 Example:
 
 auto class Foo
 {
   int member;
   this() {}
 }
 
 void main()
 {
   auto Foo foo = new Foo(); // ok
   Foo bar = new Foo(); // error: reference to auto class must be auto
 }


This is cool in theory but I have yet to actually use this feature.  I 
simply don't see the point in re-using 'auto' in this way.


 Of course, what Chris pointed out is cool from the standpoint that we 
 could probably have the 'auto' keyword (or whatever may replace it) be 
 in the allocator position without losing too much.


If a keyword were retained to signify auto-destruction then I think it 
should be in place of 'new' and not attached to the variable itself. 
Reason being that it's the data that's going away, not whatever that 
variable happens to reference on scope end.


Sean
Sep 06 2006
prev sibling next sibling parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Jarrett Billingsley wrote:

 This is what I'm talking about:
 
 Foo f = Foo(); // RAII
 Foo g = new Foo(); // Normal
 
 Can we all discuss this?  I'm sorry, but that syntax is just too easy to 
 mess up / miss.  I'm surprised that you, someone who is very much against 
 "secret things happening" would be a proponent of this syntax.  It's just 
 too nonobvious.  (And as a minor point, this also makes it impossible to 
 make a static opCall with a class.)
 

 route for type inference and come up with a "var" keyword which would be a 
 "type placeholder".  That is:
 
 var f = new Foo(); // Normal
 auto var g = new Foo(); // RAII
 
 And as you can see, this gets rid of thee "auto auto" problem.  Not to 
 mention it gets rid of the very common misunderstanding that currently, 
 "auto" is somehow used for type inference, when in fact it's simply the use 
 of a storage class without a type that invokes type inference.
 
 This, or maybe we could use a "stack" or "local" or "raii" keyword in place 
 of the "new":
 
 Foo f = stack Foo();
 Foo g = local Foo();
 Foo h = raii Foo();
 
 Something.  Anything would be better than the "new or nothing" syntax. 
 
 


I despise writing "me too" posts, but in this case I just cannot avoid it. 
So... me too!

I also find it intriguing that Phobos' RegExp module includes the following:





Yes in this case it is nothing but a wrapper around the constructor, and
essentially 
useless so far as I can tell.  However, the fact that Walter felt compelled to
provide 
such a creature is telling.

Personally I favor either 'local' or 'scope'/'scoped' as a new keyword for this
purpose, 
and do believe as others that it belongs in 'new's current position.  The
option of 
'scope'/'scoped' has the added benefit of consistancy with current keywords and
usage.

-- Chris Nicholson-Sauls
Sep 04 2006
prev sibling next sibling parent reply Robert Atkinson <Robert.Atkinson NO.gmail.com.SPAM> writes:
I'm a fan of the local keyword, or perhaps combining with the existing 
scope keywords as follows:

local:

local File file = new File(); // local RAII
local auto file = new File(); // local RAII + auto typing

or

scope(local):

scope(local) File file = new File();
scope(local) auto file = new File();

scope(local) is a little long for a single line, but it begins to look 
better if you have a group of RAII variables:

scope(local)
{
	File file;
	RecordSet rs;
	// etc
}


I believe that if we keep the auto/auto syntax, it will be a feature 
that everyone will love at first, but years from now it'll be the 
feature that we'll be cursing when we all have to maintain code. 
Scanning code quickly its hard to determine with the current auto/auto 
syntax if its RAII or auto typing.

Rob


Jarrett Billingsley wrote:

 This is what I'm talking about:
 
 Foo f = Foo(); // RAII
 Foo g = new Foo(); // Normal
 
 Can we all discuss this?  I'm sorry, but that syntax is just too easy to 
 mess up / miss.  I'm surprised that you, someone who is very much against 
 "secret things happening" would be a proponent of this syntax.  It's just 
 too nonobvious.  (And as a minor point, this also makes it impossible to 
 make a static opCall with a class.)
 

 route for type inference and come up with a "var" keyword which would be a 
 "type placeholder".  That is:
 
 var f = new Foo(); // Normal
 auto var g = new Foo(); // RAII
 
 And as you can see, this gets rid of thee "auto auto" problem.  Not to 
 mention it gets rid of the very common misunderstanding that currently, 
 "auto" is somehow used for type inference, when in fact it's simply the use 
 of a storage class without a type that invokes type inference.
 
 This, or maybe we could use a "stack" or "local" or "raii" keyword in place 
 of the "new":
 
 Foo f = stack Foo();
 Foo g = local Foo();
 Foo h = raii Foo();
 
 Something.  Anything would be better than the "new or nothing" syntax.
Sep 05 2006
next sibling parent Kristian <kjkilpi gmail.com> writes:
On Tue, 05 Sep 2006 19:30:30 +0300, Robert Atkinson  =

<Robert.Atkinson NO.gmail.com.SPAM> wrote:
[snip]

 I believe that if we keep the auto/auto syntax, it will be a feature  =



 that everyone will love at first, but years from now it'll be the  =



 feature that we'll be cursing when we all have to maintain code.  =



 Scanning code quickly its hard to determine with the current auto/auto=


  =


 syntax if its RAII or auto typing.

 Rob


Well, I got confused right away (when I discovered D). ;) (And hence nev=
er  =

liked the auto/auto syntax.)

I think it really should be changed.



 Jarrett Billingsley wrote:

 This is what I'm talking about:
  Foo f =3D Foo(); // RAII
 Foo g =3D new Foo(); // Normal
  Can we all discuss this?  I'm sorry, but that syntax is just too eas=




y  =


 to mess up / miss.  I'm surprised that you, someone who is very much =




 =


 against "secret things happening" would be a proponent of this syntax=




.   =


 It's just too nonobvious.  (And as a minor point, this also makes it =




 =


 impossible to make a static opCall with a class.)
  How about instead, we keep auto to mean a RAII reference, and we tak=




e  =







h  =


 would be a "type placeholder".  That is:
  var f =3D new Foo(); // Normal
 auto var g =3D new Foo(); // RAII
  And as you can see, this gets rid of thee "auto auto" problem.  Not =




to  =


 mention it gets rid of the very common misunderstanding that currentl=




y,  =


 "auto" is somehow used for type inference, when in fact it's simply t=




he  =


 use of a storage class without a type that invokes type inference.
  This, or maybe we could use a "stack" or "local" or "raii" keyword i=




n  =


 place of the "new":
  Foo f =3D stack Foo();
 Foo g =3D local Foo();
 Foo h =3D raii Foo();
  Something.  Anything would be better than the "new or nothing" synta=




x.





 Sep 05 2006



prev sibling  parent  Georg Wrede <georg.wrede nospam.org>  writes:


Robert Atkinson wrote:

 I believe that if we keep the auto/auto syntax, it will be a feature 
 that everyone will love at first, but years from now it'll be the 
 feature that we'll be cursing when we all have to maintain code. 
 Scanning code quickly its hard to determine with the current auto/auto 
 syntax if its RAII or auto typing.


Auto/auto will be ridiculed by those never aiming to switch to D. It 
will cause havoc when teaching the language. And it will embarrass each 
of us later when folks ask "weren't you in the D community? How come you 
didn't get rid of that thing already pre 1.0??"

Having things that look alike be different (and while I'm at it, also 
things that look different be the same), is something that belongs to 
wicked computer games, or stupid job admission tests.

Distinct concepts have to have distinct names. Clarity is the word.



 Sep 06 2006



prev sibling next sibling parent reply Garett Bass <garettbass studiotekne.com>  writes:


I'd like to note some problems that all of these approaches face.

Jarrett Billingsley wrote:

 
 Foo f = stack Foo();


Jarrett's proposed 'stack' allocation specifier is interesting in that it seems
to indicate that the object currently referenced by f will be deleted even if a
later line of code does something ugly like this:

    f = stack Foo(); // assign a different Foo to f

Now both Foo objects will be *deallocated* as the stack unwinds, but it is not
clear whether the destructor can be called on the unreferenced Foo, unless it
is called during the reassignment process.

Alternatively, either of these current implementations happily leaves one Foo
object dangling on the heap:

    auto Foo g = new Foo();
    g = new Foo(); // drops reference to original Foo

    Foo g = new Foo(); scope(exit) delete g;
    g = new Foo(); // drops reference to original Foo

How does the GC maintain these dropped references?  This seems like an easy bug
to insert, and potentially a difficult one to find.

It is unfortunate that true stack object instances do not exist in D.  The
'stack' syntax defies D's current heap-only object allocation philosophy.

Another advantage of C++ style stack object instances is the ability to
overload the assignment operator, which allows an object instance to be treated
as a built-in type.  You can't do this in D because it would alias your ability
to reassign the object reference to another object.  C++ has no problem
implementing real and imaginary numbers as classes, they need not be built-in
types since their instances can be treated as such syntactically.

I don't understand why modern high-level languages are so quick to discard (or
bias against) the pointer.  The distinction between object references/pointers
and object instances is very valuable in C++.  It can be nice to know that no
other code is going to reassign another object to your variable.

Pissing in the wind,
Garett



 Sep 06 2006



  parent  Kristian <kjkilpi gmail.com>  writes:


On Thu, 07 Sep 2006 02:44:43 +0300, Garett Bass  
<garettbass studiotekne.com> wrote:
[snip]

 It is unfortunate that true stack object instances do not exist in D.   
 The 'stack' syntax defies D's current heap-only object allocation  
 philosophy.

 Another advantage of C++ style stack object instances is the ability to  
 overload the assignment operator, which allows an object instance to be  
 treated as a built-in type.  You can't do this in D because it would  
 alias your ability to reassign the object reference to another object.   
 C++ has no problem implementing real and imaginary numbers as classes,  
 they need not be built-in types since their instances can be treated as  
 such syntactically.

 I don't understand why modern high-level languages are so quick to  
 discard (or bias against) the pointer.  The distinction between object  
 references/pointers and object instances is very valuable in C++.  It  
 can be nice to know that no other code is going to reassign another  
 object to your variable.

 Pissing in the wind,
 Garett



Now I know why D feels a bit strange at time to time. I wasn't fully aware  
of it until Garett pointed it out. And that's unability to create build-in  
types with classes. :|

I'm used to have my objects 'moduled', i.e. assigning X to Y and then  
changing Y won't change X. And there is no 'const' type... Time will tell  
how many errors I will make when handling my objects around... until I  
fully grab the concect of using references/pointers only.

Hmm, it's also 'interesting' to see how much dupping I will need. But  
dupping doesn't create deep copy, erh...


Should there be a 'physical' object instance class in D after all?



 Sep 07 2006



prev sibling  parent reply Gregor Richards <Richards codu.org>  writes:


I hate to dredge up an old post, but I was just thinking about this and 
thought I'd point out one thing to anyone listening:

RAII stands for Resource Allocation Is Initialization.  You can do RAII 
without automatically-deleted classes, it's just difficult.  For this 
reason, a keyword 'raii' would be inappropriate - what's being described 
is NOT RAII, it's just an incidental change that makes RAII more useful. 
  RDID (Resource Deallocation Is Destruction) is closer to what's being 
described, but still not spot-on: that has to do with the class 
definition, not the actual use of the class.  What's being described is 
simply an object associated with a scope.  In short: the changes 
described have nothing to do with RAII, they just make it more useful, 
so having a keyword 'raii' is nonsense.

If I see a keyword 'raii' meaning anything like this at any point in the 
future, I'll be crying myself to sleep that night :P

Just my 2¢

  - Gregor Richards



 Sep 29 2006



  parent  Georg Wrede <georg.wrede nospam.org>  writes:


Gregor Richards wrote:

 I hate to dredge up an old post, but I was just thinking about this and 
 thought I'd point out one thing to anyone listening:
 
 RAII stands for Resource Allocation Is Initialization.  You can do RAII 
 without automatically-deleted classes, it's just difficult.  For this 
 reason, a keyword 'raii' would be inappropriate - what's being described 
 is NOT RAII, it's just an incidental change that makes RAII more useful. 
  RDID (Resource Deallocation Is Destruction) is closer to what's being 
 described, but still not spot-on: that has to do with the class 
 definition, not the actual use of the class.  What's being described is 
 simply an object associated with a scope.  In short: the changes 
 described have nothing to do with RAII, they just make it more useful, 
 so having a keyword 'raii' is nonsense.
 
 If I see a keyword 'raii' meaning anything like this at any point in the 
 future, I'll be crying myself to sleep that night :P


If you get sleepless you might want to search the D newsgroup archives 
here on RAII. I promise you you'll be both crying and laughing the rest 
of the night.

What got beaten to death were: the meaning of the acronym, various 
suggestions to replace it, the entire subject, the guy who's originally 
introduced the acronym, and half of the participants' keyboards. ;-)

To comfort: you're not alone with your feeling.



 Sep 29 2006