www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 0.137 release

reply "Walter Bright" <newshound digitalmars.com> writes:
A couple of oft-requested features.

http://www.digitalmars.com/d/changelog.html
Oct 24 2005
next sibling parent Sean Kelly <sean f4.ca> writes:
In article <djjpa0$1o9n$2 digitaldaemon.com>, Walter Bright says...
A couple of oft-requested features.

Very nice! Sean
Oct 24 2005
prev sibling next sibling parent reply Vathix <chris dprogramming.com> writes:
On Mon, 24 Oct 2005 19:02:00 -0400, Walter Bright  
<newshound digitalmars.com> wrote:

 A couple of oft-requested features.

 http://www.digitalmars.com/d/changelog.html

On http://www.digitalmars.com/d/declaration.html#AutoDeclaration that anchor does not seem to exist and I can not find the word inference.
Oct 24 2005
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Vathix" <chris dprogramming.com> wrote in message
news:op.sy6bxz0dl2lsvj esi...
 On http://www.digitalmars.com/d/declaration.html#AutoDeclaration that
 anchor does not seem to exist and I can not find the word inference.

I hadn't posted the updated doc yet. It's there now.
Oct 24 2005
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter Bright wrote:
 "Vathix" <chris dprogramming.com> wrote in message
 news:op.sy6bxz0dl2lsvj esi...
 
On http://www.digitalmars.com/d/declaration.html#AutoDeclaration that
anchor does not seem to exist and I can not find the word inference.

I hadn't posted the updated doc yet. It's there now.

Cool, Implicit Type Inference! However, I think that the problems with overloading the "auto" keyword to declare it are made obvious by the special case you had to define with classes. That's sure to bite people with strange, subtle bugs. Plus, such special cases make templates harder to write. Say you were defining a mixin where it would be useful to have both: template Foo(alias func) { auto foo = func(); // drat, can't use both implicit types and auto } void main() { Foo(myFunc); ...stuff... }
Oct 25 2005
parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Russ Lewis wrote:
 
 Cool, Implicit Type Inference!
 

I agree.
 However, I think that the problems with overloading the "auto" keyword 
 to declare it are made obvious by the special case you had to define 
 with classes.  That's sure to bite people with strange, subtle bugs. 
 Plus, such special cases make templates harder to write.  Say you were 
 defining a mixin where it would be useful to have both:
 
 template Foo(alias func) {
   auto foo = func();  // drat, can't use both implicit types and auto
 }
 
 void main() {
   Foo(myFunc);
   ...stuff...
 }

And i also agree. This way you cannot have auto objects with type inference and it is a problem. Couldn't another keywoard be added for type inference? Many have been suggested (autotype, var, ...).
Oct 25 2005
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message
news:djlqvi$2tn$1 digitaldaemon.com...
 And i also agree. This way you cannot have auto objects with type
 inference and it is a problem. Couldn't another keywoard be added for
 type inference? Many have been suggested (autotype, var, ...).

I've tried to stay away from 'var', it reminds me of Pascal too much <g>. Anyhow, I've thought about this problem a lot, and there is an answer for it that is simple and consistent. It's just a bit of work to implement :-(.
Oct 25 2005
next sibling parent reply "Uwe Salomon" <post uwesalomon.de> writes:
 And i also agree. This way you cannot have auto objects with type
 inference and it is a problem. Couldn't another keywoard be added for
 type inference? Many have been suggested (autotype, var, ...).

I've tried to stay away from 'var', it reminds me of Pascal too much <g>. Anyhow, I've thought about this problem a lot, and there is an answer for it that is simple and consistent. It's just a bit of work to implement :-(.

Huh? Could you please explain that briefly? I am currently writing a compiler myself, and i thought a lot about this problem. Declarations and expressions can look very similar at the beginning, and it requires a lot of lookahead for the parser to decide between the two (which is annoying, as the lexer is more difficult then). I fumbled around with "var" and friends, too, but it looks so annoying if you have to write it everywhere. Associative arrays in the current syntax are sometimes simply undistinguishable from static arrays without context knowledge (so the D language is not 100% context-free), as in: char[something] x; To decide if x is a static or associative array, you need to know whether "something" is a type or a constant. I have not found a nice solution for this problem yet (things like char[type something] look rather disgusting). By the way, this problem is quite similar to the C cast syntax (where the parser is also unable to decide between type and expression). Ciao uwe
Oct 25 2005
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Uwe Salomon" <post uwesalomon.de> wrote in message
news:op.sy7vgtpb6yjbe6 sandmann.maerchenwald.net...
 Huh? Could you please explain that briefly? I am currently writing a
 compiler myself, and i thought a lot about this problem. Declarations and
 expressions can look very similar at the beginning, and it requires a lot
 of lookahead for the parser to decide between the two (which is annoying,
 as the lexer is more difficult then). I fumbled around with "var" and
 friends, too, but it looks so annoying if you have to write it everywhere.

Yes, I've (obviously) run into the same problems. It's not an LALR(1) grammar (one token lookahead), but doing LALR(1) would have compromised the look & feel I was trying to achieve. So arbitrary lookahead (LALR(n)) is needed. (A nit: it isn't a lexer problem, it's a parsing problem.) The lexer was designed from the start so that arbitrary lookahead is easy to do.
 Associative arrays in the current syntax are sometimes simply
 undistinguishable from static arrays without context knowledge (so the D
 language is not 100% context-free), as in:

 char[something] x;

 To decide if x is a static or associative array, you need to know whether
 "something" is a type or a constant. I have not found a nice solution for
 this problem yet (things like char[type something] look rather
 disgusting). By the way, this problem is quite similar to the C cast
 syntax (where the parser is also unable to decide between type and
 expression).

This isn't a big problem to deal with, because the resulting parse tree is the same whether it turns out to be a static array or an associative array. The D parser just creates it as an associative array. If the identifier turns out during semantic analysis not to be a type, but an expression, the type is rewritten as a static array. Since the parse tree remains the same, I believe it technically is a context-free grammar.
Oct 25 2005
parent Dave <Dave_member pathlink.com> writes:
In article <djmgi7$1jtr$2 digitaldaemon.com>, Walter Bright says...
"Uwe Salomon" <post uwesalomon.de> wrote in message
news:op.sy7vgtpb6yjbe6 sandmann.maerchenwald.net...
 Huh? Could you please explain that briefly? I am currently writing a
 compiler myself, and i thought a lot about this problem. Declarations and
 expressions can look very similar at the beginning, and it requires a lot
 of lookahead for the parser to decide between the two (which is annoying,
 as the lexer is more difficult then). I fumbled around with "var" and
 friends, too, but it looks so annoying if you have to write it everywhere.

Yes, I've (obviously) run into the same problems. It's not an LALR(1) grammar (one token lookahead), but doing LALR(1) would have compromised the look & feel I was trying to achieve. So arbitrary lookahead (LALR(n)) is needed. (A nit: it isn't a lexer problem, it's a parsing problem.) The lexer was designed from the start so that arbitrary lookahead is easy to do.
 Associative arrays in the current syntax are sometimes simply
 undistinguishable from static arrays without context knowledge (so the D
 language is not 100% context-free), as in:

 char[something] x;

 To decide if x is a static or associative array, you need to know whether
 "something" is a type or a constant. I have not found a nice solution for
 this problem yet (things like char[type something] look rather
 disgusting). By the way, this problem is quite similar to the C cast
 syntax (where the parser is also unable to decide between type and
 expression).

This isn't a big problem to deal with, because the resulting parse tree is the same whether it turns out to be a static array or an associative array. The D parser just creates it as an associative array. If the identifier turns out during semantic analysis not to be a type, but an expression, the type is rewritten as a static array. Since the parse tree remains the same, I believe it technically is a context-free grammar.

FWIW, I've been playing around with this code recently and it is a beauty to behold how it all comes together (and runs damn fast as well!).
Oct 25 2005
prev sibling parent reply Sai <Sai_member pathlink.com> writes:
Is the answer for it is to use a new keyword or to make the compiler smarter ?
Just curious 
:D
Sai


In article <djlsi7$4u4$1 digitaldaemon.com>, Walter Bright says...
"Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message
news:djlqvi$2tn$1 digitaldaemon.com...
 And i also agree. This way you cannot have auto objects with type
 inference and it is a problem. Couldn't another keywoard be added for
 type inference? Many have been suggested (autotype, var, ...).

I've tried to stay away from 'var', it reminds me of Pascal too much <g>. Anyhow, I've thought about this problem a lot, and there is an answer for it that is simple and consistent. It's just a bit of work to implement :-(.

Oct 25 2005
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Sai" <Sai_member pathlink.com> wrote in message
news:djm1oj$p58$1 digitaldaemon.com...
 Is the answer for it is to use a new keyword or to make the compiler

It's implementing class objects on the stack with the: classname(constructor arguments) syntax. Then, an RAII class object would be: auto c = classname(arguments); and a non-RAII class object would be: auto c = new classname(arguments); and the old RAII syntax would be supported as: auto classname c = new classname(arguments); and eventually deprecated.
Oct 25 2005
next sibling parent reply "Dave" <Dave_member pathlink.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:djmgi6$1jtr$1 digitaldaemon.com...
 "Sai" <Sai_member pathlink.com> wrote in message
 news:djm1oj$p58$1 digitaldaemon.com...
 Is the answer for it is to use a new keyword or to make the compiler

It's implementing class objects on the stack with the: classname(constructor arguments) syntax. Then, an RAII class object would be: auto c = classname(arguments); and a non-RAII class object would be: auto c = new classname(arguments);

Hot damn!
 and the old RAII syntax would be supported as:

    auto classname c = new classname(arguments);

 and eventually deprecated.

 

Oct 25 2005
parent "Walter Bright" <newshound digitalmars.com> writes:
"Dave" <Dave_member pathlink.com> wrote in message
news:djmm80$1sm8$1 digitaldaemon.com...
 Hot damn!

It's still a bit low down on the priority list, though.
Oct 25 2005
prev sibling next sibling parent reply Carlos Santander <csantander619 gmail.com> writes:
Walter Bright escribió:
 "Sai" <Sai_member pathlink.com> wrote in message
 news:djm1oj$p58$1 digitaldaemon.com...
 
Is the answer for it is to use a new keyword or to make the compiler

smarter ? It's implementing class objects on the stack with the: classname(constructor arguments) syntax. Then, an RAII class object would be: auto c = classname(arguments);

Regarding this case, what's gonna happen if "static classname.opCall(whatever)" has been defined?
 and a non-RAII class object would be:
 
     auto c = new classname(arguments);
 
 and the old RAII syntax would be supported as:
 
     auto classname c = new classname(arguments);
 
 and eventually deprecated.
 
 

-- Carlos Santander Bernal
Oct 25 2005
parent "Lionello Lunesu" <lio remove.lunesu.com> writes:
"Carlos Santander" <csantander619 gmail.com> wrote in message 
news:djmpd1$25oa$1 digitaldaemon.com...
 Walter Bright escribió:
 "Sai" <Sai_member pathlink.com> wrote in message
 news:djm1oj$p58$1 digitaldaemon.com...

Is the answer for it is to use a new keyword or to make the compiler

smarter ? It's implementing class objects on the stack with the: classname(constructor arguments) syntax. Then, an RAII class object would be: auto c = classname(arguments);

Regarding this case, what's gonna happen if "static classname.opCall(whatever)" has been defined?

I'm not really sure, but I guess you'll need an instance of a class for opCall to apply; there's no ambiguity here since the (..) applies to the class name. If I understood his comments correclty, Walter's not going to support classname c(arguments) for class construction. L.
Oct 27 2005
prev sibling next sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Walter Bright wrote:
 Then, an RAII class object would be:
 
     auto c = classname(arguments);
 
 and a non-RAII class object would be:
 
     auto c = new classname(arguments);

Are you serious? This would make code very unreadable. Having keywords with multiple meanings is bad enough, but when the context looks as similar as in this case then things will get confusing very quickly. IMHO the non-RAII keyword should be something different. I think many alternatives have already been proposed, but I'd like to add one. Not sure what this would mean for parsability, but I like how this looks: ... c = new classname(arguments); I.e. a new "..." keyword that represents an inferred type. Looks as if something was left out, which is exactly how it is. Hauke
Oct 26 2005
next sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Hauke Duden wrote:
 Walter Bright wrote:
 
 Then, an RAII class object would be:

     auto c = classname(arguments);

 and a non-RAII class object would be:

     auto c = new classname(arguments);

Are you serious? This would make code very unreadable. Having keywords with multiple meanings is bad enough, but when the context looks as similar as in this case then things will get confusing very quickly. IMHO the non-RAII keyword should be something different.

