Default param, is this legal

[Alf P. Steinbach /Usenet]

* Francesco S. Carta, on 14.07.2010 15:36:

[snip]

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

Simon has not asked the question you apparently think he asked, and if that
(natural but not given interpretation) was the question then it's homework.

I just note that the original posting omitted all details necessary and included
very unlikely misdirection, and that when he elaborated on what his question was
that elaboration did not include your interpretation but only irrelevant
details, i.e. more vagueness.

I.e., don't feed the troll.


Cheers,

- Alf

 

[Francesco S. Carta]

Yes, that would be much better indeed.


I discovered?, where does it say that?

That was just my impression, because it's common practice to post
standard compliant code in this group unless either:

- ignoring that it is not compliant;
- clearly marking it as platform/implementation specific;

You omitted to tell the second and I supposed for the first.

> 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.

I hope that nobody is voluntarily and consciously acting in an
"unfriendly" manner.

If you can cope with accepting that we all are fallible, and hence
accept all the misunderstandings / mistakes that happened in this
thread, it's not too late to continue.

But if you feel you need to leave, that's your prerogative - I only
can't see any true reason for that.

It does make a difference, thanks for that.


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.

If you're not using that reference after the end of that function you
are on firm ground, you can safely create that temporary as a default
parameter, you are allowed to.

 

[Jonathan Lee]

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.

Mehhh... [class.temporary] says the temp should exist until the end of
the full expression. So you might be able to do something like

MyClass b = GetMyClass(MyClass());

and effectively assign to b from the temporary. But it's not at all
clear to me what a full-expression is. I mean, it's defined in
[intro.execution] but then it lists some exceptions to the rule,
which seem to muddy the issue for me.

Can anyone clarify what these corner cases are?

--Jonathan

 

[Vladimir Jovic]

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.

You asked about this :

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

That doesn't compile in any compiler.

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 glad you figured out yourself

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

Well, I guess you asked for it. This might help you :
http://catb.org/esr/faqs/smart-questions.html

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.

Nobody told me how to read other's people minds. Whether your code is
ok, or not, depends on what do you do in your method, and you change
that in every new "example" you post.

 

[Vladimir Jovic]

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.

Mehhh... [class.temporary] says the temp should exist until the end of
the full expression. So you might be able to do something like

MyClass b = GetMyClass(MyClass());

and effectively assign to b from the temporary. But it's not at all
clear to me what a full-expression is. I mean, it's defined in
[intro.execution] but then it lists some exceptions to the rule,
which seem to muddy the issue for me.


It is obvious to me at least that the innards of GetMyClass is not
part of the expression used to invoke GetMyClass. Using a dangling
reference is UB and the reference *is* dangling as far as I am
concerned.

/Leigh

Hmmm, maybe I am mistaken, both VC++ and g++ seem to have the temp's
lifetime extend beyond the construction of the copy target.

/Leigh

Obviously I am talking about the following case:

struct MyClass
{
MyClass() { std::cout << "ctor\n"; }
MyClass(const MyClass&) { std::cout << "cctor\n"; }
~MyClass() { std::cout << "dtor\n"; }
};

const MyClass& GetMyClass(const MyClass& t = MyClass()) { return t; }

int main()
{
MyClass b = GetMyClass();
}

which outputs:

ctor
cctor
dtor
dtor

I modified your example a bit :


#include <iostream>
struct MyClass
{
MyClass() { std::cout << "ctor\n"; }
MyClass(const MyClass&) { std::cout << "cctor\n"; }
~MyClass() { std::cout << "dtor\n"; }

void foo()const{ std::cout << "foo\n"; }
};
const MyClass& GetMyClass(const MyClass& t = MyClass())
{
std::cout << "GetMyClass\n";
t.foo();
return t;
}
int main()
{
const MyClass &b( GetMyClass() );
b.foo();
}


This outputs :

ctor
GetMyClass
foo
dtor
foo
Eeek!

 

[Jonathan Lee]

It is obvious to me at least that the innards of GetMyClass is not part of
the expression used to invoke GetMyClass.

Agreed. But the temp won't be destroyed on the return from
the innards of GetMyClass. It'll be destroyed at the sequence
point after the call to GetMyClass, no? Ex.,

const MyClass& GetMyClass(const MyClass& t) { return t; }
...

MyClass a;
a = GetMyClass(MyClass());

Doesn't the sequence point (and thus destruction of the
temp) not happen until after operator=() is done?

Supposing the temp is not destructed, I think the reference
is still valid.

It's seems to me to be as valid as say

MyClass& MyClass:perator*=(int) { return *this; }

a = MyClass().operator*=(5);

Both return a reference to a temp, and both cases the temp
still lives to be assigned from.

What am I missing?

--Jonathan

 

[Öö Tiib]

* Stuart Redmann, on 14.07.2010 14:26:





This is embarassing -- for Microsoft.

[ ... snip how it compiles ]

Uh oh.

The reason is probably that Microsoft introduced some C++/CLI keywords
into usual C++. These keywords are common words and are not prefixed
with double underscores. They also want as lot of legal C++ to compile
as it is possible with both C++ and C++/CLI. Since code using their
non-standard keywords for other names is both likely and legal (and
desirable to compile) that was interesting challenge for them. They
probably removed strong difference between keywords and other names
when parsing and made diagnostics about name/keyword conflicts into
sort of soft. As we see, misuse of some standard keywords remains
undetected in some situations because some of such soft diagnostics is
not always applied.