Но эта реализация плохая, потому что ссылки занимают место в структуре (что весьма прискорбно. Я не вижу причин, по которым ссылки нельзя удалить в этом конкретном случае, возможно, это упущенная оптимизация со стороны компилятора).

Это похоже на сложную проблему. Классы стандартной компоновки должны быть совместимы друг с другом. Таким образом, компиляторам не разрешается удалять какие-либо члены, независимо от того, как они определены. За нестандартную планировку? Кто знает. Для получения дополнительной информации прочтите это: Выполните Стандарты C ++ гарантируют, что неиспользуемые частные поля будут влиять на sizeof?

По моему опыту, компиляторы никогда не удаляют члены класса, даже если они «не используются» (например, формально sizeof их использует).

У него есть УБ?

Думаю, это УБ. Прежде всего [[no_unique_address]] означает только то, что член не должен иметь уникальный адрес, а не то, что он не должен иметь уникальный адрес. Во-вторых, неясно, где начинается ваш data член. Опять же, компиляторы могут использовать или не использовать дополнения предыдущих [[no_unique_address]] членов класса. Это означает, что ваши аксессоры могут получить доступ к неправильной части памяти.

Другая проблема заключается в том, что вы хотите получить доступ к «внешней» памяти из «внутреннего» класса. AFAIK такая вещь также UB в C ++.

Что вы думаете об этом подходе?

Если предположить, что это правильно (а это не так), мне все равно это не нравится. Вам нужны геттеры / сеттеры, но C ++ не поддерживает эту функцию. Поэтому вместо того, чтобы создавать эти странные, сложные конструкции (представьте, что другие люди поддерживают этот код), как насчет того, чтобы просто сделать

struct Vector3f {
    float data[3];
    float x() {
        return data[0];
    }
    void x(float value) {
        data[0] = value;
    }
    ...
};

Вы говорите, что этот код уродлив. Может быть это. Но он прост, его легко читать и поддерживать. Нет UB, он не зависит от потенциальных хаков с союзами и делает именно то, что вы хотите, за исключением требований красоты. :)

Если это будет жить в заголовке, и вы уверены в возможностях оптимизации вашего компилятора, вы, вероятно, можете придерживаться старой простой перегрузки operator[]() и ожидать, что компилятор будет достаточно умен, чтобы отклонить вызов и вернуть элемент, который вы хотеть. Например.:

class Vec3f {
public:
    float x;
    float y;
    float z;

    float &operator[](int i) {
        if(i == 0) {
            return x;
        }
        if(i == 1) {
            return y;
        }
        if(i == 2) {
            return z;
        }
    }
};

Я бросил это в Compiler Explorer (https://godbolt.org/z/0X4FPL), который показал лязг оптимизация operator[] вызова на -O2 и GCC на -O3. Менее увлекательный, чем ваш подход, но простой и должен работать в большинстве случаев.

GLM реализует такую ​​функциональность, используя анонимные structs внутри анонимного union

Я не могу лично гарантировать, что это соответствует стандарту, но большинство основных компиляторов (MSVC, GCC, Clang) будут поддерживать эту идиому:

struct Vector3f {
    union {
        struct {
            float x, y, z;
        };
        struct {
            float data[3];
        };
    };
    Vector3f() : Vector3f(0,0,0) {}
    Vector3f(float x, float y, float z) : x(x), y(y), z(z) {}
};

int main() {
    Vector3f vec;
    vec.x = 14.5;
    std::cout << vec.data[0] << std::endl; //Should print 14.5
    vec.y = -22.345;
    std::cout << vec.data[1] << std::endl; //Should print -22.345
    std::cout << sizeof(vec) << std::endl; //On most platforms will print 12
}

Нестандартное поведение заключается в анонимной структуре, используемой для группировки букв вместе, о чем GCC выдаст предупреждение. Насколько мне известно, сам union должен быть действительным, потому что все типы данных идентичны, но вы все равно должны сверяться с документацией к компилятору, если вы не уверены, действительно ли это или нет.

Для дополнительного удобства мы также можем перегрузить оператор скобок, чтобы немного сократить наш синтаксис:

struct Vector3f {
    /*...*/
    float& operator[](size_t index) {return data[index];}
    float operator[](size_t index) const {return data[index];}
};



int main() {
    Vector3f vec;
    vec.x = 14.5;
    std::cout << vec[0] << std::endl; //Should print 14.5
    vec.y = -22.345;
    std::cout << vec[1] << std::endl; //Should print -22.345
    std::cout << sizeof(vec) << std::endl; //On most platforms will print 12
}

Для ясности, доступ к неактивным членам, как я, действителен в соответствии со стандартом C ++, потому что эти члены имеют общую подпоследовательность:

Если два члена объединения являются типами стандартного макета, вполне определено проверить их общую подпоследовательность на любом компиляторе.

Ссылка CPP: Декларация Союза

Поскольку x и data[0]

• Оба floats,
• Оба занимают одну и ту же память,
• Оба являются стандартными типами макета, как их определяет стандарт,

Совершенно верно получить доступ к одному или другому, независимо от того, который в настоящее время активен.

Как уже говорилось, это невозможно: арифметика указателей определяется только внутри массива, и нет способа (без указания ссылки в классе, который занимает место в текущих реализациях), чтобы v.x ссылался на элемент массива.