I just realized that maybe I misunderstood your plans. Do you mean that "auto" will only be used to represent a type and will not be directly connected to RAII anymore? I.e. would I also be able to create a RAII object like this? classname c = classname(arguments) In that case it would be easier to understand the concepts. However, readability would still suffer because auto c = classname(arguments); and auto c = new classname(arguments); look so similar. It would be really nice if the lines would look more different because the automatic destruction of c is such an important fact to realize. What about a C++ style syntax plus a keyword to make parsing easier? local classname c(arguments) Hauke
Oct 26 2005
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:djnhiv$1833$1 digitaldaemon.com...
 I just realized that maybe I misunderstood your plans. Do you mean that
 "auto" will only be used to represent a type and will not be directly
 connected to RAII anymore? I.e. would I also be able to create a RAII
 object like this?

 classname c = classname(arguments)

Yes.
 In that case it would be easier to understand the concepts. However,
 readability would still suffer because

 auto c = classname(arguments);

 and

 auto c = new classname(arguments);

 look so similar. It would be really nice if the lines would look more
 different because the automatic destruction of c is such an important
 fact to realize.

I think it makes logical sense, one expects new to allocate on the heap, and non-new to allocate on the stack.
 What about a C++ style syntax plus a keyword to make parsing easier?

 local classname c(arguments)

The "function style" constructors in C++ declarations cause a lot of ambiguity problems. Parsing of the auto c = classname(args) is easy. The work comes in keeping careful track of when to insert the destructors.
Oct 26 2005
parent Sean Kelly <sean f4.ca> writes:
In article <djodvq$2nvh$2 digitaldaemon.com>, Walter Bright says...
"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
 What about a C++ style syntax plus a keyword to make parsing easier?

 local classname c(arguments)

The "function style" constructors in C++ declarations cause a lot of ambiguity problems. Parsing of the auto c = classname(args) is easy. The work comes in keeping careful track of when to insert the destructors.

I very much agree. Unless function prototypes become illegal in D I would very much prefer to use a non-ambiguous class construction syntax. The C++ method can cause all sorts of subtle errors, and I've yet to meet a programmer who routinely constructs classes in a way that prevents them: MyClass c( (p1), p2, p3 ); The above doesn't seem natural and looks a bit odd. I also don't like that C++ baically offers two different ways to construct types: T t(val); T t = T(val); While the optimizer can make these effectively equivalent, the rules surrounding the need for a copy ctor and assignment operator in C++ are not particularly intuitive, and a lot of that has to do with the need to support both construction formats. Sean
Oct 26 2005
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <djnghp$13ob$1 digitaldaemon.com>, Hauke Duden says...
Walter Bright wrote:
 Then, an RAII class object would be:
 
     auto c = classname(arguments);
 
 and a non-RAII class object would be:
 
     auto c = new classname(arguments);

Are you serious? This would make code very unreadable. Having keywords with multiple meanings is bad enough, but when the context looks as similar as in this case then things will get confusing very quickly.

I think Walter's example is of an auto typed class declaration. You would also be able to instantiate a class like so: classname c = classname(arguments); classname c = new classname(arguments); At the same time, the old RAII meaning of auto would be deprecated, as it's no longer needed if you can allocate classes on the stack.
IMHO the non-RAII keyword should be something different. I think many 
alternatives have already been proposed, but I'd like to add one. Not 
sure what this would mean for parsability, but I like how this looks:

... c = new classname(arguments);

I.e. a new "..." keyword that represents an inferred type. Looks as if 
something was left out, which is exactly how it is.

I'm not sure I like it--it reminds me too much of implicitly declared variables in other languages. It could also lead to subtle errors: int myValue; myvalue = 5; With a token like 'auto' the programmer is able to explicitly declare which expressions are declarations. Sean
Oct 26 2005
parent reply Sean Kelly <sean f4.ca> writes:
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); What would be ideal is if this syntax applied to all D types: 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
Oct 26 2005
parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
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
 
 

Oct 27 2005
parent Sean Kelly <sean f4.ca> writes:
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);

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:
 

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
Oct 27 2005
prev sibling next sibling parent reply Vathix <chris dprogramming.com> writes:
On Tue, 25 Oct 2005 19:15:12 -0400, Walter Bright  
<newshound digitalmars.com> wrote:

 "Sai" <Sai_member pathlink.com> wrote in message
 news:djm1oj$p58$1 digitaldaemon.com...
 Is the answer for it is to use a new keyword or to make the compiler

It's implementing class objects on the stack with the: classname(constructor arguments) syntax. Then, an RAII class object would be: auto c = classname(arguments); and a non-RAII class object would be: auto c = new classname(arguments); and the old RAII syntax would be supported as: auto classname c = new classname(arguments); and eventually deprecated.

I like it. Only problem I can think of is conflicts if the class has a static opCall. Perhaps classes should not have them (but they're very handy for structs/unions). This extra code in the compiler to support it could possibly be hacked in by adding an internal, implicit static opCall to all classes, which are translated to RAII constructors when invoked from an initializer ;)
Oct 26 2005
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Vathix" <chris dprogramming.com> wrote in message
news:op.sy8x7py7l2lsvj esi...
 I like it. Only problem I can think of is conflicts if the class has a
 static opCall. Perhaps classes should not have them

I'm hard pressed to see the point of them for classes anyway.
 (but they're very
 handy for structs/unions). This extra code in the compiler to support it
 could possibly be hacked in by adding an internal, implicit static opCall
 to all classes, which are translated to RAII constructors when invoked
  from an initializer ;)

There's more work to get all the details ironed out, but that is where I want to go. It's needed because there are a certain class of problems D doesn't work well without.
Oct 26 2005
next sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <djodvq$2nvh$3 digitaldaemon.com>, Walter Bright says...
There's more work to get all the details ironed out, but that is where I
want to go. It's needed because there are a certain class of problems D
doesn't work well without.

I'm glad to hear it :) This is the only real syntax-level issue I have with D, and it's a relief to know that it will be addressed at some point. Sean
Oct 26 2005
parent reply Sean Kelly <sean f4.ca> writes:
Sean Kelly wrote:
 In article <djodvq$2nvh$3 digitaldaemon.com>, Walter Bright says...
 
There's more work to get all the details ironed out, but that is where I
want to go. It's needed because there are a certain class of problems D
doesn't work well without.

I'm glad to hear it :) This is the only real syntax-level issue I have with D, and it's a relief to know that it will be addressed at some point.

Oh, one more question, is there any chance that this will allow static object composition as well? ie. class C {} class D { C c = C(); } Not a big deal, but it would be nice if the entire class could avoid the use of new rather than just the outer instantiation. The syntax seems a bit weird for this purpose (as the above doesn't allow for c to be constructed in D's ctor), but perhaps there's a way to clarify it somehow? Sean
Nov 02 2005
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Sean Kelly wrote:
 Oh, one more question, is there any chance that this will allow static 
 object composition as well?  ie.
 
 class C {}
 class D { C c = C(); }
 
 Not a big deal, but it would be nice if the entire class could avoid the 
 use of new rather than just the outer instantiation.  The syntax seems a 
 bit weird for this purpose (as the above doesn't allow for c to be 
 constructed in D's ctor), but perhaps there's a way to clarify it somehow?

I also think that it would be a good idea to handle static object composition with the same syntax as classes on the stack. In either case, we are really declaring a class-value variable rather than a class-reference variable.
Nov 02 2005
parent reply Sean Kelly <sean f4.ca> writes:
Russ Lewis wrote:
 
 I also think that it would be a good idea to handle static object 
 composition with the same syntax as classes on the stack.  In either 
 case, we are really declaring a class-value variable rather than a 
 class-reference variable.

Technically, it's a class reference to a stack instance as this change would not provide value semantics for classes. The distinction is clear when considering this: class C {} class D { C c; this() { c = C(); } this( int x ) { c = new C(); } } This is completely legal with the proposed semantics and would result in c referring to an invalid location if the default ctor is called. Currently, we can use placement new to fake static composition: class E { C c; ubyte[C.sizeof] buf; this() { c = new (&buf[0]) C(); } } (I'm just guessing at syntax here as I haven't actually tried this) but this raises alignment issues and such that a language-supported method does not have. Sean
Nov 02 2005
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Sean Kelly wrote:
 Russ Lewis wrote:
 
 I also think that it would be a good idea to handle static object 
 composition with the same syntax as classes on the stack.  In either 
 case, we are really declaring a class-value variable rather than a 
 class-reference variable.

Technically, it's a class reference to a stack instance as this change would not provide value semantics for classes. The distinction is clear when considering this: class C {} class D { C c; this() { c = C(); } this( int x ) { c = new C(); } } This is completely legal with the proposed semantics and would result in c referring to an invalid location if the default ctor is called. Currently, we can use placement new to fake static composition: class E { C c; ubyte[C.sizeof] buf; this() { c = new (&buf[0]) C(); } } (I'm just guessing at syntax here as I haven't actually tried this) but this raises alignment issues and such that a language-supported method does not have.

It's a hack on top of a hack on top of a hack. And it's all because we wanted to save typing * characters for our class variables. (sigh)
Nov 02 2005
parent reply Sean Kelly <sean f4.ca> writes:
Russ Lewis wrote:
 
 It's a hack on top of a hack on top of a hack.  And it's all because we 
 wanted to save typing * characters for our class variables.  (sigh)

I used to feel this way, but I'm coming around. Adding the pointer qualifier to heap-based classes has the unfortunate consequence of requiring value semantics for their stack-based equivalent. And while I do believe that user-defined value types can be quite useful in some circumstances, I think they also tend to be misused and are prone to creating code that is difficult to read. So long as the language has sufficient support for higher maths and such built-in (the complex type, vector ops, etc), I don't see a pressing need for value semantics in D. I think it's important to note that D differs fundamentally from C++ in that it does impose language-level restrictions in an attempt to reduce the amount of unreadable code and other sheer nastiness that is common in C++. But it also provides a lot of features C++ doesn't--built into the language--to eliminate the need for such nasty code in the first place. This definately fosters a different programming style than C++, but given the vast bulk of horrible C++ code I've encountered I think that's probably a good thing. Sean
Nov 02 2005
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Sean Kelly wrote:
 Russ Lewis wrote:
 
 It's a hack on top of a hack on top of a hack.  And it's all because 
 we wanted to save typing * characters for our class variables.  (sigh)

I used to feel this way, but I'm coming around. Adding the pointer qualifier to heap-based classes has the unfortunate consequence of requiring value semantics for their stack-based equivalent. And while I do believe that user-defined value types can be quite useful in some circumstances, I think they also tend to be misused and are prone to creating code that is difficult to read. So long as the language has sufficient support for higher maths and such built-in (the complex type, vector ops, etc), I don't see a pressing need for value semantics in D. I think it's important to note that D differs fundamentally from C++ in that it does impose language-level restrictions in an attempt to reduce the amount of unreadable code and other sheer nastiness that is common in C++. But it also provides a lot of features C++ doesn't--built into the language--to eliminate the need for such nasty code in the first place. This definately fosters a different programming style than C++, but given the vast bulk of horrible C++ code I've encountered I think that's probably a good thing.

Changing the syntax doesn't require you to change the functionality, just the syntax. I'm actually pretty happy about the development of the language over time. IMHO, it was a good idea to discard class-value variables at the start of development. We all argued out whether or not they were *really* necessary. Eventually, we came to the conclusion that they were, so they were implemented, but with restrictions. That same process could have happened quite easliy even if we were typing * characters. Granted, there would be a lot more flame wars about why we didn't have "basic" features. Ick.
Nov 02 2005
parent Sean Kelly <sean f4.ca> writes:
Russ Lewis wrote:
 
 Changing the syntax doesn't require you to change the functionality, 
 just the syntax.  I'm actually pretty happy about the development of the 
 language over time.  IMHO, it was a good idea to discard class-value 
 variables at the start of development.  We all argued out whether or not 
 they were *really* necessary.  Eventually, we came to the conclusion 
 that they were, so they were implemented, but with restrictions.  That 
 same process could have happened quite easliy even if we were typing * 
 characters.

True enough. It would just be a tad weird if class variables always needed to be declared as pointers and the non-pointer syntax wasn't supported. Though I grant that it would be more consistent from a syntax perspective. I can see this potentially causing problems with template code that specializes on pointer types: template fn(T : T*) { fn( T* val ) { T temp = *val; // illegal if T is a class type ... } }
 Granted, there would be a lot more flame wars about why we didn't have 
 "basic" features.  Ick.

Yup. Sean
Nov 02 2005
prev sibling next sibling parent reply Dave <Dave_member pathlink.com> writes:
In article <djodvq$2nvh$3 digitaldaemon.com>, Walter Bright says...
"Vathix" <chris dprogramming.com> wrote in message
news:op.sy8x7py7l2lsvj esi...
 I like it. Only problem I can think of is conflicts if the class has a
 static opCall. Perhaps classes should not have them

I'm hard pressed to see the point of them for classes anyway.
 (but they're very
 handy for structs/unions). This extra code in the compiler to support it
 could possibly be hacked in by adding an internal, implicit static opCall
 to all classes, which are translated to RAII constructors when invoked
  from an initializer ;)

