Q: In practice, would a custom Double class be much slower than the built-in double? So suppose I do something like
class Double {
  double m_double;
public:
  Double() { }
  Double(double d) : m_double(d) { }
  operator double() const { return m_double; }
  operator double&() { return m_double; }
};

Maybe I later want to extend this to make NaN a bit more friendly (by adding a bool say), etc.
My question is, do you think off the top of your head that this Double (and possible extensions on it) would be "measurably" slower than using the built-in double directly?
If you have some experience in working with large data sets, with vectors, copying/moving around vectors of such data, etc. - I hope you can give me some concrete insights/pointers/tips regarding this topic based on your experience.

A: Modern compilers do excellent optimizations. Single scalar en-wrapped in a class usually performs as well as plain one. If you add additional checking into member operators then it will cost just what you added. If you need to apply additional limitations to double then that is good idea. 
Example: std::array<T,N> it is ... in essence just an array. I have failed to find test that demonstrates any overhead when comparing to raw array. The added limitations and container-like functionality make it valuable.
Avoid having operators that convert silently to scalars like operator double(). Compilers apply implicit conversions to typos with amazing ease and sometimes achieve that defects compile. Later it takes some time to realize why it is working like it is. Make the conversions more explicit like double raw() const. The resulting code is easier to understand and runs as fast. 
Example: std::array<T,N> does not convert to raw pointer to first element like ordinary array. User has to use &a[0] to get raw pointer to first element. That makes it lot safer and easier to understand in code. It works as quickly (cost of the operation is 0 in optimized code).
