Re: Assignment operator=/copy constructor/temporaries, BROKEN!
On Sep 18, 7:28 am, James Kanze <james.ka...@gmail.com> wrote:
On Sep 17, 8:57 pm, Fabrizio J Bonsignore <synto...@gmail.com> wrote:
The const in these is *not* optional, and hasn't been since
CFront 2.1 (1989, or some time around then). You cannot
initialize a non-const reference with a temporary (and the
results of a function call is a temporary).
Some compilers have been a bit slow about enforcing this, but
that's not a general rule; it was enforced by compilers I was
using in the early 1990's.
I have another project open, the compiler accepts a copy constructor
and finds it without const and without errors, compile time or run
time. This problem was surprising! That other class does derive from a
Windows struct and has conversion semantics to it, it defines both
assignment operator= and copy constructor without const... and the
compiler accepts it. I ll have to review that code to see which one of
my cases (in a previous post) I did NOT use in that project that the
compiler did not fail. I am quite liberal in the use of that beefed up
struct as it is now a very basic variable/object in that system and
there has been no such weird error messages. But this may be the case
because it actually IS-A Windows defined struct, so the actual Windows
definition may be affecting compilation. OF COURSE this means to me
more testing...
Compared to the use of const, the solution AO::AO(AO
*a); AO a(&Function()); (take address of some temporary), seems
preferable,
Oh, but it DID accept it! There s where I got stopped. Actually it
makes sense: the temporary, or anonymous variable, MUST keep existing
til the end of the current out-of-returning-function statement or the
data gets completely lost! And there is no reason why the memory
address should become invalid AFTER entering the same statement, which
happens to be... a copy constructor defined with a pointer argument!
At what point should the function-returned byvalue copy be destroyed?
The problem is still that this idiom seems to imply there was in
implicit copy constructor called in between, from the in-function
built object to the copy out-of-return-function that reaches the next,
copy constructor method and ends as argument to the next method code.
If the returned object, in the stack frame, is the same from WITHIN
the previous call and INTO the next call, no problema! The address is
valid. In effect the copy constructor gets the right data, though
something tells me that entering the new, non inlined, copy-
constructor-from-pointer, the stack frame should have been modified,
should contain ONLY this and address-of-object and... oops! But the
actual contents of the previous frame are NOT defined in the stack
itself! Unless there is a system (C++) call to **garbage collecting**
in between frame changes the data should STILL be... in the memory
area of the previous frame in the stack! This seems to be the actual
event, but no guarantee it will ALWAYS happen the same for all
classes, all returning functions and all copy constructors from
temporary pointer! Or is there? If the stack frame is actually a stack
and contains frames objects, when will that memory be overwritten? I
do not want to go so deeply into C++ compiling workings now! the idiom
that worked let me write something like:
AO a( &(object.method(argument)).functionReturningAO() );
and it passes compilation. Should I leave it like that?
You can't take the address of a temporary (unless you provide a
user defined operator&). It's not allowed by the language.
Nope, no operator& defined here... though there IS a pointer to object
member object conversion operator defined...[ operator STRUCT*()
{return &member;} ] which should NOT interfere anyway, as there is no
constructor AO::AO(STRUCT...) whatsoever to ambiguate calls for the
compiler, which incidentally has always been kind of a nuisance in the
language to make primitive type like classes... This means more
testing... but the AO example is simpler and does have the same error
message.
Different errors are detected at different phases of
compilation. A constructor AO::AO(AO) is illegal---it would be
useless if it weren't, since it would result in infinite
recursion if it were ever called.
That seems to be a REAL bug in the compiler: the problem is something
different, it should mention the lack of const as a warning (AT MOST,
I insist current practice is to make const optional), and the form of
such error message is so easily detectable that it can be substituted
by anything else in the next error reporting pass, if not completely
changed.
Danilo J Bonsignore