Комитет ISO по стандартизации языка C++ утвердил международный стандарт "C++20". Представленные в спецификации возможности, за исключением единичных случаев, поддерживаются в компиляторах GCC, Clang и Microsoft Visual C++. Поддерживающие C++20 стандартные библиотеки реализованы в рамках проекта Boost...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=53670
К C++40 многие разработчики уже не заметят как плавно стали brainfuckerами.
Язык уже настолько мутировал что для не посвящённого программиста из других языков будет выглядеть все как случайный набор символов...
Уже давно проводятся конкурсы по написанию максимально непонятного кода на c и c++, любителям стрелять себе в ногу не нужно ждать ещё 20 лет.
С другой стороны, почти на любом ЯП можно написать хорошо читаемый код.
http://ermak.cs.nstu.ru/cprog/html/у нас вот такой в НГТУ сайт был и остается по сей день - сам чёрт ногу сломит, всякое желание пропадало учить сишки, хех
>Си/Си++Скажи ему пусть определится или Си или Си плюс-плюс.
сиси плюс-плюс
Какая разница? Тогда уж UB и UB++
Ну кстати Романов - неплохой тип, хотя сайт кнчн тот ещё.По настоящему желание отпадало, когда вместо проги семак-другой-третий требовалось рисовать всевозможные диаграммы и барахло вроде Пролога..
нгту +
Содержимое сайта весьма и весьма достойное.
> у нас вот такой в НГТУ сайт был и остается по сей деньНе ври.
cs.nstu.ru перенаправляет на avtf.nstu.ru
Что ты как-то смог в недрах сайта откопать архаичную "пасхалку" не значит, что "сайт остается по сей день"
не знаю, откуда ты ходишь по сети, но с Нск с нескольких провайдеров ссылка открывается так, как я написал
А так причём тут вообще...И такое есть
http://ermak.cs.nstu.ru/~romanow/solus_rex/index.htmОпеннетчикам понравится... Кто такой Ермак не знаю.
я просто примеры кода показать...А Ермак - казак такой знаменитый хех
> я просто примеры кода показать...Ну так то же АВТФ - там что-то уровня ПТУ.
А академическое это ан приматов - там тебе за чуть что не так, так сразу по башке томиком Кнута дадут.
Ещё и компилятор заставят писать, что бы знал, как происходит, а не так писал калякал...
отличный сайт, спасибо за ссылку.
А причём тут С?
Не надо присовокуплять Си к этой @#$%$^. Си умно спроектированный лаконичный и очень прагматичный язык.
Для "непосвященного" тарабарщиной будут выглядеть только особая магия на template'ах (где смесь изи SFINAE и прочего constexpr). Все остальное интуитивно понятно.
При том SFINAE тарабарщина с C++20 заменяется Концептами, которые более читаемые. Так что все конструкции C++ должны быть понятны программисту другого высокоуровнего языка программирования (в отличие от большинства конструкций некоторых эзотерических языков).
Представления комитета C++:
> SFINAE тарабарщина с C++20 заменяется Концептами, которые более читаемыеРеальность: к тарабарщине SFINAE добавляется ещё и тарабарщина концептов.
Одна тарабарщина заменилась другой. Мало нужной для прикладных программистов. Разработчики стандарта стали делать стандарт чисто для себя
> Прекращена поддержка большинства операций с переменными, объявленными с ключевым словом volatile, в том числе запрещены операции "++" и "--" со стандартными типамии это?
При этом по-прежнему ругать за это принято perl :)
Хотя он, объективности ради, в среднем уже давно понятнее современного C++
Это справедливо для любого языка, для которого разрабы боятся сломать совместимость и послать на йух всех пользователей устаревших несовместимых версий, объявив их недолюдьми. В питоне тоже теперь стремаются, после того как выянилось, что макакам лень мигрировать код, они лучше старое говно по типу python 2 жрать будут, даже сейчас, когда 2 официально объявлен мёртвым, у очень многих проектов есть требования совместимости с python 2. Так что питона 4 не будет, и его постигнет участь всего остального стабильного говномейнстрима. А жаль.
Не побоялись и создали D. Где он сейчас...
Харэ ныть. Если не осилятор сиди и ржавей дальше вместе с Rust. У нормальных людей всё красиво логично и понятно. А все конструкции тебя никто использовать вообще не заставляет.Твой рас вообще читать не возможно.
Язык настолько мутировал, что он не особо радует даже С++ стандарта 11 и 17. Всё дальше от прикладных программистов, какой то междусобойчик для разработчиков стандартов.
В этом куске говна до сих пор нормально не сделаны индексы для многомерных динамических массивов. Чтобы без извращений. Сколько стандартов, но до сих пор не удосужились.
> Основные особенности C++20А что, модули больше не основная особенность?
Пока на них основная масса либ перейдет, уже C++32 выйдет :(
CMake не поддерживает - значит нет.
мляяяяя, хочу обратно в 1989 год, когда плюсы были простым и понятным языком
Не обязательно так далеко, достаточно просто в до-C++11 времена.
Что вам мешает писать код, ограничиваясь старыми возможностями? А многие из нововведений c++-профессионалы долго ждали.
Как же они долго ждут динамической типизации :)
В компилируемом языке?
в c# dynamic есть. Вижу крайне редко, чтобы кто-то пользовался
С шарп компилируемый язык!? Издеваешься чтоли? То что является кодом для виртуальной машины - компиляцией называться не может. Это интерпретатор.
Для тех кто в танке.
> Для тех кто в танке.забыли про рантайм, а шаблоны в ц++ что это?
>> Для тех кто в танке.
> забыли про рантайм, а шаблоны в ц++ что это?Это не аналог Си шарп и Java
> Это не аналог Си шарп и Javaне С#, не Java - не исполняют программу читая построчно исходный код (ака интерпретация)
Вопрос не в этом.
Сможете запустить прогу на Java, без самой явы? На компилируемом языке сам компилятор не нужен ля запуска.
вопрос в том, что ты придумал себе определение и квакаешь.Ознакосься, для начала, с википедией https://ru.wikipedia.org/wiki/%D0%9A%D0%...
> Ознакосься, для начала, с википедией https://ru.wikipedia.org/wiki/%D0%9A%D0%...продублирую и вам "моё" определение
В исполнение инструкций тем же ЦП это что? Зачем путать понятия процесса исполнения с процессом подготовки к исполнению? Интерпретация - это процесс исполнения, компиляция - процесс подготовки к исполнению. Отсюда сам по себе исходный код джава прогрыммы не готов к исполнению, а вот тот же питоновский код - готов к исполнению посредством его интерпретации. И говоря о ЯП - говорят об иго исходном коде, а не промежуточных состояниях (байткодах, биткодах и тд).
> вопрос в том, что ты придумал себе определение и квакаешь.
ква, ква и не вижу от вас опровержения истинности моих определений.
>Сможете запустить прогу на Java, без самой явы?Во первых, если отвечать на твой, немного дебильный вопрос, то да без Явы программу на Яве не запустишь.
Точно так же как не запустишь программу на С++ без соответствующего компилятора.И то что компилятор Явы компилирует в инструкции виртуальной машины Явы не делает его менее компилятором чем clang, который компилирует в LLVM IL.
>> Это не аналог Си шарп и Java
> не С#, не Java - не исполняют программу читая построчно исходный код
> (ака интерпретация)А выполнение ПРОМЕЖУТОЧНОГО кода ПОБАЙТОВО виртуальной машиной это не интерпретация?
НЕТ.
> А выполнение ПРОМЕЖУТОЧНОГО кода ПОБАЙТОВО виртуальной машиной это не интерпретация?В исполнение инструкций тем же ЦП это что? Зачем путать понятия процесса исполнения с процессом подготовки к исполнению? Интерпретация - это процесс исполнения, компиляция - процесс подготовки к исполнению. Отсюда сам по себе исходный код джава прогрыммы не готов к исполнению, а вот тот же питоновский код - готов к исполнению посредством его интерпретации. И говоря о ЯП - говорят об иго исходном коде, а не промежуточных состояниях (байткодах, биткодах и тд).
Там между сциллой и харибдой. JIT, который на ходу транслирует промежуточное представление в то, что исполнит конкретный проц.
Шаблоны компилятся в машинный код
> Шаблоны компилятся в машинный кодкогда я упомянул шаблоны, не шла речь о компиляциях и тд., речь изначально шла о типизации, и спрашиваю, что есть шаблоны в ц++ с точки зрения типизации?
>С шарп компилируемый язык!?Вики утверждает что стандарт на язык придусматривает и возможность компилируемого варианта создания приложения.По крайне мере в LLVM и Mono такие возможность предостовляют для некоторых платформ,правда разиер от 80 мгб приложения ....некого не удивит сейчас простой калькулятор столько же весит.
>>С шарп компилируемый язык!?
> Вики утверждает что стандарт на язык придусматривает и возможность компилируемого варианта
> создания приложения.По крайне мере в LLVM и Mono такие возможность предостовляют
> для некоторых платформ,правда разиер от 80 мгб приложения ....некого не
> удивит сейчас простой калькулятор столько же весит.Что чушь, а не компиляция. Включение в состав приложения виртуальной машины в промежуточном коде LLVM. А суть остается той-же. Интерпретация промежуточного кода при выполнении. Компилированные приложения не нуждаются в дополнительных средствах выполнения. Код готов для выполнения на процессоре целевой платформы.
А LLVM это компилятор уровня исполнения в данном случае. C шарп это инвалид, который при первом запуске транслирует промежуточный код своей виртуальной машины посредством LLVM в код целевой платформы, а потом выполняет интерпретацию промежуточного кода самого приложения.И я бы тебе настоятельно рекомендовал изучать технические спецификации и документацию прежде чем это приводить в пример, а не читать википедию во всем что касается программирования и языков программирования.
>А суть остается той-же.Хорошо а что там с mono,старых версий ?Я помню по диску LinuxFormat -ряд приложений статически скомпилировано без всякой виртуальных машин....
Правда там модель памяти и безопасности была unsafe (если в терминологии не ошибаюсь).....Все статически скомпилировано под определенную платформу, правда подало как бы не чаще ,в качестве графической обертки использовался GTK# .
В танке тут ты.Любые ООП языки не компилируются в машинных код. Нету в компьютерах никаких классов (там структуры), событий (там конечные автоматы) и т.д. "Компиляторы" ООП языков состоят из двух частей. Сначала они генерируют промежуточный байткод, переделывая объяекты, шаблоны и прочий неестественное для железа синтаксический сахар внутрь структурного байткода. Далее есть варианты
1. Гонять байткод как есть внутри виртуальной машины
2. Компилирровать налету в зависимости от имеющегося рантайма
3. Компилировать нативно.С++ отличается от Java и С# тем, что С++ не имеет никакой стандартизации байткода, несовместим сам собой в рамках платформы при смене компилятора даже в рамках одной платформы, а кроссплатформенные библиотеки на С++ это Ад и Израиль. В остальном это то же самое.
Ничего не мешает скомпилировать IL, который нагенерил .NET в машинный код. Были среды для этого. Та же Unity (игровой движок) это делала сто лет назад. У самого MS есть .NET Native https://docs.microsoft.com/en-us/dotnet/framework/net-native/ Оно пока только с таргетом под UWP, но обещают расширить количество платформ в будущем.
В MSVC, кстати, С1-компилятор можно заменить на clang, чтобы вместо LLVM генерировался нативный код.
Интерпретатор - компилятор... тьфу. Это форум в Интернете, а не контрольная по информатике. Вон есть Python. Тоже такой ООП-язык. И вон он CPython, который работает так же как .NET по умолчанию. И есть PyPy который тебе и в нативный код тебе соберёт.
Причем тут язык-то?!
>[оверквотинг удален]
> лет назад. У самого MS есть .NET Native https://docs.microsoft.com/en-us/dotnet/framework/net-native/
> Оно пока только с таргетом под UWP, но обещают расширить количество
> платформ в будущем.
> В MSVC, кстати, С1-компилятор можно заменить на clang, чтобы вместо LLVM генерировался
> нативный код.
> Интерпретатор - компилятор... тьфу. Это форум в Интернете, а не контрольная по
> информатике. Вон есть Python. Тоже такой ООП-язык. И вон он CPython,
> который работает так же как .NET по умолчанию. И есть PyPy
> который тебе и в нативный код тебе соберёт.
> Причем тут язык-то?!Ты прав относительно JAVA, C шарп.
А вот относительно C++ - полная чушь хоть он также ООП, у него в принципе нет байткода/промежуточного кода, а тем более никакой стандартизации, так же как и в C. Компилятор рожает обьектный файл, который потом линкуется динамически/статически. LLVМ в расчет не берем, к языку программирования в своей сути он отношения не имеет.
То что касается MS - даже комментировать не буду. Даже если с байткодными граблями код не переносим между различными платформами - тьфу на него еще раз.
Если грызть кактус то явно не от Майкрософт.
> А вот относительно C++ - полная чушь хоть он также ООП, у него в принципе нет байткода/промежуточного кода, а тем более никакой стандартизации, так же как и в C.Мосье теоретик, как я посмотрю...
То что вам большинство компиляторов (кроме clang) не показало промежуточное представление вовсе не значит, что они его не формировали. Они сначала приводят С++ в процедурный вариант, а потом компилируют. Подобный подход как раз сильно отличается от языка С. А что касается стандартизации, ну опять глупости. Возьмите либу на С++ и скомпилируйте её на интеловском компиляторе возьмите программу и скомпилируйте ее на g++. Попробуйте подключить одно к другому на бинарном уровне. Сравните с языком С и найдите отличие.
> Даже если с байткодными граблями код не переносим между различными платформами - тьфу на него еще раз.
И опять мосье теоретик. Все там переносимо, пока вы за пределы байткода не вырулите. Если библиотека не входящая в .NET Core требует нативную библиотеку или привязана к ядру, то это не кроссплатформенная библиотека. Тот же WPF требует DirectX, а он давно часть ядра. Это не только MS и .NET касается, это везде так.
> В компилируемом языке?не буду холиварить на эту тему, задам вопрос иначе, язык в котором есть рантайм, динамическая типизация возможна или нет?
А чего ждать собственно?
Все кому надо было, давно нагородили собственные аллокаторы.
Иногда код надо еще и читать, и уже читаемый код может быть написан с применением "нововведений"
"Новведения" позволяют избегать накруток этих "нововведений" сверху-сбоку языка самими программистами.
Из-за чего язык становится непростым и непонятным, об этом было исходное сообщение
Возвращаться в 89 не надо, ведь и сегодня ещё есть ламповая сишечка
В компании с GObject?
Ну, там ООП на уровне C++, только синтаксис корявее. Другое дело, что в C++ ООП не сказать что образцовое :)
где ООП образцовое?
В народе поговаривают что в Objective-C, но не прижился
> В народе поговаривают что в Objective-C, но не прижилсяЭто у того, у которого неймспейсы втюхали в имена классов?
Пойду проблююсь...
> где ООП образцовое?Очевидно, что в праматери всех и вся - Smalltalk.
Тогда пиши на Rust
Действительно, в нём же всё очень понятно и на него огромное количество вакансий </sarcasm>
Имхо, таки понятней, чем на свеженьких плюсах или жабе
Видел вакансию с++ и/или Rust - 450k деревянных
Обещяю вам 800k деревянных :-)
А если допустим писать на С++11, то можно ли будет собрать софт под современные ОС? И можно ли будет собрать софт на С++11 под современную ОС через лет 10?
Да и да
Лучше минимум 14. Уже не все либы поддерживают C++ ниже 14. Плюс 14 более вкусные лямбды
В идеале - минимум 17, как Qt 6
Правило опытного админа: "не тяни в рот каждую новую блестяшку".
Правило зелёного разработчика: "ой, блестяшечки!!1".Как вы мне дороги...
> Правило опытного админа: "не тяни в рот каждую новую блестяшку".
> Правило зелёного разработчика: "ой, блестяшечки!!1".
> Как вы мне дороги...Именно поэтому, Михаил, ваша команда и притянула новую блестяшку (systemd) в свой дистрибутив, дефолтом, хотя прежний вариант очень хорошо работал, причём как притянули?!... освежите пожалуйста в памяти!
И судя по тому, какое сейчас положение вещей, то воз будет ехать по заданной колее, "Just as planned".Вы нам тоже дороги, хотя вот, за державу обидно!
Правило опытного разработчика: "блестяшки желательно с аппетитом рассасывать, изучать, тестировать и постепенно внедрять, если достаточно притягательно блестит"На текущий момент блестяшка - C++20. С ним надо аккуратно, есть пока даже не до конца реализован.
А вот C++17 - уже актуальный для использования стандарт, меньше 14 не имеет смысла в новых/актуальных проектах, и во многих юзкейсах просто неудобно.
Осторожнее, у него сейчас начнёт подгорать, ведь его любимый lcc до сих пор не научился C++17.
Исходники ОСи теперь не скомпилятся ?
Научился уже http://www.mcst.ru/lcc.
Научился, ага. C±17, ржунимагу.
> Научился, ага. C±17, ржунимагу.Ну ржать-то можешь сколь угодно, но тем не менее работа идёт и код компилируется. ± - это точно atomic-и GCC-extы какие-нибудь. Что там ещё не хватает, спроси сам, у него (https://www.linux.org.ru/people/alexanius/profile), например. Я точно знаю, что Алексей работает непосредственно над компилятором lcc.
Да чего спрашивать? Как будто я сам мало с этим говном дела имел… Заявляют совместимость с GCC 5-летней давности, по факту и её нет, даром что заголовки оттуда натырили.
Можно и С++ 98 использовать и да оно соберется... Но зачем ?.
Есть даже специальные библиотеки, которые переносят новые возможности стандартной библиотеки на старые стандарты языка.
>И можно ли будет собрать софт на С++11 под современную ОС через лет 10?Если не выкинут опцию -std=c++11 или -std=gnu++11.
> если допустим писать на С++11, то можно ли будет собрать софт под современные ОС?avxsynth под debian-buster не собирался (нужны патчи), а в ubuntu-xenial норм. Как раз какие-то конструкции стали запрещены.
трактуется как ошибка. и переписать сложный build/mаkefile большого проекта та еще задача... те тупо свежий gcc не соберет ничего из времен ну допустим gcc 2.95 без танцев с бубном.
Да, да. Без работы с пмятью, статического анализа, итераторов, стандартных колекций, модулей и вообще без всего. ДЛя этого есть С.
Для с++ нужно прочитать 2-3 книги и посидесть с примерами... иначе да... все "сложнанипанятна" так-то многие старые вещи стараются не использовать, например с-шные масивы - они конечно есть, но std::array<> лучше (с концептами - еще лучше).
Мне не хватает только метаклассов, но они еще сырые, надеемся на 23-й год. Такое кол-во хаков и макросов с автогенераторами можно будет объявить легаси... ух.
В C RAII нет. Вот был бы язык как C только с RAII, а так призодится с C++ мучиться :-)
Кто мешает использовать концепцию RAII в С
Видимо, невозможность это сделать красиво и читаемо по стандарту и нежелание использовать гнутые расширения
>мляяяяя, хочу обратно в 1989 год, когда плюсы были простым и понятным языкомПлюсы никогда не были простым и понятным языком.
Чушь полнейшая, плюсы до стандарта 11 года(или 0х) - вообще неюзабельны.
Ну хотя бы С++ 11 и всё. Горшочек не вари.
> Добавлены "концепции"А когда наконец добавят концепцию KISS?
Эту концепцию должен применять и разработчик ПО, никто её за вас не применит
если нужен кисс пиши на си )
Мои поздравления коллегам-плюсовикам!
Спейсшип добавили наконец, лол.
А так да, множество расширений, которые уже активно использовались, наконец-то стандарт.
концепты выглядят интересно
Вагон дыр закрывают в шаблонах. Теперь в правильно написанный шаблон нельзя запихнуть то что в нем не должно быть - компилятор не даст.
Ну теперь любители прихать куда-либо что-либо недолжное в нем быть - взвоют.. Сишники, где вы??
Шаблоны, вообще, зло. Write only. Спустя некоторое время даже сам автор перестает понимать, что делается в его шаблоне.)))
Дырени наличествуют?
Конечно, это же C++, он весь состоит из UB
Мдаа, уж. Как самокритично...
Это ж С++, всё зависит от прокладки… точнее - от прокладок.
Добавили новых.
Ура! Улучшили язык, на котором написана треть повседневного софтаМои поздравления всем C++никам! Вы молодцы, на вас всё держится
>Вы молодцы, на вас всё держитсяСпасибо. Еще я могу на Хаскеле.
нет, спасибо, на хаскеле не надо.
> нет, спасибо, на хаскеле не надо.Хорошо, тогда я буду продолжать радовать всех прогами на С++.
> Вы молодцы, на вас всё держитсяНадо говорить «вы все красавцы!»
В с++ каждый фреймворк все ещё изобретает строки или спустя 20 лет все же перешли на std::string?
После 11 плюсов многие компании отказались от кастомных строк в пользу std::string
Но тот же QString всё ещё удобнее и функциональнее
Т.е. всё ещё велосипедят...
Стандартные классы в стл вообще довольно куцые
std::string - это боль C++ и один из самых худших дизайнов класса (детали смотри у Саттера).
А сами по себе "строки" - это тоже боль и тормоза и зоопарк видов строк (без разницы в каком языке).
Поэтому - неудивительно что "изобретали". Что сейчас - не знаю.
Изобретатели потому что почти 20 лет лет небыло строк никаких, только массивы из символов, а потом переходить не хотели.
Ни в java, ни в js, ни даже в Паскале проблем со строками небыло.
std вся сплошная боль по сравнению со стандартными библиотеками любых других современных языков. Бред наркомана.
строки уже constexpr, а ты их всё ещё изобретаешь. *бать ты застрял в прошлом, братюнь.
Сейчас нет необходимости, это было во времена C++98/03. Теперь разве что свои аллокаторы иногда изобретают.
в чем плохо создать свой класс обертка и дополнить его своими методами ?
В С++ до сих пор индексы нормально записываемые не изобрели для многомерных динамических массивов. Чтоб без извращений
Он всё ещё строгое надмножестао с++? Или всё?
Ну судя по тому что выкинули volatile, уже скорее нет.
Но мне кажется это и к лучшему
> выкинули volatileтак и не успел понять зачем он был нужен
Например, чтоб "бить по рукам" оптимизатор в хитрых низкоуровневых моментах. Иногда надо чтоб код делал ровно то что написано. Буквально. Без сюрпризов и самодеятельности (а в ассемблер уходить лень ради какой-то мелочи, да и переносимость хочется).
Может для аналогичного теперь есть какая-нибудь очередная новая синтаксическая конструкция...
>"бить по рукам" оптимизатор в хитрых низкоуровневых моментахUB-driven development?
Для разного рода embedded'щины.
Ну вот есть у нас простенький микроконтроллер, на нем куча разных прерываний вылезает, во всех переменные могут поменяться, а без volatile - компилятор, который вообще не знает про прерывания, так соптимизирует что из переменной будет читаться одно и тоже.
Для того чтобы сказать компилятору что это область памяти (переменная) особенная и может измениться в любой момент и она тебе (компилятору) не подконтрольна, так что не нужно производить над ней оптимизации. Так же, компилятор, на некоторых платформах, вставляет instruction fans (компилятор - не перемешивай порядок операций над этой областью) и cpu fans (процессор - выполняй инструкции в том порядке в котором они написаны, а не перемешивай в угоду производительности ибо есть side эффекты). Применяется когда ты работаешь с регистрами CPU, внешними устройствами, многопоточность (google: Scott Meyers Singleton, как самая известная мне иллюстрация проблемы) и другой "особенной" памятью.
Его не выкинули, просто теперь вместо 'PORTA &= 0xF0' нужно писать 'PORTA = PORTA & 0xF0', где PORTA это '#define PORTA (*(volatile uint8_t*)(0xBEEF))'.
Смысл этого изменения в том, что некоторые люди думали что операции над volatile атомарные, и пытались использовать его вместо std::atomic, с соответствующим результатом.
А теперь явно видно, что запись и чтение volatile это разные операции.
Взял и утрамбовал бифа. Люди думали - слабовато, надо так - человечество считало что volatile - это atimic, но потом я прочитал ман пагу и всех спас..
Не выкинули, но настоятельно советуют его использовать только по назначению - при прямой работе с хардварью. Что правильно - для всяких там синхронизаций надо использовать средства стандартные библиотеки, а не ручками спинлоки крутить.
чтобы ручками спинлоки крутить есть std::atomic если надо
Давно нет.
Или вы не верите в автокомпилит ?
Особую пикантность новости придает то, что модули, которые все так ждали, ни одним из перечисленных компиляторов не поддерживаются.
clang & msvc экспериментально давно поддерживают модули.
Может формально какими-то и поддерживаются, только толку пока мало. STL-то пока совсем не в модулях.
А этого и не было в стандарте пока. Такие дела.
Ничёси! Летающая тарелка прям как в Perl'е!
Любого кто скажет что язык Си является подмножеством языка Си плюс-плюс - сразу бить в морду.
мамин суп покушали уже? Боец вы наш интернетовский.
Язык Си является подмножеством языка C++.Я сказал, а теперь ударь меня, детка.
А что нет ? Вполне можно программировать в гибридном стиле, на этаком суржике из С++ и С.))) Любить printf и прочее)))
Dlang лучше.
Nim лучше.
Хаскель наше всё!
Фу. Только F#, только дотнет, только молодость, только Мытищи, только хардкор!
Только F*
Только Oberon/Scala
Нее, Obj-C круче
.. и, кроме шуток, код выглядит ощутимо приятней и документированней( когда глаза привыкнут к тому обилию квадратных скобок кнчн )
Ну а чем квадратные скобки принципиально хуже фигурных?
Ничем
[[[но поначалу] бывает ] непривычно:[такое обилие:их ]]Хотя в целом и концепция с передачей сообщений там была весьма интересна
В бездну скобочки! Begin-end - сила!
> Нее, Obj-C кручеПосле появления свифта забыл как страшный сон к счастью. Юзаю только если что-нибудь плюсовое надо обернуть.
> код выглядит ощутимо приятней и документированнейЭто заслуга многословной стандартной библиотеки, что не стали в три символа упихивать всякие std_make_shared_unique_ptr.
> После появления свифта забыл как страшный сон к счастью. Юзаю только если
> что-нибудь плюсовое надо обернуть.У свифта, насколько помню, поддержка норм работы с т.н статическими либами обычно не очень.
Особенно, если свифтовые библиотеки распространяются в скомпиленном виде, без исходников и как т.н динамические.
> Это заслуга многословной стандартной библиотеки, что не стали в три символа упихивать
> всякие std_make_shared_unique_ptr.Даже не совсем в этом дело, там своеобразный подход к именованию аргументов функций( можно передавать их читабельные имена помимо "внутренних" названий применяемых внутри конкретной функции или метода, при наличии которых нередко даже документации не требуется ):
На сях:
объект.метод( 1, 2, "ололо" )На обдж-сях:
[объект какой-тоМетодДляЕдиницы:1 читаемое_название_второго_аргумента:2 читаемое_название_третьего_аргумента:@"ололо" ]Ну и отправка сообщения с аргументами, а не просто вызов какого-то куска кода, тоже таки весьма радовал.
В некоторых случаях это позволяло без проблем и костылей получить весьма устойчивый к изменению апи библиотек код( т.е рабочий, притом, на нескольких их вариантах ).
Может Nim и хорош, но у D знакомый C-подобный синтаксис.
Пользуетесь D? Чем привлекает, нравится?
Когда за синтаксисом кода не видно логики программы, это плохо. Всё дальше уходят от ключевой особенности Си - простоты. Хотя, как уже намекнул коллега выше, никто не мешает не пользоваться.
Хорошо что в C++ это не так, как в вашем любимом языке. С каждым релизом становится всё проще писать C++ код
>С каждым релизом становится всё проще писать C++ кодThis is what c++ programmers actually believe!
То ли дело любой другой язык програмирования:public static void NotNull < T > (T argument,
[CallerArgumentExpression("argument")] string argumentExpression = null)
where T: class {
if (argument == null) throw new ArgumentNullException(paramName: argumentExpression);
}
Уж явно читаемей, чем код на джаве, который позиционируется как копроративный язык для самых маленьких.
Для полного познания дзена рекомендую открыть любой коммунити код у гугла или джет-брейнс.
>джаве, который позиционируется как копроративный язык для самых маленькихС Go спутали.
На джаве все вполне читаемо. Многословно, но это другая проблема.
public static void NotNull < T > (T argument,
[CallerArgumentExpression("argument")] string argumentExpression = null)
where T: class {
if (argument == null) throw new ArgumentNullException(paramName: argumentExpression);
}
Это вообще что за язык ^
Swift?
C#
generic function Min<T>(const A, B: T): T;
begin
if A < B then Result := A else Result := B;
end;
> С каждым релизом становится всё проще писать C++ код…и всё сложнее — понимать его.
> никто не мешает не пользоватьсямешать-то не мешает, но если в 2020 писать код на С++98 или С++03 (последние стандарты, с которыми я имел дело), смотреть будут странно.
И опять же всю эту мутотень один хрен изучать, потому что какой-нибудь Вася Пупкин будет-таки пихать 17 или даже 20 стандарт. Я вот в одном коде увидел эти лямбды и нихрена не понял, что там написано.
Как же хорошо, что я давно соскочил с этого монстра...
Зато в ругих языках лямбды предельно просто понять, и их синтаксис загуглить </sarcasm>
В Erlang, например, все элементарно:
fun (Arg) ->
мои любимые в .net: (x, y) => x + yтак же в расте: |x, y| x + y
> мои любимые в .net: (x, y) => x + yГлавное всегда уточнять, а то подумают что ты JSник (1 в 1 такой же синтаксис)
> 1 в 1 такой же синтаксисВы не понимаете! Это - другое !!111
Зараза, отправился случайно.fun(Arg) ->
some code
endВсе просто и понятно.
и даже в Расте ламбда определяется проще, чем в плюсах.
Почему "даже"?) Вообще, C++20 всё больше мотивирует изучать Хруст
Ну так я так и сделал. Посмотрел на стандарт С++17 (а там 2000 страниц) и решил, что ну его нафиг. Вспомнил еще все заморочки ООП с паттернами и прочей хренотой и решил, что лучше уж я выучу Rust, который оказался очень даже неплохим языком. И даже местами похож на Erlang.
Это лишь потому, что Rust пока не успел развиться. Но с каждым релизом туда будут досыпать и досыпать синтаксического сахара и прочих наворотов, так что Rust-2030 тоже обзаведётся 2000-страничной краткой спецификацией, без которой там вообще хрен что поймёшь.
> Rust-2030 тоже обзаведётся 2000-страничной краткой спецификацией, без которой там вообще хрен что поймёшьда пофиг. На наш век хватит незамусоренного Раста, а там может что другое появится.
Ну давай начнем с того, что сам язык (С++20) описан на 475 страницах, а остальное - stl и cstdlib. У С# - 531 а сколько страниц описания у .NET мне страшно представить. У Intel - Software Developer Manuals на 5к страниц и что дальше? Пожалуйста, воздержись от написания бреда и откровенной х...ерунды в интернетах о С/C++, так рождаются странные слухи и бестолковые легенды об этом языке, которые не отражают реальное положение дел.
> воздержись от написания бреда и откровенной х...ерунды в интернетах о С/C++, так рождаются странные слухи и бестолковые легенды об этом языке, которые не отражают реальное положение делДавай начнем с того, что про горячо уважаемый мной С я не писал вообще ничего.
А закончим вопросом: кто ты такой, чтобы диктовать мне что писать, а что нет? Я выражаю свое мнение, ты можешь только соглашаться или не соглашаться с ним, на что мне, в общем-то, наплевать.
Что, слухи настолько страшны, что могут уничтожить С++?
Мне нравился С++98 и С++03 (последние стандарты, на которых я писал), в С++11, насколько я знаю, есть интересные штуки типа auto. Но добавление излишней сложности - вот то, что отталкивает от языка, а не какие-то слухи в интернетах.
В Oberon-family языках с объемами стандартов все хорошо.> Разработка семейства языков ALGOL — Pascal — Modula-2 — Oberon — Oberon-2 — Component Pascal отмечена редукцией сложности синтаксиса языка. Полный синтаксис языка Оберон-2 описан всего в 33 предложениях по расширенной форме Бэкуса — Наура
но вот это же вот: [=]() { return n; }
это пипец. У меня первый вопрос был: "А что это за = в квадратных скобках и нафига оно нужно?"
У лямбды ключего свойство — область видимости переменных внутри. Очевидно что символ равно какое-то отношение к этому имеет.
не всем это очевидно. В языках с "более простым и понятным" синтаксисом может не быть возможности управлять областью видимости переменных, а значит те, кто на них пишут уже привыкли не думать об этом
Языки с "более простым и понятным" синтаксисом минимум в несколько раз тормознее плюсов
ну мы-то про синтаксис лямбд, зачем тему переводишь?
>У меня первый вопрос был: "А что это за = в квадратных скобках и нафига оно нужно?"Захват по значению. [&] - захват по ссылке.
В лиспе тоже просто: (lambda (arg) body).
Других языков не знаю.
Ну и нахрена такие сложности в плюсах?
ну какие там сложности? я хоть и знаком с языком только по книжке страуструпа, но ничего сложного в лямдбах крестов не вижу
https://en.cppreference.com/w/cpp/language/lambda
А теперь представьте, что последний раз вы писали на плюсах, когда там еще этой пакости не было. И тут вам попался вот такой код:
return {
[](take_atom) -> result<taken_atom, bool> {
return {taken_atom_v, false};
},
[=](put_atom) {
if (self->current_sender() == user)
self->become(available_chopstick(self));
},
};и поскольку это не ваш основной язык, вам лень гуглить, лезть в талмуд Страуструпа (который тоже надо нагуглить).
Нафига вот эти [] и [=]? Почему бы не сделать кейворд lambda, как в Лиспе, или fun, как в Erlang, или как в Расте: let add_one_v2 = |x: u32| -> u32 { x + 1 };?
Нет, надо такое, чтоб позаковыристей, чтоб враг не догадался.
выше если что, ссылка на справкупо лямбдам лямбд с примерами использования, открыл ее - прочитал и уже все понятней стало.
Все гораздо проще - не надо писать на плюсах.
А на чем мне написать кросплатформеную десктопную программу требующую кучу ресурсов ? На js ?
Я бы писал С или Rust (для него вроде есть GUI-либы), но пишу серверный софт и распределенные системы. На чем писать вам не знаю, на чем хотите, на том и пишите.
+electronНу да, все ж так делают.
А ресурсы... ну юзер богатый, он заплатит.
я бы рассматривалили Xamarin Native. Хотя этот лучше для мобилок.
> я бы рассматривалА я бы не рассматривал, особенно если это ещё потом портировать.
Я с авалонией профессионально не занимался, но у меня хобби такое, запускать небольшое графическое приложение в разных языках/фреймворках.Ну так вот эта авалония взлетела с пол пинка на линуксе винде и маке. Например, gtk, растовские iced, relm, azul, два вебассембли фреймворка попили кровь.
А тут устанавливаешь дотнет машину и все, 10 минут и у тебя в руках классисеский mvvm на xaml + c#.
Xamarin native это да, специфичная вещь, но я не знаю другой обертки над графическими примитивами разных ос, и чтобы это все работало
> Xamarin native это да, специфичная вещь, но я не знаю другой обертки
> над графическими примитивами разных ос, и чтобы это все работалоReact-Native ?) -Но этот для мобил есчто.
К слову, у яблока не так давно с xamarin'ом срач какой-то был..
п.с: чисто для любопытства глянул в общих чертах на Xamarin.
Там реально надо так извращаться на яблоке со сборкой в вижуал студии и выгрузкой приложения в стор чуть ли не через консольку или там генерируется корректный проект, который можно по человечески и собрать и выгрузить посредством "нативного" Xcode ?
> React-Native ?) -Но этот для мобил есчто.Посмотрел немного на React-Native. Есть у меня ощущение, что он не очень-то и нативный. То есть, если я правильно понимаю, это скорее аналог xamarin-forms. Сам же ксамарин это обёртки над фрагментами, активити, recyclerview, uiview, uitable, и др. То есть они практически 1 в 1 отражают апи целевой системы.
> Там реально надо так извращаться на яблоке со сборкой в вижуал студии
> и выгрузкой приложения в стор чуть ли не через консольку или
> там генерируется корректный проект, который можно по человечески и собрать и
> выгрузить посредством "нативного" Xcode ?Вообще, скорее да, чем нет. (по ощущениям, при разработке под яблоко без извращений вообще не бывает) Но не всё так плохо.
В икскоде вы скорее всего будете только ксибки и сториборды верстать. Весь c# код пишется в JB Rider или Visual studio. Вьюшки андроида верстаете в android-studio или прямо там же, в райдере.
В целом, при отладке вы получаете вполне вменяемые стектрейсы. При сборке - вполне понятные ошибки компиляции.
Работать можно в целом
> Посмотрел немного на React-Native. Есть у меня ощущение, что он не очень-то
> и нативный. То есть, если я правильно понимаю, это скорее аналог
> xamarin-forms. Сам же ксамарин это обёртки над фрагментами, активити, recyclerview, uiview,
> uitable, и др. То есть они практически 1 в 1 отражают
> апи целевой системы.Он и некоторые другие довольно похожи на Xamarin.
Основная разница у RN в том, что основной ЯП - JS, а не C#.
Может и так, но там стремятся предоставить наиболее универсальный АПИ, не зависящий от конкретной ОС с подходом к верстке, напоминающим HTML+CSS( но с нюансами, серьезно улучшающими производительность ).
И, за исключением некоторых сильно-специфичных элементов( типа переключатель ), вид итогового интерфейса и анимации получаются практически одинаковыми что на яблоке, что на андройде.> Вообще, скорее да, чем нет. (по ощущениям, при разработке под яблоко без
> извращений вообще не бывает) Но не всё так плохо.
> В икскоде вы скорее всего будете только ксибки и сториборды верстать. Весь
> c# код пишется в JB Rider или Visual studio. Вьюшки андроида
> верстаете в android-studio или прямо там же, в райдере.
> В целом, при отладке вы получаете вполне вменяемые стектрейсы. При сборке -
> вполне понятные ошибки компиляции.Я просто смутно помню, что у некоторых подобных штук проблема была вначале со сборкой, поскольку "нативная" система сборки много чего не поддерживала и, далее, сложности с выгрузкой( особенно с выходом Xcode 11 вроде перестали работать сторонние штуковины для выгрузки приложений в стор - теперь только через Xcode и его "органайзер", что некоторым доставило массу проблем ).
Чем, в свое время, сильно радовал RN, дающий 2 полноценных проекта, которые без проблем собираются "нативными" системами( XCode + что-нибудь для андройда типа Android Studio ).
Посему и интересуюсь, как там нынче.> Работать можно в целом
Ну это да. Иначе популярности у штук вроде Xamarin'а не было бы
в общем согласен, с наскоку можно не понять. Но есть пара уточнений:
> талмуд Страуструпая имел в виду его последний дайджест по языку - там всего 200 с чем-то страниц, по большей части просто разжевывание старого с советами по применению нового, а не искусство программирования на >1000
>в Расте: let add_one_v2 = |x: u32| -> u32 { x + 1 }
признаюсь, если бы не в контексте лямбд, я бы не сразу понял эту запись (|bla-bla| чем-то похоже на руби)
> если бы не в контексте лямбд, я бы не сразу понял эту записьименно поэтому я привел более простые примеры из Эрланга и Лиспа. Почему в С++ не сделали чего-то подобного - непонятно.
РУЧНОЕ УПРАВЛЕНИЕ ПАМЯТЬЮ ССЫЛКИ И УКАЗАТЕЛИ, ИЗБЕГАНИЕ КОПИРОВАНИЯ
Вы сравниваете два абсолютно разных по своей структуре ЯП.
Я сравниваю синтаксис. Или что, все вышеперечисленное не дает в плюсах сделать нормальный синтаксис для лямбд?
Не даёт, вы должны явно указать компилятору какие переменные будут доступны в замыкании и в каком виде.
А как взять что-то в замыкание в этом вашем расте?
> А теперь представьте, что последний раз вы писали на плюсах, когда там еще этой пакости не было.а если вы ни на чем, не писали, то ни на чем писать и не начнете, ведь вам лень гуглить.
Вот приходится иногда ковыряться и в джаве, и в жс, и в питоне, и в еще нескольких языках и ни один из них не мой основной. Чем C++ в этом варианте хуже?
Ну а мне 99% времени приходится ковыряться в Эрланге, который по совместительству мой основной.
а я вот пока с ним не сталкивался> Нафига вот эти [] и [=]?
в эрланге объекты/переменные для лямбд захватываются по ссылке или копируются?
Да.
> В лиспе тоже просто: (lambda (arg) body).
> Ну и нахрена такие сложности в плюсах?Захват переменных замыканием. В лиспе если у тебя есть объект, то лиспу пофигу, сколько разного кода на него ссылается. И сборщику мусора пофигу. В C/C++ же не пофигу, легко можно придти к ситуации неопределённости, когда нет возможности вне времени выполнения сказать, когда надо освобождать память. (Во-время выполнения тоже нельзя, но это лишь в дефолтном инструментарии: valgrind, например может, или сборщик мусора можно прикрутить, и он тоже найдёт память, которую следовало бы освободить).
А чтобы дать программисту возможность неопределённости избегать, запилен заморочный синтаксис лямбд, который позволяет программисту рулить тем, как переменные попадают в лямбду: копируются значения? закидываются ссылки? Заметь, что если закидываются ссылки, то программист сам должен следить за тем, чтобы не удалить объекты, на которые они ссылаются, до того, как будет удалена лямбда, иначе код лямбды обратится к освобождённой памяти. Если же копируются значения, то куда они копируются? На стек не скопируешь, потому как лямбду можно вернуть из функции и стековый фрейм может прекратить существовать. Значит копируем в кучу, а значит выделение памяти, значит с лямбдой увязан кусок памяти, который надо освободить, освобождая лямбду.
спасибо, Rust и обычная сишка попроще будут.
> Я вот в одном коде увидел эти лямбды и нихрена не понял, что там написано.Да как-то связи особой нет...
На любом стандарте можно такое понаписать.
Теми же макросами только так можно лютую штуку сделать, что от неё радугой всё блевать будет.
Проблема в том, что тут это стандарт и общепринятая практика, а не говнокод отдельно взятого индивида, которого можно просто напинать в курилке.
если есть выбор, то использую c++, как c++ без классов - pod + stl + templates
STL без классов? ;)
>> { a == b } -> std::boolean;{ a != b } -> std::boolean;
Ну почему это должно выглядеть так непонятно и непоследовательно?
сплюснутые же придумывали, нормальные люди так бы не сделали.
Хипстеры добрались и до плюсов.
Полезно, одобряю
То чувство, когда плюсы сложнее раста...😭
Ждем, когда в теме появятся растоманы
Так Раст в большинстве случаев не очень сложный
Но иногда бывают эпохальные лингвистические повороты, да. Впрочем, как и в любом языке
Он не очень сложный. Он просто излишне сложный так где не надо.
всё имеет свою цену
заморочки раста с временами жизни переменных - плата на надёжность и отсутствие неопределённого поведения, без использования сборщиков мусора
Управление памятью - вещь непростая сама по себе, и эта сложность обязательно где-то вылезет - либо в GC, либо в языковых конструкциях, либо в уязвимостях :-)
Так, а где Networking?
Они его ещё с C++14 обещают (если не раньше), говорят что ещё чуть-чуть, всё почти готово, реализация уже есть в бусте/асио нужно только в стандарт прописать, добавим в следующем мажорном релизе, мамойклянусь! А воз и ныне там, в C++23 вообще про Networking ни слова.
Я юзаю https://github.com/ValveSoftware/GameNetworkingSockets
Так с подключением внешней зависимостью какого-нибудь буста или закидыванием в дерево какого-нибудь асио проблем нет.
Проблема в том что в крестах ВООБЩЕ нет никакого кросплатформенного способа взаимодействия с сокетами искаропки. И не будет минимум до 2026 года, ибо в C++20 их перенесли на хз когда, а судя по тому что в C++23 это даже не планируют обсуждать то только к C++26 может и запилят.
Он зависит от Executors а с ними не сложилось. Добавят в с++ 23
Модули то ждали к С++17 а выкатили только к с++20
Ну так функции Бесселя гораздо чаще встречаются в жизни простых программистов чем необходимость работы с сетью. Сарказм выкл.
А потом эти люди еще удивляются почему так стремительно растёт популярно GO
и PHP
Не, ну вот из крайности в крайность не надо. Да, современный С++ перегружен и переусложнен до предела. Но и Go слишком прост, чтобы на нем делать серьезные проекты. Быстро накидать прототип или что-то несложное - да, можно. Но что-то сложнее нескольких файлов и нескольких сотен LoC - уже начинаются проблемы с построением архитектуры и чистотой кода. Куча дублирования, пустые интерфейсы, которые пускают по звизде всю систему типов... Кошмар, одним словом.
Я для себя выбрал 4 языка, с которыми мне приятно работать: Common Lisp, Erlang, Rust, C.
И с которыми я никогда больше не буду работать без критической необходимости: Go, C++, C#, Java.
Посматриваю еще в сторону Standard ML, Haskell и Ada. Последнюю щупал, вроде ничего так, но как-то слишком многословно и куча заморочек, так и не определился, нравится или нет.
>слишком многословноЯзык для оборонки создавался же. Многословность, чтобы меньше было возможности не заметить мелкую опечатку. Что скажете про Dlang и Nim?
Не пробовал, не знаю.
>> Но и Go слишком прост, чтобы на нем делать серьезные проекты. Быстро накидать прототип или что-то несложное - да, можно. Но что-то сложнее нескольких файлов и нескольких сотен LoC - уже начинаются проблемы с построением архитектуры и чистотой кода.Так и скажи, что у тебя руки растут не с того места.
Ага, на нормальных языках из того места, а на Go внезапно не из того. Ну да, ну да, конечно, проблема во мне, а в Гугле говно создать не могут по определению.
Профи отличается от начинающего умением использовать любой инструмент. Лет через двадцать кодинга на самых разных ЯП ты это осознаешь. По ходу и заметишь, что именно этот навык наиболее востребован и наиболее хорошо оплачивается. Капризульки и поиск "крутых ЯП для крутых проектов и крутых перцев"-это характерно для начинающих.ЗЫ конкретно про Go, его увлечённо взяли в оборот в крупнейших компаниях, включая РФ-вских, и пилят на нём проекты уровня bigdata платформ, тихо и молча.
Это скорее отлияает тех, кто будет жрать сам знаешь что за деньги, от всех остальных. Не более.
> именно этот навык наиболее востребован и наиболее хорошо оплачиваетсяНеа. Наиболее хорошо оплачивается умение писать качественный код, а для этого надо хорошо знать язык(и) проекта (один-два, максимум три), а не нахвататься всего по верхам.
>>умение писать качественный кодНе повторяй то, что сказано выше фразой "умением использовать любой инструмент"
PS Новичка сразу выдаёт утверждение, что освоить можно только два-три языка. Проработавшие пару десяток лет успевают не только освоить десятки ЯП-ов, но и забыть некоторые из них за ненадобностью.
> Проработавшие пару десяток лет успевают не только освоить десятки ЯП-ов, но и забыть некоторые из них за ненадобностьюНу что ж, давай перечислим языки, которые я освоил (и многие забыл) за (в общем случае, потому что начинал еще в школе на Электронике-БК или Корветах, уже не помню) 18 лет программирования.
школа, 9-10 классы, УПК:
Basic (не помню какой, как раз на Электрониках/Корветах был), TurboPascalдалее универ, 5 лет, околопрограммистская специальность САПР:
Assembler X86, AVR Assembler, C, C++, VBA, VBS, JS, Delphi (да, он считается языком), C#работа, 11 лет уже как:
продолжал Delphi, C++, C#, чуть-чуть JS. Новые: PHP, Erlang, Go, Common Lisp, Rust.Bash-скрипты и batch-файлы не считаю.
Из них продолжаю активно использовать Erlang (по работе). Есть планы по Rust'у, C и, возможно, Лиспу (для себя).
И вот после 2 лет разработки на Go могу заявить, что он - говно.
> Новичка сразу выдаёт утверждение, что освоить можно только два-три языка. Проработавшие пару десяток лет успевают не только освоить десятки ЯП-ов, но и забыть некоторые из них за ненадобностью.Не повторяй то, что сказано выше фразой "нахвататься по верхам". Можно уметь кодить на нескольких десятках языков, но при этом на всех них допускать детские ошибки или просто плодить крайне неоптимальный код. У меня и в мыслях не было с этим спорить. Но чтобы писать качественный код, надо потратить несколько лет только на разработку на одном языке (десяток лет опыта разработки вообще — это само собой разумеется). В случае такого сложного языка, как современный C++, нужно разрабатывать на нём, как минимум, последних лет 5. Именно последних, чтобы быть в курсе актуальных стандартов. И да, под разработкой я понимаю не просто написание кода, но и чтение литературы, посещение конференций и т. п., чтобы не отставать от жизни. И как-то вот получается, что больше 2-3 языков на должном уровне поддерживать очень трудно. Ну если только язык не стагнирует и не является сам по себе предельно упрощённым.
> конкретно про Go, его увлечённо взяли в оборот в крупнейших компаниях, включая РФ-вских, и пилят на нём проекты уровня bigdata платформ, тихо и молча.да бэкенды на нем пилят в основном, поскольку вся РФ - один большой аутсорсер.
> Профи отличается от начинающего умением использовать любой инструмент.он отличается умением выбирать инструмент под задачу. При чем такой инструмент, при работе с которым он будет получать удовольствие, а не ругаться матом каждые несколько минут.
ок ос на брайнфаке запилил
Согласен, неожиданно для себя понял,ч то мне, по большому счету всё равно на чем писать, а разобраться в особенностях можно из за пару недель...
Можно, конечно, привыкнуть и к говну, но зачем ?!
Go тоже та еще гадость.
Никак не дождусь автозаполнения аргументов, когда функцию объявленную как:
foo(int a, int b = 10, int c = 20);
можно использовать:
foo(1, , 5); // foo(1, 10, 5);
foo(1, int, 5); // если есть перегруза вроде foo(int a, double b = 15, int c = 20);
Неужели так сложно?
до сих пор стараюсь не писать на с++ из-за отсутствии такой важной возможности
Увы, но заменить c++ нечем. Если те же задачи решать на C то запутанность кода превысит запутанность синтаксиса современного c++
Если на сях писать аки на плюсах - тогда да.Если же кодить нормально, без этих бесконечных нагромождений псевдоабстракций, то может оказаться, что запутанности кода больше не стало, очень мягко говоря.
Хорошо продуманная абстракция как раз наоборот упрощает дизайн кода. Как пример обычная операция над объектом:
//в C++
obj.func(arg1, arg2);
//в C
objType_func(ptr_to_obg, arg1, arg2);
> Хорошо продуманная абстракция как раз наоборот упрощает дизайн кода. Как пример обычная
> операция над объектом:
> //в C++
> obj.func(arg1, arg2);
> //в C
> objType_func(ptr_to_obg, arg1, arg2);Написать короче, да. Выглядит красивей.
Вот только читая такой код ты сначала должен посмотреть что такое obj, просмотреть иерархию наследования, посмотреть все вариации func со всеми типами аргументов, посмотреть какой тип у аргументов, пройти по их иерархии наследования, попарить мозг если это какой-нибудь шаблон хитровывернутый ...и это только для того чтоб точно понять с чем именно идёт работа в данном конкретном месте - то есть это только подготовительный этап к чтению содержимого.В Си-шном варианте, хоть и более многословном, но по прототипу функции уже сразу понятно на что надо смотреть. Да, писать больше, а с вариациями аргументов и структур - намного больше (но это ж как раз про дизайн, чтоб с самого начала не плодить лишнего "just because we can").
Более классический пример:
y = x + 5;
В Си-шном коде можно вообще никуда не смотреть - сразу понятно, в целом, что происходит.
Эта же строчка на плюсах может быть вообще чем угодно (хорошо хоть пятёрка пока не может быть переопределена). Для написания - это может быть большим достоинством (краткость, единообразие, красивость и всё такое), но для чтения/понимания...
Это если первый заглянул в код тогда да. Но поработав какое-то время с проектом и познакомившись со всей иерархией классов, получаешь буст к скорости написания/понимания именно благодаря лаконичности и естественности ООП кода.
>> Если на сях писать аки на плюсах - тогда да.
>> Если же кодить нормально, без этих бесконечных нагромождений псевдоабстракций...
> Хорошо продуманная абстракция как раз наоборот упрощает дизайн кода. Как пример обычная
> операция над объектом:
> //в C++
> obj.func(arg1, arg2);
> //в C
> objType_func(ptr_to_obg, arg1, arg2);Это ведь именно попытка писания на Сях аки на плюсах, т.е к нагромождению ООП и связанных с ним тонн абстракций добавляется еще и попытка "эмуляции" ООП на языке, его не поддерживающем.
Конкретно в вашем примере - работа с объектом в ООП-стиле, на языке, который его поддерживает и на языке, котором добавляется еще один слой абстракций чисто для эмуляции ООП или к слову о прокидывании в функцию подобия this..
Само-собой подобный подход вдвойне убог.
> попытка "эмуляции" ООП на языке, его не поддерживающем.так ведь именно это и есть стиль типичного C фреймворка. Вот пример из GTK:
void gtk_window_set_default_geometry (GtkWindow *window, gint width, gint height);
Оу, все фигня. Они добавили reflection в TS А значит можно ожитать их реализации в gcc и clang. А там и метаклассы и генераторы кода...
Ну все Раст больше не нужен
Насмешил (х
Кто ты и твой коммент без раста ?
Как раз из-за C++20 нужен ещё сильнее ;)
Комитет по раздувательству С++ работает, не покладая рук.
Так, стопэ! А корутины-то допилили?// Всё остальное в основном накур - да
Допилили. И уже поддерживается в текущих компиляторах.Смотри табличку: https://en.cppreference.com/w/cpp/compiler_support
> Допилили. И уже поддерживается в текущих компиляторах.
> Смотри табличку: https://en.cppreference.com/w/cpp/compiler_supportО, точно, в Gcc допилили. В LLVM не до конца. Маладцы! Это по-моему главная киллерфича C++20. Единственно надо посмотреть какой оверхед от них будет
Не допилили, оно в экспериментальном режиме и требует отдельный флаг.
В Visual Studio пока требуется отдельный флаг: /awaitНо с версии 16.8(пока доступна лишь Preview) будет работать уже без флага.
Кто хочет выучить современные плюсы, следуйте на learncpp.com 👈
Общаясь с плюсовиками, понял примерно то что народ пишет на одиннадцатых и посматривает на 14.
Эти все нововведения нужны наверное 10% разрабов.
А новые версии плюсов выпускают что бы выпускать.Кстати, вы знали что плюсы должны быть совместимы с совершенно чудовищными вычислительными машинам с недвоичной логикой.
В результате хорошие дополнения не вводятся из-за ужасного легаси языка.
Теперь понятно почему стрельнули GOLANG и RUST
https://www.reddit.com/r/cpp/comments/ik7bwt/which_c_version.../знакомые плюсовики выборка очень плохая.
И по вашему новые версии выпускают потому что людям скучно, а не то что они пытаются решить какие-то проблемы?
>а не то что они пытаются решить какие-то проблемы?Ага. Проблемы порождённые предыдущими решениями проблем.
> В результате хорошие дополнения не вводятся из-за ужасного легаси языка.Вводяцца, лямбды вон ввелись, теперь ещё async/await. Круто же)
> Теперь понятно почему стрельнули GOLANG и RUST
...но и это конечно да, маразма там тоже хватает.
>Общаясь с плюсовиками, понялЭто та же логика, что "среди моих знакомых никто не голосовал за <кандидата>, значит, за него никто не голосовал".
> плюсы должны быть совместимы с совершенно чудовищными вычислительными машинам с недвоичной логикой.There are more than two digits!
Все верно. Все последующие нововведения нужны лишь самим разработчикам стандартов. Такой междусобойчик чисто для себя. Те же функции Бесселя, например. Нужны каждому простому программисту на практике. А вот работа с сетью - нет. Сарказм выкл. За шаблоны, вообще, нужно убивать. Write only код. Спустя некоторое время даже сам автор более менее нетривиального шаблона перестает понимать, что там делается. А уж отлаживать это чудо можно желать лишь врагу, особо злостному.)))
Ну как, для квантовых вычислений-то С++ уже готов?
Тут всё зависит от middle-end компилятора. Как доработают middle-end, так сразу для всех языков компилятора и заработает, в том числе и для Rust
Пытаюсь представить себе квантовые указатели :)
Просто достаёшь указатель где-то за пределами массива, вот тебе и квантовый указатель готов.С некоторым шансом, обращение по адресу пройдёт даже без вылета.
Ага, туфту представить невозможно! Но он привлекателен.
Почти. Как только UB расширят волновой функцией, будет точно готов.
Аффтар новости, ты вообще хоть немного понимаешь что переводишь?> Возможность лямбда-захвата выражений "*this".
this всегда можно было захватывать, сделали устаревшим автоматический захват this при использовании [=]
> Классам разрешено использование параметры шаблона без типа.
В качестве параметра шаблона-значения можно использовать классы для типа, раньше можно было только POD типы. Из-за этого нельзя было делать строковые литералы параметрами шаблонов.
> Возможность использования диапазонов для инициализации значений переменной в цикле "for"
Возможность указывать в конструкциях for(...) локальные переменные, которые дальше можно использовать в range части. К возможности использовать диапазоны это вообще не имеет никакого отношения, делать аналоги питоновского range() в range-based for можно было начиная с c++11.
> Атрибут "[[no_unique_address]]" при котором переменные без данных не занимают места.
Вообще ничего близкого по смыслу, полная чушь.
> Поддержка быстрых (immediate) функций, которые могут работать только с константами.
Поддержка функций, которые могут использоваться только на этапе компиляции.
Это совсем адовые ляпы, в половине пунктов вообще не понятно о каком нововведении пишешь.
Там под новостью справа есть ссылочка такая: "исправить".
Спасибо за попытку, но лучше патчи сразу туда и слать.
Благодарю, а я то думал, что туплю при чтении (давно не юзал плюсы, очень давно).
Это именно что захват *this, комментатор, ты хоть понимаешь что комментируешь?)
читай док: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p001...
та ну нафик... на ассемблере писать стало проще.
В GCC поддерживают драфты или релизные версии?Если драфты, то насколько они уверены в совпадении и откуда у них такая информация?
Если релизы, то где скачать документацию по этим версиям языка?
https://isocpp.org/std/the-standard
дальше purchase нужную версию, вводишь данные кредитки и вот оно счасьте в виде пдф
Одна из причин перейти на Rust.
Отсутствие стандарта как такового, единственная реализация компилятора и стандартной библиотеки?
в случае, когда за этот стандарт надо заплатить туеву хучу бабла, можно считать, что его нет.
Платный доступ к стандартам - устоявшаяся практика, и у ISO, и у ГОСТ.
Порочная практика, спешу заметить. Это во-первых.
А во-вторых - не по таким же ценам! Ну чего там такого написано на 16.5 тыс. руб.? Зачем нужны стандарты, если для того, чтобы их прочитать даже в электронном виде надо платить туеву хучу денег? Ну и продавали бы печатные копии, а электронные сделали бы общедоступными.
Кстати, все необходимые мне ГОСТы я находил в свободном доступе. А вот ISOшные стандарты - не все.
Тебе и незачем за него платить. Он для авторов компиляторов предназначен, а не для тебя.
А, ну то есть обычному пользователю языка, не автору компилятора, стандарт читать необязательно. Достаточно талмуда Страуструпа. Ню-ню.
Драфт бесплатен, качай-читай - он и нужен программистам и "обычным пользователям языка", а платный, с деталями - разрабам компиляторов.
Обычному пользователю языка за глаза хватит справочника с цплюсплюс.ком или цппреференс.ком. Для начинающих, конечно, ещё и хороший учебник нужен, но им-то стандарт точно не является.
Для тех кто не хочет платить, всегда есть последний пред-релизный драфт, который может отличаться от итогового стандарта только неправильной расстановкой запятых.
за 16 508 рублей? Спасибо, не надо нам такого счастья.
Можно пользоваться драфтом - он бесплатен, разница лишь, что нельзя официально сказать "в соответсвии со стандартом".
Да и 200 баксов - это не так уж много за формальное описание языка - люди всё-таки работали.
За многотомники по "альтернативной истории" тоже платить? Аффтар строчил, понимаешь ли.
Да нет, многовато, я за ипотеку плачу 20, а тут талмуд - 16. Пускай сами его читают. 1000 рублей - нормально.
Но это ладно. Я вот видел исошный же стандарт на 30 (30, Карл!) страниц, который ISO же продает за 11 000 рублей. Это ли не верх о*уения зажравшихся капитализдов?
на гитхабе лежат исходники стандарта.
Ненужно! Ведь уже есть rust !
Раст уже деприкейтед, команду разогнали. Пора переходить на С++
Что за глупость, Раст наконец свой фонд организовывает
Уже нет - проехали. Года 4 назад ещё можно было гадать взлетит Rust или нет. А теперь it's here to stay. Я понимаю что многих здесь он раздражает - но жизнь вообще жестокая штука...
В том то и дело что в раст почти ничего нет.
Но при этом есть все необходимое. А вот в плюсах что-то уж очень много всего по сравнению с 98 и 03 стандартами. Слишком много.
ну не используй то что тебе не нужно )
Ну вот не нужен мне С++ - я его и не использую, есть языки попроще и поинтереснее))
да и вообще жизнь без компьютера поинтереснее и попроще )).
А вообще это лично вами, в силу определенных причин, было принято решение поискать ченть попроще, в результате оно и оказалось интереснее что хоть какието вещи лично вы можете сваять ).
Что не прав? )
Нет, не правы. Это решение приняли за меня, предложив работу на Erlang. А потом я уже расхотел возвращаться на плюсы, во-первых, потому что понял убогость и их и ООП, а во-вторых, потому что не хотел осваивать новый стандарт.
ну если вам платят за другой язык то почему же и нет ) но это же совсем не то когда молодеж начинает хайповать ).
А в плане убогости в ООП в с++, тут вы не правы )
Боже ш мой, сколько бреда!!! Неужели это кому-нибудь нужно и кто-то пользуется этим?! В C++11/14 ещё были полезные нововведения, но в 17/20 - безсмыслица какая-то уже. В рефлексии как не было так и нет, токмо Qt-м и спасаемся.
Для рефлексии в этом стандарте TS сделали, надеюсь в С++23 уже будет (а в компиляторах еще раньше).
> в 17/20 - безсмыслица какая-то ужеНу почему же. В С++17 среди прочего ввели std::filesystem. А то всё приходилось С-функциями каталоги обходить. std:optional, std::string_view - тоже полезные штуки. Copy elision - тоже хорошо. В С++20 тоже много хорошего.
Выбирая между C++ и Rust стоит выбрать Haskell.
А как же JabbaScript Everywhere? 🌝
сплюснутые и ржавые начали гонку сложности к невозможности изучения языка.
Используя деепричастный оборот, стоит обособлять его запятыми.
Кажется приближается смерть плюсов от ожирения. Язык C выглядит всё боле привлекательным из-за относительной своей простоты.
Ассемблер вот где все просто. Зачем все эти абстракции когда есть посконный гоуту
Нету там никаких гоуту, goto: есть в сях
тоже мне проблема
#define goto JMP
Ну что, теперь можно написать еще 100500 библиотек для работы со строками?
Предсмертные конвульсии.
Сколько высокомерных ниасиляторов в комментах, просто ужас
Зачем осиливать^W насиловать труп?
Что осиливать, а что нет - каждый решает сам. Но высокомерно выпячивать своё неосиляторство - как-то тупо. Если чего-то не знаешь - ну нормально, просто сиди себе тихо и скромно со своим незнанием. Но высокомерные разговоры в духе "я этого не понимаю, значит это говно" - показывают тупость автора изречения, а не недостатки предмета обсуждения.
Как минимум значительно больше представителей мазохизма
Концепты конечно мощнее, чем type constraints в свифте или шарпе, но зачем так усложнять все таки...
Самый читаемый код на pascal
Нет. На J.
Ты уверен?result =. name1 verb2 5
Там тоже уже подзапутали. Но где то до уровня ранних плюсов, которые еще можно читать былоhttps://castle-engine.io/modern_pascal_introduction_russian....
Нахер надо это все. Все это в других языках делается проще и так же быстро работает. А если надо ещё быстрее, то C или C++ 11.
Какие, например?
Языки проще обычно заметно тормознее
"заметно" - это сколько долей процента?
Ну сравни скорость C++ и Питона
Ничего себе, модули завезли. Эдак они и от препроцессора вовсе откажутся.
Ага, а потом вообще морфируют в сишарп
скоро до уровня паскаля подтянутся :)
> Поддержка синтаксиса инициализации в стиле Си...Да неужели наконец-то плюсовики смогут компилировать нормальный Си-шный код? Хотел сказать "не прошло и 20-ти лет"... Но ведь прошло... В Си такая инициализация есть с С99...
Лень смотреть, а Си-шную аналогичную инициализацию массивов и тоже поддерживает?
Не смогут. Инициализация в "стиле С" с С несовместима. Там свой синтаксис.
срр для срр
уже сделали бы нормальный язык, без накруток. в компиляторе ещё возможно искать ошибки?)
даёшь dlang без gc!
Си плюс-плюсники зашёл тут к вам, растаманы в вашем треде успели посрать?
Все задачи должны решаться в едином стиле. Но это совсем не про C++, в котором есть шаблоны, constexpr, теперь уже концепции, и я боюсь представить, какая же будет интроспекция... С каждым стандартом в язык добавляются новые сущности с новым синтаксисом. Никакого единообразия. Из-за наследия комитет воротит костыли, которые в свою очередь заставляют воротить новые костыли. Такое впихивание не впихиваемого уродует язык. Уже сейчас на освоение языка нужны годы. А сколько ошибок будет допущено при разработке сложно даже представить. В масштабах мира это огромные потери человекочасов. И только из-за того, что нужно сохранять совместимость. Супер аргумент. Все радуются новому стандарту. Но с ним С++ стал только уродливее, и фактически катится в тупик.
> Из-за наследия комитет воротит костыли, которые в свою очередь заставляют воротить новые костыли. Такое впихивание не впихиваемого уродует язык.Что за ересь? Наоборот, синтаксис становится проще, понятнее и красивее.
С++03:
const std::vector<int>::const_iterator end = vec.end();
for (std::vector<int>::const_iterator it = vec.begin(); it != end; ++it) {
int n = *it;
...
}C++11:
for (int n: vec) {
...
}
Первый вариант никуда же не делся! Теперь надо знать оба. Ничего проще не стало. Это притянутый за уши, но всё же как раз пример усложнения языка.
это к вопросу о том, что если можно сделать больше чем двумя способами, то усложнение. но я с таким не согласен. если что то можно написать и просто и сложно, это нормально. плохо когда нельзя просто.к тому же в некотрых ситуация более трудный ситаксис имеет больше возможностей (например в цикле есть доступ к самому итератору в первом варианте). выбор дает больше возможностей и заставляет выбирать (думать то есть).
> выбор дает больше возможностей и заставляет выбирать (думать то есть)Теоретически да, но на практике обычно новый вариант очевидно лучше (проще, красивее, выразительнее) старого. Редкие случаи, когда не так - не делают погоды.
ну и что, вот я тоже люблю испльзовать патерны по старинке, тут вопрос привычки. С++ дают такую возможность. Я могу на С++ использовать структуры с функциями, получаем компактные объекты. Могу в кутях легко и просто использовать навороченные классы для работы с БД, 3д и тд.. Программист сам выбирает что он хочет - так и пишет. С++ это от си к абстракциям (да где то не с первого раза понимаемым конструкциям). С++ это свобода.
> Но с ним С++ стал только уродливее, и фактически катится в тупик.А у него выбора нет другого, кроме как катиться в тупик. Если забить на обратную совместимость, то получится история типа перехода python'а со 2 на 3 версию, только ещё хуже. Гораздо-гораздо хуже.
Главный вопрос. Почему стандарт до сих пор называется ISO/IEC 14882? 14/88! И в комитете по стандартизации одни белые гетеросексуальные мужики, никакого divesity. Куда смотрят SJW?
Куда они так торопятся? И где нормальная литература по современным C++?
А чего в списке новшеств ranges не упомянуты?
https://www.modernescpp.com/index.php/c-20-the-ranges-library
Или я проглядел?