Re: Initialization and trivial constructors
{ Reformatted. Please limit your lines to 70 characters -mod }
dave@boostpro.com (Dave Abrahams) wrote (abridged):
Both your (counter-)examples are *not* convincing. They
significantly change what the constructor does. (In that a
user could provide another r / in that the hypot() function
is leaked into the interface.)
I agree that this is "jumping through hoops", but there is a
standard way to deal with that problem: use delegating constructors:
True. I expect the coding policy predates C++11. C++11 adds some
features that makes initialiser lists easier to use.
in C++03, you do the same thing by adding a base class just for
construction purposes:
True. I'm not convinced the benefits of initialiser lists are worth
the price of adding another class and another level to the inheritance
hierarchy. Both of these techniques feel to me like they are
contorting code to solve something which isn't really a problem. They
seem more purist than pragmatic.
It reminds me of the debate over whether functions can have multiple
exit points. They can always be avoided, but for me the cost of doing
so isn't always worth it. These are areas where different programmers
can have different aesthetic tastes. It's not decided by objective
right and wrong, but by how we value different kinds of complexity.
-- Dave Harris, Nottingham, UK.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]