It seems to me that rather or not the constructor is trivial is not the
point. The constructor will get called - *If* there is a reference to a
method or member of the class somewhere in the application.
The optimizer's logic is: The object is not used in the program, so it
can be removed. Since it does not need to exist, there is no reason to
allocate memory or compile and invoke initialization code for it...
This logic stays the same, regardless of the complexity of the
initialization code.
To quote Bj-S, "A constructor's job is to prepare an object for use..."
It would appear that the reason that there is a 'side effect' is that
the a constructor is being asked to prepare the system for use, not the
object to which it belongs.
In general, it is bad to have 'non trivial' constructors. For a very
simple reason, constructors cannot fail gracefully, OS calls, etc.
typically can. This is one of those issues that gets discussed
endlessly in C++ circles (along with the constant complaining about the
shortsightedness of having to declare private members and methods in the
same construct as public one and the pain it causes in large projects...
<grin>)
Best Regards,
-jjf
-----Original Message-----
From: Marshall Clow [mailto:[EMAIL PROTECTED]]
Sent: Saturday, February 05, 2000 10:14 PM
To: Palm Developer Forum
Cc: Fitzpatrick, Joe
Subject: RE: Another Debug-ROM catch
[Snip]
That is true for built-in classes (or user classes that have
constructors that are trivial). However, you can't optimize
away non-trivial constructors because they may have side effects.
-- Marshall
[Snip]
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
