error C2719: alignment problem

Yes and no. If you edit the vector header or create a template specialization for vector for the particular type you have in mind, then yes. Otherwise, no.

Basically the problem is that std::vector::resize(), which is called internally by (I believe) all the vector constructors takes as a T by vaue as a parameter. This involves sticking it in a stack frame, which isn't happy, as you've noticed.

If you hack your header, you can change std::vector::resize() to accept a const T & instead of T as a second parameter. This may have adverse effects. Alternately, you can specialize std::vector for your type, and replace the resize() function signature in the specialization. This would probably be safe (but no guarantees).

Well rewriting a dynamic array class isn't exactly hard ;) But if you really want easy maintainance and all the other advantages std::vector comes with you can just use pointers to __m128 instead of actual __m128. It'll hurt performance wise, I wouldn't do it, but it's an easy way out.
I ran into the same problem when I was usind std::vector. I ended up throwing it away as I realised I was totally clueless wether the standard actually dictates if the std::vector will pass by reference or by value. The container classes aren't exactly super hard stuff to replace. Since you're using SSE you'll probably want the extra performance from a more specialised container class anyway.

Quote:

Original post by Anonymous Poster Is it be possible to create an allocator which takes this new aligned variable into account and is also recognised as a valid variable by functions...

No. Using a different allocator cannot affect most function signatures of container classes, including the one in question.

Quote:

Original post by asp_ I ended up throwing it away as I realised I was totally clueless wether the standard actually dictates if the std::vector will pass by reference or by value.

Annoyingly, std::vector::resize() is defined by the C++ standard to accept the second parameter by value, not by reference.

So it's even standardized then? That's even worse. I figured it was the implementation MS VC uses which was just bad. I can see only one reason for doing that and that's if the user passes a reference to an element in the std::vector to be resized which would probably end up as an invalid reference. I always thought you solved those cases by copying the element referenced before screwing around with the data.