С/С++, Почему до сих пор все сидят на древних языках вроде С и С++ Опции

[juvf]

Очередной хлоливар С/С++ vs Java/C# возник в месте обсуждения РТОС для мк. Я его переместил сюда.

Вброс

Читаю все это и волосы дыбом. Тем более что и работаю с этим. Почему программист должен думать об освобождении памяти? Почему многопоточность не поддерживается средствами языка? Почему до сих пор все сидят на древних языках вроде С и С++ (он недалеко ушел от С, пусть и поддерживает ООП, но все равно с ним обрушить любую систему на ура можно. Есть ли нормальные реализации Явы или С шарп для контроллеров? Иначе это хождение по граблям будет вечным. 15 лет в теме и все одно и тоже. И памяти то уже достаточно для Явы например, и все равно. От слов «указатель» и «приведение типов» тошнит уже в век, когда объемы флеш и озу - ничто, а время на выпуск - все, это анахронизм какой то

Читаю все это и волосы дыбом.

я когда вижу код на Perl - волосы дыбом, это не значит что Perl гавно.

Почему многопоточность не поддерживается средствами языка?

а почему в языке должна быть многопоточность? Язык - это всего лишь язык. А всё остальное - это библиотеки, фрэймворки. Нужна многопоточность - подключай boost, Qt, *RTOS.... или сам суперлупом обеспечивай. Такто можно заявит: Почему сигналы-слоты не обеспечивает язык? Почему extFat не обеспечивает язык? Почему KDE не обеспечивает язык?

Есть ли нормальные реализации Явы или С шарп для контроллеров?

нету. не нормальных, не ненормальных.
какая к чёрту жава на мк? Даже эти ваши линуксы пишут на си по сей день. не на жаве, и тем более не на с#. и жава.... для неё нужна жавамашина. какую жава машину вы запехнёте в мк с 1кБ ОЗУ? Всё это удел высокоуровнего программирования, окошки, форточки... даже для ПК драйвера пишут на Си/С++. Не разу не слышал чтобы кто-то написал низкоуровневый драйвер для ПК на жаве.
А по поводу с# на мк- вообще смешно.... ибо c# не не язык программирования, а "язык программирования виндоус". Вы бы ещё спросили "А есть нормальные реализации языка 1С для мк?". ))
см вики

C# — объектно-ориентированный язык программирования. Разработан в компании Microsoft как язык разработки приложений для платформы Microsoft .NET Framework....

Это нужно в мк с 256 байтами ОЗУ (да хоть и с 64 кБ ОЗУ) запихать .NET? А также для неё поставить Windows8.... c мэтро

С++ (он недалеко ушел от С, пусть и поддерживает ООП, но все равно с ним обрушить любую систему на ура можно.

Дак на ура и жавой рушатся приложения только так.

Посмотрите примеры программ на Java - там нет этого дебилизма. С++ позволит даже такое *(int *)0x40001234 = 0; На Яве вам никто не позволит пользоваться указателями, оных и нету, и никто не позволит приводить типы с уменьшением точности. С++ - это очень старый язык, он неплох для своих лет, но уже 2014 на дворе. Тот же ассемблер завуалированный.

А как в яве запись в регистр микросхемы? например в общем адресном пространстве 0x40001234 - адрес регситра RxDATA, а 0x40001236 - адрес регистра TxDATA. Как на Jave происходит обращение к этим регистрам?

С++ - это очень старый язык, он неплох для своих лет, но уже 2014 на дворе.

старый не знаяит плохой. Русский ещё старее, а на дворе 2014...
ДВС - ему больше 100 лет. а на дворе 2014. Но пока человечество не придумало лучше двигатель.

[Major]

А как связаны линукс и С++?
Про скуку просто смешно. Если Вы не используете:
1 автоматический вывод типов
2 static_assert
3 шаблоны (копипастите по случаю и без)
4 семантически безопасные контракты-классы (передаете указатели на структуры в функции)
5 про STL уже и так понятно, можно еще сказать про лямбды и семантику пеермещения
то Вы зря тратите время.
Прочитайте новый стандарт, или введение в него. Язык это не буковки и ключевые слова. Язык это фразы и ++ гораздо богаче С.
C++ тоже не идеал, но держаться за С (даже если это С99) сомнительная затея.

[AlexandrY]

А как связаны линукс и С++?
Про скуку просто смешно. Если Вы не используете:
1 автоматический вывод типов
2 static_assert
3 шаблоны (копипастите по случаю и без)
4 семантически безопасные контракты-классы (передаете указатели на структуры в функции)
5 про STL уже и так понятно, можно еще сказать про лямбды и семантику пеермещения
то Вы зря тратите время.
Прочитайте новый стандарт, или введение в него. Язык это не буковки и ключевые слова. Язык это фразы и ++ гораздо богаче С.
C++ тоже не идеал, но держаться за С (даже если это С99) сомнительная затея.

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

А то с STL мы тут уже разобрались - http://electronix.ru/forum/index.php?showt...6&hl=median
Ничего впечатляющего. Слезы.
В IAR вообще катастрофа.

[juvf]

Я ща википедию открою и еще больше лабуды из C++ перечислю.

какой лабуды? У с++ спектор шире си. На нём можно и для 8-битного процесора написать код не хуже чем на си, и для всяких монстров под управением Linux, Windows. На си конечно тоже можно для монстров писать, но для монстров и на асме можно слобать код. В таком же ключе можно поспорить си vs асм, что асм - это единственный нормальный язык, а СИ - это корявость, и что выстрелить в ногу в си, и приплесть сюда что русский древний, поэтому на асме нужно остаться, бла бла бла.

[AlexandrY]

какой лабуды? У с++ спектор шире си. На нём можно и для 8-битного процесора написать код не хуже чем на си, и для всяких монстров под управением Linux, Windows. На си конечно тоже можно для монстров писать, но для монстров и на асме можно слобать код. В таком же ключе можно поспорить си vs асм, что асм - это единственный нормальный язык, а СИ - это корявость, и что выстрелить в ногу в си, и приплесть сюда что русский древний, поэтому на асме нужно остаться, бла бла бла.

Некорректные аналогии.
С-и сократил писанину в несколько раз по сравнению с asm и был прорывом.
А С++ ее не сократил, а даже снова раздул. Это уже деградация, декаданс.

И это понятно, цикл старого всегда кончается деградацией.

[dxp]

Некорректные аналогии.
С-и сократил писанину в несколько раз по сравнению с asm и был прорывом.
А С++ ее не сократил, а даже снова раздул. Это уже деградация, декаданс.

Да, раздул. Например, эти пресловутые виртуальные функции. Ведь же целое слово ключевое придумали - virtual! И теперь такое объявление функции записывается длиннее, чем простое в С. Ну, правда, на С придётся для реализации того же функционала написать тучу кода с таблицами указателей на функции, проинициализровать их (а ещё объявления прототипов функций там надо вначале написать), и всё руками, и всё аккуратно - недайбох ошибиться, оченно подлые косяки получаются при некорректной работе с указателями и массивами, а особенно массивами указателей... Ну, да это фигня, настоящему С-кодеру это семечки, зато не придётся развозить эту писанину с virtual... Ну, а про STL вообще чего говорить - сплошная лишняя писанина, на голом С это делается в три строчки само собой и без ошибок.

[Xenia]

Да, раздул. Например, эти пресловутые виртуальные функции. Ведь же целое слово ключевое придумали - virtual! И теперь такое объявление функции записывается длиннее, чем Ну, правда, на С придётся для реализации того же функционала написать тучу кода с таблицами указателей на функции, проинициализровать их (а ещё объявления прототипов функций там надо вначале написать), и всё руками, и всё аккуратно - недайбох ошибиться, оченно подлые косяки получаются при некорректной работе с указателями и массивами, а особенно массивами указателей... Ну, да это фигня, настоящему С-кодеру это семечки, ...

Интересный (для меня) вопрос вы затронули. Хочу спросить, известно ли вам, как на простом C это может быть реализовано? Сама хотела бы вставить функции во внутрь структуры, то C этого не ест. Можно, конечно, как вы сказали, вместо функций указатели туда прописать, но тогда им инициализация нужна, и вызовы таких функций будут "косвенными", путем разыменовывания указателей на функцию.

Но если поглядеть на то, как родной C++ компилирует, то там вызовы функций-членов класса прямые (конечно, если перед этим они не были объявлены виртуальными). Как такое удается сделать, если С++ считать "надстройкой" над C, которая может быть транслирована на C препроцессором? В ведь именно так оно и было, по крайней мере, раньше.

P.S. Сама я C++ обожаю, но при программировании МК стараюсь его избегать - отпугивает излишний "динамизм", когда многое неявным образом заводится в куче. А я привыкла к спартанским ресурсам, когда под кучу памяти жалко, и хотелось бы всё по максимуму держать в статике.

[dxp]

Интересный (для меня) вопрос вы затронули. Хочу спросить, известно ли вам, как на простом C это может быть реализовано? Сама хотела бы вставить функции во внутрь структуры, то C этого не ест. Можно, конечно, как вы сказали, вместо функций указатели туда прописать, но тогда им инициализация нужна, и вызовы таких функций будут "косвенными", путем разыменовывания указателей на функцию.

Реализовать можно по той же схеме, которую использует компилятор С++. Только толку от этого будет мало - всё - определение таблиц указателей на функции, указатели на эти таблицы, инициализацию таблиц и указателя, объявление прототипов и т.д. - придётся делать руками. А профиту ноль. Ведь рулез от виртуальных функций (методов) именно в том, что программисту не нужно заморачиваться на контроле соответствия объектов и их функций - всё работает само. В С уже тот факт, что нельзя отнаследовать одну структуру от другой, сводит почти все плюсы технологии к нулю. Но руками всё это можно делать, это будет своего рода паттерн проектирования. В плюсах это реализовывается так.

В каждом классе, где объявлена хотя бы одна виртуальная функция (метод), создаётся служебный указатель vtbl - это указатель на таблицу указателей на виртуальные функции объектов этого класса. Эта таблица создаётся отдельно и инициализирутся адресами виртуальных фукнций класса. При виртуальном вызове происходит не прямой вызов функции, а (vtbl->vtable[<offset>])(), т.е. по указателю vtbl производится обращение к таблице указателей, берётся адрес требуемой функции (по смещению <offset>) и уже по этому адресу производится вызов функции. В реальности, например, на MSP430 виртуальный вызов выливается в дополнительные две регистровые однотактовые команды.

Описанный подход гарантирует, что на рантайме будет вызван метод класса, к объекту которого применяется вызов функции. Ну, собсно, это основа динамического полиморфизма, позволяет строить иерархии классов, у каждого из которых свои методы. Следует отметить, что при всей мощи, красоте и эффективности подхода не надо его применять везде. У него своя "ниша". Например, он отлично ложится на реализацию GUI или его удобно использовать в парсерах коммуникационных протоколов и их стеках. Это просто средство. Которое рулит там, где оно эффективно. Очень часто начинающие по неопытности пытаются всё делать на методах, в результате получают сложные перекрёстные зависимости, оверхед и прочие проблемы.

Но если поглядеть на то, как родной C++ компилирует, то там вызовы функций-членов класса прямые (конечно, если перед этим они не были объявлены виртуальными). Как такое удается сделать, если С++ считать "надстройкой" над C, которая может быть транслирована на C препроцессором? В ведь именно так оно и было, по крайней мере, раньше.

То, что С++ является надстройкой над С - глубокое заблуждение. С++ является надмножеством С, но это совершенно самостоятельный язык и его конструкции не могут быть "странслированы на С препроцессором". И компилятор С++ - совершенно отдельная программа, работающая по своим правилам. Из С++ на С странслировать код технически несложно, но это ни разу не препроцессор. И просто такая задача давно уже никому не нужна. Такой компилятор в истории был, он был написан самим Б.Страуструпом на начальном этапе разработке С++ и назывался "С с классами". Страуструпу было удобно использовать уже имеющиеся С компиляторы - это избавляло его от написания back-end и позволяло сосредоточиться на отработке правил нового языка.

P.S. Сама я C++ обожаю, но при программировании МК стараюсь его избегать - отпугивает излишний "динамизм", когда многое неявным образом заводится в куче. А я привыкла к спартанским ресурсам, когда под кучу памяти жалко, и хотелось бы всё по максимуму держать в статике.

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

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

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

[AlexandrY]

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

Но пока мы даже скриншоты вашего эпического GUI не видели.
Если C++ такой мощный, то и GUI видать должно превосходить по изобразительным возможностям какую-нибудь uC/GUI многократно?

P.S. Сама я C++ обожаю, но при программировании МК стараюсь его избегать - отпугивает излишний "динамизм", когда многое неявным образом заводится в куче. А я привыкла к спартанским ресурсам, когда под кучу памяти жалко, и хотелось бы всё по максимуму держать в статике.

Вот он! Голос народа!

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

Я бы сказал C++ отторгается всей embedded экосистемой.