"Перекличка куликов, часто с фальшивым голосом, из своего болота и ни о чем." (С)

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


с чего бы это? Аргументы?


Это 2 кардинально разных языка, просто С++ поддерживает С и то не полностью. Посмотрите на классический С-исходник, и на модерн-С++ , особенно асинхронный, с шаблонами,лямбдами, итд(например из моих примеров.
Хотя одну и ту же задачу можно решить как на асме, так и на С, так и на С++, при чем одним и тем же способом. Например линукс, винда - это OOП, полноценные динамические обьекты, но написаны на С (привет legacy код).
И память тут не причем, пишу на мк с 256байт памяти и 1кб флеша на С++ и ничего, оба языка статические и у обеих абсолютно одинаковое требование по ресурсам(RTTI и exceptions не в счет).


Причины почему там С-файлы я уже назвал.

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


Очень просто: описанное Вами как преимущество запрет иметь два указателя на один объект - это всего лишь ограничение языка.
А ограниченный в чем-то язык уже не сможет полноценно заменить язык без ограничений.


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


Вообще-то полноценные динамические объекты винды и объекты ООП С++ никак не связаны. мелкософт даже просит не путать.


Не только без RTTI и exceptions, но еще и без украшающий современный язык нововведений в виде лямбд и асинхронности.
Не уверен, но подозреваю и без создания динамических объектов посредством "new" - потому что из 256 байт выкидывать что-то на обслуживание этой роскоши, та еще по паре байт на указатель довольно неразумно.
И что остается от С++? - только привычка к С++-шной форме записи.

Это C++ и Rust


Это не ограничение, это мера ради безопасности, заставляющая программиста работать в определенном стиле. Можно без проблем втулить unsafe-block, но если Ваша программа состоит из кучи unsafe-блоков, значит Вы делаете что-то не так - мало опыта. Аналогично, если в С++ у Вас куча reinterpret_cast - программа написана криво, а если там хоть один С-style cast, значит программу точно надо ставить на паузу и идти учить C++.


Многие считают лаямбды просто синтаксическим сахаром для функторов, но это нет так, они кардинально отличаются. Это все равно, что считать С синтаксическим сахаром для асма (mov r0, r1 vs r0 = r1 )


Зато на плюсах реализуются гораздо проще и безопаснее, чем у этих линуксов и виндов на С.


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


Без динамического аллокатора ессно, зато с placement new - создание обьекта в статической памяти. Хоть и память статическая, но С++ рулит в полный рост - лямбды, шаблоны, виртуальные функции итд все работает как обычно.
Мало того, компилятор делает огромную работу и постоянно проверяет программиста.
Все мы люди и человеческий фактор работает у всех, компилятор уменьшает его влияние на скорость разработки.


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

С-и - это встроенные малые системы.
С++ - это коллективная разработка.

Т.е. разница как между мягким и круглым. Время и развитие тут не причем.

Асинхронность в C++ это не асинхронность в RTOS.
Здесь просто народ путается.
В C++ для ПК асинхронность это способ организации кооперативности.
Вытеснения как не было так и нет, управления реальным временем тоже.
"Асинхронность" С++ направлена на уменьшение отклика системы на действия пользователя.
Пытаться её как-то приладить в embedded все равно что возвращаться в глубокую древность, когда люди еще программировали PIC-и.

Такая же точно "асинхронность" есть и в Delphi. И те же лямбды есть. И шаблоны.

И каким образом связана многоядерность и эта псевдо-асинхронность C++?

Александр, прекращайте проповедовать свои заблуждения! Я не знаю вашего уровня владения 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 есть все же неоспоримое преимущество перед С++: там уже все вылизано проверено и посыпано песком.



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

Сообщение отредактировал aiwa - Sep 13 2016, 09:18