[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 20:28:35
[Download RAW message or body]

Peter Putzer wrote:
> 
> On Sun, 10 Dec 2000, David van Hoose wrote:
> 
> > Patrick Julien wrote:
> > >
> > > On December 10, 2000 02:07 pm, David van Hoose wrote:
> > > > 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.
> > >
> > > since when?!?  If you use the exemple, you can determine that it is in fact,
> > > doing The Right Thing.  Just add a print in B constructor and change the copy
> > > constructor B(const A&a) to say constructing a copy of b from a.
> > >
> > > > 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.
> > >
> > > Look, the operator= method is not even being called cuz that's not what's
> > > going on here.  In the example,
> > >
> > >         B b1 = a;
> > >
> > > this is not operator=, this is the copy constructor.  It doesn't have
> > > anything to do with overruling.  This is exactly the same has
> > >
> > >         B b1 ( a );
> >
> > Not in ALL cases. This is an example of gross neglect of the human mind.
> > In cases in which the code for the = operator and the constructor are
> > different, the logic flow can be damaged by this alias. Any standard
> > dealing with this should read:
> >
> > "If an assignment operator is used during the declaration process,
> > a typecast constructor shall be used except in cases in which the
> > assignment operator has been explicitly defined."
> >
> > This would prevent damage to the flow of logic.
> > Do you understand what I saying?
> 
> I at least think I do, but I disagree. It's easier to remember that "T x =
> y;" is always an alias for "T x (y);" than if it were "T x = y;" is an
> alias for "T x (y);" iff z is not true.

Ahh. Logic argumentation.. :-)
You lacked something important.
"z is the premise that the constructor and assignment operator yeild
different code."

struct A {
   int i;
};
struct B {
   B(void) { i=0; t=1; }
   B(const B &b) { i=b.i; t=2; }
   B(const A &a) { i=a.i; t=3; }
   ~B(void) { i=0; t=4; } // Sometimes used.
   B &operator=(const A &a) { i=a.i; t=5; }
   
   private:
      int i;
      int j;
};      

This example disproves your argument as t will be different if the
standard is followed. I have actually used similar code in a scripting
program. I have
an explicit specialization of the assignment operator. Ergo, it should
be used.
In this example z is true.

-- 
-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]