Изза того что MSVC манглит struct/class имена по разному, при

компиляции объектов которые декларированы по разному он продюсит ворнинг C4099.
Есть что-то в стандарте, что уравнивает семантику объявлений struct ForwardDeclaration; и class ForwardDeclaration; или мсвц в полном праве полагаться что это разные объявления?
И если семантика разная, то никто не хочет это починить с whatever ForwardDeclaration;? Еще бы и тайп альясы туда присобачить.

Зачем по разному декларировать один и тот же тип

вроде как в стандарте есть, что struct/class идентичны

Потому что ты не помнишь. Потому что поменяли оригинальный тип, но не форварды

Ну тогда ссзб

Это стреляет неприятно, когда у вас меняется тип в фреймворке, а клиенты живут в своих проектах и им надо идти менять форварды. Чинится тем что многие делают forward.hpp с форвардами, заодно и со всеми тайпалиасами, но это костыль, который не хочется делать

не меняйте так публичное апи) внезапная идея переделать class на struct кажется немного странной

надо просто не юзать class и всё

Феномен Баадера-Майнхоф, никогда такого не ловил и вдруг перепутал struct на class в forward declaration, все скомпилили а в msvc unresolved external 😂

Мс-вс поступает абсолютно корректно. Манглинг не является частью стандарта и отдан на откуп имплементации. Имплементация Мс-вс максимально строгая. В манглинг включается не только class/struct, но и retval и public/private и static и .. я хз ещё что. Чуть сбаловался - давай разбирайся.

Разобраться бывает сложно :) Оно на этапе компиляции видя что class/struct расходятся не сказало ничего. Более того, оно выдумало несуществующую функцию class T& foo() (хотя она struct T& foo()) и объявило её unresolved.

Выглядит как довольно бессмысленный механизм при работе с форвардами. Зачем включать в манглтинг стракт или класс не очень ясно. Я не вижу какую фичу это добавляет, но вижу просто ещё одно место где можно ошибиться.

но класс и стракт не идентичны, у них есть различия) Никто и не говорил, что их можно вместо друг друга использовать

для форварда это не имеет значения, что это дает при манглинге тоже неясно

ты сам написал, что компилятор ворнинг кидает, не знает такого класса/структуры

так делает только мсвц, остальные компиляторы нормально работают

ты не должен писать код, который один из 3х компиляторов не собирает (или кидает явный ворнинг), структура и класс - не одно и тоже, какая может быть причина вместо class написать в форварде struct (и наоборот)

я выше приводил пример. У вас есть фреймворк, который поменял класс на стракт, есть клиенты, которые не у вас в компании и потребляют фреймворк, у них форварды в коде старые. Теперь у них очень обскурно все ломается

Вот и не надо и нельзя так делать.

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

Не надо что делать? Форварды писать? Менять апи? Тратить время на фикс форвардов, потому что что? Есть костыльное решение для этого это держать свои форварды все в отдельном хедере и поставлять его тоже, но я не вижу большой причины для существования таких костылей. Чем может навредить forward Name; в декларации, вместо class/struct Name;? Ну кроме того что мсвц придется поменять как они манглят имена и сломать аби :D

не надо форварды писать на код, за которым даже не проверяешь при апдейте не изменилось ли там что на этот счёт, это грабли те ещё даже без манглинга если нужны форварды, но самому следить не получается, попроси апстрим фреймворка, чтобы они у себя сделали хедер с форвардами и поддерживали его не нравится, что стандарт допускает разный манглинг для struct и class, напиши пропозал в стандарт, полушай/почитай что тебе там ответят

я и есть апстрим фреймворка и поддерживаю хедер с форвардами и не хочу этого делать

ну … удали его 😈

А почему кто-то решил, что ломать abi библиотеки и скидывать вину на манглинг – норма? С таким же успехом можно было переименовать классы, сломав код пользователей

Потому что поддерживать аби библиотеки которая собирается из сорцов и наружу не торчит не очень нужно. Вы же понимаете что ваше сравнение с именами некорректно?

Ну, если мы заменим abi на api – ничего не поменяется в данном примере Автор библиотеки принял решение сломать api. Жалуемся на компилятор Должны ли эти изменения были ломать api – это уже отдельный вопрос. Но вы уж или принимайте правила всех платформ, которые поддерживаете, или не поддерживайте ту, которая вас не устроила

Ну так можно просто не использовать его либу. А если хочется фиксить ее проблемы то использовать

Вас же не заставляют насильно ее юзать

Ну, так и есть. Одно другому не сильно противоречит

Давайте ни на что не жаловаться и не развиваться! Вы знаете зачем в замангленном имени мсвц использует структ? Для чего это нужно?

>> Давайте ни на что не жаловаться Попробуйте пожаловаться на это в их багтрекер. Правда, боюсь, что попытка починить проблему окажется ещё более серьезным ломающим изменением и для api, и для abi всех пользователей платформы

сейчас это не важно, оно уже так и менять никто не будет