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

List:       kde-devel
Subject:    Re: strings and QStrings
From:       Patrick Julien <freak () desource ! net>
Date:       2000-12-10 23:08:00
[Download RAW message or body]

I think I have wasted enough time on this.  But I will try one last time.

On December 10, 2000 03:07 pm, 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:

	In all cases, YES because on init this ( B b1 = a; ) is not operator=.  Try 
any modern compiler that supports the "explicit" keyword and modify the 
original example to say.

	explicit B ( const A & a ) { ... }

All the compilers are gonna barf at 
	B b1 = a;  

but not at 
	b1 = a;
and not
	B b1 ( a );

Because they can't call the constructor implicitely.	

>
> "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?
>
> > In fact, this is old C, the following will generate the same code.
> >         int i = 0; <==> int i ( 0 );
> >

> > But this won't,
> >
> >         int i = 0;
> >         and
> >         i = 3;
>
> No.. Since 'int' is a processor type, it doesn't activate a function at
> all.

	When did I say it activated a function ???
 
>> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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