Здравствуйте, Коваленко Дмитрий, Вы писали:
_NN>>https://gcc.godbolt.org/z/mBmEEC
КД>Это как, разрешено законом что-ли?
КД>В чем прикол такое компилировать?
Это называется injected-class-name. Имя класса вставляется в область видимости класса как открытый член-тип. Благодаря этому мы имеем возможность, например, внутри шаблонного класса использовать имя этого шаблонного класса без указания всех его параметров. Это избавляет нас от ненужного многословия при написании конструкторов копирования/перемещения, операторов присваивания п пр. А посколку имя открытое (public) мы имеем к нему доступ и снаружи. Ну и вложенность обращения тоже не запрещается:
P.S. В некоторых случаях, таких как в моем примере, при обращении к injected-class-name требуется явное использование ключевого слова 'typename', чтобы отличить имя типа от конструктора. В других случаях, там где из контекста понятно, что это имя типа, использовение 'typename' не требуется.
--
Не можешь достичь желаемого — пожелай достигнутого.
Только что обнаружил, решил похвалиться — MSVC 2017 Community 15.9.21 и ниже создаёт бешенный мемори лик в релизе/х64 с таким кодом. В дебаге код корректный. В 2015й этот же код работал.
O>Спасибо, любопытно (и очень злободневно — мы как раз переходим на VS2017)... O>Проверил у себя — действительно, на Release | x64 потребление памяти растет очень быстро, а в Debug такого не наблюдается. O>VS2017 15.9.21.
VS2019 16.5 Preview 3.0 -- потребление памяти не растет
Спасибо, любопытно (и очень злободневно — мы как раз переходим на VS2017)...
Проверил у себя — действительно, на Release | x64 потребление памяти растет очень быстро, а в Debug такого не наблюдается.
VS2017 15.9.21.
J>Подал им багрепорт.
А ссылкой не поделитесь? Я бы свой голос тоже оставил...
Здравствуйте, okman, Вы писали:
O>Здравствуйте, johny5, Вы писали:
J>>...
O>Спасибо, любопытно (и очень злободневно — мы как раз переходим на VS2017)... O>Проверил у себя — действительно, на Release | x64 потребление памяти растет очень быстро, а в Debug такого не наблюдается. O>VS2017 15.9.21.
J>>Подал им багрепорт.
O>А ссылкой не поделитесь? Я бы свой голос тоже оставил...
Здравствуйте, AndrewJD, Вы писали:
O>>мы как раз переходим на VS2017... AJD>А почему не VS2019 ?
Пока будем переходить на VS2019, выйдет VS2021 и кто-то вновь будет спрашивать, почему не VS2021
А если серьезно — очень много кода и различных других аспектов, которые плохо "переносят" переезд на новые версии Visual Studio.
Очень тяжело было переходить с VS2008, т.к. другие страницы свойств, другой формат проектных файлов и еще много всего.
VS2017 нравится в плане стабильности, потому что новые фичи в нее уже не добавляют, а только багфиксы.
Но после VS2017, надеюсь, вскоре перейдем и на VS2019.
Здравствуйте, okman, Вы писали:
O>... O>А если серьезно — очень много кода и различных других аспектов, которые плохо "переносят" переезд на новые версии Visual Studio.
Так вроде же с 2015 они гарантируют совместимость ABI. Т.е. если у вас есть совсем экзотика, которая собирается только 2015 студией, вы можете использовать соответствующий тулчейн и всё будет ок, даже при мешанине с более новыми версиями.
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Здравствуйте, _NN_, Вы писали:
_NN>>Для начала int main, но это издержки совместимости в MSVC.
КД>Сорян, сэкономил
Как раз int это экономия, а void лишний символ.
_NN>>А так и GCC и Clang довольны кодом
_NN>>https://gcc.godbolt.org/z/mBmEEC
КД>Это как, разрешено законом что-ли?
КД>В чем прикол такое компилировать?
Хороший вопрос. Не имею понятия, но можно и покруче:
struct A { struct B { struct C { void f(); }; }; };
void A::A::B::B::C::C::f() {} // Voila :)
Здравствуйте, Коваленко Дмитрий, Вы писали:
_NN>>А так и GCC и Clang довольны кодом
_NN>>https://gcc.godbolt.org/z/mBmEEC
КД>Это как, разрешено законом что-ли? КД>В чем прикол такое компилировать?
Здравствуйте, night beast, Вы писали:
_NN>>>А так и GCC и Clang довольны кодом
_NN>>>https://gcc.godbolt.org/z/mBmEEC
КД>>Это как, разрешено законом что-ли? КД>>В чем прикол такое компилировать?
NB>в чем именно видишь проблему?
А как это можно продать использовать в реальном коде?
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
_NN>>>>https://gcc.godbolt.org/z/mBmEEC
NB>>в чем именно видишь проблему?
КД>А как это можно продать использовать в реальном коде?
pimpl же.
в хидере в классе мембером указатель.
в cpp -- реализация класса.
Здравствуйте, night beast, Вы писали:
NB>>>в чем именно видишь проблему?
КД>>А как это можно продать использовать в реальном коде?
NB>pimpl же. NB>в хидере в классе мембером указатель. NB>в cpp -- реализация класса.
Про pimpl я слышал, но причем он тут — не догоняю.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
NB>>pimpl же. NB>>в хидере в классе мембером указатель. NB>>в cpp -- реализация класса.
КД>Про pimpl я слышал, но причем он тут — не догоняю.
Здравствуйте, _NN_, Вы писали:
_NN>Для начала int main, но это издержки совместимости в MSVC. _NN>А так и GCC и Clang довольны кодом
_NN>https://gcc.godbolt.org/z/mBmEEC
Мелькнула мысль — "кто у кого украл?"
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, rg45, Вы писали: R>Здравствуйте, Коваленко Дмитрий, Вы писали: _NN>>>https://gcc.godbolt.org/z/mBmEEC КД>>Это как, разрешено законом что-ли? КД>>В чем прикол такое компилировать? R>Это называется injected-class-name.
То есть, если говорить прямо — это побочный эффект.
КД>VS2019 v16.4.6 компилирует без проблем. КД>А вот тут ругаются на tag_InnerClass4.
Здесь может иметь значение, что self_type — определенное пользователем имя, все-таки, а не injected class name. Хоть концептуально они и похожи, наверное, могут обрабатываться по разным правилам и с разной степенью строгости.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, johny5, Вы писали:
J>Здравствуйте, okman, Вы писали:
O>>Здравствуйте, johny5, Вы писали:
J>>>...
O>>Спасибо, любопытно (и очень злободневно — мы как раз переходим на VS2017)... O>>Проверил у себя — действительно, на Release | x64 потребление памяти растет очень быстро, а в Debug такого не наблюдается. O>>VS2017 15.9.21.
J>>>Подал им багрепорт.
Вроде как пофиксили, по крайней мере с последним апдейтом память больше не взлетает.