+1 У "правильного" программиста на ассемблере со временем накапливается своя библиотека решений, причем - досконально отработанных, оптимизированных и наглядных, так что программирование на ассемблере сложности уже не представляет ИМХО, ассемблер - единственный язык, понятный и машине, и человеку, все остальное - лишь оболочки и переводчики разной степени кривости

Общение двух, это излишне и уже не по теме получается.
По С/C++ на МК: понял что писать можно только если приперло. После C++11 и других языков все кажется серым и убогим.

По медиане: сделал обобщенный алгоритм, который принимает любой тип объектов с оператором сравнения '<' (другие операции не нужны).
Сложный объект копируется один всего раз. Функция nth_element оказалась не нужна (обошлось min и max_elements).
На ПК обгоняет Ekstrom в 1,7 раз (N=32, случайный поток + пила). На единицу выходят только для N=4.
Вечером залью в реп. Кому надо пользуйте, вопросы можно в личку.

В одной канторе ПО для МК(для всякой мелочи) пишут исключительно на UML, а вы говорите С++ не для эмбэддед.

Всем привет!
Очень интересная тема! Люблю такие.

Мне показалось, что большенство ответов пытаются перевести обсуждение asm/C/C++/C# (ява как аналог C#) из технологической области в филосовскую. Это не правильно.
Я знаком со всей линейкой и вот что скажу.
По идее переходя от этапа к этапу, т..е. от ами к С, к С++ и к С# мы жертвуем чем-то ради достижения чего-то.
При переходе от ассемблера, мы унифицируем структуру процессора (его ассемблер на все случаи жизни) в язык С. При этом обязанность использования ассемблера максимально эффективно мы отдаем компилятору.
При переходе к С++ мы унифицируем вызовы виртуальных ф-й в вызов виртуальных методов и наследование. И еще динамическое размещение объектов. (С++ имеет смысл только если используется virtual. Все остальное в нем вторично). Оптимальность вызова и размещение памяти мы снова передаем компилятору.
При переходе к С# мы вообще переходим от компилятора к интерпретатору. Это когда компилятор думает не о том как преобразовать язык в ассемблер, а о том, как вызвать блок из фреймворка (библиотеки оптимально реализованных блоков). И вот этот момент очень важен и как-то не прозвучал здесь. Работа с памятью и указатели, это все вторично. Изначально .NET можно сравнить с громадной DSP библиотекой в которой содержаться все блоки обработки, а C# это такой язык, который эти оптимально реализованные блоки соединяет. Чисто симулинк.
Канечно, при каждом переходе мы приносим в жертву производительность. Но приобритаем мы функциональность и удобство в отладке и разработке. Но процесс этот нелинейный. Чем сложнее приложение, тем меньше будет разница в производительности кода написанного на С# (с использованием оптимизированных библиотек, написанных на С или даже на asm) и кода написанного на С. В связи с тем, что все больше ф-й уже реализованно в виде оптимизированных библиотек, выигрывает тот, кто может не реализовывать и писать эти самые библиотеки, а соединять блоки между собой и использовать их.
Лично мне очень нравится C#. Просто потрясный язык и среда. MSVS13 просто фантастика! Но даже VS2008 неплохо, по сравнению с CCS и эклипсом.
И еще. Стоимость процессоров и памяти упала настолько, что смысла выбирать и оптимизировать ее просто нет.

И совсем еще. Переводя разработку для устройств на C#, вы автоматом переносим разработку из области embedded в разработку software. Это совсем другие правила, стоимость разработки и рынок труда.

В общем резюмируя: самые критические по производительности и времени части я пишу а ассемблере. Менее критические на С. Затем, инициализацию и размещение real-time объектов я пишу на С++. Просто потому что это удобно. И приложения не критические к производительности, и где это возможно, я пишу на С#.Отказываться от asm, С или С++ я не собираюсь, хотя мой любимый язык именно C#.

Как-то так.

Не расскажете, чем виртуальные функции отличаются от виртуальных методов? И как одно "унифицируется" в другое?



Правильно ли я понял, что инициализация и размещение выполняются исключительно путём виртуальных вызовов?

И ещё поясните, пожалуйста, что такое "real-time объекты"?

Википедия утверждает, что в отношении к C++ это слова-синонимы.


Нет. Инициализация и размещение происходит при вызове конструктора (функции, одноименной с именем класса), который вызывается неявно при создании объекта. Конечно, при желании конструктор, как и любую другую функцию, тоже можно объявить виртуальным, но вам оно надо?


А фиг его знает! Я полагаю, что это объекты , порождаемые динамически в процесе работы программы с коротким временем жизни - порождаем объект, используем, объект самоудалился. Но скорее всего эта терминология не из языка C++, а откуда-то еще.

