Александр, прекращайте проповедовать свои заблуждения! Я не знаю вашего уровня владения C++, но подобные заявления заставляют думать, что уровень этот невысокий. Так зачем вы агитируете против того, в чем не разбираетесь?

На плюсах спокойно программирует один человек и код получается проще, чем сишный. Но это если этот человек имеет хороший опыт c++.

Про асинхронность есть ветка про ССТ, там все показано на примерах, как работает асинхронный подход и какие его преимущества перед синхронным. Можете туда кидать и недостатки, очень желательно на реальных примерах кода, чтобы тема не превращалась в холивар.

Так попробуйте дискутировать.
Выложите на github свои проекты, покажите что разработали на C++ в одиночку.

Сразу давить на образования это не серьезно.
Я ж могу кучу коней в вакууме вывалить на C++ в доказательство своего уровня, как это делает наш уважаемый участник brag
Но для меня доказательство только реальные рабочие проекты и только открытые.

Все свои проекты уже лет десять делаю на С++ и все в одиночку. Почему я должен отказываться от классов, перегрузки операторов, шаблонов, более строгой проверки типов и переходить обратно к "голым" Сям вы объяснить не можете. Отсюда я делаю вывод, что этих возможностей C++ вы просто не знаете. Потому что если бы знали - вы бы понимали, что они не приносят никаких накладных расходов во время исполнения программы, но при этом сильно облегчают труд программиста - на сях вы делаете то же самое, но вручную, а это куча лишней писанины и потенциальная возможность ошибок, хорошо если ошибок времени компиляции.

Открывать свои проекты чтобы доказать что-то вам у меня нет никакого желания.

Причем тут стиль? Это тот случай, когда программисту нельзя доверить второй указатель. Говорит о силе языка или программиста?.
Выросла производительность железа - появилась возможность организовывать системы выделения памяти со сборщиками мусора.
Все трудоемкую работу с указателями выполнил какой-нибудь сулейман ибн оглы с Индии или Пакистана.
Программистов становится все меньше - всех делают фокспрощниками.


Лямды имеют практический смысл для RT-компиляции: сгенерировали код, отработали его и потерли за ненадобностью, освободив память для другого.
В С++ разница лишь в одном: оформит компилятор в виде вызова отдельной функции или сгенерирует "inline"-код.



Ну так мы и вернулись к началу ветки. "С" лучше чем "Паскаль", потому что у "С" С-шная форма записи - но это сугубо личное мнение, основанное на привычке к этой форме записи. Для кого-то - наоборот, а кому-то вообще может быть по барабану.
Для новичка С предпочтительней Паскаля по крайне мере из-за тотального распространения С.

А противопоставление "С" и "С++" некорректно, потому что "С++" - это "С" (плюс еще что-то). Понятное дело, что это "еще что-то" за прошедших три десятка лет выливается в более удобную и быструю разработку.

Это разные языки. Валидный Си-код может быть невалидным Си++-кодом.

Это так, но на самом деле это мелочь.

Базовые различия не в синтаксисе, а в экосистеме.
Я заметил что у нас основные агитаторы за C++ это пишущие в категории совсем мелких микроконтроллеров: STM8, PIC, MSP и т.д.
Т.е. там где и писать то нечего. Отсюда и непонимание что на самом деле ускоряет разработку и что делает ее удобнее.

А экосистема это окружающие микроконтроллерную платформу фреймворки стороннего софта.
С++ для встраиваемых систем уровня Cortex-M по сути мертв.

Тоже я скажу про С-и и Pascal для PC. Там им тоже места практически нет.

"Не судите по себе и не будете осудимы" (С)

C и Object Pascal востребованы на PC-Win. Есть немало известных как крупных, так и мелких проектов.
На моей практике вообще эта связка ( C - для математики и dll, а Delphi - как GUI + DB) - самое то.

За более чем 20 лет использования Delphi ( начиная с 1995 г. и Delphi 1) ни разу не пожалел об этой "экосистеме".
Для прикола у меня до сих пор стоит Delphi 2 и можно делать на ней почти все.
http://shot.qip.ru/00gZ9L-3OPovQGDZ/

