Default param, is this legal

[Simon]

Hi,

When defining a default value I was wondering if I could do the following...

// ---------------------------------------------------------------
....
const MyClass& GetMyClass( const MyClass& default = MyClass() );
....
// ---------------------------------------------------------------

On VS2008 the code compiles and works but I was wondering if this was
actually legal, (and not 'undefined' behaviour).

if it is legal, (as I think it is), can you think of anything wrong with
actually using that code?

Thanks

Simon

 

[Alf P. Steinbach /Usenet]

* Simon, on 14.07.2010 13:08, apparently about HOMEWORK:

When defining a default value I was wondering if I could do the
following...

// ---------------------------------------------------------------
...
const MyClass& GetMyClass( const MyClass& default = MyClass() );
...
// ---------------------------------------------------------------

On VS2008 the code compiles and works but I was wondering if this was
actually legal, (and not 'undefined' behaviour).

It's technically good standard C++.

if it is legal, (as I think it is), can you think of anything wrong with
actually using that code?

Depends on the implementation of GetMyClass.

This does sound like a homework question, so I'll leave it at that.


Cheers & hth.,

- Alf

 

[Alf P. Steinbach /Usenet]

* Alf P. Steinbach /Usenet, on 14.07.2010 13:15:

* Simon, on 14.07.2010 13:08, apparently about HOMEWORK:

It's technically good standard C++.

Oh, too fast there, it should not compile at all,

Since you said it compiled I didn't look closely.

You suppplied incorrect information and got an incorrect answer...

 

[Simon]

When defining a default value I was wondering if I could do the

It's technically good standard C++.



Depends on the implementation of GetMyClass.

To summarize, the class maintains a map, the function GetMyClass( ... )
takes an index, if the value is not in the map then the default value is
added to the map and that value is added.

In most cases the default value is given, but in some it is not needed.

This does sound like a homework question, so I'll leave it at that.

It is not, but thanks anyway.

Simon

 

[Simon]

* Alf P. Steinbach /Usenet, on 14.07.2010 13:15:

LOL, you have a problem with this.

Oh, too fast there, it should not compile at all,

Since you said it compiled I didn't look closely.

You suppplied incorrect information and got an incorrect answer...

What do you mean it does not compile?
It does on my compiler.

Why did you reply 'technically good standard c++' then if you don't
really know.

Regards.

Simon

 

[Francesco S. Carta]

LOL, you have a problem with this.


What do you mean it does not compile?
It does on my compiler.

Unlikely: try to compile the line you posted above _exactly as it is_
and you'll find the error. After fixing that, the code should be fine,
as Alf said - at least for the question at hand.

If you need further help post the exact code you're feeding to your
compiler, not the code you typed in the newsreader.

 

[Simon]

Unlikely: try to compile the line you posted above _exactly as it is_
and you'll find the error. After fixing that, the code should be fine,
as Alf said - at least for the question at hand.

I don't what else to say, it compiles fine on my side.
the same code, (with the class definition of course).

If you need further help post the exact code you're feeding to your
compiler, not the code you typed in the newsreader.

This has nothing to do with my post, but anyway...

// ---------------------------------------------------------------------
class MyClass
{
public:
MyClass(){}
~MyClass(){}
};

const MyClass& GetMyClass( const MyClass& default = MyClass() )
{
throw -1;
}

// in main
....

const MyClass& myclass = GetMyClass();

....

// ---------------------------------------------------------------------

there you go, if that does not compile on VS2008 on your side then I
don't know, maybe MS likes me or something and is doing me favours.

Simon

 

[Francesco S. Carta]

I don't what else to say, it compiles fine on my side.
the same code, (with the class definition of course).


This has nothing to do with my post, but anyway...

// ---------------------------------------------------------------------
class MyClass
{
public:
MyClass(){}
~MyClass(){}
};

const MyClass& GetMyClass( const MyClass& default = MyClass() )
{
throw -1;
}

// in main
...

const MyClass& myclass = GetMyClass();

...

// ---------------------------------------------------------------------

there you go, if that does not compile on VS2008 on your side then I
don't know, maybe MS likes me or something and is doing me favours.

You're using a keyword as an identifier, hence that code cannot be
compiled, I don't need to try it in order to know it.

Now tell me that you actually copied and pasted it from the code you
compiled - I don't want to appear harsh, but "post the exact code you're
feeding to the compiler" has not two meanings.

 

[Simon]

You're using a keyword as an identifier, hence that code cannot be
compiled, I don't need to try it in order to know it.

I know very well what you mean.

But I also know my compiler a little better than you obviously, so it
compiles just fine, (no warning level 3).

Now tell me that you actually copied and pasted it from the code you
compiled - I don't want to appear harsh, but "post the exact code you're
feeding to the compiler" has not two meanings.

What do you think I did?

Don't you think by know you should get off your mighty horse, put it in
the complier and admit that maybe, just maybe, you are wrong.

Simon

 

[Francesco S. Carta]

