[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: strings and QStrings
From:       David van Hoose <david-vh () home ! com>
Date:       2000-12-10 19:07:15
[Download RAW message or body]

Patrick Julien wrote:
> 
> Actually, the object is not being returned by operator=, a reference to that
> object is returned, so no constructor

Yeah.. That is what it is supposed to do. GCC has some bugs.
One of the bugs is the overruling of the = operator as
an implicit constuctor alias even if the = operator is different.
This violates the ISO draft. In reality, the GCC compiler does
not follow the ISO draft at all. It is worse than the Borland
compiler at skrewing things up.


> On December 10, 2000 01:02 pm, David van Hoose wrote:
> > Bo Thorsen wrote:
> > > On Sun, 10 Dec 2000, David van Hoose wrote:
> > > > SNIP
> > > >
> > > > > This prints out "constructor" twice. It has no effects to change
> > > > > optimization levels or not optimize or debug or whatever. So, I
> > > > > repeat what I said: "Class c = object" will always call the copy
> > > > > constructor and not first call constructor and then operator=.
> > > >
> > > > I know what it prints. A function that returns the object calls the
> > > > copy constructor.
> > >
> > > Please read the code again, no function is returning an object and
> > > thereby calling the copy constructor. The constructors are called only in
> > > the creation of the two objects of type B.
> > >
> > > The discussion was sparked by someone claiming that it's better to do
> > > "Object o(someOtherObject)" than "Object o = someOtherObject" which is
> > > simply not true since they generate the same code. If you keep saying
> > > that it generates different code, I suggest you look up the part in the
> > > ISO specs where this specific optimization is mentioned. I'm not going to
> > > waste my time doing so.
> >
> > Listen sir. I do not know how much you know or do not know about C++,
> > but I can say for sure that you do not know what you are talking about.
> > I am an assembly programmer. I have observed how the compiler does
> > implicit
> > placements of the constructors. The ONLY reason the code you posted for
> > the
> > overloaded = operator is because you have the object being returned.
> > Change the return to void, and you will NEVER see the constructor.
> > Because the = operator has to call the copy constructor for the return,
> > if you do not use the return value, the constructor is a better choice
> > to use.
> >
> > > Since you cut out the code being discussed, here it is again:
> > >
> > > #include <iostream>
> > >
> > > class A {
> > > public:
> > >     int i;
> > > };
> > >
> > > class B {
> > > public:
> > >     B(){}
> > >     B(const A &a) { i = a.i; std::cout << "constructor\n"; }
> > >     B &operator=(const A &a)
> > >         { i = a.i; std::cout << "operator=\n"; return *this; }
> >
> > // Object returned ------------------------------^^^^^^^^^^^^^
> >
> > > private:
> > >     int i;
> > > };
> > >
> > > int main(int argc, char **argv) {
> > >     A a;
> > >     B b1 = a;
> > >     B b2(a);
> > >     return 0;
> > > }
> 
> >> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

-- 
-Dave
 
>> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]