www.digitalmars.com         C & C++   DMDScript  

D - auto construction syntax simplification

reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
Walter

A while back I mentioned that it would be nice to allow auto instances to be
constructed without the (syntactically consistent but semantically
misleading) new syntax. In other words

            auto ExeModule xmod =   new ExeModule(moduleName);

could be written as the more accurate

            ExeModule xmod(moduleName);

If memory serves, you liked this, but it's not yet implemented. Are there
plans to do this? Is it as simple as it seems to be to implement?

Cheers

The Easter Bunny
Dec 31 2003
next sibling parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <bt0gqk$ion$1 digitaldaemon.com>, Matthew wrote:
 Walter
 
 A while back I mentioned that it would be nice to allow auto instances to be
 constructed without the (syntactically consistent but semantically
 misleading) new syntax. In other words
 
             auto ExeModule xmod =   new ExeModule(moduleName);
 
 could be written as the more accurate
 
             ExeModule xmod(moduleName);

 If memory serves, you liked this, but it's not yet implemented. Are there
 plans to do this? Is it as simple as it seems to be to implement?

It would indeed be nice if the tedious repetition of ExeModule above wouldn't be necessary. However, I believe that this form of initialization caused so much parsing grief in C++ that is was removed in D? "ExeModule xmod(moduleName);" could either be a function declaration or a variable initializer. The parser must guess whether moduleName above is a type or a variable name, and worse, the human reader must, too. It is easier because moduleName is likely to denote a variable because it's not capitalized. But what if there are no arguments at all? There is of course the option of banning function declarations altogether inside function bodies. And if auto declarations are allowed inside class bodies and globally (which makes complete sense in light of C++ RAII usage), then another can of worms is opened. Or then another syntax; how about: ExeModule xmod = moduleName; // Do as the ints do or ExeModule xmod = moduleName, anotherArgument; // Multiple arguments or ExeModule xmod = (moduleName, anotherArgument); // Easier for the eye? or ExeModule xmod.this(moduleName, anotherArgument); -Antti
Jan 01 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
 In article <bt0gqk$ion$1 digitaldaemon.com>, Matthew wrote:
 Walter

 A while back I mentioned that it would be nice to allow auto instances


 constructed without the (syntactically consistent but semantically
 misleading) new syntax. In other words

             auto ExeModule xmod =   new ExeModule(moduleName);

 could be written as the more accurate

             ExeModule xmod(moduleName);

 If memory serves, you liked this, but it's not yet implemented. Are


 plans to do this? Is it as simple as it seems to be to implement?

It would indeed be nice if the tedious repetition of ExeModule above wouldn't be necessary. However, I believe that this form of initialization caused so much parsing grief in C++ that is was removed in D? "ExeModule xmod(moduleName);" could either be a function declaration or a variable initializer. The parser must guess whether moduleName above is a type or a variable name, and worse, the human reader must, too. It is easier because moduleName is likely to denote a variable because it's not capitalized. But what if there are no arguments at all?

You're almost right. It's only a problem when there are no arguments.
 There is of course the option of banning function declarations
 altogether inside function bodies. And if auto declarations are allowed
 inside class bodies and globally (which makes complete sense in light of
 C++ RAII usage), then another can of worms is opened.

 Or then another syntax; how about:

 ExeModule xmod = moduleName; // Do as the ints do

 or

 ExeModule xmod = moduleName, anotherArgument; // Multiple arguments

 or

 ExeModule xmod = (moduleName, anotherArgument); // Easier for the eye?

 or

 ExeModule xmod.this(moduleName, anotherArgument);

 -Antti

