VectorC adds extra capabilities over those of TFVectorC<RealT>, so it has to be it's own class. Besides which, typedefs are generally avoided in RAVL as they make debugging harder and there's normally a better way of solving the problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1. Would it be nicer to have the capabilities for TFVectorC too?
2. Why it is harder to debug programs with typedefs?
3. What do you mean "better way of solving the problem"?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What is the reason of defining VectorC class as
class VectorC : public TVectorC<RealT>
not
typedef TVector<RealT> VectorC
?
VectorC adds extra capabilities over those of TFVectorC<RealT>, so it has to be it's own class. Besides which, typedefs are generally avoided in RAVL as they make debugging harder and there's normally a better way of solving the problem.
1. Would it be nicer to have the capabilities for TFVectorC too?
2. Why it is harder to debug programs with typedefs?
3. What do you mean "better way of solving the problem"?