I know very well what you mean.

But I also know my compiler a little better than you obviously, so it
compiles just fine, (no warning level 3).


What do you think I did?

Don't you think by know you should get off your mighty horse, put it in
the complier and admit that maybe, just maybe, you are wrong.

I can confirm that I actually was wrong, please accept my apologies.

You may understand that it was hard to believe that VS pushed itself
that far as to accepting keywords as identifiers.

For the sake of good communication consider that not anybody is aware of
the "extensions" of any compiler: that code is not conforming standard
C++ code and as such is not portable.

By the way, MS itself reports that you shouldn't use keywords as
identifiers, and makes no distinction for the one you used:

http://msdn.microsoft.com/en-us/library/2e6a4at9(VS.80).aspx

I believe it is allowed for legacy with some buggy old version of VS.

 

[Vladimir Jovic]

This has nothing to do with my post, but anyway...

Yes, it does. Take a look here:
http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.8

// ---------------------------------------------------------------------
class MyClass
{
public:
MyClass(){}
~MyClass(){}
};

const MyClass& GetMyClass( const MyClass& default = MyClass() )
{
throw -1;
}

// in main
...

const MyClass& myclass = GetMyClass();

...

// ---------------------------------------------------------------------

there you go, if that does not compile on VS2008 on your side then I
don't know, maybe MS likes me or something and is doing me favours.

Sorry, but that doesn't compile. Missing main()

However, this:
////////////////////////
class MyClass
{
public:
MyClass(){}
~MyClass(){}
};
const MyClass& GetMyClass( const MyClass& default = MyClass() )
{
throw -1;
}
int main()
{
const MyClass& myclass = GetMyClass();
(void)myclass;
}
////////////////////////
produces next errors when compiled with g++ 4.3 :
gk.cpp:7: error: expected ‘,’ or ‘...’ before ‘default’
gk.cpp: In function ‘int main()’:
gk.cpp:7: error: too few arguments to function ‘const MyClass&
GetMyClass(const MyClass&)’
gk.cpp:13: error: at this point in file

and that is with the least warnings and errors level.

 

[Stuart Redmann]

What do you think I did?

Don't you think by know you should get off your mighty horse, put it in
the complier and admit that maybe, just maybe, you are wrong.

Out of curiosity I compiled the code from Simon with VC2008, and it
compiles the misplaced keyword "default" just fine. That's obviously a
bug.

@Francesco:
@Alf: Both of you should re-read the Hitchhiker's Guide to the
Galaxy, especially the part about Wonko the Sane.

@Simon: You were right. However, since this is a newsgroup, and you
are trying to get some advice from others, you should never, ever get
mad at somebody who is spending time/effort to answer you. Not even if
they do. Else you may quickly end up on other people's ignore list.
Just my 2cents.

Regards,
Stuart

 

[Alf P. Steinbach /Usenet]

* Stuart Redmann, on 14.07.2010 14:26:

Out of curiosity I compiled the code from Simon with VC2008, and it
compiles the misplaced keyword "default" just fine. That's obviously a
bug.

@Francesco:
@Alf: Both of you should re-read the Hitchhiker's Guide to the
Galaxy, especially the part about Wonko the Sane.

@Simon: You were right. However, since this is a newsgroup, and you
are trying to get some advice from others, you should never, ever get
mad at somebody who is spending time/effort to answer you. Not even if
they do. Else you may quickly end up on other people's ignore list.
Just my 2cents.

This is embarassing -- for Microsoft.


<example>
C:\test> type x.cpp
class MyClass
{
public:
MyClass(){}
~MyClass(){}
};

const MyClass& GetMyClass( const MyClass& default = MyClass() )
{
throw -1;
}

int main()
{
}

C:\test> cl x.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.6030 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.

x.cpp
x.cpp(8) : error C2143: syntax error : missing ')' before 'default'
x.cpp(8) : error C2143: syntax error : missing ';' before 'default'
x.cpp(8) : error C2059: syntax error : ')'
x.cpp(9) : error C2143: syntax error : missing ';' before '{'
x.cpp(9) : error C2447: '{' : missing function header (old-style formal list?)

C:\test> "c:\program files\Microsoft Visual Studio 9.0\Common7\Tools\vsvars32.bat"
Setting environment for using Microsoft Visual Studio 2008 x86 tools.

C:\test> cl x.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

x.cpp
Microsoft (R) Incremental Linker Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.

/out:x.exe
x.obj

C:\test> cl /W4 x.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

x.cpp
x.cpp(8) : warning C4100: 'default' : unreferenced formal parameter
Microsoft (R) Incremental Linker Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.

/out:x.exe
x.obj

C:\test> _
</example>



Uh oh.

Cheers,

- Alf

 

[Francesco S. Carta]

Out of curiosity I compiled the code from Simon with VC2008, and it
compiles the misplaced keyword "default" just fine. That's obviously a
bug.

