 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/05/2011 1:19, Darren New wrote:
> On 5/11/2011 13:27, Warp wrote:
>> C# isn't C++...
>
> I know that. I'm just saying that I was surprised it worked in C++
> because everything I've ever read except the standard implies it
> shouldn't. Every tutorial etc etc etc says "You can't put a value after
> a return in a void function, and you have to put a value after a return
> in a non-void function." So it surprised me this was actually not true
> for C++. So I figured I'd try specifically for C#, because maybe all the
> tutorials for *that* were wrong. :-)
except that your "value" is actually a non-value by itself:
the function "bar" doesn't return anything, so if "foo" returns the
return-value of "bar", it also doesn't return anything.
I suppose it wouldn't work if "bar" really had a return-value.
cu!
--
ZK
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/13/2011 12:44 AM, Zeger Knaepen wrote:
> On 12/05/2011 1:19, Darren New wrote:
>> On 5/11/2011 13:27, Warp wrote:
>>> C# isn't C++...
>>
>> I know that. I'm just saying that I was surprised it worked in C++
>> because everything I've ever read except the standard implies it
>> shouldn't. Every tutorial etc etc etc says "You can't put a value after
>> a return in a void function, and you have to put a value after a return
>> in a non-void function." So it surprised me this was actually not true
>> for C++. So I figured I'd try specifically for C#, because maybe all the
>> tutorials for *that* were wrong. :-)
>
> except that your "value" is actually a non-value by itself:
>
> the function "bar" doesn't return anything, so if "foo" returns the
> return-value of "bar", it also doesn't return anything.
>
> I suppose it wouldn't work if "bar" really had a return-value.
>
> cu!
Hmm. Interesting point. Its possible that over the long time C++
compilers have been around a test was added to it, which simply tossed
the return functions, in cases where the result would never produce
output. Mind, a warning would have made more sense on those, at least.
Possible you might have an overloaded function, possibly, that would be
void in some cases, or return a value in others, thus it would be
perfectly reasonable to both get nothing from such a function, as well
as return something, in the case of bar(). Bar itself doesn't attempt to
return a value. The other one should, I would think, at least throw a
warning that you are trying to return a result in a function that
doesn't support it. Whether it should be an error, instead of a warning
though...
But, very odd.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 13/05/2011 10:25, Patrick Elliott a écrit :
> Possible you might have an overloaded function, possibly, that would be
> void in some cases, or return a value in others,
It would be possible in C where prototypes are not mandatory (but
overloading in C is not part of the language).
But I would expect a C++ compiler in C++ mode to barf on a change of
prototype will overloading or a return not matching the declaration.
The return function is not really a function: it put the value inside
the stack and then pop from the current function.
--
A good Manager will take you
through the forest, no mater what.
A Leader will take time to climb on a
Tree and say 'This is the wrong forest'.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 13.05.2011 09:44, schrieb Zeger Knaepen:
> I suppose it wouldn't work if "bar" really had a return-value.
Indeed, but you could still cast it to void:
return (void)bar(...);
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 11.05.2011 22:17, schrieb Darren New:
> On 5/11/2011 12:57, Warp wrote:
>> compiles and runs just fine.
>
> Huh. I wonder if that's just a GCC thing or whether that's actually in
> the standard. I just *actually* tried it with C# and I get "since XYZ
> returns void, the return statement may not be followed by an expression."
The C language standard is pretty clear about this; quoting from
ISO/IEC 9899:TC2:
"6.8.6.4 The return statement
Constraints
1 A return statement with an expression shall not appear in a function
whose return type is void. [...]"
The C++ standard, however, explicitly allows for such a construction;
quoting from some 2005 working draft:
"6.6.3 The return statement [stmt.return]
[...]
3 A return statement with an expression of type “cv void” can be used
only in functions with a return type of cv void; [...]."
("cv" being shorthand for "an arbitrary set of cv-qualifiers, i.e., one
of {const }, {volatile }, {const, volatile}, or the empty set")
Not of Java though; quoting from "The Java(TM) Language Specification,
Third Edition":
"8.4.7 Method Body
[...]
If a method is declared void, then its body must not contain any return
statement (§14.17) that has an Expression."
So it appears that C++ is about the only member of the C-style language
family allowing for such a construct per specification.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Huh. I wonder if that's just a GCC thing or whether that's actually in
>> the standard. I just *actually* tried it with C# and I get "since XYZ
>> returns void, the return statement may not be followed by an expression."
>
>
> The C language standard is pretty clear about this; quoting from ISO/IEC
> 9899:TC2:
>
> "6.8.6.4 The return statement
> Constraints
> 1 A return statement with an expression shall not appear in a function
> whose return type is void. [...]"
>
>
> The C++ standard, however, explicitly allows for such a construction;
> quoting from some 2005 working draft:
>
> "6.6.3 The return statement [stmt.return]
> [...]
> 3 A return statement with an expression of type “cv void” can be used
> only in functions with a return type of cv void; [...]."
>
> ("cv" being shorthand for "an arbitrary set of cv-qualifiers, i.e., one
> of {const }, {volatile }, {const, volatile}, or the empty set")
>
>
> Not of Java though; quoting from "The Java(TM) Language Specification,
> Third Edition":
>
> "8.4.7 Method Body
> [...]
> If a method is declared void, then its body must not contain any return
> statement (§14.17) that has an Expression."
>
>
> So it appears that C++ is about the only member of the C-style language
> family allowing for such a construct per specification.
Now that's what a call thorough research! O_O
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/13/2011 0:44, Zeger Knaepen wrote:
> the function "bar" doesn't return anything, so if "foo" returns the
> return-value of "bar", it also doesn't return anything.
And that's exactly why I started this thread. The syntax makes that
distinction, whereas I thought it shouldn't. Turns out that C++ at least
really doesn't make that decision.
Altho given that a simple "return;" from a function declared as returning an
int in C doesn't even raise a warning in gcc, I suspect it's at least as
much the traditional sloppiness of C in terms of parameter passing as it is
something intentionally designed into the spec. ("return 28;" from a void
function gives a warning but not an error.)
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/13/2011 7:46, clipka wrote:
> So it appears that C++ is about the only member of the C-style language
> family allowing for such a construct per specification.
Thanks for looking all that up! (I'll look up the C# if anyone cares. :-)
I suspect that was put in when templates and overloading and stuff made it
make sense.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> I suspect that was put in when templates and overloading and stuff made it
> make sense.
I get the feeling that, indeed, templates "demanded" a lot of relaxing of
the rules, which could have been much stricter (especially compared to C),
so that templated code would not break as easily if you changed between
types.
For example, in C the only way to make an explicit cast is using the
syntax "(type) variable". However, C++ added the possibility of writing
such casts as "type(variable)". This allows for 'type' to not only be a
basic type, but also a class (in which case it would be a constructor
call).
Moreover (something that many C++ programmers don't realize), C++ allows
the syntax "(type) variable" even for class types (in which case it's
*still* a constructor call). Basically "(type) variable" and "type(variable)"
are more or less identical expressions in C++. About the only practical
situation where this may come handy is in templated code.
Overloading operators is useful in non-templated code as well, although
it becomes more or less syntactic sugar there. It's most useful in templated
code because it, once again, allows for the same code to handle basic types
and classes. It is, for example, what allows STL containers to handle both
types of elements. (For example std::set and std::map require for the
elements to be assignable, and comparable using the comparison operator <.
Since you can overload operator < for classes, this means that you can use
both internal types, such as ints, and classes, such as std::string, with
the same std::set or std::map.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/14/2011 0:40, Warp wrote:
> For example, in C the only way to make an explicit cast is using the
> syntax "(type) variable". However, C++ added the possibility of writing
> such casts as "type(variable)". This allows for 'type' to not only be a
> basic type, but also a class (in which case it would be a constructor
> call).
That's cool. I'm still not sure whether to like C++ or hate it. ;-)
So what's the static_cast<...> bit all about, then? Is that just something
easy to grep for, or does it have different semantics than a regular cast?
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
