template<typename T>
class Vector3
{
public:
    union
    {
        T values[3];
        struct{ T x, y, z; };
    };
    Vector3() {}
    Vector3(T value) : x(value), y(value), z(value) {}
    Vector3(T x_, T y_, T z_) : x(x_), y(y_), z(z_) {}
};

template<typename T>
class Line
{
    union
    {
        struct{ Vector3<T> a, b; };
        struct
        {
            Vector3<T> direction;
            double length;
        };
    };
};

int main()
{
    Line<float> line;
}

VC++ 8 kompiliert es, aber

g++ schrieb:

error: member x with constructor not allowed in union

• Welcher Compiler verhält sich hier richtig?
• Ist diese Einschränkung wirklich so wichtig, oder wäre es nicht wichtiger, wenn der Compiler meckern (zumindest warnen) würde, dass man auf ein Element der union lesend zugreift, obwohl sich der letzte Schreibzugriff auf ein anderes bezog?

Der Compiler hat keine Ahnung, welche Komponente des union gerade "aktiv" ist (das wäre zu viel Verwaltungsaufwand). Deshalb ist es deine Verantwortung, darüber Buch zu führen. Und deshalb bekommst du undefiniertes Verhalten, wenn du direction/length gefüllt hast und nun versuchen willst, b auszulesen.

Ist diese Einschränkung wirklich so wichtig, oder wäre es nicht wichtiger, wenn der Compiler meckern (zumindest warnen) würde, dass man auf ein Element der union lesend zugreift, obwohl sich der letzte Schreibzugriff auf ein anderes bezog?

Wenn man auf ein Element einer union zugreift, das nicht zuletzt geschrieben wurde, so führt das in der Regel zu undefiniertem Verhalten (es gibt wenige Ausnahmen). D.h. dein Compiler kann dich warnen, er kann aber auch einfach den dritten Weltkrieg auslösen - ohne Vorwarnung.

Jetzt zu deinem Code:
Unions wie diese

union 
{
        T values[3];
        struct{ T x, y, z; };
};

sind in C++ nicht erlaubt. Die Zeile struct{ T x, y, z; }; deklariet nichts. Weder einen Typ noch ein Objekt.
Und selbst wenn du einen Typ bzw. ein Objekt deklarieren wollest (struct a{ T x, y, z; };), wäre dies nicht möglich, da dies laut Standard innerhalb einer anonymen union nicht erlaubt ist.

Dein Code ist nicht illegal, weil hier irgendwelche Typen mit Konstruktoren in unions stecken, sondern aus den oben genannten Gründen. Der VC 8 kompiliert das Ganze, weil er eine entsprechende Spracherweiterung besitzt.

#include <iostream>
using namespace std;

template<typename T>
class Vector3
{
public:
    union
    {
        T values[3];
        struct{ T x, y, z; };
    };
    Vector3() {}
    Vector3(T value) : x(value), y(value), z(value) {}
    Vector3(T x_, T y_, T z_) : x(x_), y(y_), z(z_) {}
};

int main()
{
    Vector3<float> v(.7f, .2f, .5f);
    cout << "(" << v.values[0] << ", " << v.values[1] << ", " << v.values[2] << ")" << endl;
    v.values[0] = .1f;
    cout << v.x << endl;
    cin.get();
}

Einmal wegen des anonymen structs, dann wegen des Lesezugriffs auf ein inaktives Element. Das ganze kompiliert sowohl auf VC++ 8 als auch auf MinGW-g++ 3.4.5 wunderbar und verhält sich, wie man es sich wünschen und erwarten würde. Schade, dass g++ keine Spracherweiterung für union-Elemente mit Konstruktoren hat. Der Lesezugriff auf ein inaktives Element ist aber keine Spracherweiterung, sondern eher Mißbrauch fehlender Kontrollfeatures, oder?

union
    {
        T values[3];
        struct{ T x, y, z; };
    };

leidet unter einem anonyme struct. das problem des nicht-trivialen konstruktors oder destruktors entstünde zusätzlich, falls T darüber verfügt.

union
    {
        struct{ Vector3<T> a, b; };
        struct
        {
            Vector3<T> direction;
            double length;
        };
    };