На С и C++ тоже прошел длинный курс от С на CP/M 8р и далее до Watcom C, Intel C и пр.
Watcom до сих пор для меня идеал (для тех лет).
На Watcom много писал для Novell. Про Novell мало кто уже помнит, а ведь это была сетевая OS №1 ( Netware ).

Много лет назад ( 16..18 - точно не помню) даже сделал Интернет-проект по сравнению компиляторов/интерпретаторов разных версий от производителей (Borland, Intel, Watcom, Microsoft, FreePascal, TMT, LCC/GCC, Phyton, JS) - тесты на математику, динамические структуры, тексты и т.д.
Результаты были очень интересны для специалистов.
Скриншоты:
http://shot.qip.ru/00gZ9L-3OPovQGE1/
http://shot.qip.ru/00gZ9L-6OPovQGE2/

P.S. Недавно полюбопытствовал Rust - неоднозначное пока отношение, но интересно.
На мой взгляд, все же не соблюдено требование №1 о безопасности, поскольку опять есть небезопасные возможности и много отступлений от привычного синтаксиса уже существующих языков.

Вы никогда не делали глупых ошибок с указателями? Модификатор const выброшен вами за ненадобностью?
Вообще да, говорит. Эти ограничения - меседж от разработчиков языка и компилятора "подумай еще раз, с большой вероятностью ты готовишь выстрел в ногу".

Не придирайтесь. Писал по памяти, вот написал "что-то". проверил оказалось первоначально он назывался "С с классами".
Позже это коряво-нежизнеспособное название было заменено на "С++", что в переводе с авторского означает "усовершенствованный С".
Для того, чтобы понять, что старый "С" и новый "С++" разные языки, даже валидность кода не стоит сравнивать - об этом говорит сам факт
существования двух стандартов. Но в контексте данной ветки (Pascal или С++) это несущественно.

Само сравнение "С" и "усовершенствованного С" среди разработчиков - дело бесполезное.
Использование усовершенствованного всегда удобнее и приятнее.

Но у legacy-C есть все же неоспоримое преимущество перед С++: там уже все вылизано проверено и посыпано песком.



Естественно делал, тем более имея привычку новый код получать редактированием копипаста. Но получал аналогичный месседж от компилятора,
который все же не делает ограничений. Чаще при копипасте возникает ошибка сравнения в виде присваивания, либо наоборот.
Так и в этом случае компилятор выдает предупреждение.

О чем простите думать, если Вы говорите об ОГРАНИЧЕНИИ, а не предупреждении? Ограничение означает, что не сможете этим, одним из миллионов вариантов, повредить себе ногу. Заодно не сможете вообще воспользоваться витовкой для любых других целей.
Какое относительно счастье. Спасибо разработчикам компиляторов за наше счастливое детство.
Есть и целые толпы борцов с ветряными мельницами и в Си, например, благодеятели от MISRA, но это все же НЕ ОГРАНИЧЕНИЯ, а "предупреждения".

Есть класс задач, где сборщик мусора не уместен, но они чем раз тем сложнее, и тут на помощь приходят всяки плюсы и расты, которые уменьшают человеческий фактор и делают разработку более быстрой и комфортной. Но изучать новый стиль придеться, легкого пути нет.


Это мелочь для крохотных проектов, а если там хотя бы 200к строк кода, тогда портировать такой код на плюсы будет не просто.


Глупые ошибки это одно, а когда проект очень сложный - ошибку допустить будет очень легко, а найти и тем более исправить - очень сложно, возможно для этого придется переписать тонну кода. Вот тут и помогает компилятор(то есть язык с его правиалми), который заставляет писать "нормальный" код сразу.


Сишному да и плюсовому компилятору очень далеко до того, что умеет проверять компилятор Rust. И дело тут не в крутости компилятора последнего, а в другом стиле программирования. Ни сишный, ни плюсовый стиль не позволяет выполнить необходимые проверки.
Но это не значит, что нельзя пользоваться винтовкой - да запросто- пишете код в ансейф блоке, можете хоть всю программу там написать, если знаний и опыта программирования в данном стиле нет, и потом обязательно скажете, что эти все расты и плюсы ничем не лучше обычного С