There's more work to get all the details ironed out, but that is where I want to go. It's needed because there are a certain class of problems D doesn't work well without.

Could we do stuff like this (w/o the new/delete member overrides)?: ;--- -import std.c.stdlib, std.stdio; - -void main() -{ - // imagine 'f' is constructed like: - // auto f = Foo(100); - Foo f = new(std.c.stdlib.alloca(Foo.classinfo.init.length)) Foo(100); - for(int i = 0; i < 100; i++) - { - f.x *= i + 1; - writefln(f.x); - Foo f2 = foo(f); - writefln(f2.x,"\n"); - } -} - -Foo foo(Foo f) -{ - f.x *= 3.14159; - return f; -} - -class Foo -{ - double x; - this(double x) - { - this.x = x; - } - new(uint sz, void *p) - { - return p; - } - delete(void* p) - { - assert(0); - } -} Thanks, - Dave
Oct 26 2005
next sibling parent Dave <Dave_member pathlink.com> writes:
Geesh - see code correction below..

In article <djoku3$2v3p$1 digitaldaemon.com>, Dave says...
In article <djodvq$2nvh$3 digitaldaemon.com>, Walter Bright says...
There's more work to get all the details ironed out, but that is where I
want to go. It's needed because there are a certain class of problems D
doesn't work well without.

Could we do stuff like this (w/o the new/delete member overrides)?: ;--- -import std.c.stdlib, std.stdio; - -void main() -{ - // imagine 'f' is constructed like: - // auto f = Foo(100); - Foo f = new(std.c.stdlib.alloca(Foo.classinfo.init.length)) Foo(100); - for(int i = 0; i < 100; i++) - { - f.x *= i + 1; - writefln(f.x); - Foo f2 = foo(f); - writefln(f2.x,"\n"); - } -} -

-Foo foo(Foo f) -{ - // imagine 'f2' is constructed like: - // Foo f2 = Foo(10); - Foo f2 = new(alloca(Foo.classinfo.init.length)) Foo(10); - f2.x *= f.x * 3.14159; - return f2; -} What I meant to ask is will we be able to return stack allocated class instances from functions?
-
-class Foo
-{
-    double x;
-    this(double x)
-    {
-        this.x = x;
-    }
-    new(uint sz, void *p)
-    {
-	return p;
-    }
-    delete(void* p)
-    {
-	assert(0);
-    }
-}

Thanks,

- Dave

Oct 26 2005
prev sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"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.
Oct 27 2005
prev sibling parent "Garett Bass" <garettbass studiotekne.com> writes:
Please don't kill opCall for classes, it makes for great factory method 
syntax :)  If you're leaning that way, maybe only allow static opCall for 
abstract classes?


"Walter Bright" <newshound digitalmars.com> wrote in message 
news:djodvq$2nvh$3 digitaldaemon.com...
 "Vathix" <chris dprogramming.com> wrote in message
 news:op.sy8x7py7l2lsvj esi...
 I like it. Only problem I can think of is conflicts if the class has a
 static opCall. Perhaps classes should not have them

I'm hard pressed to see the point of them for classes anyway.
 (but they're very
 handy for structs/unions). This extra code in the compiler to support it
 could possibly be hacked in by adding an internal, implicit static opCall
 to all classes, which are translated to RAII constructors when invoked
  from an initializer ;)

There's more work to get all the details ironed out, but that is where I want to go. It's needed because there are a certain class of problems D doesn't work well without.

Oct 31 2005
prev sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Walter Bright wrote:
 "Sai" <Sai_member pathlink.com> wrote in message
 news:djm1oj$p58$1 digitaldaemon.com...
 
Is the answer for it is to use a new keyword or to make the compiler

smarter ? It's implementing class objects on the stack with the: classname(constructor arguments) syntax. Then, an RAII class object would be: auto c = classname(arguments); and a non-RAII class object would be: auto c = new classname(arguments); and the old RAII syntax would be supported as: auto classname c = new classname(arguments); and eventually deprecated.

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 ) Now, as for possible alternative solutions, I don't like that proposed one either. Doesn't read that well, and it still has the homonymous keywords. How about having autoraii be just an alternative to new. Something like: Foo foo = autonew Foo(arguments); possibly with a different shorter name than autonew, like anew, or snew. And an autotype autoraii object would be: auto foo = anew Foo(arguments); Incidently, and I mean incidently, it would allow anonymous autoraii objects, and consequently would allow easier work with blocks/scopes. Something like: // prints: { anew HtmlHtml(); // <html> { anew HtmlHead(); // <head> HtmlTitle("History"); // <title>History</title> } // </head> { anew HtmlBody(); // <body> HtmlComment("HI"); // <!-- HI --> HtmlHeader("Header"); // <h1>Header</h1> { anew HtmlParagraph(); // <p> HtmlText("paragraph"); // paragraph } // </p> } // </body> } // </html> Interesting at least, but this whole issue needs to be thought about more. -- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Oct 26 2005
next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"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.
Oct 26 2005
next sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
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.

situation, 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. -- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Oct 26 2005
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"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.
Oct 27 2005
parent reply Sean Kelly <sean f4.ca> writes:
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
Oct 27 2005
next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
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
 
 

Oct 27 2005
next sibling parent reply Sean Kelly <sean f4.ca> writes:
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
Oct 27 2005
parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Sean Kelly wrote:
 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.

And we know just the man to find them :)
 
 Sean
 
 

Oct 27 2005
prev sibling next sibling parent reply Dave <Dave_member pathlink.com> writes:
In article <djrbo0$lkk$1 digitaldaemon.com>, Ivan Senji says...
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.

Yes, 'c' is dead, but before that the copy ctor is called (implicit or explicit) and that temporary copy is returned; so it really isn't undefined behaviour although it can hide bugs that seem like it <g> I think the prev. poster was just asking (as I did earlier with an example) if Walter has some magic that would allow this? Like how stack allocated D structs are returned by value (shallow copy of heap members), which D can usually get away with because of the GC.
 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
 
 


Oct 27 2005
parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Dave wrote:
 In article <djrbo0$lkk$1 digitaldaemon.com>, Ivan Senji says...
As it would in C++, at the end of scope c is dead.

Yes, 'c' is dead, but before that the copy ctor is called (implicit or explicit) and that temporary copy is returned; so it really isn't undefined behaviour although it can hide bugs that seem like it <g>

Copy ctor? D doesn't hava a copy ctor. c is a reference to a location on the stack, and when you exit the method and the objects is destroyed you really shouldn't be using that memory location. Can hide bugs? It is a bug.
 I think the prev. poster was just asking (as I did earlier with an example) if
 Walter has some magic that would allow this? Like how stack allocated D structs
 are returned by value (shallow copy of heap members), which D can usually get
 away with because of the GC.

Only Walter knows. But structs are very different from classes.
 ...

Oct 27 2005
parent reply Dave <Dave_member pathlink.com> writes:
In article <djsf79$r5t$1 digitaldaemon.com>, Ivan Senji says...
Dave wrote:
 In article <djrbo0$lkk$1 digitaldaemon.com>, Ivan Senji says...
As it would in C++, at the end of scope c is dead.

Yes, 'c' is dead, but before that the copy ctor is called (implicit or explicit) and that temporary copy is returned; so it really isn't undefined behaviour although it can hide bugs that seem like it <g>

Copy ctor? D doesn't hava a copy ctor. c is a reference to a location on the stack, and when you exit the method and the objects is destroyed you really shouldn't be using that memory location.

Ok - how's this: "Yes, 'c' is dead, but before that the copy ctor is called (implicit or explicit) and that temporary copy is returned; so it really isn't undefined behaviour /in C++/ although it can hide bugs that seem like it <g>" Since my reply was right after you mentioned C++ I thought it would be clear that the reference was to C++.
Can hide bugs? It is a bug.

 I think the prev. poster was just asking (as I did earlier with an example) if
 Walter has some magic that would allow this? Like how stack allocated D structs
 are returned by value (shallow copy of heap members), which D can usually get
 away with because of the GC.

Only Walter knows. But structs are very different from classes.
 ...


Oct 28 2005
parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Dave wrote:
 In article <djsf79$r5t$1 digitaldaemon.com>, Ivan Senji says...
 
Dave wrote:

In article <djrbo0$lkk$1 digitaldaemon.com>, Ivan Senji says...

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

Yes, 'c' is dead, but before that the copy ctor is called (implicit or explicit) and that temporary copy is returned; so it really isn't undefined behaviour although it can hide bugs that seem like it <g>

the stack, and when you exit the method and the objects is destroyed you really shouldn't be using that memory location.

Ok - how's this: "Yes, 'c' is dead, but before that the copy ctor is called (implicit or explicit) and that temporary copy is returned; so it really isn't undefined behaviour /in C++/ although it can hide bugs that seem like it <g>" Since my reply was right after you mentioned C++ I thought it would be clear that the reference was to C++.

Sorry, my mistake :) But the program segment in question i see as this code in C++: MyClass* getInstance() { MyClass c(); return &c; } And we can agree that this is not good code.
 
Can hide bugs? It is a bug.


I think the prev. poster was just asking (as I did earlier with an example) if
Walter has some magic that would allow this? Like how stack allocated D structs
are returned by value (shallow copy of heap members), which D can usually get
away with because of the GC.

Only Walter knows. But structs are very different from classes.
...



Oct 28 2005
prev sibling parent Hauke Duden <H.NS.Duden gmx.net> writes:
Ivan Senji wrote:
 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.

