Lookie what I did

After posting a little while ago that I need to brush up on templates (I was trying to export a template class in a DLL iirc) I've started playing with them to see what I can can't do; mostly weird scenarios that I couldn't imagine getting into in the first place.

So I whipped up a Vector class (that actually does nothing right now - just has constructors) which could be used if, for some reason, I didn't want to write Vec2 and Vec3 classes for my game engine.

Code:

template <const size_t DIMENSIONS, typename T> 
class Vector
{
public:
  Vector();
  Vector(T x, ...);

private:
  T mComponents[DIMENSIONS];

};

template <const size_t DIMENSIONS, typename T> 
Vector<DIMENSIONS, T>::Vector()
{
  for (size_t i = 0; i < DIMENSIONS; i++)
  {
    mComponents[i] = static_cast<T>(0);
  }
}

template <const size_t DIMENSIONS, typename T>
Vector<DIMENSIONS, T>::Vector(T x, ...)
{
  va_list args;
  int j = x;

  va_start(args, x);

  for (size_t i = 0; i < DIMENSIONS, j != -1; i++)
  {
    mComponents[i] = j;
    j = va_arg(args, T);
  }

  va_end(args);
}

It's kind of silly and nope, there was little point in posting this.

Does anyone even care?
I didn't think so

EDIT: Yes, it compiles but so far the only thing I've done to test it is:

Code:

Vector<2, int> vec(0, 0);

A small addition and look how fugly and uber-verbose operator==() is:

Code:

template <const size_t DIMENSIONS, typename T> 
class Vector
{
public:
  const static size_t  mDimensions = DIMENSIONS;

  Vector();
  Vector(T x, ...);

  // Equality
  bool operator ==(const Vector<DIMENSIONS, T> &other);

private:
  T mComponents[DIMENSIONS];

};

template <const size_t DIMENSIONS, typename T> 
Vector<DIMENSIONS, T>::Vector()
{
  for (size_t i = 0; i < DIMENSIONS; i++)
  {
    mComponents[i] = static_cast<T>(0);
  }
}

template <const size_t DIMENSIONS, typename T>
Vector<DIMENSIONS, T>::Vector(T x, ...)
{
  va_list args;
  int j = x;

  va_start(args, x);

  for (size_t i = 0; i < DIMENSIONS, j != -1; i++)
  {
    mComponents[i] = j;
    j = va_arg(args, T);
  }

  va_end(args);
}

// Test for equality.
template <const size_t DIMENSIONS, typename T>
bool Vector<DIMENSIONS, T>::operator ==(const Vector<DIMENSIONS, T> &other)
{
  _ASSERTE(mDimensions == other.mDimensions);

  for (size_t i = 0; i < DIMENSIONS; i++)
  {
    if (mComponents[i] != other.mComponents[i])
      return false;
  }

  return true;
}

int main(int argc, char *argv[])
{
  Vector<2, int> vec(0, 0);

  return 0;
}

The assertion in == is superfluous. The compiler ensures that the condition is met.

The varargs constructor is a bad idea. In fact, when talking about templates, varargs are almost always a bad idea. Templates and varargs really don't go together.
In this particular case, this constructor prevents me from using my arbitrary precision floating point class of choice for the value type, because varargs may only be of POD type, which my class isn't.

>> The assertion in == is superfluous. The compiler ensures that the condition is met.

Oh.

>> The varargs constructor is a bad idea. In fact, when talking about templates, varargs are almost always a bad idea. Templates and varargs really don't go together.

... Oh.
My bad(s). Is the new standard "doing" something about varargs and templates? It rings a bell.

The new standard will offer structural constructors, which might solve the particular problem you have. It will allow you to initialize the vector like this:

Code:

Vector<2, float> v = { 12.4f, 53.1f };

The new standard might also offer variable template arguments, which, unfortunately, doesn't help you but helps some other situations where one would be tempted to use varargs.

The new standard will not make classical varargs and templates compatible, sorry.

I'm trying to think of the best way to make a proper initilaization constructor, but drawing a bit of a blank. Something could perhaps be done with a tuple and some MPL magic. Then the constructor would be called as

Code:

Vector<2, float> v(boost::make_tuple(35.3f, 30.3f));

Boost.Fusion (not yet released) might offer more interesting interfaces.