Все, кто гонит на С++ и другие высокоуровневые языки или на какой-то непривычный для них стиль(тот же асинхронный) - просто не умеют на них программировать, просто не имеют достаточных современных знаний и опыта, и предпочитают все делать по старинке привычным для них способом
Это все равно что сравнивать стамеску, молоток и топор с много-осевым ЧПУ станком

Видал я эти "многоосевые", после которых рыдать хочется.
В итоге берешь молоток и зубило, идешь эффективным путем и получаешь годами работающее изделие без обслуживания.

Ага и вытачивать на своем много осевом винты и гайки, которые нормальный конструктор берет из кассетницы.

Убого выглядят потуги хоть как-то продвинуть C++ без опыта реальных проектов.

Еще более убого выглядят попытки его задвинуть.

Из "кассетницы берет" не конструктор, а слесарь. Вот такая принциальная разница между программированием и "програмированием". В массовом сознании еще не укрепились различия между "программистами" и "слесарями-интеллигентами"© Ильф и Петров.

Можно поинтересоваться с каким настройками предупреждений вы компилируете и исправляете ли все предупреждения?

В расте декларируется простая вещь - гарантированная безопасность данных, пока вы в рамках наложенных ограничений. Если вам не нравится ограничения, то можно пользоваться "unsafe {...}" и не получать этих гарантий. Мне наоборот нравится идея что пока я в рамках правил язык даёт мне такие гарантии, в отличии от нашего любимого C в котором неосторжная опечатка может привести к трудно отлавливаемой катастрофе. Насчёт ограниченности инструмента вы неаргументированно утверждаете что что-то сделать невозможно. Разумеется там где нужно используется"unsafe {...}" с ручной верификацией, в библиотеке самого раста немало примеров. Но для большинства применений отступать от этих правил не требуется, а профит от гарантий встроенных в язык остается. Я бы предпочел поспорить аргументированно, но т.к. у меня (и скорее всего у вас) нет опыта использования раста, то спор выйдет ущербный.

С максимумом абсолютно возможных. Исправляю все. Это относится к сообщениям компилятора, а не приблуд типа MISRA, поскольку меня волнуют все места возможного непонимания меня конкретным компилятором. А фантазии на тему разных дядей на тему где я могу ошибиться и где может не понять некий абстракный компилятор, напротив, совершенно не волнуют.

От спора по расту я бы тоже воздержался, очень новый язык и функционал его очень богат(в том числе и шаблоны, перегрузки ипт. там тоже есть), но мы все пока что не умеем им пользоваться. Сначала научимся, сделаем хотя бы парочку серьезных проектов, потом можно и спорить.

Т.е. если прямо сейчас включить опцию treat warning as error - то ничего не поменяется? Ну вот раст это постоянно включенная опция.

Ничего.

Вопрос в том, что относится к наказуемым предупреждениями вещам. В случае текущих сишных компилятров все уже достаточно сбалансировано, хотя, например, у того-же массовейшего GCC, пожалуй набор предупреждений относительно мал. Расширять-же количество warnings уже представляется достаточно бессмысленным. Но если хотите, то так-же MISRA Вам с радостью их накидает, как с бодуна и мало не покажется.

Так Вы же первый и "гнали" на С++, рекламируя Rust ему на замену. Поначалу я усомнился в его способности заменить С++, исходя из
Вашего описания ограничения на свободу с указателями. Ради интереса заглянул к ним на страничку, ну разбавили они взятый за основу С-шный синтаксис
паскалеобразностью, да еще приплели в него восторженности. Не прельщает, шарп или ява и то приятней.

Какие конструкции или ключевые слова из языка С компилятор С++ не поймёт?
Кто нибудь знает хоть один чисто си современный компилятор?
Например я С++ называю просто си, без всяких ++. Все знакомые кто в теме тоже говорят просто "сишка" или "писал на сях" и все имеют ввиду С++.