В С можно вызывать ф-и через указатели на эти ф-и. Я просто это называю виртуальными ф-ми. Всю инициализацию, в зависимости от того что вы хотите вызвать, естевственно Вы должны делать сами.
В С++ это делается автоматом в зависимости от типа создаваемого объекта через таблицу виртуальных методов.
Ну и указатель на объект не надо передавать самому. Это делает компилятор.
Недостаток данного метода, и почему его нельзя использовать в приложениях критичных к времени исполнения (real-time) вот в чем. Вместо того чтобы просто взять и вызвать метод, С++ сначала определяет тип объекта, потом находит таблицу виртуальных методов, и только потом вызывает метод.
Если я это делаю на С, то я просто беру и вызываю: my_object->function1(my_object, ...). my_object это структура объекта. Но при этом я сам руками должен инициализировать указатель на function1.
В С++ я просто пишу: my_object->method(). А компилятор добавляет в зависимости от типа нужный метод.
В общем на С++ это делает компилятор, а на С я сам. Если мне нужно чтобы метод быстро и часто вызывался без большого оверхеда, я использую С. Например метод фильтрации в обработке аудио. А если мне нужно использовать менеджер памяти для инициализоции кодека, то я использую метод mem_manager->Alloc(...), перед тем как кодек будет запущен. И мне вообще всеравно сколько он выполняется.
Как-то так.



Не совсем. Я имел в виду то, что если часть кода не критична к времени выполнения: парример инициализация кодека или олгоритма, то я использую виртуальные методы например для менеждера памяти: (Alloc, Free, Clean). Эти методы вызываются на этапе инициализации кодека, но не приложения. Но когда инициализируется приложение, оно уже определяет типы используемых менеджеров. И т.д.
Еще поясню.
У кодека внутри есть секция которая отвечает за инициализацию его самого. Именно эта секция размещает память, последоваетльность блоков и т.д. И здесь этот кодек вызывает виртуальные методы. А сами объекты били размещены приложением, или даже мной в ф-и main() в зависимости от конфигурации и типа приложения.


Это те объекты которые вызываются постоянна как поток и критичны ко времени исполнения и ресурсам. Например блоки фильтрации входного сигнала с АЦП.
Если обобщить, то вот что получается.
Например блок фильтра на 128 отсчетов выполняется за 100 мкС, а расчет коэффициэнтов для этого фильтра выполняется 3 секунды. Но ... расчет коэффициентов я делаю один раз, при старте приложения, а вызов фильтра я делаю 1000 раз в секунду на протяжении всей жизни приложения. В итоге получается что фильтр у меня написан на ассемблере, а расчет коэффициентов я могу написать хоть на С++ хоть на яве. Даже 10 секунд не будут критичны.
Так вот, фильтр в данном случае - real-time.

Вижу не читали новейшее исследование по теме выбора языков - http://macbeth.cs.ucdavis.edu/lang_study.pdf

Обязательно подучите TypeScript.
Получите наиболее качественный код.






Ну нееее..т, это просто будет DSP блок и не более.

А realtime-ом это станет если фильтр будет прерываться еще кучей задач, обслуживать несколько асинхронных входных и выходных потоков и все сделает вовремя.

Странная статья. Я понимаю когда сравнивают С и раскаль или С# и яву. Но зачем все в кучу мешать?




Да. Слово вовремя здесь решает.

Тов. Б.Страуструп не согласен с ru.wikipedia, он утверждает, ведя речь, конечно, конкретно про С++, что

"Виртуальные функции иногда называют методами". (с).

Это точная цитата. Заметьте, не виртуальными методами, а просто методами, сиречь, синонимами являются термины "виртуальная функция" и "метод". Конкретно в контексте ЯП С++. В других ЯП это может быть по-иному.

Впрочем, товарищ, к которому был вопрос, уже пояснил, что виртуальными функциями он называет обычные функции, которые вызываются через указатель. Правда, непонятно, почему и что в них такого виртуального. Вызвал функцию обычным образом - она обычная, вызвал через указатель - стала виртуальной. Та же самая функция. Я вот всегда полагал, что функция - она сразу и всегда либо обычная, либо виртуальная, и это определяется квалификатором virtual в её объявлении и порождает вполне конкретное поведение. Ну, да ладно...



Посмею вас заверить, что к терминологии С++ это не имеет ни малейшего отношения.


Я до сих пор наивно полагал, что в С нет виртуальных функций.


Вот этот момент можно поподробнее? Как "С++ сначала определяет тип объекта"? Он RTTI анализ с ним производит, что-ли? И когда я писал, например, на MSP430 программу, там вызов виртуальной функции вылился в в две быстрых, однотактовых регистровых команды:

1. загрузка vptr регистр;
2. косвенный вызов функции по адресу из vtbl, которая адресуется из регистра (со смещением, если указателей в vtbl несколько), загруженного на предыдущем шаге.

