2

I've started to pick up this pattern:

template<typename T> struct DefaultInitialize { DefaultInitialize():m_value(T()){} // ... conversions, assignments, etc .... };

So that when I have classes with primitive members, I can set them to be initialized to 0 on construction:

struct Class { ... DefaultInitialize<double> m_double; ... };

The reason I do this is to avoid having to remember to initialize the member in each constructor (if there are multiple constructors). I'm trying to figure out if:

  • This is a valid pattern?
  • I am using the right terminology?
Improve this question
5
  • Ok, another reason I do this is so I don't have to think about whether I've initialized primitives/basic types. Commented Aug 3, 2009 at 23:58
  • Why have you named your struct "Class"? Commented Aug 4, 2009 at 0:04
  • @Ed: I would assume it's an example. Although I'd use a class, too, in C++ there's not a whole lot of difference between the two. Commented Aug 4, 2009 at 0:06
  • 1
    Why m_value(T()) instead of m_value() ? Commented Aug 4, 2009 at 4:07
  • @robson3.1415 the reason was because this example was simplified. Actually, the original allowed a default value so it was m_value(T(DefaultValue)){} I just took it out in this example b/c I thought it was unnecessary to make the point. Commented Aug 4, 2009 at 5:43

4 Answers 4

Reset to default
4

This is a valid pattern?

It's a known "valid" pattern, i would say. Boost has a class template called value_initialized that does exactly that, too.

I am using the right terminology?

Well, your template can be optimized to have fewer requirements on the type parameter. As of now, your type T requires a copy constructor, unfortunately. Let's change the initializer to the following 

DefaultInitialize():m_value(){}

Then, technically this kind of initialization is called value initialization, starting with C++03. It's a little bit weird, since no kind of value is provided in the first place. Well, this kind of initialization looks like default initialization, but is intended to fill things with zero, but respecting any user defined constructor and executing that instead.

To summarize, what you did was to value initialize an object having type T, then to copy that object to m_value. What my version of above does it to value initialize the member directly.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

Oh, nice. Thanks litb for the link!
4

Seems like a lot of work to avoid having to type m_double(0). I think it's harder to understand at first glance, but it does seem fine as long as everything is implemented properly.

But is it worth it? Do you really want to have to #include "DefaultInitialize.h" everywhere?

To clarify, basically, you're:

  • Making your compile times longer because of the includes.
  • Your code base larger because you have to manage the deceptively simple DefaultInitialize class
  • Increase the time it takes other people to read your code. If you have a member of a class that's a double, that's natural to me, but when I see DefaultInitialize, I have to learn what that is and why it was created

All that because you don't like to type out a constructor. I understand that it seems very nice to not have to do this, but most worth-while classes I've ever written tend to need to have a constructor written anyway.

This is certainly only my opinion, but I think most other people will agree with it. That is: it would be handy to not have to explicitly initialize members to 0, but the alternative (your class) isn't worth it.

Not to mention that in C++0x, you can do this;

class Foo { private: int i = 0; // will be initialized to 0 }
Improve this answer

22 Comments

That is a good point, but in practice I have not had a problem with it.
Perhaps you have not, others will.
Your point about compile times being longer is well taken. I've come to the conclusion that C++ is never going to not suck for compile times. Again, management of the DefaultInitialize class has not been a problem. I'd say it makes it more easier to read, especially when debugging. I really do not like to go hunting for initialization code. When I say "I don't want to type out a constructor" it's not because I'm lazy to type, but because it is easier to read (imo.) Did you have to think very hard about what the class does? Now when you see it will you ever be confused?
No, I understood the class easily, but the fact I did have to learn it is the point, here. I don't find this easier to read at all. If I want a double in my class, I want a double. Not some contorted version of a double.
I don't see a technical reason there. I can relate to your feelings though. I can guarantee you that out of 10 c++ programmers, a significant number of them could not tell me what happens if I did not have the DefaultInitialize<T> member.
|
2

Some compilers don't properly implement value initialization. For example, see Microsoft Connect, Value-initialization in new-expression, reported by Pavel Kuznetsov.

Fernando Cacciola's boost::value_initialized (mentioned already here by litb) offers a workaround to such compiler bugs.

Improve this answer

Comments

1

If you're just initializing basic types to zero, you can override new and have it memset allocated memory to zero. May be simpler. There are pros and cons to doing this.

Improve this answer

12 Comments

Please tell me you didn't mean to suggest memseting over an entire class.
He means that when new allocates memory from the heap, it zeroes out the acquired region before handing it over to the constructor (which then builds the vtable). Or more usefully, if you have rewritten new to use a pooled allocator, then you can zero out the entire pool when you first get it from the OS.
The main con being that new isn't called for automatics, so the constructor still needs to initialize the fields unless you ban placing your object on the stack. Of course if everything is done with factories, that might not be a difficult ban to enforce.
I'm really appalled that this is being downvoted, by the way. We actually do exactly this at my workplace and it saves us a world of typing and trouble.
I suggest everyone involved use their brains instead of assuming obviously erroneous things like overwriting vtable pointers. I said there are pros and cons to doing this; many projects find it useful, and others find it somewhat impure. I'm not advocating for or against it, merely pointing out that it is an option.
|