Дык, последние по такой логике - тот же самый си, только чего-то там добавили, приплели, восторженность всякая и т.д.
Синтаксис не главная часть языка... даже близко.

Имелось в виду гонят на более высокоуровневые(такие как плюсы, или еще более высокоуровневый раст, или JS) в пользу более низко-уровневых типа С или паскаля.
У раста такой синтаксис не случайно возник, а из за того, чтобы он был растом, чтобы программист привыкал к определенному стилю и технике. И ява или шарп ему не конуренты, у них своя ниша, у раста своя. Например на яве Вы не сможере писать под Atmega8, а на расте - запросто.

Любое высокоуровневое программирование - это набор определенных ограничений и правил. И чем выше уровень, тем их больше. Даже в ассемблера есть правила, тк он более высокоуровневый, чем машинный код. В машинном коде ограничений нет - пиши что хочешь и никакой компилятор тебе ничего не запретит, тк компилятора нет


Да запросто, вот выдрал из реального коммерческого проекта. Попробуйте скомпилируйте этот код стандартным плюсовым компилятором. Стандарт С++(даже 17й) этого не поддерживает, поэтому приходится делать на С.

Ну, например const у глобальных переменных, глобальные переменные с одинаковыми именами без extern в разных единицах трансляции. Оно откомпилируется, но не слинкуется.
SDCC.

Угу:

В Rust вообще есть очень "приятная" штука, причем вне блока unsafe - "затенение" переменной.
После такого так и хочется вспомнить какой-либо бейсик..
Я даже представить не могу, чтобы где-то в программе мне захотелось переменную в пределах видимости переделать в переменную другого типа.
Да и вообще, в части терминологии, в Расте столько занятного, что слова порой заканчиваются.

fn main() {
println!("Shadowing!");

let mut x: i32 = 5; // это изменяемая переменная. Если Вы не знали, что переменные могут быт неизменяемыми - Вы Раст не видели.
println!("x = {}", x);

x = 7; // допустимо присвоение значения
println!("x = {}", x);

let x: i32 = 8; // тут мы говорим, что x уже неизменяемая переменная - нормально, да?
println!("x = {}", x);

x = 9; // увы - низя присвоить
println!("x = {}", x);

let x = "Затенение"; // ха-ха - "затеняем" i32 в String
println!("x = {}", x);


} // main

Бывает, но не все же так ужасно
- Не понимаю чего так все все восхищаются Карузо. Слуха у него нет, голоса нет, картавит, шепелявит, фальшивит...
- А где ты его слышал?
- Да Рабинович вчера напел.

Это классная фишка(это такой вид полиморфизма), мне ее не хватает в плюсах, тулить вложенные блоки - это костыли да и поведение совсем не такое.
Когда-то(а многие и до сих пор) сишники не понимали зачем переменные обьявлять посреди функции а, не в начале. Хотя в плюсах без этого просто невозможно программировать. Это я к тому, что язык тут другой и привычный сишный или даже плюсовый стиль здесь, мягко говоря, не катит.


Да, очень мощный и сложный язык. От людей, которые имеют хороший опыт программирования на нем и плюсах слышал только положительные отзывы(в том числе в сравнении с плюсами), сам пока оценку дать не готов, дам через пол года, как напрактикуюсь немного.

Так не с бухты-барахты написал, а посмотрел на примеры программ. Первое, что бросилось в глаза - изобилие восклицательных знаков,
прям не программа. а обращение ЦК КПСС к народу по случаю очередной годовщины. Но после общепризнанного ошибочного включения 'println'
в Паскаль, writeln намекает, что разработчикам в детстве сильно нравился Васик. Синткасис в соновном сишный, слегка разбавленный
паскалеобразными объявлениями типов. Пробежался наискось по оглавлению документации - что-то напоминает очередной язык, который позиционируется как самый быстрый системный язык, который по сложившейся традиции тащит всякий непотреб в виде динамического типов или встроенной потокобезопасности.

