#843 Improve implementation of constructors

Current_GIT
wont-fix
nobody
refactoring (2)
unspecified
5
2013-12-16
2011-11-08
No

Discussion

  • Nicos Gollan

    Nicos Gollan - 2011-11-08

    Initialisation lists are rather ugly, among other things they are positional which makes them hard to maintain.

     
  • Markus Elfring

    Markus Elfring - 2011-11-08

    Would you like to avoid any default initialisation for affected attributes (like "qsName" with data type "QString")?

     
  • Stefan H.

    Stefan H. - 2011-11-09

    I'm kinda torn on this ;-) For classes I write I usually use the initializer lists but ngollan has a point. While I do not exactly think they are ugly if properly formatted they implicitly rely on the definition order of the member variables in the class (which is easy to get wrong) and as you have to set the in one expression one (I guess I'm speaking for myself here more than others^^) tends to get a bit creative with stuff like inline ifs from time to time....

    Sure we save an assignment operation for those members but for most classes that are not constructed in the thousands performance is not really a valid argument.

    Soo....other thoughts on this?

     
  • Thorvald Natvig

    Thorvald Natvig - 2011-11-10

    While I might be wrong, I don't think we have any objects that are frequently initialized, hence efficiency for this is not essential.
    What I dislike the most about initialization lists is that they're ugly, and that if you refactor your header files to regroup related members, you suddenly have to reorder the matching implementation.
    Also, for a lot of complex objects, you cannot use initializer lists. If initialization of a member is conditional on other parameters, or if you need to call multiple functions to initialize it, or if you need to e.g. hold a lock while you're intializing, you have to move those parts back to normal assignment. Then you end up with some in the initializer list, and some in assignment, and they WILL be in a different order than in the header. It's a bit too easy to forget initializing a field in that case.

     
  • Kissaki

    Kissaki - 2012-12-09

    I’d definitely not use initialization lists with conditionals, inner-dependencies, or anything of that fancy sort. I would use them for static and small default values where applicable (nulls on pointers, integer numbers).

    The separation into initialization list and assignment initialization can also be an IMO good thing, visually separating them - the bare default inits from those that have some logic.

     
  • Kissaki

    Kissaki - 2012-12-09
    • labels: Mumble, refactoring
    • milestone: 1.2.3 --> Current_GIT
     
    Last edit: Kissaki 2012-12-09
  • Kissaki

    Kissaki - 2013-12-16
    • status: open --> wont-fix
    • Version: --> unspecified