hier treten auf jeden fall beide probleme auf. denn vector3<T> hat ja in jedem falle einen nicht-trivialen konstruktor (wobei das trotzdem erst beim instantiieren diagnostiziert werden kann).

Das man in unions keine Typen mit Konstruktoren haben darf hat zum einem mit der Kompatibilität mit C und zum Anderen mit dem "zero cost principle" zu tun. Würden unions solche Typen unterstützen, müsste der Compiler irgendwo Code einschieben, der testet, ob ein Objekt bereits konstruiert wurde oder nicht (selbiges für zerstört), er müsste also verfolgen, welches Element aktiv ist und immer entsprechend reagieren (und zwar in jedem Fall, nicht nur, wenn man verbotener Weise auf ein inaktves Element zugreift).
Verbietet man Typen mit Ctoren ist das alles nicht nötig. Man sagt einfach falscher Zugriff führt zu undefiniertem Verhalten und fertig.

template<typename T>
class Vector3A
{
public:
    union
    {
        T values[3];
        struct{ T x, y, z; };
    };
	Vector3A() : x(0), y(0), z(0) {}
    Vector3A(T value) : x(value), y(value), z(value) {}
    Vector3A(T x_, T y_, T z_) : x(x_), y(y_), z(z_) {}
};

template<typename T>
class Vector3B
{
public:
    union
    {
        T values[3];
        struct{ T x, y, z; };
    };
	Vector3B() : x(1), y(1), z(1) {}
    Vector3B(T value) : x(value), y(value), z(value) {}
    Vector3B(T x_, T y_, T z_) : x(x_), y(y_), z(z_) {}
};

class foo
{
public:
    union
    {
		Vector3A<int> va; //das mag der VC++ nicht
		Vector3B<int> vb; //das mag der VC++ nicht
    };
};

int main()
{
   foo f;
}

Wenn man die Objekte kapselt, kompiliert VC++ das Programm, aber man muss darauf achten, dass die Konstruktion eines Objekts, die Konstruktionen anderer kaputt machen kann:

#include <iostream>
using namespace std;

template<typename T>
class Vector3A
{
public:
    union
    {
        T values[3];
        struct{ T x, y, z; };
    };
	Vector3A() : x(0), y(0), z(0) {}
    Vector3A(T value) : x(value), y(value), z(value) {}
    Vector3A(T x_, T y_, T z_) : x(x_), y(y_), z(z_) {}
};

template<typename T>
class Vector3B
{
public:
    union
    {
        T values[3];
        struct{ T x, y, z; };
    };
	Vector3B() : x(1), y(1), z(1) {}
    Vector3B(T value) : x(value), y(value), z(value) {}
    Vector3B(T x_, T y_, T z_) : x(x_), y(y_), z(z_) {}
};

class foo
{
public:
    union
    {
		struct{Vector3A<int> va;};
		struct{Vector3B<int> vb;};
    };
};

int main()
{
   foo f;
   cout << f.va.x << endl; // ACHTUNG! Die Konstruktion von va ist nicht mehr gültig! Wegen der Konstruktion von vb ist va.x 1
   cin.get();
}

Dieses "Feature" von VC++ ist also mit sehr viel Vorsicht zu genießen.

template<typename T>
class Vector3
{
public:
    T x, y, z;
    T& operator [](size_t index)
    {
        return (&x)[index];
    }
};

Leidet zwar unter den gleichen Alignment Problemen wie deine Version. Lässt sich aber intuitiver benutzen, da du nicht foo.values[...] schreiben musst, sondern foo[..] schreiben kannst. Und ist zudem sprachkonform. Du musst dich also nicht auf irgendwelche Compilererweiterungen verlassen.

Leidet zwar unter den gleichen Alignment Problemen wie deine Version.

welche probleme?

Und ist zudem sprachkonform. Du musst dich also nicht auf irgendwelche Compilererweiterungen verlassen.

ist das so? ich hatte bisher in diesem forum den eindruck, dass nicht so ganz klar ist, ob und inwieweit eine (POD-)struktur mit membern gleichen typs layoutkompatibel zu einem array mit diesem typ als element ist.