По сути язык программирования, можно сравнить с конструктором лего, где его элементы соответсвуют одной или нескольким машинным командам, либо сравнительно небольшому набору (пролог, эпилог функций, фрейм стека для доступа к локальным переменным и прочее). И чем полнее коллекция таких элементов тем богаче язык. Это такие языки как к примеру тот же С/С++ или Объект-Паскаль.
"Богатые возможности" языков в виде "управляемой памяти" или "динамических типов", это уже увесистые кирпичи в таком конструкторе.
Причем ирония состоит в том, что апологеты таких языков еще утверждают что частое использование reinterpret_cast - плохой стиль программирования,
хотя сами употребляют его перманентно по умолчанию, скрыв от программиста.
Поэтому утверждения о силе и мощи этих языков все же спорны. Как по мне, язык без кирпичей и гибче и богаче, и отличаются такие языки лишь синтаксисом.

Глупо давать оценку столь сложному языку, просто пробежавшись по оглавлению, не написав на нем ни одной более-менее серьезной программы.


Плохой стиль программирования - это ручное приведение типов, но никак не автоматическая типизация. В ручном приведении, особенно таком, как reinterpret_cast, а хуже того - C-cast ни компилятор, ни рантайм не знают что там к чему приводится и как, вся ответственность лежит на программисте.
А в автоматическом преобразовании типов всем рулит автомат(а не человек), который и отвечает за корректность работы этого механизма. Динамическая типизация - это динамический полиморфизм - очень мощная техника на нынешнее время, без нее сейчас никак.


Самый богатый язык и без кирпичей вообще - это машинный код. Без запретов, без ограничений, без правил.

Нужна золотая середина. И для каждого видимо она своя. И ещё для разных задач "лучше" могут быть разные языки(сам не понял, что написал. Но смысл думаю понятен)

Золотая середина это такая, где программист и процессор делают минимум работы, а компилятор - максимум.
Но и тут приходится искать середину, отдавая доп. работу либо процессору, либо компилятору, либо программисту, иначе программы либо очень тормозят, либо очень долго пишутся и долго ищутся и правятся баги, либо очень долго компилируются.
Задача современных языков - как раз таки найти эту середину и каждый язык решает ее по своему, и не каждое такое решение подходит под конкретную задачу или конкретному программисту. Многие настолько зависимы от С, что даже плюсы им не под силу, не говоря уже про другие языки со слегка другим синтаксисом, он им гораздо важнее других вещей. Я их понимаю, сам такой, но все равно пытаюсь осваивать.

Та я не языку даю оценку, а мне непонятна Ваша подача материала: почему у Вас С++ и Rust парой ходят. Они же принципиально совершенно разные.
Пожалуй даже диаметрально противоположные.


Опять рекламный слоган.
Давайте уж своими словами: динамическая типизация - это прежде всего накладные расходы из-за оформления базовых типов в виде классов
из-за неизбежной необходимости табличной обработки операций с ними. Это далеко не ново, и вообще не прогрессивно.
"Безоасный код" или "чистый код" - это не улучшение языка, это удешевление последующей разработки программ.


Машинный код, то бишь ассемблер, - это не богатый и не бедный язык, он - единственный для выбранного процессора.
И все остальные языки неизбежно к нему приходят, только некоторые, особо пекущиеся о здоровье программиста, слишком окольными путями.

Это еще одно замечательное свойство С/С++: за ним всегда приблизительно видны те ассемблерные квантики, которые он будет генерировать.

Потому что это пока единственные обьектные языки, позволяющие программировать на голом железе.
Чем больше я изучаю раст, тем больше мне он кажется лучше плюсов. Но это только кажется, оценку я ему смогу дать, и то сугубо личную только тогда, когда сделаю на нем какой нибудь более-менее серьезный проект.


Точно такие же расходы(или больше) будут, если эту динамику сделать вручную на С или на асме. А там, где рантайм-поддержка на нужна - компилятор все сделает сам и дотошно проверит программиста, чтобы последний не тупанул, или уменьшит вероятность тупняка.


