2

I’m using std::chrono to track how much time is elapsed from the instantiation until every call to someMethod().

A minimal sample code looks like this:

#include <chrono>

class TestClass
{
public:
    TestClass();
    void someMethod();

private:
    std::chrono::time_point<std::chrono::steady_clock> m_timeBegin;
};

TestClass::TestClass() :
    m_timeBegin(std::chrono::steady_clock::now())
{
}

void TestClass::someMethod()
{
    auto timeNow = std::chrono::steady_clock::now();
    auto msSinceCreation = 
         std::chrono::duration_cast<std::chrono::milliseconds>(timeNow - m_timeBegin);
}

I want to get rid of the #include in the header.

Motivation

Beside compilation and link times, my main concern is about encapsulation. Using std:chrono is only relevant in the implementation. In order to use Testclass there is absolutely no need to use it or even know it’s involved.

Here is some possible scenario. If someone using the TestClass decide to use std::chrono, he can do it without add the #include. Then, if in the future the implementation of TestClass change stop using std:chrono (and in consequence removing the #include) the other code will stop compiling with no reason.

Obviously the guy who forgot to add the include did it wrong. But also obviously this will occur we like it or not.

Additional info

As it is possible that it is relevant for certain solutions, SomeMethod() is called frequently and performance is important in my scenario.

Community
  • 1
  • 1
Germán
  • 581
  • 1
  • 4
  • 19
  • 9
    I suppose, you could use [pimpl](http://en.cppreference.com/w/cpp/language/pimpl) to hide this particular implementation detail, though it will come with a cost of an additional pointer access per method call. However, I believe you are making entirely too big of a deal out of `#include `: adding this directive it's not a hard fix to make for client code, in the unlikely event that your class stops depending on it and the author of said client code for some reason decided to rely on your header to provide the include for chrono (which is kind of a mistake on *their* part, by the way). – TerraPass Nov 06 '17 at 08:00
  • 2
    Possible duplicate of [What techniques can be used to speed up C++ compilation times?](https://stackoverflow.com/questions/373142/what-techniques-can-be-used-to-speed-up-c-compilation-times) – rustyx Nov 06 '17 at 08:31
  • If you have unit tests for the functions you like to measure, you can use `https://github.com/google/benchmark`. Thus, you have no trouble with `chrono` at all. – schorsch312 Nov 06 '17 at 09:46
  • 3
    The "missing include"-problem is not limited to your code. Including *any* standard library header might already indirectly include *any other* standard library header. Which ones varies from compiler to compiler, and from one release of a standard library to the next. You are not making this any worse. – Bo Persson Nov 06 '17 at 09:59
  • I’m afraid you lost that battle twenty years ago. Unlike C, C++ is heavily dependent on headers; you can’t avoid them. – Pete Becker Nov 06 '17 at 14:16

1 Answers1

6

Your problem would be solved if time_point was a custom type, because then you could just forward declare it, change the member to a (unique) pointer, and move the include to the .cpp file. However, forward declaration of std types is undefined behavior, so that is not possible. This leaves you basically with the following options:

  • Wrap the std::chrono::time_point<std::chrono::steady_clock> in a custom class. Then you can safely forward declare that type, change the member to a (unique) pointer, and move the include of the custom class (which includes <chrono>) into the .cpp file.
  • Use the pimpl idiom and move the whole implementation of your class into the .cpp file.

I understand your motivation. Still, while your scenario that someone uses <chrono> and forgets to include it is not far fetched, it is a problem of that someone, not yours. So you should think about whether it is really necessary to introduce some complexity, just to hide the <chrono> header. The standard library includes usually dont hurt, especially because they do not introduce rebuild impact.

As others have noted, using a smart pointer for the pimpl idiom or the forward declared type would introduce another include, namely <memory>. Even though this is usually a more common header than <chrono> you just exchanged one include for another. So if you really want to avoid additional includes, you may want to use a raw pointer. But then you have to take care of other problems, such as copy and move operations.

pschill
  • 5,055
  • 1
  • 21
  • 42