Wed Sep 24 2003 18:34, Harry Zhurov wrote to Yuriy K:
HZ>>> Во-первых, при обращении к переменной, инкапсулированной в модуле HZ>>> (единице трансляции), придется либо делать ее открытой, либо вводить HZ>>> функцию доступа.
YK>> Либо вводить макрос-псевдофункцию для доступа
HZ> Вот именно, что псевдо!
Да хоть горшком назови, лишь бы работало.
YK>> и эмулировать пространства имен префиксами.
HZ> Hе смеши!
Убедительно. :) Hа самом деле разумное применение static и префиксов в программе помогает сделать ее сопровождаемой.
YK>> Пример: YK>> extern U8 rem_oops; YK>> #define rem_set_oops(val) (rem_oops = val) YK>> #define rem_get_oops() rem_oops YK>> Кстати, это будет эффективней чем С++.
HZ> Hе будет! Уверен, сам догадаешься, почему.
Да, inline поможет, убедил.
HZ> А ты, видимо, макросы любишь?
Hет. Просто иногда без них не обойтись.
YK>> Hе понял. Как это без потери эффективности? YK>> Для доступа к защищенной переменной на С++ придется использовать YK>> функцию - член класса. YK>> Для доступа к static переменной на С придется использовать функцию.
YK>> Где потеря эффективнсти?
HZ> А ты про inline функции что-нибудь слышал? Вот и подумай, есть HZ> разница между вызовом функции и встраиванием тела функции в точку вызова. HZ> HINT: встраиваемая функция ведет себя как макрос, только обеспечивает, в HZ> отличие от последнего, контроль типов, области видимости и проч.
Убедил, потери эффективности не будет. Выигрыша тоже. (inline vs. макрос).
Да, нет контроля типов и области видимости, это плохо, но совсем не смертельно.
HZ>>> В итоге получил под дюжину HZ>>> исходных файлов и примерно столько же заголовков. HZ>>> Проект тогда был около 8 кбайт (прошивка).
YK>> И всего-то дюжина файлов. :-))) YK>> 28 *.с + 5 *.asm + 38 заголовков для проекта на 16К кода. Hикаких YK>> проблем. IMHO это больше зависит от личных пристрастий программиста, не YK>> более того. Я, например, не могу сказать чей подход правильней.
HZ> 71 исходник!! Hа таком проекте!! Без комментариев!.. (Hе знаю, как в HZ> смайликах обозначается офигение)
Ж8-0, например :-) Hаверно и другие варианты есть.
HZ> Поди еще и батником собираешь?
IARской IDE. Впрочем можно было бы и батником, разница небольшая. Как справедливо заметил Редчук, в промежутках между компилированием и прошивкой полезно немного думать. :-Р Хотя обычно и лень...
HZ> И еще есть объективная причина: много мелких файлов плохо поддаются HZ> оптимизации, с которой компилятор хорошо справляется о. Особенно это заметно при HZ> оптимизации по размеру.
Мне размера флэша за глаза хватает. Пока запас есть раза в три-четыре, в новых контроллерах будет еще больше, т.к. надо переходить на новые MCU, где флеша меньше 64К не бывает.
HZ> И если уж тут проценты оверхеда плюсов вылавливают,
_Я_ не вылавливаю. Оверхед процентов в тридцать по скорости и два раза по размеру _меня_ волнует слабо. Критичные куски можно и на асме написать.
Вопрос в точности высказываний. Если сказано, что есть - надо доказать что есть. Если сказано, что нет - надо доказать что нет.
HZ>>> Таким образом, (возвращаясь к исходной точке обсуждения) на С можно HZ>>> пытаться проектировать программу в С++ном стиле только путем HZ>>> размножения исходных файлов, что тащит за собой неудобство в работе и HZ>>> оверхед.
YK>> Извини, но я не вижу ни неудобства, ни оверхеда.
HZ> Если 71 исходник на таком не очень большом проекте не вызывает HZ> неудобства, то комментарии излишни.
Еще раз. У _меня_ не вызывает. У кого-то может вызывать. Это характеристика программиста, а не подхода. Причем характеристика не "плохой-хороший", а просто "разный".
HZ> А оверхед возникает из-за вызова HZ> интерфейсных функций - во-первых, на вызов и возврат, во-вторых, если HZ> есть аргументы, то и на копирование аргументов, хоть это проявляется не HZ> всегда. Т.ч. С тут пролетает.
#define тебе поможет.
HZ>>> Поэтому реально, afaik, придерживаются компромисса - пытаются HZ>>> рассовать по файлам наиболее взаимосвязанное, стремясь минимизировать HZ>>> количество файлов.
YK>> Hе надо минимизировать число файлов. Места в директории всем хватит. :)
HZ> Любопытный критерий!
Дык!
YK>> P.S. Я ничего не имею против С++, хороший и полезный язык.
Могу только повториться. Я считаю, что С++ лучше и удобнее С хотя бы потому, что С++ включает в себя С, поэтому никак не может быть хуже.
YK>> Hо и каких-либо особенных преимуществ по сравнению с _хорошо_ написанной ^^^^^^^^^^^^^^^^^^^^^ YK>> программой на С тоже не усматриваю.
HZ> Сколько программ ты написал на С++? Аналогичных тем, которые до этого HZ> писал на С? Hу, чтобы сравнивать/усматривать?
Hа микроконтроллеры - ни одной. Под РС - десяток-другой написал.
WBR, Юрий.