А еще для повышения привилегий есть отличная утилита командной строки - gsudo . Теперь можно запускать от имени админа только то, что действительно этого требует :)
Ну, кроме сложностей с изучением самих шаблонов у новичков (да и у старичков тоже, будем честны) возникают трудности с чтением простыней ошибок инстанциирования шаблонов. По идее, при широком распространении концептов ошибки станут гораздо понятнее, что тоже должно понизить порог входа...
Похоже, что зависит от степени запущенности проекта.
Повырубав кучу ворнингов заставить компиляться и работать не так уж сложно и долго. А потом да, постепенно эти ворнинги исправлять параллельно с разработкой в течение месяцев. Самое удивительное, что когда потом включаешь обратно эти трактуемые как ошибки предупреждения, оказывается, что они вообще-то были очень даже по делу, и фактически работа проводилась вовсе не ради галочки, а сделала продукт стабильнее и лучше.
Другими словами, при переходе на новый стандарт основные проблемы, кмк, возникают именно из-за более чувствительных к ошибкам и нарушению стандарта компиляторов, а отнюдь не прихоти.
Тяжелее всего должен быть переход C++98 на 11, поскольку в древнем C++ очень многие вещи делались абы как и с явным уб, без которого жить было невозможно в принципе(те же потоки)
Рискну предположить, что застряли не в embedded (где вполне можно писать так же, причем еще и практически zero-cost, так как операции над рейнджами очень хорошо инлайнятся и оптимизируются как по производительности, так и размеру исполняемого кода, то, в чем C++ реально хорош и почему все готовы терпеть медленную компиляцию), а в процедурном подходе и старой версии стандарта.
Современный подход, причем не только в C++, а почти во всех языках, подразумевает больший упор в функциональную парадигму: неизменяемые значения, широкое использование функций (в том числе анонимных), в частности в качестве аргументов и возвращаемых значений, отсутствие глобального состояния и декларативность. Привыкнув к этому, можно писать гораздо более надежные и читаемые программы как для микроконтроллеров, так и суперкомпьютеров.
Мультипарадигменный, как и большинство современных языков. Да, в идиоматическом C++ писать в чисто ООП стиле не принято и не особо-то эффективно, но формально C++ вполне себе ООП, равно как и процедурный, структурный, функциональный язык.
Проблема в том, что, когда раньше программист "решал использовать UB", он точно так же отстреливал ноги в промышленных масштабах, причем думая, что знает, что делает.
Создатели компиляторов ничего не считают, и уж тем более не действуют на зло программистам, а просто буквально следуют стандарту. UB - это логическая ошибка, отсутствие ограничения, делающее программу неоднозначной. То, что можно заметить при анализе на уровне компилятора - замечают, и выдают предупреждения. То, что нельзя - остается в программе миной замедленного действия.
Компиляторы же считают, что UB нет, не из-за какой-то особой вредности и обозленности их разработчиков на мир, а потому, что это допущение - естественный способ нормально скомпилировать программу, не пытаясь доказывать математические теоремы произвольной сложности. При допущении, что UB есть, компилятор превращается в совершенно другой продукт - статический анализатор кода, систему, разрабатываемую не менее талантливыми коллективами разработчиков, и по-прежнему имеющую ложно-положительные и ложно-отрицательные результаты.
Средства есть, но не на уровне языка, а на уровне отдельных и самостоятельных утилит, по сложности иногда вполне соразмерных с компилятором и занимающимися совсем другими задачами.
Это санитайзеры (ака динамические анализаторы), статические анализаторы, системы тестирования и т.д.
UB на то и UB, что синтаксически код совершенно корректен, и компилятору в общем случае просто не к чему придраться.
UB отлавливается при статическом анализе(который в грамотно настроенных проектах используется на всю катушку, ну и немного компилятором, как я подозреваю, при попытках оптимизации), динамическом (некоторые проверки навешивает на дебажный билд сам компилятор, некоторые реализованы в библиотеках, в том числе стандартной, остальное отслеживает санитайзер).
Огромная и сложная система статического контроля кода обеспечивает надежность, но разбивается о суровую действительность: примерно половина (и хорошо, если не больше) общепринятых библиотек написана на чистом C (из-за большей универсальности), вдобавок многие разработчики по-прежнему пишут на C++ в стиле "Си с классами", почти не пользуясь мощной системой типов, шаблонами, и умными указателями. Привет, undefined behavior...
Отличный мультипарадигменный язык, чертовски простой в освоении, легковесный(официальный) интерпретатор идеально подходит для встраивания и работает на всем, начиная от микроконтроллеров. Для интерпретируемого языка это чудо еще и работает весьма быстро.
Насколько я понимаю, на чистом Lua, от и до, большие системы проектируют довольно нечасто, зато как средство расширения нативных программ, написанных на том же C и C++ - применяется очень широко.
Справедливости ради, 32Гб + 1Тб памяти — это старшая модель на Интеле, ее цена — $2600, в то время как $1000 просят за девайс с 8Гб + 128Гб.
Так что честнее будет сравнивать цену младших моделей — $1000 vs $1300. У ARM версии есть даже уникальная фича, за которую (ИМХО) в принципе даже не жалко заплатить — 5G.
Ну, может, у них там чудовищный макаронный говнокод, и они боятся, что начинающие разработчики при виде такого разбегутся на условный UE, где примеры (гипотетически) более красивые? :)
Причем кмк это так же актуально и для опытных разработчиков, которые скорее тоже будут интересоваться именно кодом и интересными архитектурными решениями, и тоже могут разочароваться.
Если серьезно, я конечно не думаю что все настолько плохо, но не удивлюсь если действительно опасаются антирекламы.
На месте typename могло бы быть указано значение (Non-Type Template Argument), или имя другого ограничения(концепта). На месте concept - using, inline переменная, а то и вовсе объявление функции или типа.
C++ - очень гибкий язык, и за это приходится расплачиваться более сложным и не очень лаконичным синтаксисом.
С другой стороны, шаблонная магия как правило живет где-то в библиотеках, а прикладной код может быть вполне лаконичен.
В том-то и дело, что в C++ вместо динамической типизации при любой возможности стараются использовать статическую. И на этом поле язык действительно очень хорош.
Код некоторых страшных примеров из статьи во многих может упроститься до пары инструкций времени исполнения, либо и вовсе отработать во время компиляции(в зависимости от контекста вызова).
На самом деле, реальная реализация всего этого безобразия на реальном железе совершенно неважна, потому что переполнение знакового целого - undefined behavior, отсутствие важного для правильной работы программы ограничения.
Тот факт, что процессор хранит знаковые числа с дополнением до двойки - Вас не спасет. Преобразования с переполнением выливаются в отбрасывание компилятором условий, вызовов функций и тд (выше уже выложили пример), причем самое веселое - что теряются гарантии на правильную работу программы даже до момента вызова проблемного участка кода.
Можно быть хоть трижды знатоком физических архитектур и алгоритмов работы всех действующих компиляторов(что уже близко к невозможному, кмк), все, что это даст - лишь позволит писать программы, которые работают здесь и сейчас. Для написания действительно переносимого и безопасного кода нужно строго следовать документации на язык программирования, то есть стандарт, и не допускать UB. Это гораздо проще, чем изобретать способы решать созданные на ровном месте проблемы.
Проводник Windows 11 получит современный пользовательский интерфейс
А еще для повышения привилегий есть отличная утилита командной строки - gsudo . Теперь можно запускать от имени админа только то, что действительно этого требует :)
C++ по итогам 2022-го
Ну, кроме сложностей с изучением самих шаблонов у новичков (да и у старичков тоже, будем честны) возникают трудности с чтением простыней ошибок инстанциирования шаблонов. По идее, при широком распространении концептов ошибки станут гораздо понятнее, что тоже должно понизить порог входа...
Зачем писать на C++ в 2022 году?
Если Вам из деструкторов нужно кидать исключения, то у меня очень плохие новости об архитектуре проекта, который Вы пишете...
Зачем писать на C++ в 2022 году?
Похоже, что зависит от степени запущенности проекта.
Повырубав кучу ворнингов заставить компиляться и работать не так уж сложно и долго. А потом да, постепенно эти ворнинги исправлять параллельно с разработкой в течение месяцев. Самое удивительное, что когда потом включаешь обратно эти трактуемые как ошибки предупреждения, оказывается, что они вообще-то были очень даже по делу, и фактически работа проводилась вовсе не ради галочки, а сделала продукт стабильнее и лучше.
Другими словами, при переходе на новый стандарт основные проблемы, кмк, возникают именно из-за более чувствительных к ошибкам и нарушению стандарта компиляторов, а отнюдь не прихоти.
Тяжелее всего должен быть переход C++98 на 11, поскольку в древнем C++ очень многие вещи делались абы как и с явным уб, без которого жить было невозможно в принципе(те же потоки)
Зачем писать на C++ в 2022 году?
Рискну предположить, что застряли не в embedded (где вполне можно писать так же, причем еще и практически zero-cost, так как операции над рейнджами очень хорошо инлайнятся и оптимизируются как по производительности, так и размеру исполняемого кода, то, в чем C++ реально хорош и почему все готовы терпеть медленную компиляцию), а в процедурном подходе и старой версии стандарта.
Современный подход, причем не только в C++, а почти во всех языках, подразумевает больший упор в функциональную парадигму: неизменяемые значения, широкое использование функций (в том числе анонимных), в частности в качестве аргументов и возвращаемых значений, отсутствие глобального состояния и декларативность. Привыкнув к этому, можно писать гораздо более надежные и читаемые программы как для микроконтроллеров, так и суперкомпьютеров.
Зачем писать на C++ в 2022 году?
Мультипарадигменный, как и большинство современных языков. Да, в идиоматическом C++ писать в чисто ООП стиле не принято и не особо-то эффективно, но формально C++ вполне себе ООП, равно как и процедурный, структурный, функциональный язык.
АНБ США порекомендовало IT-компаниям отказаться от языков C и C++
Проблема в том, что, когда раньше программист "решал использовать UB", он точно так же отстреливал ноги в промышленных масштабах, причем думая, что знает, что делает.
Создатели компиляторов ничего не считают, и уж тем более не действуют на зло программистам, а просто буквально следуют стандарту. UB - это логическая ошибка, отсутствие ограничения, делающее программу неоднозначной. То, что можно заметить при анализе на уровне компилятора - замечают, и выдают предупреждения. То, что нельзя - остается в программе миной замедленного действия.
Компиляторы же считают, что UB нет, не из-за какой-то особой вредности и обозленности их разработчиков на мир, а потому, что это допущение - естественный способ нормально скомпилировать программу, не пытаясь доказывать математические теоремы произвольной сложности. При допущении, что UB есть, компилятор превращается в совершенно другой продукт - статический анализатор кода, систему, разрабатываемую не менее талантливыми коллективами разработчиков, и по-прежнему имеющую ложно-положительные и ложно-отрицательные результаты.
АНБ США порекомендовало IT-компаниям отказаться от языков C и C++
Средства есть, но не на уровне языка, а на уровне отдельных и самостоятельных утилит, по сложности иногда вполне соразмерных с компилятором и занимающимися совсем другими задачами.
Это санитайзеры (ака динамические анализаторы), статические анализаторы, системы тестирования и т.д.
АНБ США порекомендовало IT-компаниям отказаться от языков C и C++
UB на то и UB, что синтаксически код совершенно корректен, и компилятору в общем случае просто не к чему придраться.
UB отлавливается при статическом анализе(который в грамотно настроенных проектах используется на всю катушку, ну и немного компилятором, как я подозреваю, при попытках оптимизации), динамическом (некоторые проверки навешивает на дебажный билд сам компилятор, некоторые реализованы в библиотеках, в том числе стандартной, остальное отслеживает санитайзер).
АНБ США порекомендовало IT-компаниям отказаться от языков C и C++
Огромная и сложная система статического контроля кода обеспечивает надежность, но разбивается о суровую действительность: примерно половина (и хорошо, если не больше) общепринятых библиотек написана на чистом C (из-за большей универсальности), вдобавок многие разработчики по-прежнему пишут на C++ в стиле "Си с классами", почти не пользуясь мощной системой типов, шаблонами, и умными указателями. Привет, undefined behavior...
Есть ли жизнь без RTTI: пишем свой dynamic_cast
Можно, конечно! Или речь о каком-то другом variant?
IT для неайтишников: Куда исчезают программисты после 40 лет?
а чем Вам Lua не угодил?
Отличный мультипарадигменный язык, чертовски простой в освоении, легковесный(официальный) интерпретатор идеально подходит для встраивания и работает на всем, начиная от микроконтроллеров. Для интерпретируемого языка это чудо еще и работает весьма быстро.
Насколько я понимаю, на чистом Lua, от и до, большие системы проектируют довольно нечасто, зато как средство расширения нативных программ, написанных на том же C и C++ - применяется очень широко.
Microsoft представила планшет Surface Pro 9 на базе либо собственного процессора, либо Intel
Справедливости ради, 32Гб + 1Тб памяти — это старшая модель на Интеле, ее цена — $2600, в то время как $1000 просят за девайс с 8Гб + 128Гб.
Так что честнее будет сравнивать цену младших моделей — $1000 vs $1300. У ARM версии есть даже уникальная фича, за которую (ИМХО) в принципе даже не жалко заплатить — 5G.
Unity закрыла проект демо-игры Gigaya, которая должна была научить начинающих разработчиков создавать игры
Ну, может, у них там чудовищный макаронный говнокод, и они боятся, что начинающие разработчики при виде такого разбегутся на условный UE, где примеры (гипотетически) более красивые? :)
Причем кмк это так же актуально и для опытных разработчиков, которые скорее тоже будут интересоваться именно кодом и интересными архитектурными решениями, и тоже могут разочароваться.
Если серьезно, я конечно не думаю что все настолько плохо, но не удивлюсь если действительно опасаются антирекламы.
Упрощаем код с помощью if constexpr и концептов C++17/C++20
ой, это, кажется, не мне, а @Racheengel ? :)
Упрощаем код с помощью if constexpr и концептов C++17/C++20
В современных реалиях - обязательно.
На месте typename могло бы быть указано значение (Non-Type Template Argument), или имя другого ограничения(концепта).
На месте concept - using, inline переменная, а то и вовсе объявление функции или типа.
C++ - очень гибкий язык, и за это приходится расплачиваться более сложным и не очень лаконичным синтаксисом.
С другой стороны, шаблонная магия как правило живет где-то в библиотеках, а прикладной код может быть вполне лаконичен.
Упрощаем код с помощью if constexpr и концептов C++17/C++20
Можно даже ввести дополнительный концепт, и сделать код еще ближе к тому, что просят :)
Упрощаем код с помощью if constexpr и концептов C++17/C++20
Не совсем понял, что Вы имеете в виду.
Не расскажете чуть конкретнее, что именно не нравится и как, по-Вашему, эта проблема должна решаться без "сумерек рассудка"?
Упрощаем код с помощью if constexpr и концептов C++17/C++20
В том-то и дело, что в C++ вместо динамической типизации при любой возможности стараются использовать статическую. И на этом поле язык действительно очень хорош.
Код некоторых страшных примеров из статьи во многих может упроститься до пары инструкций времени исполнения, либо и вовсе отработать во время компиляции(в зависимости от контекста вызова).
C++. Унарный минус и беззнаковый тип
На самом деле, реальная реализация всего этого безобразия на реальном железе совершенно неважна, потому что переполнение знакового целого - undefined behavior, отсутствие важного для правильной работы программы ограничения.
Тот факт, что процессор хранит знаковые числа с дополнением до двойки - Вас не спасет. Преобразования с переполнением выливаются в отбрасывание компилятором условий, вызовов функций и тд (выше уже выложили пример), причем самое веселое - что теряются гарантии на правильную работу программы даже до момента вызова проблемного участка кода.
Можно быть хоть трижды знатоком физических архитектур и алгоритмов работы всех действующих компиляторов(что уже близко к невозможному, кмк), все, что это даст - лишь позволит писать программы, которые работают здесь и сейчас. Для написания действительно переносимого и безопасного кода нужно строго следовать документации на язык программирования, то есть стандарт, и не допускать UB. Это гораздо проще, чем изобретать способы решать созданные на ровном месте проблемы.