I think the most important use of stack based objects is if you want something to automatically happen when the scope is left. For example (using pseudo-syntax to avoid the confusion of "auto"): { local MutexLock l=MutexLock(myMutex); ...stuff // automatically release mutex } Having this ability can be invaluable for preventing bugs that are very hard to find. The solution for preventing dangling references for stack based objects would be to make "stack-based" a type modifier without implicit conversion to non-stack-based types. For example: local MutexLock l=MutexLock(myMutex); MutexLock x=l; // error because x is not a stack-reference. local MutexLock y=l; // ok. Note that y cannot become a dangling // reference because it is either in the same // scope as l or in an inner scope. So y always // goes out of scope before l. MutexLock x=cast(local MutexLock)l; //ok? should be allowed IMHO Stack references should only be allowed as local variables and function parameters. Everything else would lead to dangling references. Note that implicit conversion from non-stack reference to stack reference is not a problem. I just realized that such a type modifier would also solve another common programming problem. You often have methods with arguments that should only be used during the execution of the method. I.e. you do not want a reference to the argument to be stored and used again later, possibly because the object might be in an invalid state at that time. Having a "local" type modifier could help to enforce this. If the function argument is "local" then it can only be stored in other local variables of that function. So it is impossible for the implementor of the method to accidently access the object again after the function returns. Hauke
Oct 29 2005
prev sibling next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 27 Oct 2005 19:48:41 +0000 (UTC), Sean Kelly <sean f4.ca> 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.

Why can't this simply be detected at compile time? Regan
Oct 27 2005
next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Regan Heath wrote:
 On Thu, 27 Oct 2005 19:48:41 +0000 (UTC), Sean Kelly <sean f4.ca> 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.

Why can't this simply be detected at compile time?

The simple example can allways be complicated: MyClass getInstance() { MyClass c = MyClass(); ...a lot of code MyClass a = c; ...a lot of code return a; } I don't think it would be possible for the compiler to track all that is going on with references to stack allocated objects. What if you had in the method above: MyClass c = MyClass(); ...a lot of code MyClass a; if(somecondition) { a = c; } else { a = new MyClass(); } return a; In this case the code is sometimes legal and sometimes not. No easy solution in sight.
 Regan

Oct 27 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 27 Oct 2005 23:24:42 +0200, Ivan Senji  
<ivan.senji_REMOVE_ _THIS__gmail.com> wrote:
 Regan Heath wrote:
 On Thu, 27 Oct 2005 19:48:41 +0000 (UTC), Sean Kelly <sean f4.ca> 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.


The simple example can allways be complicated: MyClass getInstance() { MyClass c = MyClass(); ...a lot of code MyClass a = c; ...a lot of code return a; } I don't think it would be possible for the compiler to track all that is going on with references to stack allocated objects. What if you had in the method above: MyClass c = MyClass(); ...a lot of code MyClass a; if(somecondition) { a = c; } else { a = new MyClass(); } return a; In this case the code is sometimes legal and sometimes not. No easy solution in sight.

If the actual instance is flagged as being stack based then you simply error when a reference is returned that references a stack based instance. You don't actually need to track anything, except that the instance itself is stack based, which you have to track anyway because you're going to destroy it at the end of scope, right? Regan
Oct 27 2005
parent reply Sean Kelly <sean f4.ca> writes:
In article <opszbqebii23k2f5 nrage.netwin.co.nz>, Regan Heath says...
If the actual instance is flagged as being stack based then you simply  
error when a reference is returned that references a stack based instance.  
You don't actually need to track anything, except that the instance itself  
is stack based, which you have to track anyway because you're going to  
destroy it at the end of scope, right?

If it's on the stack, no explicit tracking is needed. It will be destroyed automatically as a part of the stack unwinding process when the function exits. Though if the class has a dtor then some tracking is indeed necessary. Either way, this is something that happens at run time, not compile time. Though I suppose an AssertError is better than attempting to access released memory. Sean
Oct 27 2005
parent "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 27 Oct 2005 22:13:02 +0000 (UTC), Sean Kelly <sean f4.ca> wrote:
 In article <opszbqebii23k2f5 nrage.netwin.co.nz>, Regan Heath says...
 If the actual instance is flagged as being stack based then you simply
 error when a reference is returned that references a stack based  
 instance.
 You don't actually need to track anything, except that the instance  
 itself
 is stack based, which you have to track anyway because you're going to
 destroy it at the end of scope, right?

If it's on the stack, no explicit tracking is needed. It will be destroyed automatically as a part of the stack unwinding process when the function exits. Though if the class has a dtor then some tracking is indeed necessary. Either way, this is something that happens at run time, not compile time.

So the compiler can't flag a reference as referencing a local stack object at compile time, and error if it's returned? It would have to copy the flag on assignments and so on, but it's _possible_ right? It's more work for the compiler, but at least it's done at compile time and not runtime.
 Though I
 suppose an AssertError is better than attempting to access released  
 memory.

Most things are. Regan
Oct 27 2005
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <opszbo89dr23k2f5 nrage.netwin.co.nz>, Regan Heath says...
On Thu, 27 Oct 2005 19:48:41 +0000 (UTC), Sean Kelly <sean f4.ca> wrote:
 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.

Why can't this simply be detected at compile time?

I think it could be for simple cases, but I'm not sure the compiler could catch all such errors. Though perhaps partial detection is sufficient... Sean
Oct 27 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 27 Oct 2005 21:30:12 +0000 (UTC), Sean Kelly <sean f4.ca> wrote:
 In article <opszbo89dr23k2f5 nrage.netwin.co.nz>, Regan Heath says...
 On Thu, 27 Oct 2005 19:48:41 +0000 (UTC), Sean Kelly <sean f4.ca> wrote:
 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.

Why can't this simply be detected at compile time?

I think it could be for simple cases, but I'm not sure the compiler could catch all such errors. Though perhaps partial detection is sufficient...

Why not? Surely you just flag the actual instance as stack based and then error whenever someone returns a reference to a stack based instance? Regan
Oct 27 2005
parent Dave <Dave_member pathlink.com> writes:
In article <opszbqbmzg23k2f5 nrage.netwin.co.nz>, Regan Heath says...
On Thu, 27 Oct 2005 21:30:12 +0000 (UTC), Sean Kelly <sean f4.ca> wrote:
 In article <opszbo89dr23k2f5 nrage.netwin.co.nz>, Regan Heath says...
 On Thu, 27 Oct 2005 19:48:41 +0000 (UTC), Sean Kelly <sean f4.ca> wrote:
 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.

Why can't this simply be detected at compile time?

I think it could be for simple cases, but I'm not sure the compiler could catch all such errors. Though perhaps partial detection is sufficient...

Why not? Surely you just flag the actual instance as stack based and then error whenever someone returns a reference to a stack based instance? Regan

I think you're right - this should be do-able at compile time as long as the assignments are direct and not through pointers to references, etc. And even then the semantic optimizer in the reference compiler will remove cases like this (this 'optimizer' is run no matter which compiler flags are used): MyClass c1 = new MyClass; MyClass c2 = *&c1; // optimized to c2 = c1;
Oct 27 2005
prev sibling next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:djraup$jeb$1 digitaldaemon.com...
 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?

 a design support returning classes by value?  ie.

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

Returning references to stack variables is wrong, wrong, wrong <g>.
 From what you're saying, this sounds like it would produce undefined

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

 the need for pointer semantics for heap-based classes?  I'd think it would

 a degree of checking that the handle-based syntax doesn't:

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

It's not an improvement, the same errors are possible. Those errors are just as possible in C++, too.
Oct 27 2005
parent reply Dave <Dave_member pathlink.com> writes:
In article <djrt8q$2o2o$1 digitaldaemon.com>, Walter Bright says...
"Sean Kelly" <sean f4.ca> wrote in message
news:djraup$jeb$1 digitaldaemon.com...
 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?

 a design support returning classes by value?  ie.

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

Returning references to stack variables is wrong, wrong, wrong <g>.

What happens with structs now? They are copied by value, but are not deep copied. In D this is usually fine w/o big problems because of the GC - as long as the programmer remembers that pointers and ref. types will refer to the same chunk of memory unless reassigned: void main() { S s = foo(); printf("%d\n",s.c.i); } struct S { C c; } class C { int i; } S foo() { S s; s.c = new C; s.c.i = 10; return s; } So, for stack alloc. classes (excluding RAII), couldn't an implicit shallow copy be made into a temporary returned on the stack, and then the reference to that assigned in the new scope? From there the semantics for stack allocated class objects with pointer and ref. members would be consistent with returning structs by value.
 From what you're saying, this sounds like it would produce undefined

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

 the need for pointer semantics for heap-based classes?  I'd think it would

 a degree of checking that the handle-based syntax doesn't:

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

It's not an improvement, the same errors are possible. Those errors are just as possible in C++, too.

Oct 27 2005
parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Dave wrote:
 So, for stack alloc. classes (excluding RAII), couldn't an ...

RAII classes/objects are *the same*. There is no stack allocated classes/objects that are not RAII.
 In article <djrt8q$2o2o$1 digitaldaemon.com>, Walter Bright says...
"Sean Kelly" <sean f4.ca> wrote in message
Would such

a design support returning classes by value?  ie.

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

Returning references to stack variables is wrong, wrong, wrong <g>.


Why did everyone suddenly started talking about implementind value semantics for classes? It has nothing to do with the current design/issue (which is RAII and auto-type). Just because the new RAII proposal has a syntax similiar to C++'s value objects, it doesn't mean they are anywhere near the same.
 What happens with structs now? They are copied by value, but are not deep
 copied. ...

Structs have value semantics because they are structs, *not because* they are stack allocated. Thus just because we have stack allocated objects (RAII) doesn't mean they should have value semantics as well! D's objects follow a reference model (all of them), and any discussion regarding that, is off-topic for this thread. -- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Oct 28 2005
next sibling parent Sean Kelly <sean f4.ca> writes:
In article <djssee$1b40$1 digitaldaemon.com>, Bruno Medeiros says...
"Would such a design support returning classes by value?"
Why did everyone suddenly started talking about implementind value 
semantics for classes? It has nothing to do with the current 
design/issue (which is RAII and auto-type). Just because the new RAII 
proposal has a syntax similiar to C++'s value objects, it doesn't mean 
they are anywhere near the same.

I asked mostly because the two go hand-in-hand and I wanted to be sure I understood what Walter was proposing. I've given this issue some thought however, and I think Walter is right for avoiding value semantics for classes with this change. I can't think of a way around the need for a copy ctor and assignment operator support, and smart pointers also typically require an overloaded -> operator, which would be an overloaded dot operator in D (a horrifying idea IMO). I have also seen arguments that shared_ptr does not offer deterministic destruction so it's really more like a poor man's GC in most cases--the real strength of shared_ptr lies in its ability to execute arbitrary code on destruction, which we can do easily enough with auto classes accepting a delegate. I've realized that most times I want stack-based classes it's either because I want scope-specific RAII or because I want to avoid the use of heap allocation for one reason or another, and Walter's proposal provides this. I personally don't believe that D has this now because alloca() is a nonstandard C extension, and is therefore nonportable (it's also done at runtime, which is unnecessary in most cases). The semantic issue makes sense in this light because classes will never be value types, unlike all other types in D. So long as the new construction method is extended to work for all types (besides struct), I'll be quite happy: T v = T(val); T v = new T(val); (assume this is template code so T is actually a pointer type for non-class values) And if not, I'll stick to using template wrappers for this stuff :p Sean
Oct 28 2005
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
In article <djssee$1b40$1 digitaldaemon.com>, Bruno Medeiros says...
Dave wrote:
 So, for stack alloc. classes (excluding RAII), couldn't an ...

RAII classes/objects are *the same*. There is no stack allocated classes/objects that are not RAII.
 In article <djrt8q$2o2o$1 digitaldaemon.com>, Walter Bright says...
"Sean Kelly" <sean f4.ca> wrote in message
Would such

a design support returning classes by value?  ie.

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

Returning references to stack variables is wrong, wrong, wrong <g>.


Why did everyone suddenly started talking about implementind value semantics for classes? It has nothing to do with the current design/issue (which is RAII and auto-type). Just because the new RAII proposal has a syntax similiar to C++'s value objects, it doesn't mean they are anywhere near the same.
 What happens with structs now? They are copied by value, but are not deep
 copied. ...

Structs have value semantics because they are structs, *not because* they are stack allocated. Thus just because we have stack allocated

Yep, but classes having value semantics was not necessarily what I was implying.
objects (RAII) doesn't mean they should have value semantics as well!

I'm not really asking for value semantics, I'm asking /if/ classes allocated on the stack can be returned 'safely' in a defined way, and I suggested a way to implement it that would basically allow the same syntax whether or not a class object was heap or stack allocated.
D's objects follow a reference model (all of them), and any discussion 

No, they don't - structs can be considered 'objects' as can any native type - especially when you consider the implications of the current design on generic programming techniques. For example, for many algorithms you would have to develop two sets of templates or use compiler conditionals like static if everywhere to support both class and struct 'objects' with the same template declarations. That is not what I'd like to call 'generic' programming.
regarding that, is off-topic for this thread.

Huh? Asking whether or not the new syntax that Walter put out here and has been recently discussed (and replied to) would let us return class objects allocated on the stack is completely within the context of this discussion since it was not real clear whether or not RAII and/or class object stack allocation would require 'auto' declaration or not.
-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."

Oct 28 2005
parent Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Dave wrote:
 In article <djssee$1b40$1 digitaldaemon.com>, Bruno Medeiros says...
 
Dave wrote:

So, for stack alloc. classes (excluding RAII), couldn't an ...

Walter has said this here before: stack allocated classes/objects and RAII classes/objects are *the same*. There is no stack allocated classes/objects that are not RAII.
In article <djrt8q$2o2o$1 digitaldaemon.com>, Walter Bright says...

"Sean Kelly" <sean f4.ca> wrote in message
Would such


a design support returning classes by value?  ie.

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

Returning references to stack variables is wrong, wrong, wrong <g>.


"Would such a design support returning classes by value?" Why did everyone suddenly started talking about implementind value semantics for classes? It has nothing to do with the current design/issue (which is RAII and auto-type). Just because the new RAII proposal has a syntax similiar to C++'s value objects, it doesn't mean they are anywhere near the same.
What happens with structs now? They are copied by value, but are not deep
copied. ...

What follows is a reply to also some other comments in others posts: Structs have value semantics because they are structs, *not because* they are stack allocated. Thus just because we have stack allocated

Yep, but classes having value semantics was not necessarily what I was implying.

 
objects (RAII) doesn't mean they should have value semantics as well!

I'm not really asking for value semantics, I'm asking /if/ classes allocated on the stack can be returned 'safely' in a defined way, and I suggested a way to implement it that would basically allow the same syntax whether or not a class object was heap or stack allocated.
D's objects follow a reference model (all of them), and any discussion 

No, they don't - structs can be considered 'objects' as can any native type - especially when you consider the implications of the current design on generic programming techniques. For example, for many algorithms you would have to develop two sets of templates or use compiler conditionals like static if everywhere to support both class and struct 'objects' with the same template declarations. That is not what I'd like to call 'generic' programming.

now have value semantics, and that it wasn't because they were stack allocated.
 
regarding that, is off-topic for this thread.

Huh? Asking whether or not the new syntax that Walter put out here and has been recently discussed (and replied to) would let us return class objects allocated on the stack is completely within the context of this discussion since it was not real clear whether or not RAII and/or class object stack allocation would require 'auto' declaration or not.

is relevant. -- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Oct 29 2005
prev sibling parent Niko Korhonen <niktheblak hotmail.com> writes:
Sean Kelly wrote:
 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*
 }

...and by that time D's metamorphosis into C++ will be complete. -- Niko Korhonen SW Developer
Oct 30 2005
prev sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
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.

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."
Oct 27 2005
parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
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.
 

Oct 27 2005
parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Ivan Senji wrote:
 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.

No it shouldn't be. I said before (here: digitalmars.D.announce/1771 ) that I was talking about the current DMD.137 situation in that post, not Walter's new proposal. -- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Oct 28 2005
parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Bruno Medeiros wrote:
 Ivan Senji wrote:
 
 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.

No it shouldn't be. I said before (here: digitalmars.D.announce/1771 ) that I was talking about the current DMD.137 situation in that post, not Walter's new proposal.

Sorry, i really was tired when reading these posts :)
 

