Joe,
I'm not clear one what your point is. Are you on the side that it's OK to remove
unreferenced global objects or not? If the former, then please consider the
following:
class MyClass
{
public:
MyClass (void) { gObjectPtr = this; }
static MyClass* gObjectPtr;
};
MyClass* MyClass::gObjectPtr;
MyClass gObject;
It's trivial, can't fail, doesn't make OS calls, or much else. However, if the
application references only gObjectPtr and never references gObject, then an
overly-zealous linker will remove gObject, the constructor will never be called,
and gObjectPtr will never get initialized. What the linker doesn't realize is
that gObject *is* being accessed, just indirectly via gObjectPtr.
BTW: in my experience, non-trivial constructors are bad, but not for the reason
you give. It's OK for a constructor to fail. Exception handling takes care of
that problem. However, I've found that non-trivial constructors are a hidden
cost that programmers don't normally see. I once worked on a large C++ project
that brought the system to its knees in large part because of the hidden expense
of constructors. The project eventually failed.
-- Keith Rollin
-- Palm OS Emulator engineer
"Fitzpatrick, Joe" <[EMAIL PROTECTED]> on 02/05/2000 11:59:47 PM
Please respond to "Palm Developer Forum" <[EMAIL PROTECTED]>
Sent by: "Fitzpatrick, Joe" <[EMAIL PROTECTED]>
To: "Palm Developer Forum" <[EMAIL PROTECTED]>
cc: (Keith Rollin/HQ/3Com)
Subject: RE: Another Debug-ROM catch
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
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
