Здравствуйте, kaa.python, Вы писали:
KP>А что такое "стабильная ветка" на примере C++? Мы всё что можно сразу на C++17 пишем сейчас, сильно комфортнее писать по сравнению с 11 стандартом, да и удобнее 14, что уж. Я вообще за то, что бы использовать последнюю стабильную версию языка и платформы.
Вот как раз с плюсами это может выйти боком, когда речь идет о переносимости и библиотечном коде. Скажем для сборки под какой-нибудь девайсе может тупо быть последней версии плюсов и если они использованы в библиотечном коде, ты наелся.
У меня один знакомый недавно из-за этого при разработке под роутер выбрал С (без плюсов).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, cppguard, Вы писали:
C>Почитал про нововведения 3.10. "Да это же какой-то С++20хх получается", было первым, что пришло в голову.
Питоном не пользуюсь, но считаю, что позиция вроде твоей основывается только на том, что тебе в лом разбираться в нововведениях и ты просто записываешь в ненужное то, что пока не понял и не осознал.
C>А вы лично очень ждёте новинок в своем языке или предпочитаете сидеть на стабильной ветке?
Лично я просто добавляю новинки в свой любимый язык и скорее страдаю от того, что некоторые не так то просто добавить и придется убить много времени. Так же страдаю от того, что приходится использовать старые версии того же C#.
Проблему в новых конструкциях вижу только в области обратной совместимости. Но эта проблема скорее присутствует в языках компилируемых в нативный код, вроде С++. Например, не для всех девайсов доступны свежие компиляторы плюсов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Питоном не пользуюсь, но считаю, что позиция вроде твоей основывается только на том, что тебе в лом разбираться в нововведениях и ты просто записываешь в ненужное то, что пока не понял и не осознал.
C>>А вы лично очень ждёте новинок в своем языке или предпочитаете сидеть на стабильной ветке?
Звучит так, словно очередное изменение это теория относительности, чтобы с ней нужно было разбираться. Про defensive programming слышали? Так вот это работает тогда, когда язык хорошо продуман. А когда возможности добавляются лишь бы добавить, то эта возможность исчезает. Хороший тому пример — JavaScript и PHP. Почему от них все плюются? Да потому что на определённом этапе языка в оба стали добавлять что-то, что ломает предыдущую логику, в итоге появились безобидные на первый взгляд конструкции, которые при ближайшем рассмотрении приносят много боли.
Вот такой пример. Пока в Python не было async/await, все пользовались Twisted. И Twisted создал набор приёмов, который более-менее соответствовал теории CS и в итоге со временем устоялся. Но в Python 3 пришла asyncio и всё поломали. Им же нужно было быстро показать, что Питон всё ещё модный и молодёжный, а разработчики... разработчики как-нибудь выкрутятся.
Здравствуйте, VladD2, Вы писали:
VD>Вот как раз с плюсами это может выйти боком, когда речь идет о переносимости и библиотечном коде. Скажем для сборки под какой-нибудь девайсе может тупо быть последней версии плюсов и если они использованы в библиотечном коде, ты наелся.
Ну да, может быть. А может и не быть же. Просто надо понимать что и для чего ты пишешь.
VD>У меня один знакомый недавно из-за этого при разработке под роутер выбрал С (без плюсов).
Ну вот это странно, честно. Если это роутер, там скорее всего Linux и с большой вероятностью там можно и довольно современный C++ использовать. Даже на QNX вполне себе C++14 доступен.
Здравствуйте, velkin, Вы писали:
V>1) Где в C++ нормальная рефлексия, свойства, события?
Какая такая рефлексия в компилируемом языке? Вот ты для микроконтроллера прошивку пишешь, которая прожигается намертво в ПЗУ. Какая тут может быть рефлексия? Там и места-то нету в памяти под всю эту машинерию рефлексии (компилятор, и иже с ними).
Здравствуйте, cppguard, Вы писали:
C>А вы лично очень ждёте новинок в своем языке или предпочитаете сидеть на стабильной ветке?
как будто есть выбор. на чем контора пишет, на том и сидим.
если о личном — то я ненавижу эти новинки, в основном за то, что любой недоделанный разработчик считает самоцелью их юзание.
да, тенденция к переусложнению в языках есть, но это и хорошо — без работы не останемся. количество перейдет в качество в очередной раз, и все велосипеды надо будет в очередной раз переписывать на новом языке, покоряющем мир.
опа опа мы воюем с нато
любит хавать этот кал
путинская вата
Здравствуйте, cppguard, Вы писали:
C>Здравствуйте, VladD2, Вы писали:
VD>>А зачем в тракторе руль и тормоза? Они же есть в легковушках. "Логика" примерно такая же.
C>Я думал, там настоящий pattern matching, а там обычный switch-case. Конструкция нужная, спору нет.
А что такое "настоящий pattern matching"? Вроде в питоне он структурный, как и в хаскеле.
Здравствуйте, cppguard, Вы писали:
>и уже не совсем понятно, успевает ли кто-то осилить весь этот багаж?
А это нужно, все осилить? Можно использовать нужные лично тебе фичи и игнорировать другие. И философия C++ "ты не платишь за то, что не используешь" этому способствует.
>то Фейсбук ещё в 2017-ом плотно сидел на С++11, дописывая недостающие (и часто тривиальные) части из 14 и 17 собственоручно.
И что? Это еще прогрессивный пример. В NASA в 1995г. сишка считалась слишком сырым языком, т.к. стандарту 89го года к тому моменту было всего 6 лет, и это считалось слишком новоделом для NASA. Чтобы когда-то новые фичи можно было использовать, они когда-то таки должны быть приняты в стандарт. Иначе они никогда не появятся. Это ты можешь считать, что фичи добавляют слишком быстро, а иные жалуются наоборот, что слишком медленно. И что стандартная библиотка до сих пор слабовата, и networking, и модули никак не допилят, и что надо тащить ворох библиотек типа boost, Qt и д.р., а многое можно было давно реализовать в std.
C>А вы лично очень ждёте новинок в своем языке или предпочитаете сидеть на стабильной ветке?
На стабильной, конечно. Но это не отменяет тот факт, что в то время, как мы сидим на стабильной, новые фичи апробируются параллельно, пилятся инструменты, получается опыт, чтобы когда оно стабилизируется, можно было быстрее на него пересесть. Ждем больше завершения реализаций стандартов в инструментарии, т.к. они всегда запаздывают.
Здравствуйте, jamesq, Вы писали:
V>>1) Где в C++ нормальная рефлексия, свойства, события? J>Какая такая рефлексия в компилируемом языке? Вот ты для микроконтроллера прошивку пишешь, которая прожигается намертво в ПЗУ. Какая тут может быть рефлексия? Там и места-то нету в памяти под всю эту машинерию рефлексии (компилятор, и иже с ними).
Сам спросил, потом ограничил выбор конкретной архитектурой программы и сам ответил. Но в Qt рефлексия есть, и свойства есть, и события есть, там даже плагины с интерфейсами для них есть. Только вызовы реализованы не оптимально, хотя у C++ были способы сделать это лучше. Фактически добавляя свой генератор на C++ можно реализовать много что даже не прибегая к новым диалектам.
И между прочим как я и говорил начинаются рассуждения в стиле, когда одни говорят, нам нужно вот это, а другие говорят, нам это не надо. Хотя C++ как правило не заставляет использовать все возможности языка. Он не заставляет писать именно закрытые модификаторы доступа и так далее, люди сами это делают. Потом они сами пишут методы, они же функции-члены в C++, которые как-то пытаются с этим работать. И все иерархии выдумываются людьми. А потом бах, объектно-ориентированное программирование — катастрофа на триллион долларов.
А мои вопросы по сути игнорируют, полностью та секция была такой:
1) Где в C++ нормальная рефлексия, свойства, события?
2) И в целом где граница между языком и архитектурой приложений?
Когда делаешь программу для контроллера или ПЛК, то используешь определённую архитектуру программы. Архитектура это конструкция проходящая через всю программу, которой придерживается программист.
А дальше начинаются разные мнения.
1) Кто-то думает, что некий язык X удобен, это не обязательно C++, вообще любой и ему только не достаёт неких конструкций в спецификации, чтобы стало совсем хорошо.
2) Я же придерживаюсь мнения, что язык X изначально неудобен и ему недостаёт не конкретных конструкций, а способа вменяемой работы с этим языком.
Ведь из чего исходили программисты писавшие компиляторы. Давайте дадим читаемые имена ключевым словам, но эти имена оказались читаемы только англичанами. Потом разработчики стандартных и прочих библиотек так же создали алгоритмы и типы со своими именами. На основе конструкций языка придумывались конструкции пользователей до идиом, шаблонов проектирования и наконец архитектур.
И почему собственно так сложно работать с чужим кодом. Отчасти потому, что собственное представление о том, как нужно записывать эти алгоритмы отличается от чужого авторского.
Представление можно разделить на два вида:
1) Видимость (например видишь "if", "while", ..., а хочешь видеть "если", "пока", ..., видишь функцию "push_back", а хочешь видеть "добавить элемент в конец", то есть даже не перевод, с другой стороны японец предпочтёт "最後に要素を追加します" или как-то так, если верить гуглу).
2) Конструирование (просто разные представление о том, как записать свою конструкцию с помощью конструкций языка).
При этом видимость никак не меняет сути программы, а конструирование меняет, но и то и другое важно.
Теперь перейдём к следующему вопросу:
1) А почему в проекте используется C++11 или выше, а не C++03, а то и вовсе Python, C#, Java, да и вообще всё что угодно.
Можно спорить сколько угодно, типа каждый инструмент под свою задачу и тому подобное. Но объективно говоря кто-то и когда-то для конкретного проекта сделал этот выбор. И не потому, что что-то обязательно лучше подходило под задачу.
Давайте оставим этот спор о диалектах, например, я могу сказать, что просто C++ ISO/IEC 14882 это лучший выбор, 11-ый, 14-ый, 17-ый, да хоть 20-ый. Тогда начнутся споры о других языках. Но лучший или не лучший, кто-то всё равно примет решение, и потом на этом языке программирования и будут работать.
Фактически люди могли бы не дёргаться и оставаться на старом диалекте. А могли бы всё время переходить на новый. На мой взгляд проблему видимости и конструкций это слабо решает. Даже не так, кому-то решает, а лично для меня новые диалекты не решили абсолютно ничего.
Зато я вижу тенденцию пытаться быть модным, стильным, молодёжным и выпускать обновления для C++ каждые 3 года. То есть каждые 3 года готовтесь переписывать код, но "Я вам рефлексию не отдам. Потому что у вас документов нету!". После этого даже Apple со своими "революциями" выглядит вполне себе нормально.
Здравствуйте, jamesq, Вы писали:
V>>1) Где в C++ нормальная рефлексия, свойства, события? J>Какая такая рефлексия в компилируемом языке? Вот ты для микроконтроллера прошивку пишешь, которая прожигается намертво в ПЗУ. Какая тут может быть рефлексия?
Ну отдельные элементы типа проверки реального типа в dynamic_cast таки есть.
Нахождение в ПЗУ им не мешает.
J> Там и места-то нету в памяти под всю эту машинерию рефлексии (компилятор, и иже с ними).
Кто сказал, что для рефлексии нужен компилятор в рантайме?
Здравствуйте, cppguard, Вы писали:
C>Звучит так, словно очередное изменение это теория относительности, чтобы с ней нужно было разбираться. Про defensive programming слышали? Так вот это работает тогда, когда язык хорошо продуман. А когда возможности добавляются лишь бы добавить, то эта возможность исчезает. Хороший тому пример — JavaScript и PHP. Почему от них все плюются? Да потому что на определённом этапе языка в оба стали добавлять что-то, что ломает предыдущую логику, в итоге появились безобидные на первый взгляд конструкции, которые при ближайшем рассмотрении приносят много боли.
Нет, наоборот. Новые фичи в JS хорошие, правильные и полезные. А большинство проблем в унаследованных WTF, основанных, как правило, на нелогичных неявных преобразованиях типов, которые нельзя понять, можно только заучить.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, kaa.python, Вы писали:
KP>Ну да, может быть. А может и не быть же. Просто надо понимать что и для чего ты пишешь.
Ну, вот с EKA ты ведь знаком? Ты в Каспере вроде паботал?
Вот прикинь сейчас молодые джигиты заюзали в ней С++17. В результате, когда пришлось писать код для роутера, оказалось, что ЕКУ применять нельзя, так как для этого роутера доступен только довольно древний GCC не поддерживающий 17-х фич.
KP>Ну вот это странно, честно. Если это роутер, там скорее всего Linux и с большой вероятностью там можно и довольно современный C++ использовать. Даже на QNX вполне себе C++14 доступен.
Да, Линукс. Но давно отптченый клон. Заниматься портипрованием под него нового компилятора слешком дорого. Ну. и как бы проблемы с ресурсами там. Плюсы за собой тянут много либ. С — нет. Думаю еще было желание похардкорить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ну, вот с EKA ты ведь знаком? Ты в Каспере вроде паботал?
О да, я с этой библиотекой знаком, причём сильно ближе и глубже чем хотелось бы
Я просто кодовую базу переводил с C++03 на сборку C++11. Это было для Маков, но по факту всю кодовую базу KIS пришлось перелопатитть.
А вот ты откуда про неё знаешь? Ты в ЛК подался?
VD>Вот прикинь сейчас молодые джигиты заюзали в ней С++17. В результате, когда пришлось писать код для роутера, оказалось, что ЕКУ применять нельзя, так как для этого роутера доступен только довольно древний GCC не поддерживающий 17-х фич.
Вот поэтому я и говорю что от задач зависит. Если предполагается портирование кода на старые платформы, а в случае с ЛК это довольно вероятно, то лучше выше C++14, а то и C++11 для надёжности, не прыгать. Если же ты знаешь платформы которые надо поддерживать, то хоть GCC 10 с C++20 бери и всё будет хорошо. Мы, к примеру, так и делаем, просто у нас своя сборка Linux и железо собственное и единственный критерий для выбора компилятора это требования по безопасности для конкретного компонента.
VD>Да, Линукс. Но давно отптченый клон. Заниматься портипрованием под него нового компилятора слешком дорого. Ну. и как бы проблемы с ресурсами там. Плюсы за собой тянут много либ. С — нет. Думаю еще было желание похардкорить.
Я может не прав, но это звучит как "хотелось написать на Си". Это безусловно нормально, но найти что-либо живое и не поддерживающее C++11 надо ещё постараться.
Здравствуйте, kaa.python, Вы писали:
KP>А вот ты откуда про неё знаешь? Ты в ЛК подался?
Да.
KP>Вот поэтому я и говорю что от задач зависит. Если предполагается портирование кода на старые платформы, а в случае с ЛК это довольно вероятно, то лучше выше C++14, а то и C++11 для надёжности, не прыгать. Если же ты знаешь платформы которые надо поддерживать, то хоть GCC 10 с C++20 бери и всё будет хорошо. Мы, к примеру, так и делаем, просто у нас своя сборка Linux и железо собственное и единственный критерий для выбора компилятора это требования по безопасности для конкретного компонента.
Эта проблема появляется когда есть (нужна) переносимость на уровне кода. Для С++-библиотек это очень частое явление. По сему библиотечный код лучше делать совместимым со старыми версиями языка, но проверять и на новых компиляторах.
Эта проблема слабее выражена для байткоднутых языков/виртуальных машин. Но тоже присутствует. В том же ЛК, в мобильном СДК не хотят использовать Котлин, так как он может притащить лишнего. А до недавнего времени использовалась старая версия Явы.
KP>Я может не прав, но это звучит как "хотелось написать на Си". Это безусловно нормально, но найти что-либо живое и не поддерживающее C++11 надо ещё постараться.
Какой-то С++ там поддерживался, но из-за кучи нового кода в ЕКЕ ее применение было невозможно и нужно было вписаться в очень ограниченные требования по памяти и размеру бинарей. Кроме того то ли в тамошних плюсах, то ли из-за того, что компонент в ядре грузится нельзя было использовать исключения. А как ты понимаешь сейчас на них многое завязано. Ну, и конечно "хотелось написать на Си" тоже присутствовало. Но это было одним из аргументов, а не основным. Гуй (он нужен был переносимым) они написали на чем-то высокоуровневом. Вроде бы на Flutter-е.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Класс, лучшая компания в Мск
VD>Эта проблема появляется когда есть (нужна) переносимость на уровне кода. Для С++-библиотек это очень частое явление. По сему библиотечный код лучше делать совместимым со старыми версиями языка, но проверять и на новых компиляторах.
Такая совместимость нужна только в случае специфичного коробочного ПО, типа того что ЛК пишет, которое потенциально на дохлом роутере может понадобится запустить. За пределами этого узкого варианта использования, ты вообще самые последние версии компиляторов и стандарта языка легко используешь. К примеру взять тот же Alpine так популярный в AWS и пожалуйста, бери GCC 10 себе на здоровье и почти все фичи C++20 тебе доступны. Сложность с разработкой для ЛК в том, что они не в состоянии контролировать платформу на которой выполняется приложение. Для таких случаев и при наличии ожиданий что понадобится портировать под совсем экзотику твое утверждение верно. К примеру в том же Автодеске мы легко использовали C++17 т.к. знали что на экзотику такие тяжелые продукты не засунут и значит париться с обратной совместимостью кода не надо.
Именно поэтому я раньше писал, что заморочки с обратной совместимостью языков в компаниях типа FB и Google скорее всего связанны с проблемной кодовой базой. Они имеют 100% контроль над платформой и это единственная причина почему могла появиться библиотека типа https://abseil.io/
Здравствуйте, Ватакуси, Вы писали:
В>Чего тебе не понравилось в последних питонах?
На новом проекте заставили использовать систему типов. Теперь нужно 10 раз запустить проверку типов, чтобы убедиться, что всё type hints написал правильно. Только безопасным код это не делает от слова совсем.
Здравствуйте, cppguard, Вы писали:
C>На новом проекте заставили использовать систему типов. Теперь нужно 10 раз запустить проверку типов, чтобы убедиться, что всё type hints написал правильно. Только безопасным код это не делает от слова совсем.
— Типы в питоне в первую очередь для поддерживаемости кода, и в меньшей степени для типобезопасности
— Уровень проверки типов можно настроить — от "ничего не проверять" до "проверять как в статический языках"
— Проверки типов выполняются автоматически в IDE в фоновом режиме. Если и нужны дополнительные проверки, то обычно один раз перед пушем
