я нашел свой путь через лабиринт к некоторым отличным источникам об этом, и я думаю, что у меня есть довольно полное резюме этого. Я публикую это как ответ, потому что это, похоже, объясняет как (ИМО очень ошибочное) намерение предложения C, так и тот факт, что C++ не наследует его. Это будет развиваться со временем, если я обнаружу дополнительные вспомогательные материалы или ситуация изменится.

это моя первая попытка подвести итог очень сложной ситуации, которая кажется плохо определено даже для многих языковых архитекторов, поэтому я буду приветствовать разъяснения/предложения о том, как улучшить этот ответ - или просто лучший ответ, если у кого-то есть.

Наконец, некоторые конкретные комментарии

через неопределенно связанные темы я нашел следующий ответ @tab - и высоко оценил содержащиеся ссылки на (освещающие, если не окончательные) отчеты о дефектах GCC и рабочей группы:ответ по вкладке на StackOverflow

в Ссылка GCC содержит некоторые интересные обсуждения и показывает значительное количество путаницы и противоречивых интерпретаций со стороны комитета и поставщиков компиляторов - вокруг темы union s, каламбур и сглаживание в C и c++.

в конце концов, мы связаны с основным событием-другой поток BugZilla,65892 ошибка С очень полезное обсуждение. В частности, мы находим наш путь к первому из два ключевых документа:--27-->

начало добавленной строки в C99

C предложение N685 происхождение добавлен пункт касательно видимость union объявление типа. Благодаря тому, что некоторое утверждение (см. поток GCC #2) является полной неправильной интерпретацией "общей начальной последовательности", n685 действительно предназначен для релаксации правил сглаживания для "общей начальной последовательности"structs в пределах TU известно о некоторых union содержащие экземпляры said struct типы, как мы видим из этой цитаты:

предложенное решение требует, чтобы быть союзом декларации видно если псевдонимы через общую начальную последовательность (как указано выше) возможны. Поэтому следующий TU обеспечивает такой вид сглаживания при желании:

union utag {
    struct tag1 { int m1; double d2; } st1;
    struct tag2 { int m1; char c2; } st2;
};

int similar_func(struct tag1 *pst2, struct tag2 *pst3) {
     pst2->m1 = 2;
     pst3->m1 = 0;   /* might be an alias for pst2->m1 */
     return pst2->m1;
}

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

очевидно, как трудно было бы удовлетворить эту интерпретацию добавленного предложения, не полностью калеча многие оптимизации-для небольшой выгоды, так как мало кодеров хотели бы эту гарантию, а те, кто это делает, могут просто включить fno-strict-aliasing (что ИМО указывает на большие проблемы). Если реализованная, эта надбавка, скорее всего, выловит людей и злонамеренно взаимодействует с другими декларациями unions, чем быть полезным.

пропуск строки из C++

следуя из этого и комментария, который я сделал в другом месте,@Potatoswatter в этом ответе здесь на SO гласит:

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

другими словами, похоже на С++ сознательно избегал принятия этого добавили пункт, скорее всего из-за его широко pereceived абсурда. попросив" на запись " цитату из этого, Potatoswatter предоставил следующую ключевую информацию об участниках потока:

люди в этой дискуссии по существу" на записи " там. Эндрю Пински-хардкорный бэкэнд GCC. Мартин Себор является активным C член комитета. Джонатан Уэйкли-активный член комитета C++ и разработчик языка/библиотеки. Эта страница более авторитетна, ясна и полна, чем все, что я мог бы написать.

Potatoswatter, в том же потоке SO, связанном выше, делает вывод, что C++ намеренно исключил эту строку, не оставив специального лечения (или, в лучшем случае, определенного реализацией лечения) для указателей в общую начальную последовательность. Будет ли их лечение в будущем конкретно определенные, по сравнению с любыми другими указателями, еще предстоит увидеть; сравните с моим заключительным разделом ниже О C. В настоящее время, хотя это не так (и снова, ИМО, это хорошо).

что это означает для C++ и практических реализаций C?

Итак, с гнусной линией от N685... ' cast в сторону'... мы вернулись к предположению, что указатели на общую начальную последовательность не являются особыми с точки зрения сглаживания. До сих пор. стоит подтвердить, что этот абзац на C++ значит, без него. Ну, 2-й поток GCC выше ссылки на другой драгоценный камень:

дефект C++ 1719. Это предложение достигло DRWP статус: "проблема DR, решение которой отражено в текущем рабочем документе. Рабочий документ представляет собой проект будущего варианта стандарта" -цитировать. Это либо сообщение C++14, либо, по крайней мере, после окончательного проекта, который у меня есть здесь (N3797) - и выдвигает значительно, и в моем мнение освещающее, перепишите формулировку этого абзаца, следующим образом. Я выделяю то, что считаю важными изменениями, и {эти замечания} мое:

в стандартной разметки союз с активным {"активный" означает union экземпляр, а не только тип} (9.5 [класс.союз]) структуры типа T1 разрешается читать {ранее "проверить"} a нестатический элемент данных m другого члена Союза структуры типа T2 предоставил m часть общая начальная последовательность T1 и T2. [Примечание: чтение Летучего объекта через энергонезависимый glvalue имеет неопределенное поведение (7.1.6.1 [dcl.типа.cv]). - конец Примечания]

это, кажется, проясняет смысл старой формулировки: для меня это говорит о том, что любое специально разрешено 'каламбурно между union член structs с общими начальными последовательностями должно быть сделано через экземпляр родитель union - вместо того, чтобы основываться на типе structs (например, указатели на них передаются некоторые функции). Эта формулировка, по-видимому, исключает любую другую интерпретацию,а-ля N685. C было бы неплохо принять это, я бы сказал. Эй, кстати, см. ниже!

в результате этого-как хорошо продемонстрировано @ecatmur и в билетах GCC-это листья такие union s по определению в C++ и практически в C, с учетом тех же строгих правил псевдонима, что и любые другие 2 официально несвязанных указателя. явное гарантия умея читать общую начальную последовательность неактивных union s теперь более четко определен, не включая расплывчатую и невообразимо утомительную для обеспечения "видимости" как попытка по N685 для C. По этому определению основными компиляторами были поведение, предназначенное для C++. Что касается C?

возможный разворот этой строки в C / clarification в C++

также очень стоит отметить, что член комитета C Мартин Себор тоже хочет исправить это на этом прекрасном языке:

Мартин Себор 2015-04-27 14:57: 16 UTC если один из вас может объяснить проблему с ним, я готов написать статью и представить ее WG14 и попросить изменить стандарт.

Мартин Себор 2015-05-13 16: 02: 41 UTC у меня была возможность обсудить этот вопрос с Кларком Нельсоном на прошлой неделе. Кларк работал над улучшением частей сглаживания спецификации C в прошлом, например, в N1520 (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1520.htm). Он согласился с тем, что, как и проблемы, отмеченные в N1520, это также нерешенная проблема, которую WG14 стоило бы пересмотреть и устанавливать."

Potatoswatter вдохновенно заключает:

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

мы можем только надеяться!

опять же, все дальнейшие мысли приветствуются.