"John Reimer" <John_member@pathlink.com> wrote in message news:djp8g4$fj9$1@digitaldaemon.com...
> In article <djopo5$29m$1@digitaldaemon.com>, Sean Kelly says...
> >
> >In article <djoo2b$lv$1@digitaldaemon.com>, John Reimer says...
> >>
> >>One note, though.  It won't work in it's current form.  Having the
ability
> >>to apply extern(linkage) for nested functions is primarily useful for OS callback methods; but as implemented right now, this is not possible
because
> >>the nested functions are seen solely as /delegates/ not /function
pointers/.
> >
> >Try this:
> >
> >>void init( UPDATE_EVENT_W fc )
> >>{
> >> extern(Windows) int func1( int a, int b )
> >
> >static extern(Windows) int func1( int a, int b )
> >
> >
> >Sean
> >
> >
>
> I tried that already and numerous other combinations.  Nothing worked.
>
> Did you actually get that to work?

Yes, but it's:

    extern (Windows) static int func1(int a, int b) ...

"Bruno Medeiros" <daiphoenixNO@SPAMlycos.com> wrote in message news:djosi1$5b9$1@digitaldaemon.com...
> Whoa, you lost me there. Are you talking about the current DMD.127 situation,

The current version is 0.137 <g>

> or your alternative proposal? It seems you are talking about
> your new proposal, however that (quoted) comment of mine was relative to
> the current DMD.127 situation.
> I'm still kinda lost because the following statement will be false
> nomatter what situation you were refering to: "All 'auto' declarations
> will be destroyed when they go out of scope." (I assume "'auto'
> declaration" is any with a 'auto' keyword in there)
> There is an error or misunderstanding here somewhere.

The statement will remain true, and that's because class declarations are only for *references* to a class, not instances. The auto reference will always go away at the end of the scope. Whether the instance does or not depends on if it is on the class or the stack. The way the initializer is written determines if it is a stack or a heap instance.

"Dave" <Dave_member@pathlink.com> wrote in message news:djoku3$2v3p$1@digitaldaemon.com...
> Could we do stuff like this (w/o the new/delete member overrides)?:

Yes.

Sean Kelly wrote:
> In article <djo5n4$2cqp$1@digitaldaemon.com>, Sean Kelly says...
> 
>>classname c = classname(arguments);
>>classname c = new classname(arguments);
> 
> 
> Oops, I meant:
> 
> classname c = classname(arguments);
> classname* c = new classname(arguments);
> 

I hope not. Just as we all got used to objects-are-references this would break everything.

> What would be ideal is if this syntax applied to all D types:
> 

With this i agree, but value types and reference types are different and they should be treated different (at least it is that way, for example, in C#). So i don't know what is the solution to the problems in templates but new returning a pointer is returning to C++ and i don't like it.

> int x = int(5);
> int* x = new int(5);
> 
> etc.  This makes instantiation easier to accomplish in template code as the
> syntax is consistent.  I'm not certain whether the ambiguity with opCall will be
> a problem however, as it's essentially a matter of overload resolution.  So long
> as static opCall functions and class ctors don't have the same parameter list I
> don't think the compiler will complain.
> 
> 
> Sean
> 
> 

In article <djr50f$4pr$3@digitaldaemon.com>, Walter Bright says...
>
>The statement will remain true, and that's because class declarations are only for *references* to a class, not instances. The auto reference will always go away at the end of the scope. Whether the instance does or not depends on if it is on the class or the stack. The way the initializer is written determines if it is a stack or a heap instance.

Interesting.  So the variable would be declared the same either way?  Would such a design support returning classes by value?  ie.

MyClass getInstance() {
MyClass c = MyClass();
return c;
}

From what you're saying, this sounds like it would produce undefined behavior. And in large function calls, this could be an easy mistake to make.  Why omit the need for pointer semantics for heap-based classes?  I'd think it would offer a degree of checking that the handle-based syntax doesn't:

MyClass* getInstance() {
MyClass c = MyClass();
return c; // error: cannot convert MyClass to MyClass*
}


Sean

Walter Bright wrote:
> "Bruno Medeiros" <daiphoenixNO@SPAMlycos.com> wrote in message
> news:djnlj6$1nbv$1@digitaldaemon.com...
> 
>>But I must say I too don't like having auto (type) share the same name
>>as the unrelated (RAII) auto. Not only it has now that pratical problem
>>of not being able to declare an "auto auto" object, but conceptually as
>>well I don't think it's good to have two keywords with the same name who
>>do quite different things. (remeber C's static ... ugh :P )
> 
> 
> But I think it is completely related! All 'auto' declarations will be
> destroyed when they go out of scope. Remember that class declarations only
> give references to class objects, not class objects themselves. So,
> class(args) creates a stack class object, which is destroyed when it goes
> out of scope. new class(args) creates one on the heap, which is not.
> 
> 
Ok, I've re-read this statement after your other explanation. I still find some things to be in error. In "All 'auto' declarations will be destroyed when they go out of scope", I read "destroyed" as refering to the object of the declaration (the instance), not the reference of course. The reference, being a local pointer, is obviously allocated on stack and is destroyed at the end of the scope. I would have to be seriously out-of-place/unknowledgeable to think otherwise.
So, "All 'auto' declarations will be destroyed when they go out of scope" is false, since by "'auto' declarations" one should interpret as the objects created (instances), not the references. Namely, here are two auto declarations, taken from the docs, where the statement is false on the first one:

auto c = new C();   // c is not RAII , is auto-typed
auto C d = new C(); // c is RAII, is not auto-typed

Also, This goes back to my original post, and clarifies what I meant by having the keyword 'auto' have two different meanings.

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

Sean Kelly wrote:
> In article <djr50f$4pr$3@digitaldaemon.com>, Walter Bright says...
> 
>>The statement will remain true, and that's because class declarations are
>>only for *references* to a class, not instances. The auto reference will
>>always go away at the end of the scope. Whether the instance does or not
>>depends on if it is on the class or the stack. The way the initializer is
>>written determines if it is a stack or a heap instance.
> 
> 
> Interesting.  So the variable would be declared the same either way?  Would such
> a design support returning classes by value?  ie.
> 
> MyClass getInstance() {
> MyClass c = MyClass();
> return c;
> }
> 
> From what you're saying, this sounds like it would produce undefined behavior.

As it would in C++, at the end of scope c is dead.

> And in large function calls, this could be an easy mistake to make.  Why omit

Indeed.

> the need for pointer semantics for heap-based classes?  I'd think it would offer
> a degree of checking that the handle-based syntax doesn't:
> 
> MyClass* getInstance() {
> MyClass c = MyClass();
> return c; // error: cannot convert MyClass to MyClass*
> }
> 

Yuck.
With stack based class objects we are getting big bunch of problems with returning destructed objects. Is it really a good idea to have stack-based classes? We have lived without them for a long time in D.
And although i can see that they have some advantages (like speed) but it looks to me they bring big problems to the language.

> 
> Sean
> 
> 

Bruno Medeiros wrote:
> 
> auto c = new C();   // c is not RAII , is auto-typed
> auto C d = new C(); // c is RAII, is not auto-typed
> 

Shouldn't it be:

type c = new type(args); //type not infered, no RAII
auto c = new type(args); //type infered, no RAII
type c = type(args);     //type not infered, RAII
auto c = type(args);     //type infered, RAII

At least this is what i figured out it should be, so:
auto means type is infered, no new means RAII.

> Also, This goes back to my original post, and clarifies what I meant by having the keyword 'auto' have two different meanings.
> 

In article <djrata$jac$1@digitaldaemon.com>, Ivan Senji says...
>
>Sean Kelly wrote:
>> In article <djo5n4$2cqp$1@digitaldaemon.com>, Sean Kelly says...
>> 
>>>classname c = classname(arguments);
>>>classname c = new classname(arguments);
>> 
>> 
>> Oops, I meant:
>> 
>> classname c = classname(arguments);
>> classname* c = new classname(arguments);
>> 
>I hope not. Just as we all got used to objects-are-references this would break everything.

Yes, but it would do so very obviously and be quite simple to fix, since value semantics don't exist for classes right now.

>> What would be ideal is if this syntax applied to all D types:
>> 
>With this i agree, but value types and reference types are different and they should be treated different (at least it is that way, for example, in C#). So i don't know what is the solution to the problems in templates but new returning a pointer is returning to C++ and i don't like it.

As I said in my other post, I'm not sure whether return by value will work with the existing handle semantics.  And without return by value, this would be little more than in-language support for alloca(), which is not sufficient to solve the problems normally handled by stack-based UDTs.  That said, true value semantics for stack-based classes raises a bunch of other issues as well--such as the need for copy ctors and the like--which may well turn out to be a big can of worms.  I know that Walter is also (understandably) not particularly fond of this aspect of C++, so I plan to Wait and See insofar as this particular feature is concerned.  I very much like the idea of stack-based classes, but I think the design will require some care to get right.  And I certainly do not expect this to be a direct port of the features as they exist in C++ :-)


Sean

In article <djrbo0$lkk$1@digitaldaemon.com>, Ivan Senji says...
>
>With stack based class objects we are getting big bunch of problems with returning destructed objects. Is it really a good idea to have stack-based classes? We have lived without them for a long time in D. And although i can see that they have some advantages (like speed) but it looks to me they bring big problems to the language.

I very much agree.  But as Walter said, there is a certain class of problems that require stack-based behavior to be easily solvable.  I think a careful, explicit use of handles might resolve this in some instances, but as Regan's smart pointer example shows, this is not particularly natural in D and is very prone to programmer error.  I believe there must be a more elegant way to implement value semantics than how they are handled in C++, perhaps this is mostly a matter of finding it.


Sean