P
Ну то есть не факт конечно, это все мои фантазии
Size: a a a
2021 February 19
P
Но я бы не удивился
KF
Ну тут как
В шарпах же тоже есть куски которые "трогать нельзя, но вообще-то можно" типа unsafe
В шарпах же тоже есть куски которые "трогать нельзя, но вообще-то можно" типа unsafe
KF
Так же я и плюсы воспринимаю. Пока тебе комфортно в определенном сабсете - ну и хорошо. Когда становится тесно - расширяешь сабсет. Так постепенно доходишь от смартпоинтеров до самописных смартпоинтеров и ручного управления с malloc/free
KF
А там и до интерсинков можно докатиться, вопрос цели
KF
Как вам, например шарповая конструкция
struct Foo {}
private Foo m_foo;
public readonly ref Foo myFoo => readonly ref m_foo;
struct Foo {}
private Foo m_foo;
public readonly ref Foo myFoo => readonly ref m_foo;
KF
Чтобы всего лишь передать const Foo&
KF
То бишь структуру по ссылке без права изменения
P
Так же я и плюсы воспринимаю. Пока тебе комфортно в определенном сабсете - ну и хорошо. Когда становится тесно - расширяешь сабсет. Так постепенно доходишь от смартпоинтеров до самописных смартпоинтеров и ручного управления с malloc/free
Это кстати, я считаю, самый правильный подход. Только плюсы чаще всего наоборот учат: сначала сложные вещи которые ты почти никогда не будешь использовать (ручное управление памятью, сишные массивы), а только потом нормальным вещам.
a
язык сумбурно развивался, его синтаксис далеко не идеален. настолько, что неоднозначные ситуации нужно с помощью отдельного синтаксического нововведения фиксить - то бишь с помощью костыля
язык полон наследственных болячек. разумеется, это не критично, но ощущение, как я уже говорил, помоечное. требование обратной совместимости закрепляет многие проблемы. по хорошему надо все эти include грохнуть полностью, и оставить лишь новые модули. но нельзя
никаких статьей с критикой не читал, и даже ни в чем не убедился пока
язык полон наследственных болячек. разумеется, это не критично, но ощущение, как я уже говорил, помоечное. требование обратной совместимости закрепляет многие проблемы. по хорошему надо все эти include грохнуть полностью, и оставить лишь новые модули. но нельзя
никаких статьей с критикой не читал, и даже ни в чем не убедился пока
Язык вроде как планомерно развивается и теперь с 20 стандартом он наконец такой каким его описывал бьярне в дизайне и эволюции языка с++. А большинство болячек из-за обратной совместимости с си и потому что большинство программистов в комитетах по стандартизации с++ повернуты на низкоуровневых вещах и забивают на простые вещи, которые вызывают жопаболь
P
Как я понял многие боятся вносить ломающие изменения, потому что это может вынудить разработчиков оставаться на старых версиях.
Ещё боятся что может случиться как с питоном, когда выкатили классную новую версию которая фиксит много проблем но не всякий старый код будет работать с ней, и появится форк со старой версии для тех кто не хочет обновляться.
В плюсах увы нет пока механизма чтобы часть кода собирать для старой версии плюсов, часть для новой, если новая не будет поддерживать фичи старой.
Ещё боятся что может случиться как с питоном, когда выкатили классную новую версию которая фиксит много проблем но не всякий старый код будет работать с ней, и появится форк со старой версии для тех кто не хочет обновляться.
В плюсах увы нет пока механизма чтобы часть кода собирать для старой версии плюсов, часть для новой, если новая не будет поддерживать фичи старой.
N
да ладно, шарп тоже кривой)
из насущного - принудительные пустые конструкторы страктов, неотличимость использования ссылочного типа от value, невозможность из рефлекшна дергать методы возвращающие ref, да и вообще сам синтаксис ref-ов. недопередженерики (слишком мудреные чтобы легко через них писать на рефлекшне магию как в яве, и слишком простые чтобы мутить compile-time магию как в крестах)
из насущного - принудительные пустые конструкторы страктов, неотличимость использования ссылочного типа от value, невозможность из рефлекшна дергать методы возвращающие ref, да и вообще сам синтаксис ref-ов. недопередженерики (слишком мудреные чтобы легко через них писать на рефлекшне магию как в яве, и слишком простые чтобы мутить compile-time магию как в крестах)
R
пустые конструкторы структур обусловлены производительностью. в плюсах тоже нельзя конструктор, если ты хочешь POD-тип. просто в плюсах структура и класс особо ничем не различаются, тогда как в шарпах структура по умолчанию POD, и это проверяется компилятором. в плюсах же это на твоей совести
P
пустые конструкторы структур обусловлены производительностью. в плюсах тоже нельзя конструктор, если ты хочешь POD-тип. просто в плюсах структура и класс особо ничем не различаются, тогда как в шарпах структура по умолчанию POD, и это проверяется компилятором. в плюсах же это на твоей совести
Немного не понял про нельзя конструктор если POD тип
P
Можно же вроде, главное чтобы не дефолтный 🤔
P
Хотя надо сказать я ничего не понял про C#, так что немного не в теме
АТ
Не трогайте вы Романа
R
0_0
да я вроде не против
да я вроде не против
АТ
Если человека на пет-прожекте про воксели начало корёжить от шарпа ещё в самом начале по вопросам производительности, то процесс мутации в другую форму покемонов запущен
АТ
Вылупится человек в c++, d, rust или jai - зависит от природы. Не вмешивайтесь в естественный процесс )