I tried it with VC2010, and it compiled just fine too. Maybe they didn't
notice it? I believe it's a known, old bug "kept in" for legacy - I
might well be wrong, though.

@Francesco:
@Alf: Both of you should re-read the Hitchhiker's Guide to the
Galaxy, especially the part about Wonko the Sane.

Nice advice, although, seriously, I would be better spending my time on
the English Grammar and on the C++ Standard instead of on H2G2 - the
formers are giving me way much more problems than the latter.

 

[Simon]

Yes, it does. Take a look here:
http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.8

Surely, it's debatable, part of my question was "On VS2008 the code
compiles and works but I was wondering if this was actually legal..."

The answer is, no it is not legal, but for a reason other than the one I
asked.

Sorry, but that doesn't compile. Missing main()

Yes, you are 100% right, it does indeed make a world of difference, I
now hang my head in shame, I could I ever hope to have my question
answered, I am such a fool indeed.

I am really sorry that this group is so agressive that it could not
answer my original post.

A discussion around my original question, (that I am fairly certain
everyone understood even though I shamefully only included pseudo-
code), would have been better spent in my opinion.

////////////////////////
produces next errors when compiled with g++ 4.3 :

The clue was in my original post.

Simon

 

[Francesco S. Carta]

I am really sorry that this group is so agressive that it could not
answer my original post.

Your question has already been answered, I'm sorry that you're taking it
that bad: this group isn't that aggressive as you feel, please read
again all the posts (including your replies) and draw your conclusions.

 

[Simon]

@Simon: You were right. However, since this is a newsgroup, and you
are trying to get some advice from others, you should never, ever get
mad at somebody who is spending time/effort to answer you. Not even if
they do. Else you may quickly end up on other people's ignore list.
Just my 2cents.

I am not mad, just surprised, I am fairly certain that my question was
understood by everybody.

Even if the code did not compile, it is fairly obvious what my question
was, and that is what I would have rather have others concentrate on.

Even Alf replied without compiling the code, (as there was no need to do
really).

Instead of discussing the standard, best practice and so forth others
felt that time would be better spent nitpicking what was clearly
pseudo-code.

Simon

 

[Simon]

Your question has already been answered, I'm sorry that you're taking it
that bad: this group isn't that aggressive as you feel, please read
again all the posts (including your replies) and draw your conclusions.

I am not taking it 'this bad', (I am not sure what you mean by that
anyway, it is a very subjective statement).

Alf answered my question, (kind of), then asked me for details, (that I
gave), before concentrating on the pseudo-code I gave.

His reaction made me seriously doubt, (and still does to an extent), his
ability to answer the question at all.

Simon

 

[Francesco S. Carta]

I am not taking it 'this bad', (I am not sure what you mean by that
anyway, it is a very subjective statement).

OK, let's drop all sparkles, so that this discussion can come back to a
normal tone instead of pushing it towards a real flamewar.

Some of us (myself included) overreacted to the fact that you posted
non-compliant code - apparently, you discovered it during this thread -
on the other side, I believe you overreacted to our replies.

So far, I'm the only one who apologized for his mistakes, but that
doesn't really make any difference.

About the question in your original post, I cannot speak for the
standard, but I can make a test:

//-------
#include <iostream>

struct Test {
Test() {
std::cout << "create" << std::endl;
}
~Test() {
std::cout << "destroy" << std::endl;
}
static const Test& GetTest(const Test& t = Test()) {
return t;
}
};

int main() {
{
const Test& t = Test::GetTest();
std::cout << "about to exit scope" << std::endl;
}
{
const Test& t = Test::GetTest();
std::cout << "about to exit scope" << std::endl;
}
}
//-------

The above produces the following output on my computer:

//-------
create
destroy
about to exit scope
create
destroy
about to exit scope
//-------

According to what I see above, the object gets destroyed right after the
end of the call to that static function, so I think you're NOT safe
using that reference afterwards.

I repeat, that's just an empirical test, I have no idea about what the
standard mandates about it, although I feel it's UB at least.

 

[Simon]

OK, let's drop all sparkles, so that this discussion can come back to a
normal tone instead of pushing it towards a real flamewar.

Yes, that would be much better indeed.

Some of us (myself included) overreacted to the fact that you posted
non-compliant code - apparently, you discovered it during this thread -
on the other side, I believe you overreacted to our replies.

I discovered?, where does it say that?
But I fear it is to late and it is best to leave the thread now. I'll
try and present my question to a friendlier forum.

So far, I'm the only one who apologized for his mistakes, but that
doesn't really make any difference.

It does make a difference, thanks for that.

About the question in your original post, I cannot speak for the
standard, but I can make a test:

I was more wondering about using the legality of using ... (const Test&
t = Test()) in the first place.

It does make sense that I cannot use the value, for the same reason that
I cannot use

const Test& GetTest(const Test t = Test() )
{
return t;
}

't' would fall out of scope in either cases.
This is why my, (eventual), example code used throw -1 rather as I am
not using the value given as a return value.

Simon