digitalmars.D - void returns
- Benedikt Meurer (17/17) May 22 2004 Hello,
- J C Calvarese (33/57) May 22 2004 In D, void means the function doesn't return a value. But that doesn't
- Andy Friesen (13/16) May 22 2004 Right. He's referring to syntactically allowing 'void' to be returned.
- J C Calvarese (7/31) May 22 2004 Oops. Somehow I missed his reference to templates (perhaps my eyes
- Matthew (4/21) May 22 2004 Ah, something I've always wanted in C++...
- davepermen (6/34) May 22 2004 works in c++...
- Matthew (7/45) May 22 2004 Yes, but it's a relatively late addition, and several recent or still in...
- Kris (4/7) May 22 2004 I suppose sizeof(void) would need to reflect the size of void[] elements...
- Matthew (5/12) May 22 2004 Sorry, I forgot to say. I would want sizeof(void) to be 0, so it could f...
- Hwa Hwa (1/4) May 22 2004 Yes, you would gloat too much.
- Kevin Bealer (5/8) May 26 2004 There would discussion, then arguments, then terrible war between the pr...
- Matthew (6/14) May 26 2004 a
- Kevin Bealer (8/23) May 27 2004 Actually, I meant, that usenet's natural state is endless war, so there'...
- Arcane Jill (14/33) May 27 2004 Actually, that is a very good point. If void.sizeof were simply *not def...
- James McComb (17/23) May 22 2004 According to Bertrand Meyer, creator of Eiffel, there are two kinds of
- Juan C (5/7) May 22 2004
- davepermen (5/12) May 22 2004 or a knife to kill people/animals. should not be allowed.
- Walter (5/9) May 22 2004 My thoughts exactly. I know this feature was added to C++, but are there
- Benedikt Meurer (33/44) May 23 2004 No, it is an important point in the C++ language, cause without it, you'...
- Walter (8/23) May 23 2004 another
- Arcane Jill (14/26) May 24 2004 I've used templates a lot in C++. I haven't used them in D (yet) because...
- Sean Kelly (19/23) May 23 2004 This comes up a lot when using the algorithms from the C++ standard
- Norbert Nemec (10/38) May 23 2004 D allows lots of stuff that Bertrand Meyer does not like. If you want to
- Bent Rasmussen (10/19) May 23 2004 I'd call it an idiom than you can use, but Eiffel does not force you int...
- Norbert Nemec (10/17) May 23 2004 I don't believe, splitting "pop" into two calls would prevent any bugs. ...
- James McComb (10/12) May 23 2004 I agree with you. In case you think I worship Betrand Meyer, here's the
- Norbert Nemec (5/19) May 24 2004 Sorry, I have no idea what he means with "weakening exception safety". I
- Matthew (9/28) May 24 2004 If you pop and return the pop'd value in one notional operation, it is p...
- Ivan Senji (16/33) May 24 2004 I have to say I am surprised that this isn't possible in D.
- Kevin Bealer (26/34) May 25 2004 This idea could be taken further. Instead of just for return types, ima...
- Norbert Nemec (2/26) May 25 2004 You probably want to say "A map with no *data*"
- Arcane Jill (26/26) May 26 2004 Since the bool type suggestion went down so well, it's worth pointing ou...
- Juan C (2/28) May 26 2004
- Regan Heath (8/50) May 26 2004 Intersting idea..
- Derek Parnell (12/44) May 26 2004 Hmmmmm...don't know....sounds a bit too logical... Oh well, let's throw
- Antti =?iso-8859-1?Q?Syk=E4ri?= (11/21) May 27 2004 Why not use just byte* instead of unknown*?
Hello,
Would it be possible to add support for void returns, as in
void f1 () { ... }
void f2 () { ...; return f1 (); }
to D? This would be invaluably helpful in template programming. Else one has
to either make heavy use of mixins or write a lot of specialisations.
(Looking at the code, it seems, that only dmd/statement.c has to be modified
to archive this goal).
regards,
Benedikt
--
NetBSD Operating system: http://www.NetBSD.org/
pkgsrc "Work in progress": http://pkgsrc-wip.sf.net/
XFce desktop environment: http://www.xfce.org/
German Unix-AG Association: http://www.unix-ag.org/
os-network: http://www.os-network.de/
OpenPGP Key: http://www.home.unix-ag.org/bmeurer/#gpg
May 22 2004
Benedikt Meurer wrote:Hello, Would it be possible to add support for void returns, as in void f1 () { ... } void f2 () { ...; return f1 (); } to D? This would be invaluably helpful in template programming. Else one has to either make heavy use of mixins or write a lot of specialisations. (Looking at the code, it seems, that only dmd/statement.c has to be modified to archive this goal). regards, BenediktIn D, void means the function doesn't return a value. But that doesn't prevent you from calling another function. I'm not sure I understand what your goal is. You can already do this: void f1() { printf("Running f1...\n"); } void f2() { bit itsAGoodIdea = true; printf("Running f2...\n"); if(itsAGoodIdea) { f1(); return; } printf("Don't go there.\n"); } void main() { f2(); printf("The end.\n"); } /* Output: Running f2... Running f1... The end. */-- NetBSD Operating system: http://www.NetBSD.org/ pkgsrc "Work in progress": http://pkgsrc-wip.sf.net/ XFce desktop environment: http://www.xfce.org/ German Unix-AG Association: http://www.unix-ag.org/ os-network: http://www.os-network.de/ OpenPGP Key: http://www.home.unix-ag.org/bmeurer/#gpg-- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/
May 22 2004
J C Calvarese wrote:In D, void means the function doesn't return a value. But that doesn't prevent you from calling another function. I'm not sure I understand what your goal is.Right. He's referring to syntactically allowing 'void' to be returned. void f1() { } void f2() { return f1(); } f1 has no return value, and neither does f2, so it... sort of, makes sense. The big reason to allow it is because the return type may be parameterized: template t(T) { T f1() { ... } T f2() { return f1(); } } If void can be returned, T can be void, in this example. -- andy
May 22 2004
J C Calvarese <jcc7 cox.net> Andy Friesen wrote:J C Calvarese wrote:Oops. Somehow I missed his reference to templates (perhaps my eyes started to glaze after after I saw his example). Sounds like a good idea since it'd help templatization. -- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/In D, void means the function doesn't return a value. But that doesn't prevent you from calling another function. I'm not sure I understand what your goal is.Right. He's referring to syntactically allowing 'void' to be returned. void f1() { } void f2() { return f1(); } f1 has no return value, and neither does f2, so it... sort of, makes sense. The big reason to allow it is because the return type may be parameterized: template t(T) { T f1() { ... } T f2() { return f1(); } } If void can be returned, T can be void, in this example. -- andy
May 22 2004
Ah, something I've always wanted in C++...
I echo the request.
"Benedikt Meurer" <benedikt.meurer unix-ag.uni-siegen.de> wrote in message
news:c8o52s$1j0l$1 digitaldaemon.com...
Hello,
Would it be possible to add support for void returns, as in
void f1 () { ... }
void f2 () { ...; return f1 (); }
to D? This would be invaluably helpful in template programming. Else one has
to either make heavy use of mixins or write a lot of specialisations.
(Looking at the code, it seems, that only dmd/statement.c has to be modified
to archive this goal).
regards,
Benedikt
--
NetBSD Operating system: http://www.NetBSD.org/
pkgsrc "Work in progress": http://pkgsrc-wip.sf.net/
XFce desktop environment: http://www.xfce.org/
German Unix-AG Association: http://www.unix-ag.org/
os-network: http://www.os-network.de/
OpenPGP Key: http://www.home.unix-ag.org/bmeurer/#gpg
May 22 2004
works in c++... should be working in D, too, indeed. "Matthew" <matthew.hat stlsoft.dot.org> schrieb im Newsbeitrag news:c8okjt$28o9$1 digitaldaemon.com...Ah, something I've always wanted in C++... I echo the request. "Benedikt Meurer" <benedikt.meurer unix-ag.uni-siegen.de> wrote in message news:c8o52s$1j0l$1 digitaldaemon.com...hasHello, Would it be possible to add support for void returns, as in void f1 () { ... } void f2 () { ...; return f1 (); } to D? This would be invaluably helpful in template programming. Else onemodifiedto either make heavy use of mixins or write a lot of specialisations. (Looking at the code, it seems, that only dmd/statement.c has to beto archive this goal). regards, Benedikt -- NetBSD Operating system: http://www.NetBSD.org/ pkgsrc "Work in progress": http://pkgsrc-wip.sf.net/ XFce desktop environment: http://www.xfce.org/ German Unix-AG Association: http://www.unix-ag.org/ os-network: http://www.os-network.de/ OpenPGP Key: http://www.home.unix-ag.org/bmeurer/#gpg
May 22 2004
Yes, but it's a relatively late addition, and several recent or still in use compilers don't support it, which makes its use a portability problem. Here's another one to consider. In C++ I've had occasion to require a sizeof(void), and had to resort to traits in order to get it. Does anyone see a downside with sizeof(void) being legal in D? "davepermen" <davepermen hotmail.com> wrote in message news:c8ol00$29c3$1 digitaldaemon.com...works in c++... should be working in D, too, indeed. "Matthew" <matthew.hat stlsoft.dot.org> schrieb im Newsbeitrag news:c8okjt$28o9$1 digitaldaemon.com...Ah, something I've always wanted in C++... I echo the request. "Benedikt Meurer" <benedikt.meurer unix-ag.uni-siegen.de> wrote in message news:c8o52s$1j0l$1 digitaldaemon.com...hasHello, Would it be possible to add support for void returns, as in void f1 () { ... } void f2 () { ...; return f1 (); } to D? This would be invaluably helpful in template programming. Else onemodifiedto either make heavy use of mixins or write a lot of specialisations. (Looking at the code, it seems, that only dmd/statement.c has to beto archive this goal). regards, Benedikt -- NetBSD Operating system: http://www.NetBSD.org/ pkgsrc "Work in progress": http://pkgsrc-wip.sf.net/ XFce desktop environment: http://www.xfce.org/ German Unix-AG Association: http://www.unix-ag.org/ os-network: http://www.os-network.de/ OpenPGP Key: http://www.home.unix-ag.org/bmeurer/#gpg
May 22 2004
I suppose sizeof(void) would need to reflect the size of void[] elements, which are 1 byte each ... "Matthew" <matthew.hat stlsoft.dot.org>Here's another one to consider. In C++ I've had occasion to require a sizeof(void), and had to resort to traits in order to get it. Does anyonesee adownside with sizeof(void) being legal in D?
May 22 2004
Sorry, I forgot to say. I would want sizeof(void) to be 0, so it could function in constraints validating type sizes. "Kris" <someidiot earthlink.dot.dot.dot.net> wrote in message news:c8oo5n$2dpi$1 digitaldaemon.com...I suppose sizeof(void) would need to reflect the size of void[] elements, which are 1 byte each ... "Matthew" <matthew.hat stlsoft.dot.org>Here's another one to consider. In C++ I've had occasion to require a sizeof(void), and had to resort to traits in order to get it. Does anyonesee adownside with sizeof(void) being legal in D?
May 22 2004
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message news:c8p0mt$2pl2$1 digitaldaemon.com...Sorry, I forgot to say. I would want sizeof(void) to be 0, so it couldfunctionin constraints validating type sizes.There's no way you can make void.sizeof be 0 in D.
May 22 2004
"Walter" <newshound digitalmars.com> wrote in message news:c8p9tn$5js$1 digitaldaemon.com..."Matthew" <matthew.hat stlsoft.dot.org> wrote in message news:c8p0mt$2pl2$1 digitaldaemon.com...Do you mean "there's no way that would be a good thing to do" or "there's no way to technically achieve that"? I can't believe the latter, so am intrigued as to your reasoning for the former.Sorry, I forgot to say. I would want sizeof(void) to be 0, so it couldfunctionin constraints validating type sizes.There's no way you can make void.sizeof be 0 in D.
May 22 2004
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message news:c8pbkm$7tr$1 digitaldaemon.com..."Walter" <newshound digitalmars.com> wrote in message news:c8p9tn$5js$1 digitaldaemon.com...no way"Matthew" <matthew.hat stlsoft.dot.org> wrote in message news:c8p0mt$2pl2$1 digitaldaemon.com...Do you mean "there's no way that would be a good thing to do" or "there'sSorry, I forgot to say. I would want sizeof(void) to be 0, so it couldfunctionin constraints validating type sizes.There's no way you can make void.sizeof be 0 in D.to technically achieve that"? I can't believe the latter, so am intrigued as to your reasoning for theformer. The reason is because you can do pointer arithmetic on void* and indexing of void[]. An axiom of pointer arithmetic is to advance a void* pointer, you add void.sizeof. Breaking this would make an ugly and confusing wart in the language.
May 22 2004
Yes, I can certainly see that point. "Walter" <newshound digitalmars.com> wrote in message news:c8pgrt$f23$2 digitaldaemon.com..."Matthew" <matthew.hat stlsoft.dot.org> wrote in message news:c8pbkm$7tr$1 digitaldaemon.com..."Walter" <newshound digitalmars.com> wrote in message news:c8p9tn$5js$1 digitaldaemon.com...no way"Matthew" <matthew.hat stlsoft.dot.org> wrote in message news:c8p0mt$2pl2$1 digitaldaemon.com...Do you mean "there's no way that would be a good thing to do" or "there'sSorry, I forgot to say. I would want sizeof(void) to be 0, so it couldfunctionin constraints validating type sizes.There's no way you can make void.sizeof be 0 in D.to technically achieve that"? I can't believe the latter, so am intrigued as to your reasoning for theformer. The reason is because you can do pointer arithmetic on void* and indexing of void[]. An axiom of pointer arithmetic is to advance a void* pointer, you add void.sizeof. Breaking this would make an ugly and confusing wart in the language.
May 23 2004
Here's another one to consider. In C++ I've had occasion to require a sizeof(void), and had to resort to traits in order to get it. Does anyone see a downside with sizeof(void) being legal in D?Yes, you would gloat too much.
May 22 2004
In article <c8omac$2bc9$1 digitaldaemon.com>, Matthew says... .Here's another one to consider. In C++ I've had occasion to require a sizeof(void), and had to resort to traits in order to get it. Does anyone see a downside with sizeof(void) being legal in D?There would discussion, then arguments, then terrible war between the proponents of "void.size==" 0, 1, and 4. So essentially, no. Kevin
May 26 2004
"Kevin Bealer" <Kevin_member pathlink.com> wrote in message news:c93rtk$1bic$1 digitaldaemon.com...In article <c8omac$2bc9$1 digitaldaemon.com>, Matthew says... .aHere's another one to consider. In C++ I've had occasion to require a sizeof(void), and had to resort to traits in order to get it. Does anyone seeproponentsdownside with sizeof(void) being legal in D?There would discussion, then arguments, then terrible war between theof "void.size==" 0, 1, and 4. So essentially, no.Yup, if there could not be 99.98% consensus, then I agree the idea must die. I'll just have to have a size_traits in DTL like I've got in STLSoft. ;)
May 26 2004
In article <c940h3$1i62$1 digitaldaemon.com>, Matthew says..."Kevin Bealer" <Kevin_member pathlink.com> wrote in message news:c93rtk$1bic$1 digitaldaemon.com...Actually, I meant, that usenet's natural state is endless war, so there's no downside. Maybe the classes which want void.size really should be broken. If you can't get around needing the size then you probably have a bug right? I mean, unless it is just a printf(). I think if there was void.sizeof there would be people arguing that it should be illegal, in the same spirit as bit == bool. KevinIn article <c8omac$2bc9$1 digitaldaemon.com>, Matthew says... .aHere's another one to consider. In C++ I've had occasion to require a sizeof(void), and had to resort to traits in order to get it. Does anyone seeproponentsdownside with sizeof(void) being legal in D?There would discussion, then arguments, then terrible war between theof "void.size==" 0, 1, and 4. So essentially, no.Yup, if there could not be 99.98% consensus, then I agree the idea must die. I'll just have to have a size_traits in DTL like I've got in STLSoft. ;)
May 27 2004
Maybe the classes which want void.size really should be broken. If you can't get around needing the size then you probably have a bug right? I mean, unless it is just a printf(). I think if there was void.sizeof there would be people arguing that it should be illegal, in the same spirit as bit == bool. KevinActually, that is a very good point. If void.sizeof were simply *not defined* then you'd HAVE to cast it to something else before trying to do pointer arithmetic with it. I still like the idea of having some kind of type with zero size though. So that:zero_size_thing x; // legal zero_size_thing* p, q, r; // legal zero_size_thing[1000000000] a; // is also legal, and takes no memory x.sizeof // equals zero a.sizeof // equals zero p = a; // legal q = &a[100]; // legal q = &a[1000000001]; // NOT legal - array bounds exception r = &x; // legal (p == q) // returns true (p == r) // returns false (a[0] == x) // returns true, since all zero sized objects are equal return x; // identical in meaning to return;I'm not hung up on this one. I don't care one way or the other whether sizeof void is 0, 1, or undefined. I don't care if we split void into its two separate meanings (zero_size_thing and unknown) or not. But in my own little way I like to speculate about such ideas, and if they turn out to be useful, fair play. If not, it's no big deal. I've made other suggestions which matter more to me, but this thread I just regard as fun. Incidently, I accidently parsed "void returns" in the same way as "Batman Returns". I thought: does it? Jill
May 27 2004
Benedikt Meurer wrote:
Hello,
Would it be possible to add support for void returns, as in
void f1 () { ... }
void f2 () { ...; return f1 (); }
According to Bertrand Meyer, creator of Eiffel, there are two kinds of
routines:
Commands (i.e. functions that return void), and
Queries (i.e. functions that return non-void).
According to Meyer, Commands should be used to change state, and Queries
should be used only to query that state.
What is the point of this distinction? For a variety of reasons, the
most important being exception-safety, Queries should not have
side-effects (roughly, they should not change state). This is why pop()
doesn't return a value in the STL stack. pop() is the Command, and top()
is the Query.
If functions that return void and functions that return non-void should
be used for fundamentally different purposes, when would it be a good
idea to have function template parameterized to sometimes return void
and sometimes return non-void?
James McComb
May 22 2004
<snip>According to Meyer, Commands should be used to change state, and Queries should be used only to query that state.</snip> Well then I submit that a knife is to cut food, and a fork is to pick up food (with a spoon being a specialized type of fork?). So one should not use a fork to cut pancakes.
May 22 2004
or a knife to kill people/animals. should not be allowed. "Juan C" <Juan_member pathlink.com> schrieb im Newsbeitrag news:c8osai$2jj6$1 digitaldaemon.com...<snip>foodAccording to Meyer, Commands should be used to change state, and Queries should be used only to query that state.</snip> Well then I submit that a knife is to cut food, and a fork is to pick up(with a spoon being a specialized type of fork?). So one should not use aforkto cut pancakes.
May 22 2004
"James McComb" <alan jamesmccomb.id.au> wrote in message news:c8ophn$2flh$1 digitaldaemon.com...If functions that return void and functions that return non-void should be used for fundamentally different purposes, when would it be a good idea to have function template parameterized to sometimes return void and sometimes return non-void?My thoughts exactly. I know this feature was added to C++, but are there legitimate uses for it, or is it a misfeature, or a workaround for another bug in C++?
May 22 2004
Walter wrote:"James McComb" <alan jamesmccomb.id.au> wrote in message news:c8ophn$2flh$1 digitaldaemon.com...No, it is an important point in the C++ language, cause without it, you'd end up writing a lot of template specialisations for void. Imagine the following very simple example: class Handler(ReturnType, Parameter) { public: alias ReturnType function(Parameter) Function; this (Function func) { func_ = func; } ReturnType opCall (Parameter1 parameter) { return func_ (parameter); } private: Function func_; }; (Of course, you'll probably also want to have a Handler template for functions with 2, 3, 4, ..., x parameters). This won't work if ReturnType is void. The only way to get this to work in D (I should note, that I'm using the latest gdc) is to create a void specialisation for every such template class. This leds to lots of code duplication which is IMHO a bad thing. One should also keep in mind, that the above is a very simple example. Therefore I consider this a vital feature for template programming. The adoption should be easy, just add a paragraph to the spec: "If a function that is declared to return void, discovers a return statement with an expression, this expression has to evaluate to void." or something like that. best regards, Benedikt -- NetBSD Operating system: http://www.NetBSD.org/ pkgsrc "Work in progress": http://pkgsrc-wip.sf.net/ XFce desktop environment: http://www.xfce.org/ German Unix-AG Association: http://www.unix-ag.org/ os-network: http://www.os-network.de/ OpenPGP Key: http://www.home.unix-ag.org/bmeurer/#gpgIf functions that return void and functions that return non-void should be used for fundamentally different purposes, when would it be a good idea to have function template parameterized to sometimes return void and sometimes return non-void?My thoughts exactly. I know this feature was added to C++, but are there legitimate uses for it, or is it a misfeature, or a workaround for another bug in C++?
May 23 2004
"Benedikt Meurer" <benedikt.meurer unix-ag.uni-siegen.de> wrote in message news:c8pjgl$k6c$1 digitaldaemon.com...Walter wrote:another"James McComb" <alan jamesmccomb.id.au> wrote in message news:c8ophn$2flh$1 digitaldaemon.com...If functions that return void and functions that return non-void should be used for fundamentally different purposes, when would it be a good idea to have function template parameterized to sometimes return void and sometimes return non-void?My thoughts exactly. I know this feature was added to C++, but are there legitimate uses for it, or is it a misfeature, or a workaround forendbug in C++?No, it is an important point in the C++ language, cause without it, you'dup writing a lot of template specialisations for void. Imagine thefollowingvery simple example:I see its need for that example, but I don't see that the example does anything useful <g>. The trouble is, I'm not an expert at using templates, so I'd have to take your word for it.
May 23 2004
In article <c8qoat$27jv$1 digitaldaemon.com>, Walter says...I've used templates a lot in C++. I haven't used them in D (yet) because I'm working on a specific project, which just happens not to need them. But I can tell you that being allowed to return void is something that you definitely need in a lot of generic programming. You need it so much, that, if you DON'T put it into the language, then people *will* make their own workarounds for it. For example - I might change something like:I see its need for that example, but I don't see that the example doesanything useful <g>. The trouble is, I'm not an expert at using templates, so I'd have to take your word for it.void printNiceMessage() { printf("hello\n"); }to:bit printNiceMessage() { printf("hello\n"); return true; }just so that I can use it in templates. But this clutters the interface, and confuses people - sometimes they end up testing the return value, thinking false means "something went wrong", when in fact, it can never return false at all. It would be better to allow void as a return type. Arcane Jill
May 24 2004
Walter wrote:My thoughts exactly. I know this feature was added to C++, but are there legitimate uses for it, or is it a misfeature, or a workaround for another bug in C++?This comes up a lot when using the algorithms from the C++ standard library. They all want to pass functions or function objects around to do stuff, and the return type is a part of the template parameterization: template<typedef Ty> struct accumulate : public std::unary_function<void,Ty> { void operator()( Ty const& val ) { total += val; } Ty total; }; It's pretty common to not care about a return type for these functions, but because of the template design a dummy one often has to be provided just to get the code to compile (I commonly change the void to a bool). So there are legitimate uses for it as a workaround for design aspects of the C++ standard library :) I personally don't have much of an issue with "return void;" from a semantic standpoint. It seems pretty clear, if a bit odd. Sean
May 23 2004
D allows lots of stuff that Bertrand Meyer does not like. If you want to follow his coding principles, you are free to do so, but obviously D was not designed to force people using a certain style, but to allow them to express themselves in the way they want to. I like Bertrand Meyer's ideas, but I think that they are a bit idealistic and lead to extremely wordy programs in real life. Just consider a stack class that offeres a "pop" routine. According to Bertrand Meyer, "pop" would be illegal and you should split it up into "get_top" and "remove_top"... James McComb wrote:Benedikt Meurer wrote:Hello, Would it be possible to add support for void returns, as in void f1 () { ... } void f2 () { ...; return f1 (); }According to Bertrand Meyer, creator of Eiffel, there are two kinds of routines: Commands (i.e. functions that return void), and Queries (i.e. functions that return non-void). According to Meyer, Commands should be used to change state, and Queries should be used only to query that state. What is the point of this distinction? For a variety of reasons, the most important being exception-safety, Queries should not have side-effects (roughly, they should not change state). This is why pop() doesn't return a value in the STL stack. pop() is the Command, and top() is the Query. If functions that return void and functions that return non-void should be used for fundamentally different purposes, when would it be a good idea to have function template parameterized to sometimes return void and sometimes return non-void? James McComb
May 23 2004
D allows lots of stuff that Bertrand Meyer does not like. If you want to follow his coding principles, you are free to do so, but obviously D was not designed to force people using a certain style, but to allow them to express themselves in the way they want to.I'd call it an idiom than you can use, but Eiffel does not force you into using it, its just good practice and so has nothing to do with Eiffel forcing you into anything. However Eiffel does seem to be designed to be very coherent and the libraries are not an exception. But make your own exceptions. Except for libraries where you'd probably not want two versions, one for side-effecting queries and one for side-effecting queries for terseness. ;) A D-like compromise would be to build the side-effecting query on top of the separated command and query.I like Bertrand Meyer's ideas, but I think that they are a bit idealistic and lead to extremely wordy programs in real life. Just consider a stack class that offeres a "pop" routine. According to Bertrand Meyer, "pop" would be illegal and you should split it up into "get_top" and "remove_top"...One more call, one less bug? ;)
May 23 2004
Bent Rasmussen wrote:I don't believe, splitting "pop" into two calls would prevent any bugs. It would be just as likely that you forget one "remove_top" somewhere in the code. Every experienced C/C++/D programmer knows that side-effects of functions have to be taken carefully. Looking back at a long time of programming, I don't think that bugs caused by unexpected side-effects ever were a major problem. Actually, looking at exapmles like the ++/-- operators, side-effects are planted so deep inside the philosophy of C/C++/D that you might have a hard time if you want to follow Bertram Meyer's concepts.I like Bertrand Meyer's ideas, but I think that they are a bit idealistic and lead to extremely wordy programs in real life. Just consider a stack class that offeres a "pop" routine. According to Bertrand Meyer, "pop" would be illegal and you should split it up into "get_top" and "remove_top"...One more call, one less bug? ;)
May 23 2004
Norbert Nemec wrote:I like Bertrand Meyer's ideas, but I think that they are a bit idealistic and lead to extremely wordy programs in real life.I agree with you. In case you think I worship Betrand Meyer, here's the same idea expressed by C++ guru Herb Sutter: <quote> Incidentally, have you ever grumbled at the way the standard library containers' pop functions (e.g., list::pop_back, stack::pop, etc.) don't return the popped value? Well, here's one reason to do this: It avoids weakening exception safety. </quote> James McComb
May 23 2004
James McComb wrote:Norbert Nemec wrote:Sorry, I have no idea what he means with "weakening exception safety". I realize now, that STL's "pop" really doesn't return a value. Guess, I have to reconsider my former statements. Anyhow, I really would like to understand the rationale behind it.I like Bertrand Meyer's ideas, but I think that they are a bit idealistic and lead to extremely wordy programs in real life.I agree with you. In case you think I worship Betrand Meyer, here's the same idea expressed by C++ guru Herb Sutter: <quote> Incidentally, have you ever grumbled at the way the standard library containers' pop functions (e.g., list::pop_back, stack::pop, etc.) don't return the popped value? Well, here's one reason to do this: It avoids weakening exception safety. </quote>
May 24 2004
If you pop and return the pop'd value in one notional operation, it is possible for the element to be removed from the container, but for an exception to throw in the copy constructor of the returned value - if of class type - which would result in the element being lost, both from the container and from client code. This is an artefact of C++'s return-by-value semantics, and is not an issue in D. (Unless one can do such things with structs, which is counter to my current understanding.) "Norbert Nemec" <Norbert.Nemec gmx.de> wrote in message news:c8s7dn$18u0$2 digitaldaemon.com...James McComb wrote:Norbert Nemec wrote:Sorry, I have no idea what he means with "weakening exception safety". I realize now, that STL's "pop" really doesn't return a value. Guess, I have to reconsider my former statements. Anyhow, I really would like to understand the rationale behind it.I like Bertrand Meyer's ideas, but I think that they are a bit idealistic and lead to extremely wordy programs in real life.I agree with you. In case you think I worship Betrand Meyer, here's the same idea expressed by C++ guru Herb Sutter: <quote> Incidentally, have you ever grumbled at the way the standard library containers' pop functions (e.g., list::pop_back, stack::pop, etc.) don't return the popped value? Well, here's one reason to do this: It avoids weakening exception safety. </quote>
May 24 2004
"Benedikt Meurer" <benedikt.meurer unix-ag.uni-siegen.de> wrote in message news:c8o52s$1j0l$1 digitaldaemon.com...Hello, Would it be possible to add support for void returns, as in void f1 () { ... } void f2 () { ...; return f1 (); }I have to say I am surprised that this isn't possible in D. In my opinion one of the most important things in any language is that it is consistent. So if it is possible to do: int f1 () { ... } int f2 () { ...; return f1 (); } then this should be allowed also void f1 () { ... } void f2 () { ...; return f1 (); } Function f2 is declared to return void(nothing) and the return type of f1 is also void, so it just makes prefect sence to redirect f1s void to f2s void.to D? This would be invaluably helpful in template programming. Else onehasto either make heavy use of mixins or write a lot of specialisations. (Looking at the code, it seems, that only dmd/statement.c has to bemodifiedto archive this goal). regards, Benedikt -- NetBSD Operating system: http://www.NetBSD.org/ pkgsrc "Work in progress": http://pkgsrc-wip.sf.net/ XFce desktop environment: http://www.xfce.org/ German Unix-AG Association: http://www.unix-ag.org/ os-network: http://www.os-network.de/ OpenPGP Key: http://www.home.unix-ag.org/bmeurer/#gpg
May 24 2004
In article <c8o52s$1j0l$1 digitaldaemon.com>, Benedikt Meurer says...
Hello,
Would it be possible to add support for void returns, as in
void f1 () { ... }
void f2 () { ...; return f1 (); }
to D? This would be invaluably helpful in template programming. Else one has
to either make heavy use of mixins or write a lot of specialisations.
(Looking at the code, it seems, that only dmd/statement.c has to be modified
to archive this goal).
This idea could be taken further. Instead of just for return types, imagine
something like this:
void[int] set_of_int;
Now, I have a set. The object is a map (assoc. array) but a map with no
key is a set. I would need some way to determine if an element is present of
course.
Another example:
template(Bar) {
struct Baz {
char[] name;
Foo value;
}
}
Now, Bar!(void).Baz yields:
struct Baz {
char[] name;
};
Baz x;
x.value = 5; // Do nothing statement.
5; // An equivalent statement.
A statement like "x.value = 4" would simply disappear.
I'm not saying this is a good idea; I'll let others speculate. Essentially all
statements using the "void" object would just disappear. This allows the
creation of optional fields. (But would it be useful? not sure.)
Kevin
May 25 2004
Kevin Bealer wrote:In article <c8o52s$1j0l$1 digitaldaemon.com>, Benedikt Meurer says...You probably want to say "A map with no *data*"Hello, Would it be possible to add support for void returns, as in void f1 () { ... } void f2 () { ...; return f1 (); } to D? This would be invaluably helpful in template programming. Else one has to either make heavy use of mixins or write a lot of specialisations. (Looking at the code, it seems, that only dmd/statement.c has to be modified to archive this goal).This idea could be taken further. Instead of just for return types, imagine something like this: void[int] set_of_int; Now, I have a set. The object is a map (assoc. array) but a map with no key is a set. I would need some way to determine if an element is present of course.
May 25 2004
Since the bool type suggestion went down so well, it's worth pointing out that the keyword "void" is also similarly overloaded to mean two completely different things - and this is also true in C, C++ and Java. "void" on its own means "nothing". A function which returns void, is a function which does not return a value at all. On the other hand, "void *" does NOT mean "pointer to nothing". It means "pointer to ANYTHING". And there is a big, big difference in meaning between "nothing" and "anything". Imagine if, instead of the single type void, we had two types: "void" and "unknown". Throughout the universe of D, all instances of "void *" would be changed to "unknown *". unknown.sizeof would be defined to be equal to 1, but "void.sizeof" would be defined to be equal to 0. Functions would be allowed to return void, but it would be illegal to return unknown (but perfectly ok to return a POINTER to unknown). A "variable" could be declared as being of type void (but not unknown). Such a void variable would occupy zero bytes of storage, but it would still be possible to take its address. An array like void[100000000] would be possible, and would still occupy zero bytes. (And yes, this would be useful - at least, in generic template programming). "unknown", on the other hand would be less flexible. Only "unknown *" would be allowed. Such a pointer may never be dereferenced, without first being cast into something else. Of course, I don't expect anyone either to take this seriously, or to implement this. But I just bring this to people's attention - (void *) does not mean "pointer to void", it means "pointer to something but we don't know what it is". And this can sometimes cause confusion. Arcane Jill
May 26 2004
I'm for it. In article <c91ipc$10lq$1 digitaldaemon.com>, Arcane Jill says...Since the bool type suggestion went down so well, it's worth pointing out that the keyword "void" is also similarly overloaded to mean two completely different things - and this is also true in C, C++ and Java. "void" on its own means "nothing". A function which returns void, is a function which does not return a value at all. On the other hand, "void *" does NOT mean "pointer to nothing". It means "pointer to ANYTHING". And there is a big, big difference in meaning between "nothing" and "anything". Imagine if, instead of the single type void, we had two types: "void" and "unknown". Throughout the universe of D, all instances of "void *" would be changed to "unknown *". unknown.sizeof would be defined to be equal to 1, but "void.sizeof" would be defined to be equal to 0. Functions would be allowed to return void, but it would be illegal to return unknown (but perfectly ok to return a POINTER to unknown). A "variable" could be declared as being of type void (but not unknown). Such a void variable would occupy zero bytes of storage, but it would still be possible to take its address. An array like void[100000000] would be possible, and would still occupy zero bytes. (And yes, this would be useful - at least, in generic template programming). "unknown", on the other hand would be less flexible. Only "unknown *" would be allowed. Such a pointer may never be dereferenced, without first being cast into something else. Of course, I don't expect anyone either to take this seriously, or to implement this. But I just bring this to people's attention - (void *) does not mean "pointer to void", it means "pointer to something but we don't know what it is". And this can sometimes cause confusion. Arcane Jill
May 26 2004
Intersting idea.. Q: why type "unknown *" when we could just type "unknown"? basically the type "unknown" could be defined as a pointer to anything, so assigning anything to an unknown automatically takes it's address. On Wed, 26 May 2004 07:59:40 +0000 (UTC), Arcane Jill <Arcane_member pathlink.com> wrote:Since the bool type suggestion went down so well, it's worth pointing out that the keyword "void" is also similarly overloaded to mean two completely different things - and this is also true in C, C++ and Java. "void" on its own means "nothing". A function which returns void, is a function which does not return a value at all. On the other hand, "void *" does NOT mean "pointer to nothing". It means "pointer to ANYTHING". And there is a big, big difference in meaning between "nothing" and "anything". Imagine if, instead of the single type void, we had two types: "void" and "unknown". Throughout the universe of D, all instances of "void *" would be changed to "unknown *". unknown.sizeof would be defined to be equal to 1, but "void.sizeof" would be defined to be equal to 0. Functions would be allowed to return void, but it would be illegal to return unknown (but perfectly ok to return a POINTER to unknown). A "variable" could be declared as being of type void (but not unknown). Such a void variable would occupy zero bytes of storage, but it would still be possible to take its address. An array like void[100000000] would be possible, and would still occupy zero bytes. (And yes, this would be useful - at least, in generic template programming). "unknown", on the other hand would be less flexible. Only "unknown *" would be allowed. Such a pointer may never be dereferenced, without first being cast into something else. Of course, I don't expect anyone either to take this seriously, or to implement this. But I just bring this to people's attention - (void *) does not mean "pointer to void", it means "pointer to something but we don't know what it is". And this can sometimes cause confusion. Arcane Jill-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
May 26 2004
On Wed, 26 May 2004 07:59:40 +0000 (UTC), Arcane Jill wrote:Since the bool type suggestion went down so well, it's worth pointing out that the keyword "void" is also similarly overloaded to mean two completely different things - and this is also true in C, C++ and Java. "void" on its own means "nothing". A function which returns void, is a function which does not return a value at all. On the other hand, "void *" does NOT mean "pointer to nothing". It means "pointer to ANYTHING". And there is a big, big difference in meaning between "nothing" and "anything". Imagine if, instead of the single type void, we had two types: "void" and "unknown". Throughout the universe of D, all instances of "void *" would be changed to "unknown *". unknown.sizeof would be defined to be equal to 1, but "void.sizeof" would be defined to be equal to 0. Functions would be allowed to return void, but it would be illegal to return unknown (but perfectly ok to return a POINTER to unknown). A "variable" could be declared as being of type void (but not unknown). Such a void variable would occupy zero bytes of storage, but it would still be possible to take its address. An array like void[100000000] would be possible, and would still occupy zero bytes. (And yes, this would be useful - at least, in generic template programming). "unknown", on the other hand would be less flexible. Only "unknown *" would be allowed. Such a pointer may never be dereferenced, without first being cast into something else. Of course, I don't expect anyone either to take this seriously, or to implement this. But I just bring this to people's attention - (void *) does not mean "pointer to void", it means "pointer to something but we don't know what it is". And this can sometimes cause confusion. Arcane JillHmmmmm...don't know....sounds a bit too logical... Oh well, let's throw caution to the wind. I think this is a Good Idea (tm). Let's see now... unknown *X; int A; int B; X = &A; // Now X points to A B = cast(int)*X; // Assign B to whatever X points to ('A' in this case) -- Derek 27/May/04 10:00:26 AM
May 26 2004
In article <c91ipc$10lq$1 digitaldaemon.com>, Arcane Jill wrote:On the other hand, "void *" does NOT mean "pointer to nothing". It means "pointer to ANYTHING". And there is a big, big difference in meaning between "nothing" and "anything". Imagine if, instead of the single type void, we had two types: "void" and "unknown". Throughout the universe of D, all instances of "void *" would be changed to "unknown *". unknown.sizeof would be defined to be equal to 1, but "void.sizeof" would be defined to be equal to 0. Functions would be allowed to return void, but it would be illegal to return unknown (but perfectly ok to return a POINTER to unknown). A "variable" could be declared as being of typeWhy not use just byte* instead of unknown*? Because in the end every pointer *is* a pointer to a byte, and that's about as little semantics as you can give to a pointer to anything. I know - safety issues I guess, to prevent accidental use of those pointers? (I like the idea of void as something of size 0) -Antti -- I will not be using Plan 9 in the creation of weapons of mass destruction to be used by nations other than the US.
May 27 2004