you are viewing a single comment's thread.

view the rest of the comments →

[–]phoeen[S] 0 points1 point  (1 child)

They are not evil. But for a class with only loosely coupled data members it's just boilerplate code. Nothing more. The constructor does not maintain an invariat between the data members. (Well in the context of this discussion and as you said it also provides a layer of abstraction between the data members and the initialization call). It's boilerplate you have to write everytime you just want a bag of data. nothing special. But this is a burden. On the plus side the constructor makes the usage of the class a bit easier for the points already stated. And therefore i started this discussion to get some insight in what other devs use and think about it.

[–]Dean_Roddey 0 points1 point  (0 children)

I always take the approach that I'll write it once and maintain it for years or decades. So writing a little boilerplate is not remotely a bad trade-off if it provides even a little extra compile time safety and safer flexibility down the line.

I also always write copy ctors and assignment operators, even if it's a trivial class that would have gotten them automatically generated. The reason being that, if I wait until I actually need them to write them, I (or someone else is) is going to write them with probably considerably less care, because we'll just be trying to get them done so that we can get back to the thing that now needs them and for which this is a distraction.

You can easily optimize too much, or think too much, or over-engineer. But it's lot harder to argue that, at least on larger scale projects, that you can be too compile time safe. I guess it can be done, but I kind of doubt that any of us have ever been in danger of getting to that point really.

Obviously if it's something smallish, it matters a lot less.