Re: Assignment operator=/copy constructor/temporaries, BROKEN!
Oops!
On Sep 17, 5:38 pm, LR <lr...@superlink.net> wrote:
Fabrizio J Bonsignore wrote:
On Sep 17, 3:12 pm, =D6=F6 Tiib <oot...@hot.ee> wrote:
If you did not declare copy constructor and assignment operator then
compiler produces these for you (expect for cases the class was made
not copyable). That has been so as long i remember in C++ so i do not
get what you complain there.
Indeed, it works automatically and will generate errors if you are
using pointers and managing your own memory.
I thought the default copy ctor in this case would generate a shallow
copy of the argument.
Indeed a shallow bitwise copy of member object data, so if any of them
is a pointer (heap memory), you end up with two copies of the same
pointer value! Which means you cannot simply delete the pointer in the
destructor because you would delete it twice so that particular object
cannot manage that pointer s memory! The common case is char *texts,
each instance has its own text (if necessary), or can choose to make
it 0, which makes sense if the text is user initialized! For example,
you copy a bitmap object (bitwise data), then wait for the user to
give it a name or it ends up recorded as noname [if ((char *)text ==
0...)] Shallow copy constructors are unacceptable here.
The AO has also been
normal C++ as long as I remember but now it is not working well. The
error message says:
[line] no match for 'operator=' in 'f = BO::Retit()()'
[line] candidates are AO& operator=(AO&);
!!! Precisely!
What happens if you change that to
AO &operator=(const AO &);
That s the solution you provided! And it worked as long as BOTH
assignment operator and copy constructor are signed as (const AO &);
The other error is similar:
[line] no matching function for call to `AO::AO(AO)'
[line] candidates are: AO::AO(AO&)
[line] AO::AO()
!!! Which is nonsense!
These look like they may be compiler bugs, or else you may be compiling
something different than what you posted.
It is the case, seems to be a bug in the compiler but it MAY be a
combination of compiler flags that has to be defined to avoid that
error. In any case it is in the compiler where you do NOT expect nor
can accept bugs at all... or your code becomes undefined!
It SEEMS to work with AO:: (const AO &) in BOTH copy constructor and
assignment operators, the compiler accepts it (compile time), but
const here is almost optional and has been so since ever. Strictly
speaking it is not the same as AO::AO(AO const &x)...
That seems pretty strict. I'm not sure how
A0::AO(const AO &)
and
AO::AO(const AO &x)
are different for purposes of this discussion. Can you please explain tha=
t?
Should not matter, but you can ask for a warning on the lines of:
unused function argument or something similar. I ve always considered
signature argument names as documentation and definition argument
names as minimum name variables, but since the language can accept
function calls in the SIGNATURE of a member function (even anonymous
classes lately...), I always define them even if unneeded for the
method (like the int in post/pre fix operator++).
and you would
even have to disambiguate to the extreme of AO::AO(const AO const &
const a)... and add all variants for BOTH assignment and copy
constructors!
I'm not sure I follow that. I thought that
You can consider the REFERENCE as const or the OBJECT REFERRED TO as
const or the VARIABLE NAME as const... or all three... but I omit
const as far as possible. In worst cases const propagates to all
methods of a class! So you end up having version void F(AO); void
F(const AO); etc. duplicated, but doing exactly the same, to the
extent the const_cast operator became necessary to take away/add const
in hard cases. I never use it, so I am not sure of all the
consequences and differences between those signatures, though the
difference is real for the compiler, or should be.
AO(const AO &); and AO(AO const &); were equivalent. The compiler I use
thinks so too.http://www.comeaucomputing.com/tryitout/seems to
indicate that this is the case as well.
Nope, it may be but you can read both version as different
referents... const AO says that the object cannot stop being an AO! If
that is the case (more testing...), how can you pass it as argument to
a BASE CLASS copy constructor? Strictly speaking you would have to
cast down to base class and even take away the const first, cast, then
add the const again! But too much expliciting of polymorphism actually
DESTROYS IT, you want your polymorphism to be TRANSPARENT for the user
because it hides complexity.
In the program this problem arose it is NOT the case: I
need a SINGLETON, actually I need some UNIQUE reading to propagate
after initial construction wherever objects of primitive class AO take
it, UNTIL any of them is Closed(); which means in one scenario (maybe
at most) I have to discard the reading from the copied object...
violating the const.
I'm not sure that I follow all of that, but it sounds like you want to
be able to partially construct and object and perhaps not complete
construction depending on some resource. Is that right?
Specifically I wanted to erase the reading from the copied object and
_move_it_ into the new, copied-to object, so the original object would
not invoke Close() in the destructor after finding an empty reading.
This assumes new objects s lifespans are longer than the sources and
get destructed later, which is a very good assumption IF you copy
around objects by value! The original gets destroyed in the
originating function, the function that catches it now has the rading
and MAY be the function that ultimately can call Close() or destroy
the object to get a final legitimate reading.
It is NOT FUNNY that the suggestion was
AO::AO(const AO &) and not AO::AO(AO const &) or AO::AO(AO & const);
the latter variants did not compile!
If you try them all together at once I don't think they will compile.
And this Q(Q & const) {} got me a warning about an anachronism from my
compiler.
}-) That s the point! It takes time to test... but here the point is
other similar posts all suggest (AO const &) [const reference to
object of type AO] and not the _working_ const object of type AO taken
by reference. I am not sure, but that anachronism may mean you can
only call some methods on the [ommitted] variable and not others
depending on the placement of their constness const int F(); vs int
F() const; Which IS one the reason why I am perplexed that the
compiler does not let me decide if I change the argument object in a
constructor or not.
This code here is trivial and
does nothing, but in real code I cannot truly know if I can honor ANY
constness in the argument object!
But I'm confused as to why. When you call a ctor with a const
reference, that object is, was, already constructed and it's not clear
to me that you want to alter the already constructed argument. Or
perhaps a slightly different design is what's needed since I think that
a copy ctor that alters the argument tends, not always, but tends, to
violate the principle of least astonishment. IMO.
I am astonished. Reference counting seems to be the typical case where
constness can be broken by necessity, but there are other schemes.
const means that you agree NOT to modify the argument, which is why
you have to define const methods if you want to call methods at all!
It makes for very inefficient programming... The bad C assumption is
that all you can and want to do with the argument is to copy data, but
it IS the natural place to perform initializations, management,
profiling, synchronizations... because the argument is an OBJECT and
includes methods. O CloneX() seems to be a valid method to define and
call in a copy constructor method for members of type O.
Or do you want to call a ctor with an argument that is only partially
constructed? I don't think that's really possible. I think it's very
likely that I don't understand what you mean. Maybe a small real world
example is called for?
But that seems to be what the compiler is doing! It SEEMS to be
creating a temporary with the default constructor, then complaining
that it cannot assign it (because it is partially constructed)! The
error Retut()() implies (Retut()=AO)() === default constructor, the=
n
gets lost because it cannot call in addition AO(AO...)!
Which means the risk of needing to
defining different signatures with almost identical code to handle all
possibilities! Compared to the use of const, the solution AO::AO(AO
*a); AO a(&Function()); (take address of some temporary), seems
preferable, but the problem is still the insistence of g++ 3.4.2 in
finding AO::AO(AO) (!) when later it would say it IS an illegal copy
constructor signature.
Again, this seems very peculiar. Also, from reading herehttp://gcc.gnu.or=
g/it seems that gcc 4.5.1 has been released.
I think you've implied that gcc 3.4.2 is not the compiler that you've
been using with this code. Is using this compiler a recent change?
Do you get these errors when you compile the code that you posted here?
.... gcc 4.5.1 seems to keep adding and adding to the language... and
to the list of BUGS. 4.5.1 means to go through a new installation but
I got my version bundled. I was reading the known bugs and it seems to
keep changing things to new features I do not plan to use which
besides are still buggy! My point is that the code I posted here [AO
and BO] is such typical and basic C++ it has to compile. The version I
ve been using exclusively is 3.4.2 I do not want to change it...
unless it has a real crucial error. Which is what I want to determine.
Danilo J Bonsignore