Oct 28 2005
prev sibling parent Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Bruno Medeiros wrote:
 Walter Bright wrote:
 It's implementing class objects on the stack with the:
     classname(constructor arguments)
 syntax. Then, an RAII class object would be:

     auto c = classname(arguments);

 and a non-RAII class object would be:

     auto c = new classname(arguments);

 and the old RAII syntax would be supported as:

     auto classname c = new classname(arguments);

 and eventually deprecated.


 
 Now, as for possible alternative solutions, I don't like that proposed 
 one either. Doesn't read that well, and it still has the homonymous 
 keywords.
 

proposal correctly the first time. It seems to me this is a good alternative, even better than my similar 'autonew/snew' one. For the sake of no misundertansdings, I mean this: auto foo = Foo(arguments); // auto-type, RAII auto foo = new Foo(arguments); // auto-type, non-RAII (heap/GC) Foo foo = Foo(arguments); // explicit type, RAII Foo foo = new Foo(arguments); // explicit type, non-RAII (heap/GC) -- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Oct 29 2005
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <djjpa0$1o9n$2 digitaldaemon.com>, Walter Bright says...
A couple of oft-requested features.

I'm running into an odd error with typeof. I have this line in std.c.stddef: alias typeof(int.sizeof) size_t; and have this in object.d: public import std.c.stddef; When I try to compile stddef I get this error: C:\bin\dmd\src\ares\std\c>dmd -c stddef.d stddef.d(10): size of type typeof(4) is not known When I move the alias into object.d however, the error goes away. This pattern worked fine when I was using version blocks to define the size_t alias, so it's something to do with typeof. Any ideas? Sean
Oct 24 2005
parent "Walter Bright" <newshound digitalmars.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:djjrin$1q93$1 digitaldaemon.com...
 When I try to compile stddef I get this error:

 C:\bin\dmd\src\ares\std\c>dmd -c stddef.d
 stddef.d(10): size of type typeof(4) is not known

 When I move the alias into object.d however, the error goes away.  This

 worked fine when I was using version blocks to define the size_t alias, so

 something to do with typeof.  Any ideas?

I can't reproduce the error.
Oct 25 2005
prev sibling next sibling parent reply "John Reimer" <terminal.node gmail.com> writes:
Yay!

"extern(linkage) for nested functions now works."

Thanks, Walter!  I thought you had all but forgotten this one.

- John

"Walter Bright" <newshound digitalmars.com> wrote in message 
news:djjpa0$1o9n$2 digitaldaemon.com...
A couple of oft-requested features.

 http://www.digitalmars.com/d/changelog.html


 

Oct 25 2005
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"John Reimer" <terminal.node gmail.com> wrote in message
news:djlrjv$3pl$1 digitaldaemon.com...
 Yay!

 "extern(linkage) for nested functions now works."

 Thanks, Walter!  I thought you had all but forgotten this one.

I just kept getting distracted onto other things. Sorry it took so long.
Oct 25 2005
parent reply "John Reimer" <terminal.node gmail.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:djlu50$agr$1 digitaldaemon.com...
 "John Reimer" <terminal.node gmail.com> wrote in message
 news:djlrjv$3pl$1 digitaldaemon.com...
 Yay!

 "extern(linkage) for nested functions now works."

 Thanks, Walter!  I thought you had all but forgotten this one.

I just kept getting distracted onto other things. Sorry it took so long.

No problem! You certainly have plenty to distract you. :-) 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/. See the following: module callback; extern(Windows) alias int function(int,int) UPDATE_EVENT_W; // Simulate external win32 call extern(Windows) int extfunction( UPDATE_EVENT_W func ) { // do nothing auto fw = func; return 1; } void init( UPDATE_EVENT_W fc ) { extern(Windows) int func1( int a, int b ) { if (fc !is null) fc( a, b ); } extfunction( &func1 ); } That code produces the following compile message: callback.d(20): function callback.extfunction (int(Windows *)(int, int)) does not match argument types (int de legate(int a, int b)) callback.d(20): cannot implicitly convert expression (&func1) of type int delegate(int a, int b) to int(Window s *)(int, int) Is it possible to fix this? Also it appears that extern(Linkage) {} still won't work and defining function literals with a linkage attribute is also impossible. Thanks! -John
Oct 26 2005
parent reply Sean Kelly <sean f4.ca> writes:
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
Oct 26 2005
parent reply John Reimer <John_member pathlink.com> writes:
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? -JJR
Oct 26 2005
next sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <djp8g4$fj9$1 digitaldaemon.com>, John Reimer says...
I tried that already and numerous other combinations.  Nothing worked.

Did you actually get that to work?

I didn't try it. I know that 'static' is supposed to make local delegates into nonlocal functions and figured it was worth a shot. I'll try to find some time to mess with it tomorrow. Sean
Oct 26 2005
parent John Reimer <John_member pathlink.com> writes:
In article <djpppq$12v6$1 digitaldaemon.com>, Sean Kelly says...
In article <djp8g4$fj9$1 digitaldaemon.com>, John Reimer says...
I tried that already and numerous other combinations.  Nothing worked.

Did you actually get that to work?

I didn't try it. I know that 'static' is supposed to make local delegates into nonlocal functions and figured it was worth a shot. I'll try to find some time to mess with it tomorrow. Sean

Um actually, you are correct. The problem arose elsewhere. Static is required and makes complete sense; it just won't work in the context I gave. The reason it won't work is because I was silly enough to try to access the init() functions stack variable from within the nested func1. Clearly, that stack variable fc will only last the life of the init function. Once that's run the nested function won't be accessing a vaild variable making func1 completely illegal to submit as a callback. Therefore adding static would work only if I don't try to access the init() variables. I'm afraid I was not thinking. My original idea was to encase an external function of normal D linkage (perhaps even a delegate) within a windows linkage callback that could be submitted to win32 function. My method obviously was invalid. In conclusion, adding static does the trick for func1() as long as init() stack variables aren't referenced. -JJR
Oct 27 2005
prev sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"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



to apply extern(linkage) for nested functions is primarily useful for OS
callback methods; but as implemented right now, this is not possible



the nested functions are seen solely as /delegates/ not /function



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) ...
Oct 27 2005
prev sibling next sibling parent reply Carlos Santander <csantander619 gmail.com> writes:
Walter Bright escribió:
 A couple of oft-requested features.
 
 http://www.digitalmars.com/d/changelog.html
 
 
 

I really like the auto type declaration, but I'd like to suggest something slightly related: can't static strings be of type char[] instead of static char[length]? The problem is that this doesn't work: auto str = "hi"; str = "hello"; -- Carlos Santander Bernal
Oct 25 2005
next sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"Carlos Santander" <csantander619 gmail.com> wrote in message
news:djmpd4$25oa$2 digitaldaemon.com...
 I really like the auto type declaration, but I'd like to suggest something
 slightly related: can't static strings be of type char[] instead of static
 char[length]? The problem is that this doesn't work:

 auto str = "hi";
 str = "hello";

I hear you, but it's easier to go from a static array to a dynamic array, but not vice versa. So I think making it a static array type is better.
Oct 25 2005
prev sibling parent reply Vathix <chris dprogramming.com> writes:
On Tue, 25 Oct 2005 22:19:25 -0400, Carlos Santander  
<csantander619 gmail.com> wrote:

 Walter Bright escribió:
 A couple of oft-requested features.
  http://www.digitalmars.com/d/changelog.html

I really like the auto type declaration, but I'd like to suggest something slightly related: can't static strings be of type char[] instead of static char[length]? The problem is that this doesn't work: auto str = "hi"; str = "hello";

auto str = "hi"[]; str = "hello";
Oct 25 2005
parent "Walter Bright" <newshound digitalmars.com> writes:
"Vathix" <chris dprogramming.com> wrote in message
news:op.sy8mfjbxl2lsvj esi...
 On Tue, 25 Oct 2005 22:19:25 -0400, Carlos Santander
 <csantander619 gmail.com> wrote:
 I really like the auto type declaration, but I'd like to suggest
 something slightly related: can't static strings be of type char[]
 instead of static char[length]? The problem is that this doesn't work:

 auto str = "hi";
 str = "hello";

auto str = "hi"[]; str = "hello";

I had missed that. Thanks for pointing it out.
Oct 25 2005
prev sibling next sibling parent reply "John C" <johnch_atms hotmail.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:djjpa0$1o9n$2 digitaldaemon.com...
A couple of oft-requested features.

 http://www.digitalmars.com/d/changelog.html

Superb. By introducing local type inference now, D is ahead of the competition in this respect. C# won't get it until version 3, C++ for a long while yet, and Java probably never. Coincidentally (or maybe not), "auto" also happens to be the proposed C++ syntax.
Oct 26 2005
next sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"John C" <johnch_atms hotmail.com> wrote in message
news:djnapn$d2b$1 digitaldaemon.com...
 Superb. By introducing local type inference now, D is ahead of the
 competition in this respect. C# won't get it until version 3, C++ for a

 while yet, and Java probably never.

 Coincidentally (or maybe not), "auto" also happens to be the proposed C++
 syntax.

It's auto for the same reason, "auto" is an old C keyword used for local stack variables, and this presses it into service.
Oct 26 2005
prev sibling parent reply renox <renosky free.fr> writes:
John C wrote:
 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:djjpa0$1o9n$2 digitaldaemon.com...
 
A couple of oft-requested features.

http://www.digitalmars.com/d/changelog.html

Superb. By introducing local type inference now, D is ahead of the competition in this respect. C# won't get it until version 3, C++ for a long while yet, and Java probably never. Coincidentally (or maybe not), "auto" also happens to be the proposed C++ syntax.

Just to add a 'dissenting view' Limbo (a relatively unknown language for Plan9 that I've never used but just read it's nifty syntax) had type inference for a long time.. Anyway I applaud the type inference for D which IMHO will have a profound impact on code's readability. The reuse of auto word for both type inferencing and RAII seems a bit strange, IMHO ':=' as in Limbo is the best (as it's the shortest: having nearly invisible variable declaration is a good thing, especially since in D you can't have two declaration of the same variable in a function which prevent abuse), var is nice too (it's used in Scala). Regards, Renaud. PS: Hoping that it won't be considered as trolling but I tend to think than Limbo's variable declaration syntax is more readable than D: x : int; // declares x to be of type int x : int = 5; //declares x to be of type int and initialize it to 5. x := 8; //declares x to be to the type of 8: int and initialize it to 8. This Pascal-like syntax is a bit verbose sometimes but very readable: x : array[10] of int; The advantage is that declaration and utilisation are made in the same order, contrary to D. Of course it isn't C-like, but while C has strong points some parts like its syntax to declare variable, switch/case with default fall-through, ';' instead of '{}' for empty loop/if/while (took me two days to find a bug caused by this one time), octal which starts with 0 instead of 0o are not very good..
Nov 13 2005
parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
renox wrote:
 John C wrote:
 
 Just to add a 'dissenting view' Limbo (a relatively unknown language for 
 Plan9 that I've never used but just read it's nifty syntax) had type 
 inference for a long time..
 
 Anyway I applaud the type inference for D which IMHO will have a 
 profound impact on code's readability.

