#890 Improve implementation of constructors

[Markus Elfring]

I have noticed that some assignments are used in the constructor bodies.

Examples:
http://icewm.cvs.sourceforge.net/viewvc/icewm/icewm-1.2/src/ywindow.cc?revision=1.54&view=markup
http://icewm.cvs.sourceforge.net/viewvc/icewm/icewm-1.2/src/yapp.cc?revision=1.59&view=markup
http://icewm.cvs.sourceforge.net/viewvc/icewm/icewm-1.2/src/ytimer.cc?revision=1.2&view=markup

The recommended way for performing efficient construction is to use the initialisation list.
http://dietmar-kuehl.de/mirror/c++-faq/ctors.html#faq-10.6
http://cprogramming.com/tutorial/initialization-lists-c++.html
http://www.codeguru.com/cpp/tic/tic0145.shtml
http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=15&rl=1
http://goingware.com/tips/parameters/membervars.html

[Eduard Bloch]

In theory, you are right.

In practice... seriously, WTF? Every normal C++ compiler from the last decade should be able to optimize trivial assignment lists as needed.

[Markus Elfring]

Would you also like to consider any adjustments for the initialisation of pointer member variables?

Update candidates:
- fMotion = new XMotionEvent;
- fDocked = new YXEmbedClient(this, this, win);
- cpu = new int *[taskBarCPUSamples];
- fUpdateTimer = new YTimer(taskBarCPUDelay);
- clockTimer = new YTimer(1000);
- ppp_in = new long[taskBarNetSamples];
- ppp_out = new long[taskBarNetSamples];
- fUpdateTimer = new YTimer();
- tray = new SysTray();
- fClientContainer = new YClientContainer(this, this);
- fTitleBar = new YFrameTitleBar(this, this);
- Other constructors: TextView, HTextView, IceSame, AboutDlg, CtrlAltDelete

How do you think about to reuse the class "std::unique_ptr"?
http://en.wikipedia.org/wiki/Smart_pointer#C.2B.2B_Smart_Pointers

[Eduard Bloch]

I don't know what Marko thinks, here is my opinion:

Using C++11 features just for the sake of code beautification is not worth it.

If you can safe time or enhance code safety (or both) then we might talk about it, but in this case, what's the point? Those member variables are private and only allocated on heap in order to keep the stack size sane, and they are never passed around. The only good reason for auto_ptr (and family) might be the work around exception handling in constructors... but icewm does not use exceptions so that point is void.

[Markus Elfring]

Would you like to support exception handling?
Would you like to avoid any difficulties from an event like the exception
"std::bad_alloc" that might occur during execution of affected constructor bodies?

http://stackoverflow.com/questions/7575459/c-should-i-initialize-pointer-members-that-are-assigned-to-in-the-constructor
http://stackoverflow.com/questions/563221/is-there-an-implicit-default-constructor-in-c#answer-4982720

[Eduard Bloch]

@elfring: I suggest that you start your problem description with telling what the actual problem is ("here: new throws std::bad_alloc") and not with throwing buzzwords and imprecise RTFM hints at people. No offense implied.

@Marko: unfortunately, he has a point. std::bad_alloc is thrown by the libstdcxx's implementation of malloc so using -fno-exceptions does not really help. On Debian, I link with libsupc++ but even that one throws std::bad_alloc (for some reason I assumed the opposite).

[Eduard Bloch]

PS: double-thinking about it, I guess the problem can be "solved" by replacing the normal new/delete operators with non-throwing versions, see http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=40 for example (just the other way round).

[Markus Elfring]

If you do not want to support exception handling, you do not need to change the mentioned source code places because the compiler parameter "-fno-exceptions" should have got the effect that your program will be eventually aborted.
http://gcc.gnu.org/onlinedocs/libstdc++/manual/using_exceptions.html#intro.using.exception.no

But I hope that you are interested to improve your software a bit more.