 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I find it mildly distracting that I can't do this:
void xyz() { ... }
void abc()
{
if (...)
return xyz();
else blah blah blah;
}
I can do it if xyz and abc return values, but not if they don't. I have to
instead
if (...)
{
xyz();
return;
}
which significantly expands a function that has lots of such dispatches. It
also makes it unclear to the casual reader that this is a tail call.
Also, I realized I tend to have larger functions than necessary because most
languages I'm using don't let me nest functions. For example, I have an
output list, two error bars, and a point. I want to add the point (or a few)
to the list if it's within the two error bars. I do this several times.
In Pascal or Ada or something, I could do something ilke
MaybeAddPoint(x, y);
as the call, and MaybeAddPoint being nested would let it access the other
locals. But in C or C# or Java, I have to do
MaybeAddPoint(x, y, errlo, errhi, output);
where errlo, errhi, and output are the same value for every call of the
function. Hence, when it's only two or three calls, with lots of those
kinds of constant-for-all-calls arguments, I find I sometimes wind up
inlining the stuff, because that's just as clear as passing half a dozen
"parameters" that aren't really parameters at all, but rather the
environment they're working in.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 02/05/2011 18:26, Darren New wrote:
> I find it mildly distracting that I can't do this:
>
> void xyz() { ... }
>
> void abc()
> {
> if (...)
> return xyz();
> else blah blah blah;
> }
>
> I can do it if xyz and abc return values, but not if they don't. I have
> to instead
> if (...)
> {
> xyz();
> return;
> }
>
> which significantly expands a function that has lots of such dispatches.
> It also makes it unclear to the casual reader that this is a tail call.
How about just
if (...)
{xyz(); return;}
else...
That's slightly less load.
Of course, The Real WTF is "functions" that return void. ;-)
> Also, I realized I tend to have larger functions than necessary because
> most languages I'm using don't let me nest functions.
No comment. ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/3/2011 1:43, Invisible wrote:
> That's slightly less load.
Still ugly, and non-standard formatting. :-)
> Of course, The Real WTF is "functions" that return void. ;-)
Like functions that return unit are better?
>> Also, I realized I tend to have larger functions than necessary because
>> most languages I'm using don't let me nest functions.
>
> No comment. ;-)
I realize that this is the primary semantic difference between "Algol-like
languages" and "C-like languages", with the use of punctuation instead of
keywords being the syntactic primary difference.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 03/05/2011 16:40, Darren New wrote:
> On 5/3/2011 1:43, Invisible wrote:
>> That's slightly less load.
>
> Still ugly, and non-standard formatting. :-)
Yeah. It's about the best you can do though.
>> Of course, The Real WTF is "functions" that return void. ;-)
>
> Like functions that return unit are better?
How many of those can you name?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> I find it mildly distracting that I can't do this:
> void xyz() { ... }
> void abc()
> {
> if (...)
> return xyz();
> else blah blah blah;
> }
What's wrong with:
void abc()
{
if (...)
xyz();
else blah blah blah;
}
(Structured programming purists would recommend doing it like that
because there's no early return.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/3/2011 8:43, Invisible wrote:
>>> Of course, The Real WTF is "functions" that return void. ;-)
>>
>> Like functions that return unit are better?
>
> How many of those can you name?
Not many, but then I work in languages where functions can return void. ;-)
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/3/2011 8:50, Warp wrote:
> What's wrong with:
The "else" doesn't end the function, and I tend to have several of these in
a row, and sometimes it's inside a loop, etc.
> (Structured programming purists would recommend doing it like that
> because there's no early return.)
I could restructure things, sure, but then it's even more verbose and unlike
my initial thought processes. Structured programming wouldn't let me return
a value from the middle of the function either. It's the asymmetry between
a return after a void call and a return after a value-producing call that is
ugly.
(I had to giggle yesterday when I added an "else break" as the last
statement of a do-while loop, too.)
--
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] sanrrcom> wrote:
> On 5/3/2011 8:43, Invisible wrote:
> >>> Of course, The Real WTF is "functions" that return void. ;-)
> >>
> >> Like functions that return unit are better?
> >
> > How many of those can you name?
> Not many, but then I work in languages where functions can return void. ;-)
Well, if we go to the strict definition of "function", that's not the
only problem. For one, strict functions must always return the same value
for the same parameters and must not have side-effects. (Hence eg. rand()
is not a true function.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/3/2011 11:36, Warp wrote:
> Darren New<dne### [at] sanrrcom> wrote:
>> On 5/3/2011 8:43, Invisible wrote:
>>>>> Of course, The Real WTF is "functions" that return void. ;-)
>>>>
>>>> Like functions that return unit are better?
>>>
>>> How many of those can you name?
>
>> Not many, but then I work in languages where functions can return void. ;-)
>
> Well, if we go to the strict definition of "function",
That too. And I would wonder how realistic it is to have a strict function
returning a "value" that the type system prevents you from ever seeing.
(I.e., the stuff you use to order calculations in a pure language like Haskell.)
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 03/05/2011 08:02 PM, Darren New wrote:
> That too. And I would wonder how realistic it is to have a strict
> function returning a "value" that the type system prevents you from ever
> seeing. (I.e., the stuff you use to order calculations in a pure
> language like Haskell.)
I'm not sure what you're talking about.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/3/2011 12:52, Orchid XP v8 wrote:
> I'm not sure what you're talking about.
Like the IO part of the IO monad.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 03/05/2011 09:20 PM, Darren New wrote:
> On 5/3/2011 12:52, Orchid XP v8 wrote:
>> I'm not sure what you're talking about.
>
> Like the IO part of the IO monad.
The type system doesn't prevent you "seeing" an IO value. You can pick
them up and move them around just like any other value. It's just that
you can't do a lot else with them. That's just how the API works;
nothing to do with the type system.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/3/2011 13:41, Orchid XP v8 wrote:
> That's just how the API works; nothing to do with the type system.
That's what I'm talking about.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In C++ it is supported at lead for function templates:
template<class T>
T foo(int x)
{
if(x>10) {
// ... do something interesting
return foo<T>(x-1);
} else {
// ... do something else and finally
return foo<T>(x*3);
}
}
int main()
{
foo<double>(23);
foo<void>(42);
}
Lars R.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/11/2011 12:01, Lars R. wrote:
> In C++ it is supported at lead for function templates:
Interesting!
--
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] sanrrcom> wrote:
> I find it mildly distracting that I can't do this:
> void xyz() { ... }
> void abc()
> {
> if (...)
> return xyz();
> else blah blah blah;
> }
I assumed this to be so in C++ without actually checking. However, now
that I checked it, it seems to work. For example:
//----------------------------------------
#include <iostream>
void bar() { std::cout << "bar()\n"; }
void foo(int i)
{
if(i < 0) return bar();
std::cout << "foo()\n";
}
int main()
{
foo(1);
foo(-1);
}
//----------------------------------------
compiles and runs just fine.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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."
--
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] sanrrcom> wrote:
> 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."
C# isn't C++...
--
- Warp
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."
>
> C# isn't C++...
Presumably that's the whole point of C++. ;-)
Oh, wait...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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. :-)
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] sanrrcom> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> 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?
The C-style cast will cast from anything to anything else. Hence it's
not the safest thing in the world, as it's relatively easy to miscast and
have your program misbehave.
static_cast will only work between compatible types. For example you can
cast an int to a char, a signed int to an unsigned int, classes to other
classes within their inheritance hierarchy, and so on. However, if you try
to static_cast between incompatible types, you will get a compiler error.
For example, you can't cast an int to a pointer, a const pointer to a
non-const one (even if the pointers are of the same type) or between classes
not in direct inheritance relationship.
It is thus recommended to use static_cast instead of C style casts
whenever possible. Incidentally (but not surprisingly), if you use
static_cast to cast some variable to a class type, and that class has
a constructor that takes a value of that type, it will work. (It will
be the same as constructing the object with the regular syntax.) Supporting
the C style of casting exists more or less just for compatibility with C
code (which of course means that many C++ programmers are using it instead
of static_cast because it's shorter and more "convenient").
To cast constness away between compatible types const_cast should be
used. (It's basically its only role.)
To cast between incompatible types reinterpret_cast should be used.
(It assumes you know what you are doing.)
reinterpret_cast should *not* be used to cast between pointers to objects
in the same inheritance hierarchy because it may forgo adjusting the pointer
offset which may be necessary in some situations.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 14.05.2011 18:34, schrieb Darren New:
> 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?
"5.2.9 Static cast [expr.static.cast]
1 The result of the expression static_cast<T>(v) is the result of
converting the expression v to type T. If T is a
reference type, the result is an lvalue; otherwise, the result is an
rvalue. Types shall not be defined in a static_cast.
THE STATIC_CAST OPERATOR SHALL NOT CAST AWAY CONSTNESS (5.2.11)."
(emphasis added)
I.e. the static_cast of a const pointer remains a const pointer. It is
therefore a good idea to always use static_cast instead of a classic
cast, as it prevents accidental "stripping" of the const property;
consider, for instance, the following code:
void foo(int* x);
void bar(void* x) {
...
foo((int*)x);
...
}
Now assume the code is refactored to use const qualifiers, but for some
reason the cast in the call to foo() goes unnoticed:
void foo(const int* x);
void bar(const void* x) {
...
foo((int*)x);
...
}
Now assume a functionality change requires foo() to modify its parameter:
void foo(int* x);
void bar(const void* x) {
...
foo((int*)x);
...
}
The code still compiles, so it goes unnoticed that the function
signature of bar() is now actually wrong.
If the original code author had used static_cast instead, the mistake
would have been detected by the compiler, as the following code raises
an error due to mismatching const qualifiers:
void foo(int* x);
void bar(const void* x) {
...
foo(static_cast<int*>x);
...
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/15/2011 1:00, Warp wrote:
> static_cast will only work between compatible types.
Ah, cool. Again, thanks for the info!
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
