[Гость TSerg]

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

[brag 0]

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

Все остальное - просто реклама.

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

 

Rust не знаю, но ,судя по описанию, для замены С++ он не годится.

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

 

Давайте расставим точки над i. С и С++ - это один язык только в разные времена. Один в те времена, когда в больших микросхемах было мало памяти, второй - когда в маленьких микросхемах стало до фига памяти.

Это 2 кардинально разных языка, просто С++ поддерживает С и то не полностью. Посмотрите на классический С-исходник, и на модерн-С++ , особенно асинхронный, с шаблонами,лямбдами, итд(например из моих примеров:).

Хотя одну и ту же задачу можно решить как на асме, так и на С, так и на С++, при чем одним и тем же способом. Например линукс, винда - это OOП, полноценные динамические обьекты, но написаны на С (привет legacy код).

И память тут не причем, пишу на мк с 256байт памяти и 1кб флеша на С++ и ничего, оба языка статические и у обеих абсолютно одинаковое требование по ресурсам(RTTI и exceptions не в счет).

 

Вы до недавнего времени даже не знали что ваш Node.JS писан поверх Сишной либы https://github.com/libuv/libuv

В папочку src то заходили? Чего дам одни .c файлы? wink.gif

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

[aiwa 0]

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

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

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

 

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

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

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

 

Это 2 кардинально разных языка, просто С++ поддерживает С и то не полностью. Посмотрите на классический С-исходник, и на модерн-С++ , особенно асинхронный, с шаблонами,лямбдами, итд(например из моих примеров:).

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

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

 

Например линукс, винда - это OOП, полноценные динамические обьекты, но написаны на С (привет legacy код).

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

 

И память тут не причем, пишу на мк с 256байт памяти и 1кб флеша на С++ и ничего, оба языка статические и у обеих абсолютно одинаковое требование по ресурсам(RTTI и exceptions не в счет).

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

Не только без RTTI и exceptions, но еще и без украшающий современный язык нововведений в виде лямбд и асинхронности.

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

И что остается от С++? - только привычка к С++-шной форме записи.

 

[brag 0]

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

Это C++ и Rust :)

 

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

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

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

 

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

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

 

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

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

 

но еще и без украшающий современный язык нововведений в виде лямбд и асинхронности.

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

 

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

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

Мало того, компилятор делает огромную работу и постоянно проверяет программиста.

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

 

И что остается от С++? - только привычка к С++-шной форме записи.

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

[AlexandrY 3]

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

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

 

С-и - это встроенные малые системы.

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

 

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

 

Асинхронность в C++ это не асинхронность в RTOS.

Здесь просто народ путается.

В C++ для ПК асинхронность это способ организации кооперативности.

Вытеснения как не было так и нет, управления реальным временем тоже.

"Асинхронность" С++ направлена на уменьшение отклика системы на действия пользователя.

Пытаться её как-то приладить в embedded все равно что возвращаться в глубокую древность, когда люди еще программировали PIC-и.

 

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

 

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

[Сергей Борщ 140]

С-и - это встроенные малые системы.

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

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

[brag 0]

С-и - это встроенные малые системы.

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

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

 

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

[AlexandrY 3]

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

 

Так попробуйте дискутировать.

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

 

Сразу давить на образования это не серьезно.

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

Но для меня доказательство только реальные рабочие проекты и только открытые.

 

[Сергей Борщ 140]

покажите что разработали на C++ в одиночку.

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

 

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

 

[aiwa 0]

Это не ограничение, это мера ради безопасности, заставляющая программиста работать в определенном стиле.

 

Причем тут стиль? Это тот случай, когда программисту нельзя доверить второй указатель. Говорит о силе языка или программиста?.

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

Все трудоемкую работу с указателями выполнил какой-нибудь сулейман ибн оглы с Индии или Пакистана.

Программистов становится все меньше - всех делают фокспрощниками.

 

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

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

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

 

 

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

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

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

 

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

 

[andrew_b 16]

"С++" - это "С" (плюс еще что-то).

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

[AlexandrY 3]

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

 

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

 

Базовые различия не в синтаксисе, а в экосистеме.

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

Т.е. там где и писать то нечего. Отсюда и непонимание что на самом деле ускоряет разработку и что делает ее удобнее.

 

А экосистема это окружающие микроконтроллерную платформу фреймворки стороннего софта.

С++ для встраиваемых систем уровня Cortex-M по сути мертв.

 

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

[Гость TSerg]

Тоже я скажу про С-и и 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 о безопасности, поскольку опять есть небезопасные возможности и много отступлений от привычного синтаксиса уже существующих языков.

 

[Kabdim 0]

Причем тут стиль? Это тот случай, когда программисту нельзя доверить второй указатель. Говорит о силе языка или программиста?.

Вы никогда не делали глупых ошибок с указателями? Модификатор const выброшен вами за ненадобностью? :)

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

[aiwa 0]

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

Не придирайтесь. Писал по памяти, вот написал "что-то". проверил оказалось первоначально он назывался "С с классами".

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

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

существования двух стандартов. Но в контексте данной ветки (Pascal или С++) это несущественно.

 

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

Использование усовершенствованного всегда удобнее и приятнее.

 

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

 

 

Вы никогда не делали глупых ошибок с указателями? Модификатор const выброшен вами за ненадобностью? :)

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

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

который все же не делает ограничений. Чаще при копипасте возникает ошибка сравнения в виде присваивания, либо наоборот.

Так и в этом случае компилятор выдает предупреждение.

Изменено 13 сентября, 2016 пользователем aiwa