Re: Assignment operator=/copy constructor/temporaries, BROKEN!
Fabrizio J Bonsignore wrote:
Oops!
On Sep 17, 5:38 pm, LR <lr...@superlink.net> wrote:
Fabrizio J Bonsignore wrote:
On Sep 17, 3:12 pm, ?? 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 &);
Maybe that's the fix you're looking for then.
I'm wondering if this is related
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16889
Followed link from http://gcc.gnu.org/gcc-3.4/changes.html#3.4.2
Followed link from http://gcc.gnu.org/gcc-3.4/
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!
gcc 3.4.2 was released in 2004. Compilers have bugs. You can find the
list for 3.4.2 at one of the links above. Although, this seems like a
fairly fundamental thing.
[snip]
You can consider the REFERENCE as const or the OBJECT REFERRED TO as
const or the VARIABLE NAME as const... or all three...
I don't follow that as all.
I think that references are const. You can't change them once they're
initialized. An object that is referenced can be const. The variable
name? You've lost me there. I don't know what that means.
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,
No. They don't do the same thing, and this can be very useful.
Personally I think it's much easier to write and debug code where as
much as possible is const. But maybe that's just me.
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?
I'm not sure I understand. Do you mean like this:
class Base {
....
public:
Base(const Base &b) {}
};
class Derived : public Base {
.....
public:
Derived(const Derived &d) : Base(d) {}
};
I don't see the problem.
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.
I'm sorry, but I still don't see the problem.
[snip]
Specifically I wanted to erase the reading
I'm not sure what you mean by "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.
An empty reading? Are you reading a file to construct your object?
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
Are you throwing an exception?
now has the rading
and MAY be the function that ultimately can call Close() or destroy
the object to get a final legitimate reading.
Sorry. I don't understand that.
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;
Assuming that both of these are class members.
Where
const int f();
is a function that returns a const int.
then
SomeClass obj; // can't be const, calling a non const method.
int t = obj.f(); // obj might change
or
const int t = obj.f(); // obj might change
Where
int f() const;
is a function returns an int that will not change the object f() is
called with.
then
SomeClass obj; // could be const if I want.
int t = obj.f(); // obj won't be changed
or
const int t = obj.f(); // obj won't be changed
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...
I find that const makes me more efficient, not less.
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...
For the object that is being constructed.
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.
Now you've lost me again. But in general, I'd say this depends on what
you want to accomplish. IME, keeping the args to assignment operators
and copy ctors, in fact almost all arguments const, saves me time later.
... 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!
In my sad experience all compilers have bugs.
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.
According to the faq
http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.9 you
might want to post in gnu.g++.help to get compiler specific help.
LR