Nope. It needs to be ExeModule xmod(moduleName); Virtually no-one uses local function declarations in C++, and I don't foresee any issues in our outlawing them in D. If necessary, we could have a "function" keyword to force a declaration, as in function ExeModule xmod(); // Now is a function called xmod that returns ExeModule but I really don't think this is necessary. Happy New Year -- Matthew Wilson STLSoft moderator (http://www.stlsoft.org) Contributing editor, C/C++ Users Journal (www.synesis.com.au/articles.html#columns) "I can't sleep nights till I found out who hurled what ball through what apparatus" -- Dr Niles Crane ---------------------------------------------------------------------------- ---
Jan 01 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Matthew wrote:
 Virtually no-one uses local function declarations in C++, and I don't
 foresee any issues in our outlawing them in D.

STOP. inner functions are one of the most useful features in D, which partly compenastes for the lack of preprocessor! -eye
Jan 02 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
Do you have some compelling examples?

I'm not sure we're talking about the same thing here

"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:bt3qnp$2d45$1 digitaldaemon.com...
 Matthew wrote:
 Virtually no-one uses local function declarations in C++, and I don't
 foresee any issues in our outlawing them in D.

STOP. inner functions are one of the most useful features in D, which partly compenastes for the lack of preprocessor! -eye

Jan 02 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Are we talking of the possibility to define a function within a 
function? This inner function would be able to acess the locals of the 
function it is defined in, which is very useful. I think examples were 
in C or C++ to D transition in the manual. These are things where you 
would #define a function-like macro on the beginning of function in C++, 
and #undef it at the end. Like, you see repetitious code in a function, 
but it acesses local variables, so you factor it out, either by writing 
a macro or by creating a struct to hold locals. With D, there is this 
elegant solution with inner functions. I can dig out some real-world 
examples if you like.

The thing is, we also need a possibility to make forward declarations 
for such functions, because in local scope, as opposed to global scope, 
forward declarations are not automatic. You cannot make alternating 
recursion without forward declarations.

-eye

Matthew wrote:
 Do you have some compelling examples?
 
 I'm not sure we're talking about the same thing here

Jan 04 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
So we'd need a function keyword, then.

"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:bta1s8$2f9j$1 digitaldaemon.com...
 Are we talking of the possibility to define a function within a
 function? This inner function would be able to acess the locals of the
 function it is defined in, which is very useful. I think examples were
 in C or C++ to D transition in the manual. These are things where you
 would #define a function-like macro on the beginning of function in C++,
 and #undef it at the end. Like, you see repetitious code in a function,
 but it acesses local variables, so you factor it out, either by writing
 a macro or by creating a struct to hold locals. With D, there is this
 elegant solution with inner functions. I can dig out some real-world
 examples if you like.

 The thing is, we also need a possibility to make forward declarations
 for such functions, because in local scope, as opposed to global scope,
 forward declarations are not automatic. You cannot make alternating
 recursion without forward declarations.

 -eye

 Matthew wrote:
 Do you have some compelling examples?

 I'm not sure we're talking about the same thing here


Jan 04 2004
parent Hauke Duden <H.NS.Duden gmx.net> writes:
Matthew wrote:
 So we'd need a function keyword, then.

Why not create auto objects like this: auto Foo bar("xy",z); instead of auto Foo bar=new Foo("xy",z); The extra auto shouldn't be too much to type. And the syntax seems to be unambiguous to me, since functions cannot return auto objects (IIRC). Hauke
Jan 04 2004
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:bt0gqk$ion$1 digitaldaemon.com...
 Walter

 A while back I mentioned that it would be nice to allow auto instances to

 constructed without the (syntactically consistent but semantically
 misleading) new syntax. In other words

             auto ExeModule xmod =   new ExeModule(moduleName);

 could be written as the more accurate

             ExeModule xmod(moduleName);

 If memory serves, you liked this, but it's not yet implemented. Are there
 plans to do this? Is it as simple as it seems to be to implement?

As the other respondents pointed out, there are many parsing issues to be worked out to make this work. I think we'll leave it as is for the time being.
Jan 13 2004
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Walter wrote:
 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:bt0gqk$ion$1 digitaldaemon.com...
 
Walter

A while back I mentioned that it would be nice to allow auto instances to

be
constructed without the (syntactically consistent but semantically
misleading) new syntax. In other words

            auto ExeModule xmod =   new ExeModule(moduleName);

could be written as the more accurate

            ExeModule xmod(moduleName);

If memory serves, you liked this, but it's not yet implemented. Are there
plans to do this? Is it as simple as it seems to be to implement?

As the other respondents pointed out, there are many parsing issues to be worked out to make this work. I think we'll leave it as is for the time being.

What about this one? auto ExeModule xmod(moduleName); Hauke
Jan 14 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:bu357d$b60$1 digitaldaemon.com...
 Walter wrote:
 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:bt0gqk$ion$1 digitaldaemon.com...

Walter

A while back I mentioned that it would be nice to allow auto instances



 be

constructed without the (syntactically consistent but semantically
misleading) new syntax. In other words

            auto ExeModule xmod =   new ExeModule(moduleName);

could be written as the more accurate

            ExeModule xmod(moduleName);

If memory serves, you liked this, but it's not yet implemented. Are



plans to do this? Is it as simple as it seems to be to implement?

As the other respondents pointed out, there are many parsing issues to


 worked out to make this work. I think we'll leave it as is for the time
 being.

What about this one? auto ExeModule xmod(moduleName);

That's good. Can we have that Walter?
Jan 14 2004
parent reply "C" <dont respond.com> writes:
Honestly I kind of like the current syntax.  I think one of the gotchas
moving from C++ is forgetting to new everything , if we require the same
syntax it will drive home that everything must be new'ed.

C


"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:bu35b2$bii$1 digitaldaemon.com...
 "Hauke Duden" <H.NS.Duden gmx.net> wrote in message
 news:bu357d$b60$1 digitaldaemon.com...
 Walter wrote:
 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:bt0gqk$ion$1 digitaldaemon.com...

Walter

A while back I mentioned that it would be nice to allow auto instances



 be

constructed without the (syntactically consistent but semantically
misleading) new syntax. In other words

            auto ExeModule xmod =   new ExeModule(moduleName);

could be written as the more accurate

            ExeModule xmod(moduleName);

If memory serves, you liked this, but it's not yet implemented. Are



plans to do this? Is it as simple as it seems to be to implement?

As the other respondents pointed out, there are many parsing issues to


 worked out to make this work. I think we'll leave it as is for the



 being.

What about this one? auto ExeModule xmod(moduleName);

That's good. Can we have that Walter?

Jan 14 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
But auto instances do not exist on the heap and, for me at least, new says
"create one of these on the heap".

I grant you, or anyone else, that new actually has two functions, and my
focus on the heap side (as opposed to the construction side) is undoubtedly
from my C++ thinking


"C" <dont respond.com> wrote in message
news:bu4fqf$2guo$1 digitaldaemon.com...
 Honestly I kind of like the current syntax.  I think one of the gotchas
 moving from C++ is forgetting to new everything , if we require the same
 syntax it will drive home that everything must be new'ed.

 C


 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:bu35b2$bii$1 digitaldaemon.com...
 "Hauke Duden" <H.NS.Duden gmx.net> wrote in message
 news:bu357d$b60$1 digitaldaemon.com...
 Walter wrote:
 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:bt0gqk$ion$1 digitaldaemon.com...

Walter

A while back I mentioned that it would be nice to allow auto





 to
 be

constructed without the (syntactically consistent but semantically
misleading) new syntax. In other words

            auto ExeModule xmod =   new ExeModule(moduleName);

could be written as the more accurate

            ExeModule xmod(moduleName);

If memory serves, you liked this, but it's not yet implemented. Are



plans to do this? Is it as simple as it seems to be to implement?

As the other respondents pointed out, there are many parsing issues




 be
 worked out to make this work. I think we'll leave it as is for the



 being.

What about this one? auto ExeModule xmod(moduleName);

That's good. Can we have that Walter?


Jan 14 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Matthew wrote:

But auto instances do not exist on the heap and, for me at least, new says
"create one of these on the heap".

I grant you, or anyone else, that new actually has two functions, and my
focus on the heap side (as opposed to the construction side) is undoubtedly
from my C++ thinking

  

What about: ExeModule xmod = auto ExeModule(moduleName); then?
"C" <dont respond.com> wrote in message
news:bu4fqf$2guo$1 digitaldaemon.com...
  

Honestly I kind of like the current syntax.  I think one of the gotchas
moving from C++ is forgetting to new everything , if we require the same
syntax it will drive home that everything must be new'ed.

C

    


Jan 14 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:bu51da$ah3$1 digitaldaemon.com...


"C" <dont respond.com> wrote in message
news:bu4fqf$2guo$1 digitaldaemon.com...


Honestly I kind of like the current syntax.  I think one of the gotchas
moving from C++ is forgetting to new everything , if we require the same
syntax it will drive home that everything must be new'ed.

C


Matthew wrote:
But auto instances do not exist on the heap and, for me at least, new


"create one of these on the heap".

I grant you, or anyone else, that new actually has two functions, and my
focus on the heap side (as opposed to the construction side) is


from my C++ thinking

What about: ExeModule xmod = auto ExeModule(moduleName); then?

That's almost as verbose as it already is auto ExeModule xmod = new ExeModule(moduleName); I really think auto ExeModule xmod(moduleName); is the best compromise. It's not ambiguous wrt local function declarations, and it's pretty clear what's going on. Walter?
Jan 14 2004
next sibling parent Alix Pexton <Alix thedjournal.com> writes:
I admit that I haven't really thought about it, but the way D reuses the 
'this' keyword gave me an idea...

ExeModule xmod = auto(moduleName);

how does that do?
I don't realy like it my self, but I think the statement *needs* to have 
an equals in it, so that non D-adepts can look at it and know it is 
declaring a variable.

If it were unambiguous, I suspect that the following would also be 
possible for non-auto instances...

SomeClass obj = new(parameters);

which has the same non-replication.

Like I said I don't actually like this form myself, but I felt I had to 
share.

Alix...


Matthew wrote:

What about:

ExeModule xmod = auto ExeModule(moduleName);

then?
    

That's almost as verbose as it already is auto ExeModule xmod = new ExeModule(moduleName); I really think auto ExeModule xmod(moduleName); is the best compromise. It's not ambiguous wrt local function declarations, and it's pretty clear what's going on. Walter?

-- Alix Pexton Webmaster - http://www.theDjournal.com Alix theDjournal.com
Jan 15 2004
prev sibling parent reply davepermen <davepermen_member pathlink.com> writes:
auto ExeModule xmod(moduleName);


I'd prefer ExeModule xmod = auto(moduleName); somehow.. i don't like the constructor parameters bound to the object.. looks like an opCall for me, dunno how nice to parse.. or ExeModule(moduleName) xmod; that would be best possibly. not even an auto needed. why is that best? because constructor gets called the very same way, just not on a new-ed object ( = new ExeModule(moduleName); ), but directly on the stack (just as int x, the int will be on the stack).. i think the last proposial of me is the most logical one. more logical than the c++ way at least. its the same as int[] x; instead of int x[]; and Type(params) name; would be unambiguous to parse. and short. and understandable. doesn't even require the auto keyword then anymore. wich is a good thing imho.. oh, and.. if the constructor has no parameters, you still have to call it with Type() name; this could even be standard. instanciate an object of some type has to be done with Type(...). if you want it on the gc-heap, you new it. else, you just use it (and then, it will behave stackbased..) Type(); unnamed object on the stack new Type(); unnamed object on the heap Type; unnamed reference Type name; named reference Type name = new Type(); named reference to an unnamed object on the heap Type name = Type(); named reference to an unnamed object on the stack Type() name; named object on the stack new Type() name; named object on the heap :D hehe, fun:D
Jan 15 2004
next sibling parent Georg Wrede <Georg_member pathlink.com> writes:
I like this!!

This way the language makes it very clear that we are doing
two different kinds of things. Even newbies would spot this
easily. 

"Simplicity, clarity, generality." Kernighan & Pike


In article <bu73om$o91$1 digitaldaemon.com>, davepermen says...
..
i think the last proposial of me is the most logical one. more
logical than the c++ way at least.

its the same as

int[] x;

and

Type(params) name; would be unambiguous to parse. and short. and
understandable. Doesn't even require the auto keyword then anymore.
wich is a good thing imho..

oh, and.. if the constructor has no parameters, you still have to
call it with Type() name;

this could even be standard. instanciate an object of some type has
to be done with Type(...). if you want it on the gc-heap, you new it.
Else, you just use it (and then, it will behave stackbased..)

Type(); unnamed object on the stack
new Type(); unnamed object on the heap
Type; unnamed reference
Type name; named reference
Type name = new Type(); named reference to an unnamed object on the heap
Type name = Type(); named reference to an unnamed object on the stack
Type() name; named object on the stack
new Type() name; named object on the heap :D

Jan 16 2004
prev sibling parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <bu73om$o91$1 digitaldaemon.com>, davepermen wrote:
auto ExeModule xmod(moduleName);


I'd prefer ExeModule xmod = auto(moduleName); somehow.. i don't like the constructor parameters bound to the object.. looks like an opCall for me, dunno how nice to parse.. or ExeModule(moduleName) xmod;

For some reason, this one actually seems an incredibly good. It just seems as if it's the one syntax everybody's been hunting down all the time. It might have small but solvable parsing issues (the part before "xmod" first looks like a function call) and it just might not be the perfect one, but I like the terseness and consistency with "new ExeModule(moduleName)" Yet I think that the following should mean the same: ExeModule() xmod; // instantiate ExeModule with no args ExeModule xmod; // instantiate ExeModule with no args You know, "do as the ints do". And if there's no need to sprinkle superfluous parentheses around, I'd rather not. -Antti
Jan 18 2004
next sibling parent Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <slrnc0mcde.f82.jsykari pulu.hut.fi>, Antti Sykäri wrote:
 In article <bu73om$o91$1 digitaldaemon.com>, davepermen wrote:
auto ExeModule xmod(moduleName);


I'd prefer ExeModule xmod = auto(moduleName); somehow.. i don't like the constructor parameters bound to the object.. looks like an opCall for me, dunno how nice to parse.. or ExeModule(moduleName) xmod;

For some reason, this one actually seems an incredibly good. It just seems as if it's the one syntax everybody's been hunting down all the time.

*Ahem* I probably was in an imaginary wonderland where saying ExeModule xmod; would indicate declaring a variable of type xmod _and_ instantiating it using the default constructor. In the D as we know it, it may or may not instantiate an object of type xmod, depending on its kind (class objects are not instantiated, struct objects are.) Now it would be silly if a class object suddenly _would_ be instantiated if it's just marked "auto". The policy of how to create an object should not be controlled by whether it's a representative of a "class", or a "struct", or an "auto class", however obvious it is to the seasoned programmer who knows how these concepts are implemented (and who never makes mistakes anyway). The rules could be simplified to some extent if "ExeModule() xmod" would instantiate the object it but "ExeModule xmod" wouldn't. But then we are in the C++ land where "Foo bar();" means a different thing than "Foo bar;", and confusing the two causes diabolically cryptical parse errors since the former is a function declaration and the latter is a variable declaration. In other words: don't go there. *However* -- I'm not quite out of silly ideas yet -- what if *all* references were explicitly marked so instead of being implicitly determined by the "classness" of an object? Let's create a new kind of derived type, "reference type" -- which acts precisely like class object types do, namely that objects are treated by reference as opposed to by value. This means effectively pointers with implicit address-taking and dereferencing. Then introduce the rule that all objects, whether they be struct or class or fundamental type, are by value by default and by reference only if marked as so. Since these references are not the same references as C++ has, and because C++ has an awfully confusing syntax for them, we don't use C++ syntax. Instead let's adopt the syntax "ref Type" (originally from Algol 68). Examples: class Object { this() { ... } this(int x) { ... } } struct Struct { this() { ... } this(int x) { ... } } void main() { int i; // an int, initialized to 0. int j = 5; // an int, initialized to 5. int(5) j; // the same, using the cool syntax invented by davepermen. ref Struct a; // a reference to a Struct, initialized to null. ref Struct b = new Struct(5); // reference to a struct, new'ed from the heap ref Struct(5) c; // same as above. (maybe?) Struct d; // a Struct, initialized to default value Struct(5) e; // do as the ints do! // With objects, everything is the same except they can't be // instantiated on the stack. ref Object x; // Reference to Object, initialized to null. ref Object y = new Object(5); // Do like the structs do. :) ref Object(5) z; // likewise Object w; // Illegal! You can only make references of class types Object(5) v; // Illegal as well. // Actually, why not the following as well, if need be: ref int = new int(5); // do as the structs do! ;) } Perhaps "ref" could be similar property like "auto", so that you can declare "ref class ClassName { ... }" and then they would be all by reference. OTOH then you wouldn't know whether you're looking at a reference or a normal variable if you see a declaration somewhere. So just perhaps. Now why would this be good? a) overall simplicity and consistency in the language which leads to: b) seamless migration from structs to classes. You can use structs and pass them around using references, and if you need dynamic behavior you can change them to classes with no change in semantics at all. And vice versa! (Ignoring the fact that constructors do not (yet?) properly work for structs, is that correct) c) no need to think "should I make this concept a struct or a class" -- just pick one, you can change it later if needed d) even less need to use pointers (now that structs can be passed by reference) and, most importantly, e) no newbies asking "Why does my program 'MyClass x; x.helloWorld();' fail" I don't really know just *how* important (e) would be, but guess it wouldn't hurt either. Besides everybody is supposed to know Java (tm) nowadays so I guess everybody knows how to avoid the dreaded NullPointerException. Not all roses and sunshine here though. Some bad sides of making reference types explicit that I can think of are: a) it's a move that would require significant re-engineering of the language; For example, do function argument passing modes need to be rethought? How? b) there might be non-obvious semantical gaps in the language after the change (well, probably more than there are now at least); For example, how do references to references behave? c) doing it differently from The Big Languages, C# and Java, is always risky (as if it mattered before) ...All right, maybe I'll implement it in my OWN language (some day!) -Antti
Jan 18 2004
prev sibling parent Hauke Duden <H.NS.Duden gmx.net> writes:
Antti Sykäri wrote:
ExeModule(moduleName) xmod;

For some reason, this one actually seems an incredibly good. It just seems as if it's the one syntax everybody's been hunting down all the time. It might have small but solvable parsing issues (the part before "xmod" first looks like a function call) and it just might not be the perfect one, but I like the terseness and consistency with "new ExeModule(moduleName)" Yet I think that the following should mean the same: ExeModule() xmod; // instantiate ExeModule with no args ExeModule xmod; // instantiate ExeModule with no args

That's the problem: the last one is already used to create a reference. And I think the one before is too close to the reference thing - there should be some more noticeable difference. However, I agree that having the arguments after the class name does seem "right" and is more consistent with the rest of the language (i.e. the new syntax). So, what about auto ExeModule(moduleName) xmod; This makes it more obvious that you're dealing with an auto object and at the same time it solves the minor parsing issue you mentioned. Hauke
Jan 19 2004
prev sibling parent "Ben Hinkle" <bhinkle4 juno.com> writes:
auto, as written in the D doc, is independent of where the object is
allocated. In fact I can't find anything in the dmd source that indicates it
is on the stack. I think it would be tricky to allocate on the stack
currently because the compiler would have to know from a statement like
 auto Class x = new Subclass();
to ignore the size of Class and use the size of Subclass. Also what about
 auto Class x = something_that_returns_an_object();

I agree the C/C++ programmer would see auto and think "stack" but that is a
different problem.

-Ben

"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:bu4uou$6bv$1 digitaldaemon.com...
 But auto instances do not exist on the heap and, for me at least, new says
 "create one of these on the heap".

 I grant you, or anyone else, that new actually has two functions, and my
 focus on the heap side (as opposed to the construction side) is

 from my C++ thinking


 "C" <dont respond.com> wrote in message
 news:bu4fqf$2guo$1 digitaldaemon.com...
 Honestly I kind of like the current syntax.  I think one of the gotchas
 moving from C++ is forgetting to new everything , if we require the same
 syntax it will drive home that everything must be new'ed.

 C


 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:bu35b2$bii$1 digitaldaemon.com...
 "Hauke Duden" <H.NS.Duden gmx.net> wrote in message
 news:bu357d$b60$1 digitaldaemon.com...
 Walter wrote:
 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:bt0gqk$ion$1 digitaldaemon.com...

Walter

A while back I mentioned that it would be nice to allow auto





 to
 be

constructed without the (syntactically consistent but semantically
misleading) new syntax. In other words

            auto ExeModule xmod =   new ExeModule(moduleName);

could be written as the more accurate

            ExeModule xmod(moduleName);

If memory serves, you liked this, but it's not yet implemented.






 there
plans to do this? Is it as simple as it seems to be to implement?

As the other respondents pointed out, there are many parsing





 to
 be
 worked out to make this work. I think we'll leave it as is for the



 being.

What about this one? auto ExeModule xmod(moduleName);

That's good. Can we have that Walter?



Jan 16 2004