[ icewm-Bugs-3469478 ] Improve implementation of constructors
Brought to you by:
captnmark
Menu
▾
▴
[ icewm-Bugs-3469478 ] Improve implementation of constructors
|
From: SourceForge.net <no...@so...> - 2012-01-08 12:30:30
|
Bugs item #3469478, was opened at 2012-01-04 09:18 Message generated for change (Comment added) made by elfring You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100031&aid=3469478&group_id=31 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: icewm-1.3 Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Markus Elfring (elfring) Assigned to: Nobody/Anonymous (nobody) Summary: Improve implementation of constructors Initial Comment: 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 ---------------------------------------------------------------------- >Comment By: Markus Elfring (elfring) Date: 2012-01-08 04:30 Message: 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. ---------------------------------------------------------------------- Comment By: Eduard Bloch (thefirstone) Date: 2012-01-08 03:37 Message: 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). ---------------------------------------------------------------------- Comment By: Eduard Bloch (thefirstone) Date: 2012-01-06 16:52 Message: @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). ---------------------------------------------------------------------- Comment By: Markus Elfring (elfring) Date: 2012-01-05 11:44 Message: 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 ---------------------------------------------------------------------- Comment By: Eduard Bloch (thefirstone) Date: 2012-01-05 11:01 Message: 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. ---------------------------------------------------------------------- Comment By: Markus Elfring (elfring) Date: 2012-01-05 05:30 Message: 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 ---------------------------------------------------------------------- Comment By: Eduard Bloch (thefirstone) Date: 2012-01-05 03:53 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100031&aid=3469478&group_id=31 |