-1

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?
Humam Helfawi
  • 17,706
  • 12
  • 64
  • 134

2 Answers2

2

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).

R Sahu
  • 196,807
  • 13
  • 136
  • 247
1

You are weighing the cost of reinventing the wheel with somewhat heavy machinery (Eigen::vector3f) and increased maintenance effort (implementing the pimpl idiom). If your application does not care about the underlying machinery, i.e Eigen::vector3f can be swapped with Boost.Units or some other specialized library, then the pimpl idiom may be appropriate. This is even more true if you have a closed source application that needs to comply with the licenses of OSI-licensed projects, like Qt. The advantage is that if you ever need to switch in the future due to legal reasons or because the project no longer usable/dead, the pimpl idiom eases that.

As for performance degradation, you possibly will get increased memory usage/allocations/hinder the ability for the compiler to optimize. But these are hypothetical. Like any other situation, the only way to know is to measure/benchmark. I find it far more likely that an application dealing with physics is going to have bottlenecks in other areas.