В общем, я тут не видел, чтобы "С++ определял тип объекта". И, соответственно, каких-то накладных, мешающих real-time тоже не усматривается. Код на С (или асме), который будет звать функции из таблицы указателей, будет ровно таким же. Упомянутый тов. Б.Страуструп утверждал (в книжке "Дизайн и эволюция С++"), что когда проектировался механизм виртуальных функций, была цель получить максимально эффективное решение, при котором всё, что можно разрешить на этапе компиляции, должно быть разрешено на этом этапе, а для рантайма оставить только малое количество простых действий - как то: взять указатель vptr у конкретного экземпляра, по нему добраться до vtbl и по адресу из неё вызвать функцию. Никаких определений типов объекта на рантайме уже не выполняется, всё определено и проверено статически на этапе сборки.

Почему же куча?
Вы разве не знаете что одним из языков программирования beagleboard и других подобных встраиваемых плат является JavaScript?
Дроны, квадракоптеры программируются на JavaScript.
Я использую JavaScript в своих разработках.

Теперь, когда узнал о TypeScript обязательно на него перейду.
Все таки наиболее защищенный от ошибок язык.

что-то мне подсказывает, что это не могли быть однотактовые регистровые команды ))
что всего две - вполне верю.

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


Посмею вас заверить, что к терминологии С++ это не имеет ни малейшего отношения.



Не совсем так, но в общем верно. Все зависит от компилятора и того как вы реализуете вызов. По личным наблюдениям, С++ в разы медленней (чисто вызов). Именно поэтому я использую в некоторых моментах именно С. Не потому что я против С++, а просто С быстрее. И еще учитавайте, что С++ компиляторы разные на разных платформах.
В общем, если говорить о asm/C/C++, то на асме у меня 10 ф-й, на С - 20, а на С++ все остальное...
Как-то так.

Десять баллов!
Обсуждение действительно становится нескучным.

Я тут недавно взял и переименовал все свои файлы в проекте с .c на .cpp.
Просто ради эксперимента, чтобы проверить насколько легко перейти на C++.
Вышло в лет, и медленней работать почему-то не стало .

Потом правда вернул обратно. Зачем этот гем.. если все вокруг написано на C-и.

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

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

Уболтали!
Вспомнил я почему я использую С вместо С++! Хотя изначально все было именно на С++!
В общем так.
Действительно, разницы между С++ и С при вызовах виртуальных методов практически нет, НО!
Разница появляется когда мы начинаем вызывать объекты из кешированной памяти.
Если в случае с С я могу руками указать что структура будет размещаться в быстрой памяти (точнее я ее просто могу разместить динамически там), то в случае с С++ я не могу сказать компилятору чтобы он таблицу виртуальных методов для данного класса хранил в быстрой памяти. Либо я указываю что все таблицы для всех классов должны храниться там, а это как правило больше чем доступно памяти, либо ВМТ должна храниться во внешней памяти, и тогда облом с быстродействием...
Но еще скажу, что для С и для С++ я использую С++ компилятор.
Т.е. разница не в компиляторе как таковом, а в методах вызова.

Вам мало троллинга в теме про SVN, вы пришил сюда порезвиться?
Хорошо, покормлю немного.

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

Что значит честно?

Обязательно применить библиотеку шаблонов?
Так они показали свою неэффективность. Cм. примеры выше.

Или обязательно оформить модули в классы и придумать им предков с виртуальными функциями?
Так это значит зафлудить свои тексты и разбросать семантические единицы по файлам, потерять скорость кодирования и усложнить отладку.

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

Что еще надо честно сделать?

Сначала ответьте на вопрос: зачем вы переименовали файлы из *.c в *.cpp?

очевидно, чтобы лично убедиться, что "С++ в разы медленней (чисто вызов)"

Как зачем? Чтобы показать какой я крутой программер.
Вот дескать, все пишу на C++.

Речь шла о накладных расходах на виртуальный вызвов, сам вызов, ессно, не учитывается - он ровно тот же по затратам, что и обычный вызов. Насчёт однотактовых, вы правы, я, наверное, погорячился: первая команда - загрузка vptr по this (который уже в регистре) - это загрузка из памяти, она занимает пару тактов, вторая - загрузка адреса из vtbl, т.е. тож из памяти, опять пару тактов.

Раз уж мы разобрались с С и С++, определив что ООП можно и на С делать, если нужно...
Предлагаю приступить к обсуждению С#.
Интересно мнение тех кто пишет на С# под WinCE, т.е. использует .NET Compact Framework. Яву я предлагаю не обсуждать, так как тормоза которые она показывает на гигагерцовых телефонах отбивает всякое желание ее использовать. А вот C# вполне себе шустренько летает, если конечно бездумно не использовать.

