What are the risks of using non exposed type in the public headers

Question

I am developing a library where one of its public interface class defined as:

class speed:
public:
    //constructors, operators, setter, getters...
private:
    float x,y,z; 
};

I think here that I am re-inventing the wheel again. Using something like Eigen::vector3f (or any other alternative from another known 3rd libraries) instead of plain float x,y,z as a private member variable is much superior than re-writing all arithmetics operators taking care of all corners case.

In the same time, I do not want to expose any 3rd party with my library (that is a requirement that I have to meet).

Would it be wise to forward declare the the Eigen::vector3f or any other well-designed float vector and use it inside a suitable smart pointer?

To not trap in the opinion-based question style:

• Is there any possible risk by using this approach?
• Would it, theoretically, decrease the performance since the data is dynamically allocated?

Answer 1

This is a software engineering issue, and hence, the answer(s) are most likely to be based on opinion.

My suggestion:

Provide a function that returns a Eigen::vector3f given a speed object. Whether that function is a member function or a non-member function is secondary, though a non-member function is preferable.

Given that, whether you store the internal data using three floats or a Eigen::vector3f is immaterial.

Is there any possible risk by using this approach?

I don't see any. However, I haven't used Eigen::vector3f in any project. I may be off target with my risk assessment.

Would it, theoretically, decrease the performance since the data is dynamically allocated?

I don't see why it would. If you are going to dynamically allocate speed objects, the cost of such allocations would be independent of whether you store three floats or a Eigen::vector3f as member variable(s).