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

List:       kde-devel
Subject:    Re: strings and QStrings
From:       Bo Thorsen <bo () sonofthor ! dk>
Date:       2000-12-10 8:29:55
[Download RAW message or body]

On Sun, 10 Dec 2000, David van Hoose wrote:

> Bo Thorsen wrote:
> > 
> > On Sat, 9 Dec 2000, Guillaume Laurent wrote:
> > 
> > > On Friday 08 December 2000 21:39, robbie wrote:
> > >
> > > > Thanks for the help I used
> > > >
> > > > QString defdrive=get_default_drive().c_str();
> > >
> > > For what it's worth,
> > >
> > > QString defdrive(get_default_drive().c_str());
> > >
> > > is a bit more efficient.
> > 
> > No it's not. You should write a bug report if the compiler doesn't do this
> > implicitly. So which of the two you use in your code doesn't matter; the
> > compiled code is the same. Personally I find the "=" version more readable.
> 
> The code for the operator should *NOT* implicitly be defined as a
> constructor
> as there may be other operations to be executed or not be.

See this code:

/* Start code */
#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; }
private:
    int i;
};

int main(int argc, char **argv) {
    A a;
    B b1 = a;
    B b2(a);
    return 0;
}
/* End code */

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

Bo.

-- 

Bo Thorsen
bo@sonofthor.dk
Lahnsgade 31, st.
DK-5000 Odense C
Tlf: +45 66 11 83 85

Rule one of good programmers: anything You can do, I can do better
Rule two of good programmers: anything I can do, You can do better
The Programming Theorem: anything worth doing is worth doing over and over again


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

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