I think so too.
 The reuse of auto word for both type inferencing and RAII seems a bit 
 strange, IMHO ':=' as in Limbo is the best (as it's the shortest: having 
 nearly invisible variable declaration is a good thing, especially since 
 in D you can't have two declaration of the same variable in a function 
 which prevent abuse), var is nice too (it's used in Scala).
 
 Regards,
 Renaud.
 
 PS: Hoping that it won't be considered as trolling but I tend to think 
 than Limbo's variable declaration syntax is more readable than D:
 

More readable to a compiler definitelly because there is no ambiguity in this syntax, but more readable to humans is a discutable thing.
 x : int; // declares x to be of type int
 x : int = 5; //declares x to be of type int and initialize it to 5.
 x := 8; //declares x to be to the type of 8: int and initialize it to 8.

 This Pascal-like syntax is a bit verbose sometimes but very readable:
 x : array[10] of int;
 
 The advantage is that declaration and utilisation are made in the same 
 order, contrary to D.
 Of course it isn't C-like, but while C has strong points some parts like 
  its syntax to declare variable, switch/case with default fall-through, 
 ';' instead of '{}' for empty loop/if/while (took me two days to find a 
 bug caused by this one time), octal which starts with 0 instead of 0o 
 are not very good..

Nov 13 2005
parent renox <renosky free.fr> writes:
Ivan Senji wrote:

 renox wrote:
 
 John C wrote:

 Just to add a 'dissenting view' Limbo (a relatively unknown language 
 for Plan9 that I've never used but just read it's nifty syntax) had 
 type inference for a long time..

 Anyway I applaud the type inference for D which IMHO will have a 
 profound impact on code's readability.

I think so too.
 The reuse of auto word for both type inferencing and RAII seems a bit 
 strange, IMHO ':=' as in Limbo is the best (as it's the shortest: 
 having nearly invisible variable declaration is a good thing, 
 especially since in D you can't have two declaration of the same 
 variable in a function which prevent abuse), var is nice too (it's 
 used in Scala).

 Regards,
 Renaud.

 PS: Hoping that it won't be considered as trolling but I tend to think 
 than Limbo's variable declaration syntax is more readable than D:

More readable to a compiler definitelly because there is no ambiguity in this syntax, but more readable to humans is a discutable thing.

Of course, as everything is, but I've used mostly C (that I like for small programs) / C++ (that I dislike very much) and still I find Limbo's syntax for variable declaration *very nice* to read (better than C, C++ and also better than D sorry).. Not that it matters to D: its syntax is definitely good enough for me. Regards, Renaud Hebert.
 x : int; // declares x to be of type int
 x : int = 5; //declares x to be of type int and initialize it to 5.
 x := 8; //declares x to be to the type of 8: int and initialize it to 8.

 This Pascal-like syntax is a bit verbose sometimes but very readable:
 x : array[10] of int;

 The advantage is that declaration and utilisation are made in the same 
 order, contrary to D.
 Of course it isn't C-like, but while C has strong points some parts 
 like  its syntax to declare variable, switch/case with default 
 fall-through, ';' instead of '{}' for empty loop/if/while (took me two 
 days to find a bug caused by this one time), octal which starts with 0 
 instead of 0o are not very good..


Nov 13 2005
prev sibling next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:
 A couple of oft-requested features.
 
 http://www.digitalmars.com/d/changelog.html

Now that you're working on the compiler once again, is there any chance of an answer about these any time soon? digitalmars.D/28426 digitalmars.D/28449 Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Oct 26 2005
prev sibling next sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <djjpa0$1o9n$2 digitaldaemon.com>, Walter Bright says...
A couple of oft-requested features.

http://www.digitalmars.com/d/changelog.html

Walter, I think others have brought this up, but there's a problem with overloading the use of 'auto' in this way. If one wants to have both RAII *and* auto-type capabilities in the same statement, it can't be done since they both use the same keyword. Might I propose moving the RAII aspect of auto out to a new keyword? How about "raii"? // code listed including your proposal for stack-allocation, for completeness auto a = new classname(); // auto-type, heap alloc auto b = classname(); // auto-type, stack alloc raii c = new classname(); // RAII, heap alloc raii d = classname(); // RAII, stack alloc auto raii e = new classname(); // auto-type, RAII, heap alloc auto raii f = classname(); // auto-type, RAII, stack alloc Also, others have mentioned a possible ambiguity with "static opCall()" and your proposal for stack-allocation. What are your thoughts on using a keyword in place of 'new' to signify stack-allocation? - EricAnderton at yahoo
Oct 26 2005
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
pragma wrote:
 In article <djjpa0$1o9n$2 digitaldaemon.com>, Walter Bright says...
 A couple of oft-requested features.

 http://www.digitalmars.com/d/changelog.html

Walter, I think others have brought this up, but there's a problem with overloading the use of 'auto' in this way. If one wants to have both RAII *and* auto-type capabilities in the same statement, it can't be done since they both use the same keyword.

You've got me wondering what practical use this auto-type facility has. Just syntactic sugar for typeof(4u) y = 4u; ? Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Oct 26 2005
parent reply "John C" <johnch_atms hotmail.com> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message 
news:djohp1$2rnq$1 digitaldaemon.com...
 pragma wrote:
 In article <djjpa0$1o9n$2 digitaldaemon.com>, Walter Bright says...
 A couple of oft-requested features.

 http://www.digitalmars.com/d/changelog.html

Walter, I think others have brought this up, but there's a problem with overloading the use of 'auto' in this way. If one wants to have both RAII *and* auto-type capabilities in the same statement, it can't be done since they both use the same keyword.

You've got me wondering what practical use this auto-type facility has. Just syntactic sugar for typeof(4u) y = 4u; ?

If it spares one from having to write the type twice -- first for the declaration, then for the initialisation -- then I think it's a welcome addition. And while it may not seem a huge deal, already I have saved time by cutting down on errors made keying in template and delegate declarations. For example, I'm often unsure which of these two is correct because the way one declares and initialises a delegate differs: delegate int(char[]) d = delegate int(char[] s) { ... }; or int delegate(char[]) d = delegate int(char[] s) { ... }; And I won't find out that the first is incorrect until I compile. But using auto I'll not have to fix and recompile: auto d = delegate int(char[] s) { ... }; Plus if I change the signature of the delegate, I need do it only in one place. I know some will disagree, but I also think this is more readable. John.
 Stewart.

 -- 
 -----BEGIN GEEK CODE BLOCK-----
 Version: 3.1
 GCS/M d- s:- C++  a->--- UB  P+ L E  W++  N+++ o K-  w++  O? M V? PS- PE- 
 Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
 ------END GEEK CODE BLOCK------

 My e-mail is valid but not my primary mailbox.  Please keep replies on the 
 'group where everyone may benefit. 

Oct 26 2005
parent "Walter Bright" <newshound digitalmars.com> writes:
"John C" <johnch_atms hotmail.com> wrote in message
news:djokmm$2upu$1 digitaldaemon.com...
 Plus if I change the signature of the delegate, I need do it only in one
 place. I know some will disagree, but I also think this is more readable.

Right. This reduces the need for typedef's. It can also reduce bugs that happen when one changes the types in components of an initializer, but fail to correct all the uses of those components, yet with implicit conversions the error may get hidden.
Oct 27 2005
prev sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"pragma" <pragma_member pathlink.com> wrote in message
news:djo2np$2995$1 digitaldaemon.com...
 I think others have brought this up, but there's a problem with

 use of 'auto' in this way.  If one wants to have both RAII *and* auto-type
 capabilities in the same statement, it can't be done since they both use

 same keyword.

No, there isn't a conflict. Auto *always* makes it RAII. The initializer is another matter, though. If it's 'new', it's not RAII, if it's not 'new', it is not. There is no need at all for heap allocated objects to be RAII.
 Also, others have mentioned a possible ambiguity with "static opCall()"

 proposal for stack-allocation.

I know, that has to be worked out.
 What are your thoughts on using a keyword in
 place of 'new' to signify stack-allocation?

I don't believe it's necessary.
Oct 26 2005
prev sibling next sibling parent reply Kyle Furlong <kylefurlong gmail.com> writes:
Walter Bright wrote:
 A couple of oft-requested features.
 
 http://www.digitalmars.com/d/changelog.html
 
 
 

Would the new auto declaration permit a "mode" where ALL declarations are implicitly auto? e.g. <code> x = 1; // x is int and has value 1 x = 2; // x is assigned 1 x = 1u; // Compile Error? x = new AnotherObject(); // Compile Error: x is int o1 = new MyObject(1); // o1 is MyObject o2 = new MyObject(2); // o2 is MyObject o1 = o2; // okay o1 = new AnotherObject(); // Compile Error: o1 is MyObject ao = new AnotherObject(); // okay o2 = ao; // Compile Error: o2 is MyObject </code> What could be broken in this? Well, obviously there is the issue that you cant declare a new local variable with the same name as a variable in an outer scope. Then there case where conversions are possible is another area. Another is the cases where the complier cant determine the type of the rvalue. I dont know if there are any cases of this though. Another question is is this desirable syntax? I think if you are going to use the auto type declaration, then yes it is, saves 4 keystrokes per declaration.
Oct 27 2005
next sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
Kyle Furlong wrote:
 Walter Bright wrote:
 
 A couple of oft-requested features.

 http://www.digitalmars.com/d/changelog.html

Would the new auto declaration permit a "mode" where ALL declarations are implicitly auto? e.g. <code> x = 1; // x is int and has value 1 x = 2; // x is assigned 1

This line should read: x = 2; // x is assigned 2
 x = 1u;              // Compile Error?
 x = new AnotherObject();     // Compile Error: x is int
 
 o1 = new MyObject(1);        // o1 is MyObject
 o2 = new MyObject(2);        // o2 is MyObject
 o1 = o2;            // okay
 o1 = new AnotherObject();    // Compile Error: o1 is MyObject
 ao = new AnotherObject();    // okay
 o2 = ao;            // Compile Error: o2 is MyObject
 
 </code>
 
 What could be broken in this? Well, obviously there is the issue that 
 you cant declare a new local variable with the same name as a variable 
 in an outer scope. Then there case where conversions are possible is 
 another area. Another is the cases where the complier cant determine the 
 type of the rvalue. I dont know if there are any cases of this though.
 
 Another question is is this desirable syntax? I think if you are going 
 to use the auto type declaration, then yes it is, saves 4 keystrokes per 
 declaration.

Oct 27 2005
prev sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Kyle Furlong wrote:
 Walter Bright wrote:
 
 A couple of oft-requested features.

 http://www.digitalmars.com/d/changelog.html

Would the new auto declaration permit a "mode" where ALL declarations are implicitly auto? e.g. <code> x = 1; // x is int and has value 1 x = 2; // x is assigned 1 x = 1u; // Compile Error? x = new AnotherObject(); // Compile Error: x is int o1 = new MyObject(1); // o1 is MyObject o2 = new MyObject(2); // o2 is MyObject o1 = o2; // okay o1 = new AnotherObject(); // Compile Error: o1 is MyObject ao = new AnotherObject(); // okay o2 = ao; // Compile Error: o2 is MyObject </code> What could be broken in this? Well, obviously there is the issue that you cant declare a new local variable with the same name as a variable in an outer scope. Then there case where conversions are possible is another area. Another is the cases where the complier cant determine the type of the rvalue. I dont know if there are any cases of this though. Another question is is this desirable syntax? I think if you are going to use the auto type declaration, then yes it is, saves 4 keystrokes per declaration.

Syntax is great with auto because it simplifies things alot, but for x=1; to be a declaration would be a big mistake, i never liked those languages, things like that cause bugs that are really hard to find if you for example misspell something, or if you later need to find the places in code where you declare new objects it is imposible.
Oct 27 2005
parent "Walter Bright" <newshound digitalmars.com> writes:
"Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message
news:djsfm9$rr8$1 digitaldaemon.com...
 Syntax is great with auto because it simplifies things alot, but for
 x=1; to be a declaration would be a big mistake, i never liked those
 languages, things like that cause bugs that are really hard to find if
 you for example misspell something, or if you later need to find the
 places in code where you declare new objects it is imposible.

You're right. Declarations that have the same syntax as expressions or other statements lead to the classic "DO10I" bug.
Oct 28 2005
prev sibling next sibling parent reply James Dunne <james.jdunne gmail.com> writes:
Walter Bright wrote:
 A couple of oft-requested features.
 
 http://www.digitalmars.com/d/changelog.html
 
 
 

Can we have a new warning for use of potentially uninitialized variable? I know this might cause problems with current code relying on D's default initialization values. Anyway, I have a mathematical model which makes exclusive use of the double floating-point type, and doubles are initialized to NaN in D by default. Consequently, propogating NaNs through the calculation makes it hard to track down where the first NaN came from - hence, which variable in particular was forgotten to be initialized. There are a lot of variables in this model, and debugging is not easy since it is running under Excel (from VBA) as an external Win32 DLL, so no printf tricks will track the guy down unfortunately. Anyway, I think my point still stands. Use of uninitialized variable warning, please? Or perhaps a way to trap usage of a NaN in a calculation and break into the debugger - THAT would make debugging MUCH faster, i.e. use SNANs instead of QNANs (signaling/noisy vs. quiet).
Oct 28 2005
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"James Dunne" <james.jdunne gmail.com> wrote in message
news:djtfg6$1u2s$1 digitaldaemon.com...
 Can we have a new warning for use of potentially uninitialized variable?
   I know this might cause problems with current code relying on D's
 default initialization values.

As you say, that kinda undermines a lot of the way D is oriented.
 Anyway, I have a mathematical model which makes exclusive use of the
 double floating-point type, and doubles are initialized to NaN in D by
 default.  Consequently, propogating NaNs through the calculation makes
 it hard to track down where the first NaN came from - hence, which
 variable in particular was forgotten to be initialized.

 There are a lot of variables in this model, and debugging is not easy
 since it is running under Excel (from VBA) as an external Win32 DLL, so
 no printf tricks will track the guy down unfortunately.

When I needed to use printf in a DLL with no console, I'd have the printf write to a file. That worked well.
 Anyway, I think my point still stands.  Use of uninitialized variable
 warning, please?  Or perhaps a way to trap usage of a NaN in a
 calculation and break into the debugger - THAT would make debugging MUCH
 faster, i.e. use SNANs instead of QNANs (signaling/noisy vs. quiet).

Some strategically placed assert(!isnan(x)) expressions should help.
Oct 28 2005
parent reply James Dunne <james.jdunne gmail.com> writes:
In article <djtk8t$22lg$2 digitaldaemon.com>, Walter Bright says...
"James Dunne" <james.jdunne gmail.com> wrote in message
news:djtfg6$1u2s$1 digitaldaemon.com...
 Can we have a new warning for use of potentially uninitialized variable?
   I know this might cause problems with current code relying on D's
 default initialization values.

As you say, that kinda undermines a lot of the way D is oriented.

Well, I think the case is exceptional for IEEE floating point types in D. If I assume correctly, you've initialized them to _quiet_ NaNs so that it'd be easy to detect when they are used in their "uninitialized" state. Since the IEEE spec defines that no _signaling_ NaN will be produced by any floating point operation, and that SNaNs are strictly for assignment purposes, it seems logical to initialize floating point values to signaling NaNs instead of quiet NaNs. I'm sure you're well aware of this, and perhaps it might have been a minor oversight. However, if there was some conscious decision made as whether to use QNaNs over SNaNs I'd be interested to hear some reasoning. FWIW, I'm not that well read on the topic of the IEEE standard, but I did do my homework! =) I came across 'rumors', if you will, that supporting signaling NaNs is tough to do in implementation because I guess the spec is unclear on specific details of implementation and certain usage cases.
 Anyway, I have a mathematical model which makes exclusive use of the
 double floating-point type, and doubles are initialized to NaN in D by
 default.  Consequently, propogating NaNs through the calculation makes
 it hard to track down where the first NaN came from - hence, which
 variable in particular was forgotten to be initialized.

 There are a lot of variables in this model, and debugging is not easy
 since it is running under Excel (from VBA) as an external Win32 DLL, so
 no printf tricks will track the guy down unfortunately.

