Re: Keeping type safety for classes derived from template class adapters and few good practice questions
* Shimon Shvartsbroit:
For educational purposes I've decided to write linear algebra based
classes. I want to have Vector2 - represents vector in 2d space,
Vector3 - which represents a vector in 3d space, and so on..
Since there are many operations that are similar for Vector2, Vector3
and Vector4 I have decided to write a common base class, VectorAdapter
as follows:
BTW, I am writing this code from top of my head so it might have
compile errors. I didn't paste my original class because it's much more
complex and doesn't add additional information.
When you don't post actual code responses may be focused on problems
that are not present in the actual code, and vice versa, problems that
/are/ present in the actual code may not be accurate conveyed (or
conveyed at all) by your posting.
It's a good idea to post actual code.
template <int N, typename T>
class VectorAdapter:public boost::additive<VectorAdapter<N, T> >
{
public:
typedef VectorAdapter<N, T> ValueType;
// implementation for operators manipulation
ValueType& operator+=(const ValueType& rhs)
{
for (size_t i = 0; i < N; ++i)
{
elements_[i] += rhs.elemens_[i];
}
return *this;
}
protected:
T elements_[N];
};
Not sure how this is an adapter of any kind. It seems to a fixed size
vector. I'd call it FixedSizeVector or I'd use an existing such class.
By using Boost.Operators I have a non member function defined for
operator + as follows:
template <int N, typename T>
VectorAdapter<N, T> operator+(const VectorAdapter<N, T>& lhs,
const VectorAdapter<N, T>& rhs);
In theory I could derive Vector4 from VectorAdapter<4, float> and
Color4 from VectorAdapter<4, float> , since both of them should have
same interface and same implementation.
The problem that occurs now is that I can add instance of Vector4 with
instance of Color4.
Color4 c;
Vector4 v;
c + v; // legal syntax - Color4 and Vector4 behave like
VectorAdapter<4, float> because of public inheritance
Then don't use public inheritance from the same class.
I ask for your advice for best practices to avoid this. I'd like to get
a compile error with such behavior. In case there should be conversion
from Vector4 to Color4 and viceversa I want it to be an explicit one.
One possible solution would be to declare VectorAdapter as:
template <int N, typename T, int ClassIdNumber>
ClassIdNumber - unique number for each class derived from
VectorAdapter.
class Vector4: public VectorAdapter<4, float, 0> {..};
class Color4: public VectorAdapter<4, float, 1> {..};
class Other4: public VectorAdapter<4, float, 2> {..};
I am sure there's a better approach.
One IMO better approach is to use an id type rather than an id number.
The compiler ensures that types are distinct.
Now there are two questions regarding the implementation of operator +=
in VectorAdapter class.
1). Is it more recommended to unroll the "for" loop with template
metaprogramming techniques? If so, could you please show me how this
can be achieved in elegance.
See <url: http://en.wikipedia.org/wiki/Software_optimization#Quotes>.
2). Would any of you implements the sum of VectorAdapter coordinates
using std::transform algorithm? I'm trying to grasp when it's a good
use of STL algorithms. I think that I am aware for most of the
tradeoffs with use of STL algorithms and aware of Boost.Lamba
expressions. Nevertheless, many of you are more experienced with such
topics than I am.
Depends on what the maintainers of the code would be comfortable with,
and what you're comfortable with.
Personally I think abstraction usage that doesn't in some way actually
reduce the amount of current or future work, is ungood.
When using a standard library algorithm saves you (or others) some
significant amount of work, use it.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]