Should a C++ constructor that interfaces with hardware do real work? [duplicate]

Answer 1

I'd like to add my own experience there.

I won't say much about the traditional debate Constructor/Init... for example Google guidelines advise against anything the in the Constructor but that's because they advise against Exceptions and the 2 work together.

I can speak about a Connection class I use though.

When the Connection class is created, it will attempt to actually connect itself (at least, if not default constructed). If the Connection fails... the object is still constructed and you don't know about it.

When you try to use the Connection class you are thus in one of 3 cases:

• no parameter has ever been precised > exception or error code
• the object is actually connected > fine
• the object is not connected, it will attempt to connect > this succeeds, fine, this fails, you get an exception or an error code

I think it's quite useful to have both. However, it means that in every single method actually using the connection, you need to test whether or not it works.

It's worth it though because of disconnection events. When you are connected, you may lose the connection without the object knowing about it. By encapsulating the connection self-check into a reconnect method that is called internally by all methods needing a working connection, you really isolate the developers from dealing with the issues... or at least as much as you can since when everything fails you have no other solution that letting them know :)

Answer 2

When using a constructor and an Init() method you have a source of error. In my experience you will encounter situation where someone forgets to call it, and you might have a subtle bug in your hands. I would say you shouldn't do much work in your constructor but if any init method is needed, then you have a non-trivial construction scenario, and it is about time to look at the creational patterns. A builder function or a factory be wise to have a look at. With a private constructor making sure that no one except your factory or builder function actually build the objects, so you can be sure that it is always constructed correctly.

If your design allow for mistakes in implementation, someone will do those mistakes. My friend Murphy told me that ;)

In my field we work with loads of similar hardware related situations. Factories gives us both testability, security and better ways of failing construction.

Answer 3

It is worth considering lifetime issues and connecting/reconnecting, as Neal S. points out.

If you fail to connect to a device at the other end of a link then it is often the case that the 'device' at your end is usable and will be later if the other end gets its act together. Examples being network connections etc.

On the other hand if you try and access some local hardware device that does not exist and will never exist within the scope of your program (for example a graphics card that is not present) then I think this is a case where you want to know this in the constructor, so that the constructor can throw and the object can not exist. If you don't then you may end up with an object that is invalid and will always be so. Throwing in the constructor means that the object will not exist, and thus functions can't be called on that object. Obviously you need to be aware of cleanup issues if you throw in a constructor, but if you don't in cases like this then you typically end up with validation checks in all functions that may be called.

So I think that you should do enough in the constructor to ensure you have a valid, usable, object created.

Answer 4

The only real reason is Testability. If your constructors are full of "real work", that usually means the objects can only be instantiated within a fully initialized, running application. It's a sign the object/class needs further decomposition.