Новая этика?



Конечно, ждем.

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

Написал набросок, без строгих требований к интерфейсу. Проверил на ПК (release).
Выравнивание на кэш сделал, гонку кэша запретил.
10000000 случайных значений на окне 32.
Мой код 2,7 сек.
Стартовый код из темы про медиану 11 сек.
Генератор чисел: 250 мс.
В субботу скомпилирую для keila. В симуляторе проверить будет достаточно (такты процессора)?
Код и результат симуляции выложу.

Нормальный код. Код как код.


А зачем? Зачем использовать 64 битный суперкомп где справится 8битник?
Человек живет не для того, чтобы есть, а ест для того чтобы жить.

А то как в анекдоте: купил автомобиль и сколько всего успел:
и колеса переобуть и масло сменить и на автобазар слетать за свечами..

Суета это.

Сообщение отредактировал A. Fig Lee - Sep 3 2014, 20:45

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

Мне кажется, что С++ тесно связан с такими понятиями как "архитектура приложения", "шаблоны проектирования" и "командная разработка", и существенно отличается от С в качестве инструмента для реализации этих подходов.

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

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

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

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

Вообще-то, в названии темы говорится не о том, почему C++ лучше C, а что C# лучше убогого C++.

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

А отсюда если что и выросло, так это контейнеры, итераторы, алгоритмы, в общем, STL.

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

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

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

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

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

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

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

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

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



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


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

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

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

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




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

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

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

Проникся, вдохновлен и нацелен на использование C++ в микроконтроллерах, спасибо dxp!
Только не соображу, как на объекты программу делить? Обычно, где-то передается, где-то принимается. Куда задвигать функцию пересылки (приема)?