When I needed to use printf in a DLL with no console, I'd have the printf write to a file. That worked well.

Thought of doing that, yes...
 Anyway, I think my point still stands.  Use of uninitialized variable
 warning, please?  Or perhaps a way to trap usage of a NaN in a
 calculation and break into the debugger - THAT would make debugging MUCH
 faster, i.e. use SNANs instead of QNANs (signaling/noisy vs. quiet).

Some strategically placed assert(!isnan(x)) expressions should help.

Yes, but hopefully catching a floating-point exception from usage of a signaling NaN would track it down even better... ? Regards, James Dunne
Oct 28 2005
next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
James Dunne wrote:

 Well, I think the case is exceptional for IEEE floating point types
 in D.  If I assume correctly, you've initialized them to _quiet_ NaNs
 so that it'd be easy to detect when they are used in their
 "uninitialized" state.  

 Since the IEEE spec defines that no
 _signaling_ NaN will be produced by any floating point operation, and
 that SNaNs are strictly for assignment purposes, it seems logical to
 initialize floating point values to signaling NaNs instead of quiet
 NaNs.

Precisely! I too missed the distinction when I last year studied NANs. For some embarrassing oversight, I never stopped to figure out exactly why there are two distinct NANs in the first place. (I guess I just vaguely assumed that it'd give more ways for the application programmer to deal with them.) Even though we have "printf debugging", this would save a considerable amount of time. And while QNANs would be propagated, SNANs should at least cause an error whenever they are stumbled upon. (This includes code that never expects to see them.)
Oct 29 2005
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"James Dunne" <james.jdunne gmail.com> wrote in message
news:djun8f$1ht$1 digitaldaemon.com...
 Well, I think the case is exceptional for IEEE floating point types in D.

 assume correctly, you've initialized them to _quiet_ NaNs so that it'd be

 to detect when they are used in their "uninitialized" state.  Since the

 spec defines that no _signaling_ NaN will be produced by any floating

 operation, and that SNaNs are strictly for assignment purposes, it seems

 to initialize floating point values to signaling NaNs instead of quiet

 I'm sure you're well aware of this, and perhaps it might have been a minor
 oversight.  However, if there was some conscious decision made as whether

 QNaNs over SNaNs I'd be interested to hear some reasoning.

I essentially gave up on the SNAN/QNAN distinction because it was too often unsupported.
 FWIW, I'm not that well read on the topic of the IEEE standard, but I did

 homework! =)  I came across 'rumors', if you will, that supporting

 NaNs is tough to do in implementation because I guess the spec is unclear

 specific details of implementation and certain usage cases.

It isn't hard to do the implementation. The hard thing is that too much software out there ignores the distinction, and nearly all documentation makes no distinction. It's just too frustrating.
When I needed to use printf in a DLL with no console, I'd have the printf
write to a file. That worked well.

 Anyway, I think my point still stands.  Use of uninitialized variable
 warning, please?  Or perhaps a way to trap usage of a NaN in a
 calculation and break into the debugger - THAT would make debugging



 faster, i.e. use SNANs instead of QNANs (signaling/noisy vs. quiet).

Some strategically placed assert(!isnan(x)) expressions should help.

Yes, but hopefully catching a floating-point exception from usage of a

 NaN would track it down even better... ?

No, all the signal does is set a flag FE_EXCEPT. Not too useful.
Oct 29 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Walter Bright wrote:
 It isn't hard to do the implementation. The hard thing is that too
 much software out there ignores the distinction, and nearly all
 documentation makes no distinction. It's just too frustrating.

...
 NaN would track it down even better... ?

No, all the signal does is set a flag FE_EXCEPT. Not too useful.

Hmm. Seems to me inserting tests for FE_EXCEPT and then throwing wouldn't bee too hard? Of course it would slow non-release floating point code significantly, but I don't see that as a major problem. Granted, if we use bad (non-D) libraries, then we're out of luck, but the point here is to make it easy to write robust floating point libraries in D. As well as robust applications. Somehow I can't help feeling this should be easier to implement than bounds checking. Or then I've misunderstood something. :-)
Oct 29 2005
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message
news:4363EFF5.20203 nospam.org...
 No, all the signal does is set a flag FE_EXCEPT. Not too useful.

Hmm. Seems to me inserting tests for FE_EXCEPT and then throwing wouldn't bee too hard? Of course it would slow non-release floating point code significantly, but I don't see that as a major problem.

No, it wouldn't be too hard. But it wouldn't be any easier than doing assert(!isnan(x));
 Granted, if we use bad (non-D) libraries, then we're out of luck, but
 the point here is to make it easy to write robust floating point
 libraries in D. As well as robust applications.

 Somehow I can't help feeling this should be easier to implement than
 bounds checking. Or then I've misunderstood something. :-)

Oct 30 2005
next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Walter Bright wrote:
 "Georg Wrede" <georg.wrede nospam.org> wrote in message
 news:4363EFF5.20203 nospam.org...
 
No, all the signal does is set a flag FE_EXCEPT. Not too useful.

Hmm. Seems to me inserting tests for FE_EXCEPT and then throwing wouldn't bee too hard? Of course it would slow non-release floating point code significantly, but I don't see that as a major problem.

No, it wouldn't be too hard. But it wouldn't be any easier than doing assert(!isnan(x));

So, the bright boy from the plains asks the weathered seaman "we'd need a power winch at this point on the deck" and the seaman answers "you'd only need it late in the afternoon when everybody is drunk, or at night in the storm when everybody is too exhausted to think clearly". I step back.
Granted, if we use bad (non-D) libraries, then we're out of luck, but
the point here is to make it easy to write robust floating point
libraries in D. As well as robust applications.

Somehow I can't help feeling this should be easier to implement than
bounds checking. Or then I've misunderstood something. :-)


Oct 30 2005
prev sibling parent reply James Dunne <james.jdunne gmail.com> writes:
Walter Bright wrote:
 "Georg Wrede" <georg.wrede nospam.org> wrote in message
 news:4363EFF5.20203 nospam.org...
 
No, all the signal does is set a flag FE_EXCEPT. Not too useful.

Hmm. Seems to me inserting tests for FE_EXCEPT and then throwing wouldn't bee too hard? Of course it would slow non-release floating point code significantly, but I don't see that as a major problem.

No, it wouldn't be too hard. But it wouldn't be any easier than doing assert(!isnan(x));

That'd get real ugly, real quick. Especially when you have complex lines of code that are using vectors of doubles with operator overloads. Granted, the assert statement could go in the vector's operator overloads, but still the problem remains for complex lines of floating-point calculations... Let me fabricate an example from a line of my code: debug { assert(!isnan(a)); assert(!isnan(b)); assert(!isnan(c)); assert(!isnan(d)); assert(!isnan(e)); assert(!isnan(f)); } T = (a * b + c*d + (a * (e - b) + (e - c) * d) / f) * (1.0 / (a + d)); (the variable names have been changed to protect intellectual property and to disguise any actual meaning of the calculation) Anyway, this is just one of a few hundred lines of calculations in the model, and requiring that block of 6 assert lines to be called before each line (worst-case scenario of course) is a bit overwhelming. In reality, you'd only have to check the inputs as they come into the function with a nice contract - but to be honest, I never have used DbC and completely forget that they exist. The way I see it, there are 2 possible solutions here: 1) Have compiler throw in assert(!isnan(x)) statements automatically under debug build (possibly with additional compiler switch) before each floating-point operation 2) Switch default QNaN initialization to SNaN and check FE_EXCEPT flag after each floating-point operation to throw a FloatingPointException (again under debug build possibly with additional compiler switch) Are you sure that FE_EXCEPT flag is the only thing that happens when a SNaN is hit? Isn't there a hardware interrupt tied in somewhere for this sort of thing? Throwing up a flag is nice and all, but quite useless if it must be checked explicitly after each floating-point operation... I think the implicit assert statement is a good option if the hardware end seems to fall apart. It'd be no worse than implicit array bounds checking. And like George said, it's only in debug mode. It would certainly lighten the load from the programmer off to the compiler.
 
Granted, if we use bad (non-D) libraries, then we're out of luck, but
the point here is to make it easy to write robust floating point
libraries in D. As well as robust applications.

Somehow I can't help feeling this should be easier to implement than
bounds checking. Or then I've misunderstood something. :-)


Oct 31 2005
next sibling parent reply Sean Kelly <sean f4.ca> writes:
James Dunne wrote:
 
 Are you sure that FE_EXCEPT flag is the only thing that happens when a 
 SNaN is hit?  Isn't there a hardware interrupt tied in somewhere for 
 this sort of thing?  Throwing up a flag is nice and all, but quite 
 useless if it must be checked explicitly after each floating-point 
 operation...

The C standard says that floating point exceptions should be handled in a similar fashion to exceptions raised by arithmetic exceptions, thus any traps the system supports should be called by feraiseexcept. I know the Sun compiler can be set to behave this way, and I believe it can be turned off by specifying that quiet NaNs should be used (fuzzy on the details, I only saw mention of all this in their header files). I'm not sure how much granularity might be useful, but it would probably no be terribly difficult to provide a mask that indicates which exceptions should throw/signal and which should not. I'll check the IA-32 docs and see if I can find some more info on this. My experience with floating point at this level is very limited. Sean
Oct 31 2005
parent reply Sean Kelly <sean f4.ca> writes:
It turns out that x86 does define a set of floating point exceptions, 
and these are handled just like divide by zero and such.  At a glance, I 
think exception handling support for this could be built into Phobos, 
likely by modifying internal/deh.c.  I need to read up a bit on 
structured exception handling, but I'll play with this a bit and see 
what I can work out.  I don't know offhand if it will conflict with how 
the DM C library handles floating point exceptions though, perhaps 
Walter can tell us?


Sean
Oct 31 2005
parent James Dunne <james.jdunne gmail.com> writes:
Sean Kelly wrote:
 It turns out that x86 does define a set of floating point exceptions, 
 and these are handled just like divide by zero and such.  At a glance, I 
 think exception handling support for this could be built into Phobos, 
 likely by modifying internal/deh.c.  I need to read up a bit on 
 structured exception handling, but I'll play with this a bit and see 
 what I can work out.  I don't know offhand if it will conflict with how 
 the DM C library handles floating point exceptions though, perhaps 
 Walter can tell us?
 
 
 Sean

Exactly! Setting the signaling NaN to raise an exception should *NOT* adversely affect any previously existing code, unless such code *explicitly* makes use of signaling NaNs. Most uses of NaNs are quiet. This is why the distinction exists. If the signaling NaN is not set to raise an exception, then there is effectively no difference between signaling and quiet NaNs (aside from simply setting the FE_INVALID flag, but even that is rarely checked).
Nov 03 2005
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"James Dunne" <james.jdunne gmail.com> wrote in message
news:dk5ncl$1hp0$1 digitaldaemon.com...
 That'd get real ugly, real quick.  Especially when you have complex
 lines of code that are using vectors of doubles with operator overloads.
   Granted, the assert statement could go in the vector's operator
 overloads, but still the problem remains for complex lines of
 floating-point calculations...  Let me fabricate an example from a line
 of my code:

 debug {
 assert(!isnan(a));
 assert(!isnan(b));
 assert(!isnan(c));
 assert(!isnan(d));
 assert(!isnan(e));
 assert(!isnan(f));
 }
 T = (a * b + c*d + (a * (e - b) + (e - c) * d) / f) * (1.0 / (a + d));

 (the variable names have been changed to protect intellectual property
 and to disguise any actual meaning of the calculation)

