далее автор и описал, чем он руководствовался когда говорил хороший:
К слову о Go. Если в Go и есть что-то хорошее, так это инструментарий. C++ по сравнению с ним – это натуральный мамонт. У C++ нет единой системы сборки, ничего даже близко похожего на единую систему управления пакетами, а еще его невероятно сложно разбирать и анализировать (это очень важно с точки зрения инструментария).
Не могу сказать что имелось ввиду хороший объективно (хотя все познается в сравнении), но как минимум хороший на фоне C++
мне кажется вам стоит углубиться в Раст.. да и вообще в любой язык/технологию, чтобы прийти к тому, что везде есть свои тонкости, которые узнаются с опытом и новыми шишками
а есть какие-нибудь советы как это подружить с расширением классов?
Я обычно полагаюсь на размер при передаче в функцию, но если в будущем класс будет расширен.. То уже не уверен стоит ли принимать даже 8 байтовый тип по значению
ответ на ваш вопрос лежит прямо в https://github.com/golang/go
По прочтении - расскажите. Наверняка всем будет интересно узнать каких закладок напихал туда гугл
не понял о C++ ли вы, но я ОЧЕНЬ редко пишу free/delete.
Фактически мусор собирает компилятор благодаря raii
все кроме наследования, которое итак почти является анти-паттерном и во многих местах лучше использовать композицию/агрегацию.
Вполне полноценное ООП как по мне
далее автор и описал, чем он руководствовался когда говорил хороший:
Не могу сказать что имелось ввиду хороший объективно (хотя все познается в сравнении), но как минимум хороший на фоне C++
не использовать бинарный интерфейс?
будьте осторожны с кофе.
Но не забывайте аргументировать свои утверждения
Ну не преувеличивайте.. в C++17 чтобы сравнивать без учета регистра достаточно создать кастомный
std::char_traits
Любые изменения вносят дополнительную нагрузку на изучение. Вообще любые и в любых областях знаний.
К тому же есть те, которые улучшают читаемость если знать о них.
Например structure-bindings, концепты, рефлексия, ranges, потенциальные нововведения - контракты.
2-4% использует это чтобы написать библиотеки, которыми будут пользоваться 90%.
Если вам кажется что после C++14 нет ничего полезного для обычного юзера, то вы вероятно плохо знакомы с ними..
пост с реддита хотя бы объясняет что означает "забанили".
Автор же статьи не потрудился об этом упомянуть. Зато растянул предысторию с жертвой-контрибьютором на 2000 символов)
За остальное ничего сказать не могу.
полагаю, вам придется по вкусу Lisp
не сильно опытен в расте, но довольно спорное суждение)
С опытом написания на C++ я избегаю 99% UB, но это никак не помогает мне избавиться от логических ошибок. Также не поможет и раст.
мне кажется вам стоит углубиться в Раст.. да и вообще в любой язык/технологию, чтобы прийти к тому, что везде есть свои тонкости, которые узнаются с опытом и новыми шишками
с радостью, если бы туда брали)
Вы ведь сами сказали тут:
что jj может работать с git.
Поэтому это решает проблему зависимости от инфраструктуры git.
да, как возможное решение, но overcomplicated как мне кажется.
Тогда уж можно прийти к созданию in, out шаблонных структур, которые будут делать выбор в зависимости от размера. Так делается в cppfront вроде бы
[держите)](https://web.archive.org/web/20240802233720/https://habr.com/en/articles/832678/)
кража пакетов...
так вот чему моя бабушка посвятила целую жизнь :0
а есть какие-нибудь советы как это подружить с расширением классов?
Я обычно полагаюсь на размер при передаче в функцию, но если в будущем класс будет расширен.. То уже не уверен стоит ли принимать даже 8 байтовый тип по значению
а вы уверены что тут проблема в отсутствии такой фичи в языке...?
/s