Как я уже писал, лично мне C# очень нравится. Иногда напрягает кастрированность .NETCF, но это мелочи. В принципе не так критично. Например нету нормального WCF, но базовые ф-и есть, и то хорошо.

А я предлагаю этого не делать.

Причина популярности языка C/C++ среди электронщиков именно в том, что мы на нем прошивки для МК пишем! Поскольку этот язык позволяет создавать рабочий код при минимальной поддержке операционной системы, а зачастую и при полном отсутствии последней. Все же остальные языковые монстры требуют для своей поддержки не только операционную систему, но и порой очень больших по объему библиотек.

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

Убедили! В принципе согласен, что С++ наиболее универсальное и оптимальное решение для микроконтроллеров. Тут весь вопрос в том, а что можно называть микроконтроллером?
Уже сейчас можно найти за 20 баксов "микроконтроллер" в виде платы с мегабайтами памяти, питанием и т.д. и готовой ОС.
Да что там... 4-х ядерный 2 ГГц SoC с графикой и DSP стоит 20 $.
В итоге получается что время на разработку стоит дороже чем переплата за отдельный девайс.
К чему это я?
К тому, что мне кажется что сейчас четко видна тенденция переноса решений с PC на "микроконтроллеры". Если раньше нужен был сервер, мощный комп и сервер БД. то теперь все можно делать локально на флешке.
Поэтому понятие embedded сильно размывается, так как маленькое устройство может содержать в себе ресурсы больше чем большущий сервер еще каких-то 10 лет назад.
В итоге получается что С++ остается только за драйверами и реалтаймом.

Ну да ладно.

Весело тут у вас, особенно с переименованием *.c в *.cpp.

А, тем временем, Microsoft делает очередной крупный шаг в сторону предоставления свободных средств разработки:

Visual Studio Community 2013
A full-Featured IDE - Free.
Start coding the app of your dreams for Windows, Android, and iOS.
http://www.visualstudio.com/products/visual-studio-co..

Если говорить о Workstation/Server, то кроме системного программирования,
где управление аппаратными ресурсами и связанными с ними структурами данных
и kernel API-неотемлемая часть, C/C++ нужно там где требуется свехпроизводительность
и наносекундный отклик, которе во многом обеспечиваются глубокой оптимизацией струкур данных и
блоков кода на привязанность к отображению на кэши и протоколам когерентности для
мультипроцессорных систем, продвинутых алгоритмов синхронизации
потоков с использование соответствующего API и быстрых алгоритмов упраления памятью.
Поэтому С/С++ очень интенсивно используется в серверной части програмных продуктов для
электронной торговли, в частности почти все market data feed (FIX over UDP), HFT algorithms.

Скоро все перейдут на Яву)

Не факт
Познавательно Снимок базы проекта RosettaCode

P.S. Github добавил и поиск по тегам в строке поиска в форме Topic:тэг (можно и несколько Topic:тэг перечислить)
но проекты ещё мало классифицированы по тегам и поиск по словам даёт больше проектов.
Проверил и текущий Topic:Forth

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

Задачи по программированию на языке C++, часть 2 (обновление)


Задачи по программированию на языке C, часть 1 (обновление)


Задачи не тривиальные, сложные ... рассчитаны на программистов, имеющих уже изрядный уровень в C/C++.

Чтобы добавить вашему весёлому обсуждению интриги, я добавлю сюда загадку:
- обращали ли вы внимание, что на сегодня ("аж 2017-й год" - как кого-то там волнует) осталось крайне мало языков программирования (среди широко применяемых), которые выполняют компиляцию программного кода в нативный код процессора?
- на сегодня это только C, C++ и Go ... а среди продвинутых "не древних" - так и вовсе нет.

Вот и загадка: кто сможет назвать ещё языки программирования (из широко применяемых!), которые предполагают компиляцию в нативный (машинный) код?

P.S. Все "отмершие" языки, начиная с FORTRAN и, особенно, всю линейку от Pascal (Delphy, Turbo..., Modula-2, ...) - не надо беспокоить

P.P.S. И ещё более - всякий дерибас индивидуального применения, слепленный "на коленке", типа язык D и т.п. - не называть.


Я даже табличку здесь рядом привёл, чтобы не показаться предвзятым: Паскаль повержен - впервые за много лет

В процессе развития - Rust, в процессе отмирания - Fort.

Forth никогда не компилировался в нативный код, а компилировался в собственный байт-код стековой машины, т.е. код требовал исполняющую среду.



Rust - никогда не был в числе применяемых, восстребованных языков, по свежему рейтингу TIOBE Index for April 2017 от зависает там где-то на 41-й позиции ... и так навсегда и останется "в процессе развития"...

А как же форт-процессоры, вроде GA144 или синтезированных в ПЛИС?

Moderator: Все, хватит, тему закрыл.