implicit QChar constructors

[Dirk Mueller]

On Mit, 22 Jan 2003, Dirk Mueller wrote:

> yes, gcc should be able to detect that the constructor is a pure function 
> (has no side effects). so as it can do strength-reduction in similiar cases, 
> I don't see why it doesn't do that here. Compiler guru, if you're listening, 
> speak up. 

Ok, creating a testcase unveiled the problem: gcc does not loop-eliminate 
constructions when there is a copy constructor. Again this confirms the 
golden rule of C++ coding: never declare a copy/assignment operator unless 
you have to, because the compiler is always more efficient in creating such 
a "default" copy constructor. 

Unfortunately, Trolltech has declared a copy constructor. 

See this testcase: 

//#define BREAK_GCC

class QChar {
public:
    QChar() : ucs(0) {}
    QChar( char c );
    QChar( unsigned char c );
#ifdef BREAK_GCC
    QChar( const QChar& o) : ucs(o.ucs) {};
#endif

private:
    unsigned short ucs;
};

inline QChar::QChar( char c ) : ucs( (unsigned char)c ) {}
inline QChar::QChar( unsigned char c ) : ucs( c ) {}

int main()
{
    QChar* txt = new QChar[10];
    for ( unsigned int z = 10; z--;)
        txt[z] = ' ';

    return 0;
}


gcc successfully loop-eliminates the QChar construction if you remove the 
copy constructor. 


-- 
Dirk (received 355 mails today)