What I'd to is just add: assert(!isnan(T)). Then, only if it trips, would I worry about which one it is.
 Anyway, this is just one of a few hundred lines of calculations in the
 model, and requiring that block of 6 assert lines to be called before
 each line (worst-case scenario of course) is a bit overwhelming.  In
 reality, you'd only have to check the inputs as they come into the
 function with a nice contract - but to be honest, I never have used DbC
 and completely forget that they exist.

 The way I see it, there are 2 possible solutions here:

 1) Have compiler throw in assert(!isnan(x)) statements automatically
 under debug build (possibly with additional compiler switch) before each
 floating-point operation

NaN is a useful value in its own right, especially when doing data collection. You don't want to throw out your entire data set because of a few known bad values (such as data from a space probe, or data from a camera with a few stuck pixels). You only want to know if your output is affected by those bad values. NaN fits the bill perfectly. (In digital electronics, one normally deals with True, False, and Don't Know. NaN corresponds to the Don't Know state.) Implementing "nans-are-bugs" would preclude D from being useful for a significant problem space.
 2) Switch default QNaN initialization to SNaN and check FE_EXCEPT flag
 after each floating-point operation to throw a FloatingPointException
 (again under debug build possibly with additional compiler switch)

 Are you sure that FE_EXCEPT flag is the only thing that happens when a
 SNaN is hit?

Yes (actually, it's FE_INVALID). A qnan does not set FE_INVALID.
 Isn't there a hardware interrupt tied in somewhere for
 this sort of thing?  Throwing up a flag is nice and all, but quite
 useless if it must be checked explicitly after each floating-point
 operation...

It's possible to configure the hardware to do that. I don't know if such is supported by Win32 or Linux, though. I'd also caution against it, because all sorts of floating point code will start failing, as that isn't expected behavior.
Nov 01 2005
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
 
 NaN is a useful value in its own right, especially when doing data
 collection. You don't want to throw out your entire data set because of a
 few known bad values (such as data from a space probe, or data from a camera
 with a few stuck pixels). You only want to know if your output is affected
 by those bad values. NaN fits the bill perfectly. (In digital electronics,
 one normally deals with True, False, and Don't Know. NaN corresponds to the
 Don't Know state.) Implementing "nans-are-bugs" would preclude D from being
 useful for a significant problem space.

I agree. Were this to be implemented it should be purely optional. I've never felt the need for this feature myself, but if it's not too hard to do, perhaps it could be a compile or run-time option?
Isn't there a hardware interrupt tied in somewhere for
this sort of thing?  Throwing up a flag is nice and all, but quite
useless if it must be checked explicitly after each floating-point
operation...

It's possible to configure the hardware to do that. I don't know if such is supported by Win32 or Linux, though. I'd also caution against it, because all sorts of floating point code will start failing, as that isn't expected behavior.

Win32 supports at least some of the FP exceptions through SEH, but divide by zero was the only one I saw listed in the Win32 docs that seemed particularly useful and D already supports that one. I couldn't say whether Linux supports this, but I imagine it does. Sean
Nov 01 2005
parent "Walter Bright" <newshound digitalmars.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:dk914a$1afm$1 digitaldaemon.com...
 Walter Bright wrote:
 NaN is a useful value in its own right, especially when doing data
 collection. You don't want to throw out your entire data set because of


 few known bad values (such as data from a space probe, or data from a


 with a few stuck pixels). You only want to know if your output is


 by those bad values. NaN fits the bill perfectly. (In digital


 one normally deals with True, False, and Don't Know. NaN corresponds to


 Don't Know state.) Implementing "nans-are-bugs" would preclude D from


 useful for a significant problem space.

I agree. Were this to be implemented it should be purely optional. I've never felt the need for this feature myself, but if it's not too hard to do, perhaps it could be a compile or run-time option?

C and C++ are loaded up with compiler switches that change the meaning of the language. I really want to do my best to avoid this. In the end, it does the users a disservice because they can't rely on consistent semantics.
Nov 01 2005
prev sibling next sibling parent reply James Dunne <james.jdunne gmail.com> writes:
Walter Bright wrote:
 "James Dunne" <james.jdunne gmail.com> wrote in message
 news:dk5ncl$1hp0$1 digitaldaemon.com...
 
That'd get real ugly, real quick.  Especially when you have complex
lines of code that are using vectors of doubles with operator overloads.
  Granted, the assert statement could go in the vector's operator
overloads, but still the problem remains for complex lines of
floating-point calculations...  Let me fabricate an example from a line
of my code:

debug {
assert(!isnan(a));
assert(!isnan(b));
assert(!isnan(c));
assert(!isnan(d));
assert(!isnan(e));
assert(!isnan(f));
}
T = (a * b + c*d + (a * (e - b) + (e - c) * d) / f) * (1.0 / (a + d));

(the variable names have been changed to protect intellectual property
and to disguise any actual meaning of the calculation)

What I'd to is just add: assert(!isnan(T)). Then, only if it trips, would I worry about which one it is.
Anyway, this is just one of a few hundred lines of calculations in the
model, and requiring that block of 6 assert lines to be called before
each line (worst-case scenario of course) is a bit overwhelming.  In
reality, you'd only have to check the inputs as they come into the
function with a nice contract - but to be honest, I never have used DbC
and completely forget that they exist.

The way I see it, there are 2 possible solutions here:

1) Have compiler throw in assert(!isnan(x)) statements automatically
under debug build (possibly with additional compiler switch) before each
floating-point operation

NaN is a useful value in its own right, especially when doing data collection. You don't want to throw out your entire data set because of a few known bad values (such as data from a space probe, or data from a camera with a few stuck pixels). You only want to know if your output is affected by those bad values. NaN fits the bill perfectly. (In digital electronics, one normally deals with True, False, and Don't Know. NaN corresponds to the Don't Know state.) Implementing "nans-are-bugs" would preclude D from being useful for a significant problem space.
2) Switch default QNaN initialization to SNaN and check FE_EXCEPT flag
after each floating-point operation to throw a FloatingPointException
(again under debug build possibly with additional compiler switch)

Are you sure that FE_EXCEPT flag is the only thing that happens when a
SNaN is hit?

Yes (actually, it's FE_INVALID). A qnan does not set FE_INVALID.
Isn't there a hardware interrupt tied in somewhere for
this sort of thing?  Throwing up a flag is nice and all, but quite
useless if it must be checked explicitly after each floating-point
operation...

It's possible to configure the hardware to do that. I don't know if such is supported by Win32 or Linux, though. I'd also caution against it, because all sorts of floating point code will start failing, as that isn't expected behavior.

How can I catch an assert from a DLL using WinDbg? From what I've seen, WinDbg doesn't break on D's exceptions, unless they're serious enough like an Access Violation.
Nov 03 2005
parent Sean Kelly <sean f4.ca> writes:
James Dunne wrote:
 
 How can I catch an assert from a DLL using WinDbg?  From what I've seen, 
 WinDbg doesn't break on D's exceptions, unless they're serious enough 
 like an Access Violation.

I think you either need to override the assert handler or put a breakpoint there (Ares makes it easy to do this). Do a search in phobos/internal for "_d_assert." The easiest thing is just to add a divide by zero or an asm { int 3; } statement. Sean
Nov 03 2005
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Walter Bright wrote:
 "James Dunne" <james.jdunne gmail.com> 

 Isn't there a hardware interrupt tied in somewhere for this sort of
 thing?  Throwing up a flag is nice and all, but quite useless if it
 must be checked explicitly after each floating-point operation...

It's possible to configure the hardware to do that. I don't know if such is supported by Win32 or Linux, though. I'd also caution against it, because all sorts of floating point code will start failing, as that isn't expected behavior.

I don't understand the problem. Suppose my code wants to use a hardware interrupt with FPU ops. Then, first my code sets up a handler, then turns on the interrupt. Now, if an interrupt occurs, then my code gets executed. Any other code running simultaneously on the (windows or linux) machine, gets the FPU flags set its own way whenever a process switch takes place. Therefore, the other code is oblivious of my FPU interrupt settings, right? So, we're back to if I use sloppy 3rd party libraries from my D code, and they choke on SNANs. But then, my handler gets executed anyway, which is what I'd want all along. And any new process starting on the machine gets the FPU reset, flags and all. So, I still don't see the problem. Additionally, how my code uses the FPU should not interest the OS, right? If I crap up my calculations, as long as I have installed the interrupt handler, nothing disturbs anybody else. Unless of course, Windows _prevents_ me from doing that, or deliberately interferes. But even I am not paranoid enough to really suspect that.
Nov 03 2005
next sibling parent Sean Kelly <sean f4.ca> writes:
Georg Wrede wrote:
 Walter Bright wrote:
 
 "James Dunne" <james.jdunne gmail.com>

 Isn't there a hardware interrupt tied in somewhere for this sort of
 thing?  Throwing up a flag is nice and all, but quite useless if it
 must be checked explicitly after each floating-point operation...

It's possible to configure the hardware to do that. I don't know if such is supported by Win32 or Linux, though. I'd also caution against it, because all sorts of floating point code will start failing, as that isn't expected behavior.

I don't understand the problem. Suppose my code wants to use a hardware interrupt with FPU ops. Then, first my code sets up a handler, then turns on the interrupt. Now, if an interrupt occurs, then my code gets executed.

I think the issue is that this is something that is supposed to be done through the OS rather than setting hardware traps directly--see the IA-32 docs on floating point exceptions for more information. But you're right about the behavior.
 Any other code running simultaneously on the (windows or linux) machine, 
 gets the FPU flags set its own way whenever a process switch takes 
 place. Therefore, the other code is oblivious of my FPU interrupt 
 settings, right?

Yes.
 Additionally, how my code uses the FPU should not interest the OS, 
 right? If I crap up my calculations, as long as I have installed the 
 interrupt handler, nothing disturbs anybody else.

It's just like a divide by zero error (which is also a hardware exception) The only thing that happens is that the OS halts your app, often triggering a debugger if one is active. Sean
Nov 03 2005
prev sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message
news:436A5D7A.4020102 nospam.org...
 So, we're back to if I use sloppy 3rd party libraries from my D code,
 and they choke on SNANs. But then, my handler gets executed anyway,
 which is what I'd want all along.

I wouldn't call it sloppy, because SNANs have simply (and unfortunately) not been endorsed by the standards that matter, and so code doesn't take the difference between SNAN and QNAN into account. This includes C, and D is supposed to conform to the C ABI.
Nov 06 2005
prev sibling parent reply Burton Radons <burton-radons smocky.com> writes:
Walter Bright wrote:
 A couple of oft-requested features.
 
 http://www.digitalmars.com/d/changelog.html

Scoping access rights broke: class A { class B { protected this () { } } } int main () { new A.B (); return 0; } This fails compilation in Linux with "class f.A.B member this is not accessible". It worked before.
Nov 04 2005
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Burton Radons" <burton-radons smocky.com> wrote in message
news:dkgtc4$4oi$1 digitaldaemon.com...
 Walter Bright wrote:
 A couple of oft-requested features.

 http://www.digitalmars.com/d/changelog.html

Scoping access rights broke: class A { class B { protected this () { } } } int main () { new A.B (); return 0; } This fails compilation in Linux with "class f.A.B member this is not accessible". It worked before.

I believe the compiler is correct, as protected means that only derived classes can access it. main() is not a member of a class derived from B, so it cannot create an instance of B, because B's constructor is protected.
Nov 05 2005
parent reply Burton Radons <burton-radons smocky.com> writes:
Walter Bright wrote:
 "Burton Radons" <burton-radons smocky.com> wrote in message
 news:dkgtc4$4oi$1 digitaldaemon.com...
 
Walter Bright wrote:

A couple of oft-requested features.

http://www.digitalmars.com/d/changelog.html

Scoping access rights broke: class A { class B { protected this () { } } } int main () { new A.B (); return 0; } This fails compilation in Linux with "class f.A.B member this is not accessible". It worked before.

I believe the compiler is correct, as protected means that only derived classes can access it. main() is not a member of a class derived from B, so it cannot create an instance of B, because B's constructor is protected.

You forget your language. :) Private and protected members are accessible throughout the module they've been declared in: "Private means that only members of the enclosing class can access the member, or members and functions in the same module as the enclosing class. Private members cannot be overridden. ... Protected means that only members of the enclosing class or any classes derived from that class, or members and functions in the same module as the enclosing class, can access the member." (http://www.digitalmars.com/d/attribute.html under Protection Attribute)
Nov 05 2005
parent "Walter Bright" <newshound digitalmars.com> writes:
"Burton Radons" <burton-radons smocky.com> wrote in message news:dkil5i$1o40
 You forget your language.  :)  Private and protected members are
 accessible throughout the module they've been declared in:

You're right. I'll fix the bug.
Nov 06 2005