Машинный код богаче ассемблера, он позволяет сделать то, что не позволяет ассемблер (например выполнить недокументированную инструкцию процессора). А ассемблер богаче С, потому что на нем можно сделать то, что нельзя на С - вызывать строго определенные инструкции(документированные) проца в строго определенном порядке.

Согласитесь, что про программирование меги на расте Вы слегка погорячились.


Вы опять уводите в сторону: на С/С++ эту динамику не нужно делать, потому что он не поддерживает динамическую типизацию принципиально.
Динамическая типизация позволяет сделать короче исходный текст программы за счет увеличения рабочего кода и скорости выполнения.
Сомнительное удовольствие. Я уж лучше напишу имя второй переменной.


У ассемблера предусмотрена возможность непосредственной вставки (DB, DW) не только недокументированной инструкции,
но и даже отсутствующей в машинном коде инструкции, если вдруг такая бы появилась. Не проще ли считать ассемблер просто машинным кодом та и все.

https://github.com/avr-rust/rust https://github.com/avr-llvm/llvm пока что криво и с напильником, но работает. Москва тоже не сразу строилась


Можно пример кода? а то я на пальцах плохо понимаю.


В С++ тоже можно делать вставки ассемблерного и машинного кода, но С++ нельзя назвать ни ассемблером, ни машинным кодом Делая такую вставку Вы уже пишете не на С++, а на ассемблере или на машинном коде Я такие вставки и сам иногда делаю, но по возможности стараюсь избегать.
У ассемблера есть компилятор, который программиста уже проверяет, а у машинного кода и этого нет.

Ох как резко то всё в холливар скатывается, когда brag начинает рассказывать о новых модных языках и лямбдах в С++ )))))))))

aiwa, ну вы всё таки рубите с плеча, не разобравшись. Нельзя так, если конечная цель что-то отличное от флейма.
Восклицательные знаки - обязательная пометка макроса, что бы нельзя было как в си устроить спагети из не очевидных макросов. Зачем они нужны - если бы вы разобрались, выяснилось бы что они скрывают базовый стиль обработки ошибок что бы не заставлять писать лишнее в примерах и там где это не нужно.

Судя по конфигурационному файлу пока еще не криво: бэкенд-компилятор стандартный LLVM, а фронт-енд компилятор - СLang или GCC.
Таким макаром можно писать для AVR хоть на турецком. Посмотрим, когда построится Москва, сколько прогрессивного будет зарублено
и насколько он будет отличаться от собратьев.



Берем пример из раста подаваемый динамическое типизирование как прогрессивное преимущество:
{
а = 5; // это тип u32

a = "abcd"; // а это та же переменная, но имеющая совершенно другой тип.
}

с С++ уже надо вводить другую переменную:
{
u32 а = 5; // это тип u32

char b[] = "abcd"; //
}

C++ выделяет в фрейме стека 4 байта для переменной а и на этом накладные расходы заканчиваются. Информацию об "а" он хранит во время компиляции
и просто генерирует команды 32-битной обработки. Раст же поместит в 4-байта в стеке указатель на участок памяти, который содержит непосредственно саму
переменную "а", и информацию о ее типе, скорее всего в виде таблицы вызовов кода команд 32-ти битной обработки. Грубо говоря оформление типа u32
в виде класса с виртуальными функциями базовых операций 32-х разрядной арифметики.
Поэтому вместо одной ассемблерной команды для a+=5 в случае статического типизирования, раст вынужден будет выполнять call или jump на эту функцию сложения u32-типа.
Могу ошибаться, но мелкософтные делфи, которые обозвали шарпом делают именно так: Все типы происходят от одного предка. Оставленные для совместимости "int" да "char" соответствуют классам TInt и TChar.
И запись "int a = 5" означает "создать в управляемой куче объект класса Tint и инициализировать его 5." Названия, естественно, условны - передана лишь суть.


Так вроде бы и не сплеча: предварил, что языка не знаю и оцениваю только синтаксис. Причем такая оценка априори субъективна.

Выделение макроса все-таки, наверное, преимущество. Но вот выбор восклицательного знака мне кажется неудачным.
Все-таки стоит учитывать человеческий фактор.