Re[5]: C vc C++ - C/C++

Здравствуйте, Motoroller, Вы писали:

M>Имеется проект под встроенную realtime ОС, содержащий смесь C и C++ файлов. Его необходимо "причесать" для дальнейшего усовершенствования. Коллега, программист на asm и C, задает вопросы:

M>1.Надо бы перевести проект на "плюса", да только надо ли? Есть ли и в чем преимущество "плюсов" в контексте поставленной задачи? С другой стороны, когда к проекту подключатся другие разработчики(C++), это потребуется все-равно.

Надо. C++ лучше контролирует типы, чем C, да и собирать проект на одном языке проще.

M>2.Он считает, что быстродействие C-программы лучше, чем C++. Так ли это?

Наоборот. В C даже inline функций нет а их эмуляция макросами порождает трудноуловимые ошибки.
Твой товарищь явно некомпетентен в вопросе.

M>3.Есть ли вообще преимущество C++ в задачах такого класса, где требуется максимальная скорость и по-возможности экономия ресурсов?(вопрос ставился именно так — "зачем C++, если есть C?".

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

M>В проекте глобально решается 3 типа задач:
M>-первоначальная инициализация "железа", записать-считать регистр
M>-взаимодействие с внешним миром — задачи ip-stack, snmp,и.т.д.
M>-взаимодействие между блоками и внутри блоков в оборудовании

M>Для программиста C++ структурированная работа с использованием классов C++ — привычна и логична. Но как объяснить это C-программисту? И прав ли он, что C-программы быстрее? (размер программы и памяти не критичны). Для него работы через подпрограммы удобнее и проще, чем через методы классов.

А что мешает использовать С++ в процедурном стиле?
Кроме того, анализ С программ очень часто выявляет, то что С код вручную эмулирует и классы, и наследование, и виртуальные функции, а эмуляция шаблонов достигается через copy-past.
Посмотри на библиотеку stdio, например. Типичная симуляция объектно-ориентированого подхода на С.
Посмотри на API Win32 или на API своей RTOS. Тоже самое -- симуляция классов средствами C.

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

Здравствуйте, programmater, Вы писали:

D>>>>>- С быстрее и программы на С проще оптимизируются
CC>>>>Бездоказательно.
P>Я бы сказал так: на C++ очень просто (и гораздо проще чем на C) написать неэффективную программу. Аргументы ниже.
Отчасти верно. Но верно и то, что на любом языке программирования можно написать неэффективную программу если задаться такой целью или же не думать головой в процессе. Т.е. программа в первую очередь плоха настолько, насколько плох программист ее написавший.

[skipped]
P>Так что C++ провоцирует на написание диких и рессурсожрущих программ. А для того, чтобы написать на C++ эффективную программу (представьте себе, что такое все же возможно!

) нужно иметь гораздо более высокую квалификацию, думать над каждой строчкой и уметь не поддаться соблазну.
ИМХО любой более высокоуровневый язык в отличие от предшествующего ему менее высокоуровневого предоставляет пачку ништяков, которые заточены на ускорение разработки но содержащие в себе те самые подлянки, что ты привел выше. И если бездумно применять все появившиеся возможности то получится громоздкая жрущая ресурсы хрень. Тут я согласен.
Однако мое ИМХО что при написании любой программы в первую очередь надо думать головой и применять не все что под руку подвернется а подумав.
Кроме того, std::string для меня не часть языка С++ а только поставляющаяся с ним библиотека. Вот темплейты, на которых STL построена — да, часть языка.

В целом я твою мысль понял. А если задать вопрос так:
"А если использовать С++ как С с классами и темплейтами но без STL"

Лирическое отступление: интересно, что в ветке неподалеку С++сники писали С#пникам что то вроде:

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Motoroller, Вы писали:

M>Имеется проект под встроенную realtime ОС, содержащий смесь C и C++ файлов. Его необходимо "причесать" для дальнейшего усовершенствования. Коллега, программист на asm и C, задает вопросы:
M>1.Надо бы перевести проект на "плюса", да только надо ли? Есть ли и в чем преимущество "плюсов" в контексте поставленной задачи? С другой стороны, когда к проекту подключатся другие разработчики(C++), это потребуется все-равно.

Во встроенных системах C++ используют довольно редко. Вот основные причины на мой взгляд:
— С++ в разы сложнее
— разработчики на С++ дороже стоят
— в качестве программистов нередко выступают электронщики, которые не смогут программировать на С++ (точнее смогут, но лучше бы вообще не могли)
— для оптимизации потребуется использовать такие тонкости С++-а как аллокаторы и т.п. вещи. Да и вообще надо очень хорошо знать С++ для того чтобы писать быстрые программы
— не на всех РТОС есть компилятор С++ (даже есть есть компилятор, то не факт что дебагер/профайлер понимает С++)
— С быстрее и программы на С проще оптимизируются
— для С++ -а нужно таскать за собой толстые библиотеки stdc++ и т.д. Которые по сути лишь красивая обертка к libc или newlib.
— асемблерные вставки в С++ коде смотрятся как .. ээээ короче плакать после такого хочется. А без них никак.
— объекты, объекты а в РТ без функций не обойтись (регистрация сигналов, спуллинг и т.д.). Неизбежен смешанный стиль программирования и опять таки страшный С++ код.

В РТ приложениях вся сложность в системном слое ПО и тонкостях железа, а потому не стоит добавлять еще одну сложность. Да и вообще С++ нужен если предметная область довольно сложна и ее можно красиво отобразить на объекты. Там он реально помогает.

Здравствуйте, dimon0981, Вы писали:

D> Если стиль процедурный то зачем браться за С++?

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

2. Шаблоны. Шаблонные классы и функции позволяют избавиться от copy-paste. Кроме того, шаблоны инлайнятся и хороший оптимизатор может сгенерировать из шаблонов более быстрый код, чем на основе обычных C-шных процедур.

3. Классы, не полиморфные. Наследование используется для агрегирования данных и/или функциональности (т.е. классы как mixin-ы). Так же позволяет избавиться от не нужного copy-paste.

4. Конструкторы и деструкторы для организации RAII.

5. Пространства имен. Чтобы избавиться от функций с длинными префиксами в именах.

6. Перегрузка функций и операторов (вроде оперетора <<). Об этом здесь уже сказали.

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

Здравствуйте, dimon0981, Вы писали:

D>- для оптимизации потребуется использовать такие тонкости С++-а как аллокаторы и т.п. вещи. Да и вообще надо очень хорошо знать С++ для того чтобы писать быстрые программы
Прошу объяснить на пальцах как помогут аллокаторы в оптимизации проги написанной в процедурном стиле?

А так же очень хорошее знание С++ опять таки для процедурного программирования? Когда используется в основном С и чуть чуть простых ништяков из С++
ЗЫ. А для встроенных систем для написания быстрых программ надо хорошо знать архитектуру системы.

D>- С быстрее и программы на С проще оптимизируются
Бездоказательно.
D>- асемблерные вставки в С++ коде смотрятся как .. ээээ короче плакать после такого хочется. А без них никак.

Нормально ИМХО смотрятся.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

D>Использование тех же string-ов вместо char[] приводит к массе лишних операций. Исключения "отжирают" ресурсы. Если Вы не пользуйтесь исключениями, то ими пользуются стандартные контейнеры.

Видимо это была шутка

одно иж жутчайших особенносте C это C стринги. Приводящие к N*N сложености в местах где это не надо....
.

Здравствуйте, Lorenzo_LAMAS, Вы писали:

АШ>>Не знал, это расширение или стандартная фича?

L_L>Стандартная.

В С99. До этого -- только как расширения компилятора...

Здравствуйте, eao197, Вы писали:

E>1. Аргументы-ссылки.
E>2. Шаблоны.
E>3. Классы, не полиморфные.
E>4. Конструкторы и деструкторы для организации RAII.
E>5. Пространства имен.
E>6. Перегрузка функций и операторов (вроде оперетора <<).

Еще можно было бы добавить исключения, т.к. они позволяют избавиться от "лесничного" кода, вроде:

if( 0 == ( rc = get_first_action() ) )
  if( 0 == ( rc = get_second_action() ) )
    if( 0 == ( rc == get_another_action() ) )
      if( 0 == ( rc == get_yet_another_action() ) )
         if( 0 == ( rc == this_is_not_last_action_too() ) )
           rc = and_now_last_action();
return rc;

Да и работать вариант с исключениями (если исключения редки) будет быстрее из-за отсутствия постоянных проверок.

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

Поэтому об исключениях сразу не стал писать.

Здравствуйте, mr_jek, Вы писали:

_>не помню сколько лет назад проводили сравнение, код с исключениями работал на 15% медленее в самом лучшем случае, честно говоря что что-нибудь поменялась.

Про это можно где-нибудь почитать? А то похоже на шутку

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

The "Code" Approach действительно имеет оверхед по времени выполнения:

The cost of this (in this model, unavoidable) bookkeeping varies dramatically from
implementation to implementation. However, one vendor reports speed impact of about
6% for a C++ to ISO C translator. This is generally considered a very good result.

(Это даже не для компилятора С++)

The "Table" Approach (в GCC вроде бы как раз он применяется) практически не имеет оверхеда (только при раскрутки стека), там оверхед по размеру

One vendor reported a code and data space impact of about 15% for the generated
tables. It is possible to do better, as this vendor had no need to optimize for space.

Источник: Technical Report on C++ Performance 5.4 Exception Handling

Ну и можно самостоятельно измерить, не забывая:

When considering the overheads of exception handling, we must remember to take into
account the cost of alternative error handling techniques.

Здравствуйте, Ubivetz, Вы писали:

U>Здравствуйте, Motoroller, Вы писали:

M>>Пока был принят один аргумент:
M>>1.перегрузка функций. Вместо набора функций write_byte(addr, data), write_word(addr, data), write_dword(addr, data) используется одна перегруженная функция write_data(addr, data).

M>>Что можно добавить еще??????

U>3. Если не использовать классы, производительность такая же как и на С.

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

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Анатолий Широков, Вы писали:

АШ>>Это Вы о полиморфных классах, надеюсь? Обычные классы никакой потери в производительности не несут.

А>А что с полиморфными классами не так?
А>Эмулировать их на С (если конечно задача этого требует)
А>не будет ни надежнее, ни быстрее, чем это сделает C++ компилятор.

Мой ответ следует рассматривать в контесте утвержения "Если не использовать классы, производительность такая же как и на С." Если использовать полиморфные классы, которые несут лишь небольшие накладные расходы при вызове, то, действительно, использование полиморфных классов несколько снижает производительности.

Здравствуйте, mr_jek, Вы писали:

_>примет
_>extern void f(const std::string&); — библиотека

_>f(NULL); — так вызвал пользователь библиотеки,

Если я не ошибаюсь, передача NULL в конструктор std::string запрещена стандартом С++. То есть имеем UB или же ill-formed код. Пользователь библиотеки -- сам себе злобный буратино.

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, dimon0981, Вы писали:

D>>>>- для оптимизации потребуется использовать такие тонкости С++-а как аллокаторы и т.п. вещи. Да и вообще надо очень хорошо знать С++ для того чтобы писать быстрые программы
CC>>>Прошу объяснить на пальцах как помогут аллокаторы в оптимизации проги написанной в процедурном стиле?

А так же очень хорошее знание С++ опять таки для процедурного программирования? Когда используется в основном С и чуть чуть простых ништяков из С++
CC>>>ЗЫ. А для встроенных систем для написания быстрых программ надо хорошо знать архитектуру системы.
D>> Если стиль процедурный то зачем браться за С++? Хорошее знание все равно потребуется, например очень желательно знать как реализованны std::string и другие контейнеры, как вызоваются виртуальные функции и т.д.
CC>С++ на STL клином не сошелся. Совсем не обязательно если уж используется С++ то сразу все писать на STL контейнерах и.т.п.

D>>>>- С быстрее и программы на С проще оптимизируются
CC>>>Бездоказательно.
Я бы сказал так: на C++ очень просто (и гораздо проще чем на C) написать неэффективную программу. Аргументы ниже.
D>>Использование тех же string-ов вместо char[] приводит к массе лишних операций. Исключения "отжирают" ресурсы. Если Вы не пользуйтесь исключениями, то ими пользуются стандартные контейнеры.
CC>Никто не заставляет пользовать string и исключения. STL это всего лишь набор темплейтов — хочу пользуюсь, хочу — нет. Это просто еще одна библиотека. И к ней следует точно так же присматриваться как и к другим кандидатам на использование при написании кода для встраиваемых систем. Если она не подходит по своим характеристикам то ничто не мешает от нее отказаться и написать свою. Да и ничто не мешает использовать с С++ проге char[] вместо string.
Никто. Но ведь гораздо проще взять и в цикле писать

std::string ResultStr="";
for(i=0; i< StrVec.size(); i++)
{
  ResultStr+=StrVec[i];
}

со всеми вытекающими автоматическими (а посему прозрачными для программиста) переаллокациями памяти, чем сначала посчитать размер буфера и сделать грамотное копирование. Да, если включить думалку с самого начала, то написать грамотный код на C++ в конечном итоге будет не сложнее, чем на C. Но писанина на C заставляет думать сразу. А у C++ есть другой путь, куда более удобный и привлекательный. И очень многие по этому пути идут, т.к. он уменьшает время разработки. Только вот готовый продукт жрет столько рессурсов, что мало не покажется. Я уже молчу, что вектора иногда передаются в функцию по значению(!), т.к. там есть удобный и красивый перегруженный operator= и копирующий конструктор. И в готовом коде будет минимум строк и смотреться он будет очень красиво. А во что он развернется мало кто из авторов задумывается.
Так что C++ провоцирует на написание диких и рессурсожрущих программ. А для того, чтобы написать на C++ эффективную программу (представьте себе, что такое все же возможно!

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

D>>>>- асемблерные вставки в С++ коде смотрятся как .. ээээ короче плакать после такого хочется. А без них никак.
CC>>>

Нормально ИМХО смотрятся.

ага.

Имеется проект под встроенную realtime ОС, содержащий смесь C и C++ файлов. Его необходимо "причесать" для дальнейшего усовершенствования. Коллега, программист на asm и C, задает вопросы:
1.Надо бы перевести проект на "плюса", да только надо ли? Есть ли и в чем преимущество "плюсов" в контексте поставленной задачи? С другой стороны, когда к проекту подключатся другие разработчики(C++), это потребуется все-равно.
2.Он считает, что быстродействие C-программы лучше, чем C++. Так ли это?
3.Есть ли вообще преимущество C++ в задачах такого класса, где требуется максимальная скорость и по-возможности экономия ресурсов?(вопрос ставился именно так — "зачем C++, если есть C?".

В проекте глобально решается 3 типа задач:
-первоначальная инициализация "железа", записать-считать регистр
-взаимодействие с внешним миром — задачи ip-stack, snmp,и.т.д.
-взаимодействие между блоками и внутри блоков в оборудовании

Для программиста C++ структурированная работа с использованием классов C++ — привычна и логична. Но как объяснить это C-программисту? И прав ли он, что C-программы быстрее? (размер программы и памяти не критичны). Для него работы через подпрограммы удобнее и проще, чем через методы классов.
А может быть в данном случае программа на C действительно будет более эффективна? В другом имеющемся у нас C++ проекте реально от возможностей C++ используется очень мало....

Пока был принят один аргумент:
1.перегрузка функций. Вместо набора функций write_byte(addr, data), write_word(addr, data), write_dword(addr, data) используется одна перегруженная функция write_data(addr, data).

Что можно добавить еще??????

Здравствуйте, Motoroller, Вы писали:

M>1.Надо бы перевести проект на "плюса", да только надо ли? Есть ли и в чем преимущество "плюсов" в контексте поставленной задачи? С другой стороны, когда к проекту подключатся другие разработчики(C++), это потребуется все-равно.

почему?

M>2.Он считает, что быстродействие C-программы лучше, чем C++. Так ли это?

абсолютно нет так.

M>3.Есть ли вообще преимущество C++ в задачах такого класса, где требуется максимальная скорость и по-возможности экономия ресурсов?(вопрос ставился именно так — "зачем C++, если есть C?".

чем больше задача, тем преимущества С++ наглядней

M>Пока был принят один аргумент:
M>1.перегрузка функций. Вместо набора функций write_byte(addr, data), write_word(addr, data), write_dword(addr, data) используется одна перегруженная функция write_data(addr, data).

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

Здравствуйте, Motoroller, Вы писали:

M>Пока был принят один аргумент:
M>1.перегрузка функций. Вместо набора функций write_byte(addr, data), write_word(addr, data), write_dword(addr, data) используется одна перегруженная функция write_data(addr, data).

M>Что можно добавить еще??????

1. Исключения.
2. new вместо malloc и free.
3. Если не использовать классы, производительность такая же как и на С.

Здравствуйте, Анатолий Широков, Вы писали:

АШ>Это Вы о полиморфных классах, надеюсь? Обычные классы никакой потери в производительности не несут.

А что с полиморфными классами не так?
Эмулировать их на С (если конечно задача этого требует)
не будет ни надежнее, ни быстрее, чем это сделает C++ компилятор.

Одна из причин почему С++ не надо использовать — это
если на данной платформе нету качественного компилятора.
Все остальные причины довольно сомнительны...

Ш>Наоборот. В C даже inline функций нет а их эмуляция макросами порождает трудноуловимые ошибки.
inline там есть.

Здравствуйте, Lorenzo_LAMAS, Вы писали:

Ш>>Наоборот. В C даже inline функций нет а их эмуляция макросами порождает трудноуловимые ошибки.
L_L>inline там есть.

Не знал, это расширение или стандартная фича?

АШ>Не знал, это расширение или стандартная фича?

Стандартная.

BF>В С99. До этого -- только как расширения компилятора...
Так C99 это не диалект С, это стандартный С. Так что не обязательно, ИМХО, уточнять, что в С99. В каком-то там С и присваивания структур не было, это ж никому не интересно.

Здравствуйте, Lorenzo_LAMAS, Вы писали:

BF>>В С99. До этого -- только как расширения компилятора...
L_L>Так C99 это не диалект С, это стандартный С. Так что не обязательно, ИМХО, уточнять, что в С99. В каком-то там С и присваивания структур не было, это ж никому не интересно.
Не обязятельно, но, ИМХО, желательно. Под целевую платформу может не быть компилятора с поддержкой С99, только С89.

Здравствуйте, Lorenzo_LAMAS, Вы писали:

Ш>>Наоборот. В C даже inline функций нет а их эмуляция макросами порождает трудноуловимые ошибки.
L_L>inline там есть.

Только в С99. Прикол в том, что С99 до сих пор не вытеснил предыдущий.

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, dimon0981, Вы писали:

D>>- для оптимизации потребуется использовать такие тонкости С++-а как аллокаторы и т.п. вещи. Да и вообще надо очень хорошо знать С++ для того чтобы писать быстрые программы
CC>Прошу объяснить на пальцах как помогут аллокаторы в оптимизации проги написанной в процедурном стиле?

А так же очень хорошее знание С++ опять таки для процедурного программирования? Когда используется в основном С и чуть чуть простых ништяков из С++
CC>ЗЫ. А для встроенных систем для написания быстрых программ надо хорошо знать архитектуру системы.

Если стиль процедурный то зачем браться за С++? Хорошее знание все равно потребуется, например очень желательно знать как реализованны std::string и другие контейнеры, как вызоваются виртуальные функции и т.д.

D>>- С быстрее и программы на С проще оптимизируются
CC>Бездоказательно.
Использование тех же string-ов вместо char[] приводит к массе лишних операций. Исключения "отжирают" ресурсы. Если Вы не пользуйтесь исключениями, то ими пользуются стандартные контейнеры.

D>>- асемблерные вставки в С++ коде смотрятся как .. ээээ короче плакать после такого хочется. А без них никак.
CC>

Нормально ИМХО смотрятся.

Вставки в стиле gcc имеют смысл только для интегральных типов:
asm( "CODE", prm1, prm2, prm3 );
где prm — описывают входные, выходные и измененные параметры
Если вы работайте с объектами, то придется все приводить к этим типам.
Если в С асм-овые вставки можно не заморачиваясь встраивать куда угодно, то в С++ надо сначала думать. Пока на все грабли не наступишь будешь рвать волосы.
Рыться в стеке перед вызовом вертуальных ф-ии опасно. Кто знает что туда положит компилятор, это в Си все эти тонкости в стандарте описанны, в С++ — нет. После вызова ф-ии анологично.

Здравствуйте, dimon0981, Вы писали:

D>>>- для оптимизации потребуется использовать такие тонкости С++-а как аллокаторы и т.п. вещи. Да и вообще надо очень хорошо знать С++ для того чтобы писать быстрые программы
CC>>Прошу объяснить на пальцах как помогут аллокаторы в оптимизации проги написанной в процедурном стиле?

А так же очень хорошее знание С++ опять таки для процедурного программирования? Когда используется в основном С и чуть чуть простых ништяков из С++
CC>>ЗЫ. А для встроенных систем для написания быстрых программ надо хорошо знать архитектуру системы.
D> Если стиль процедурный то зачем браться за С++? Хорошее знание все равно потребуется, например очень желательно знать как реализованны std::string и другие контейнеры, как вызоваются виртуальные функции и т.д.
С++ на STL клином не сошелся. Совсем не обязательно если уж используется С++ то сразу все писать на STL контейнерах и.т.п.

D>>>- С быстрее и программы на С проще оптимизируются
CC>>Бездоказательно.
D>Использование тех же string-ов вместо char[] приводит к массе лишних операций. Исключения "отжирают" ресурсы. Если Вы не пользуйтесь исключениями, то ими пользуются стандартные контейнеры.
Никто не заставляет пользовать string и исключения. STL это всего лишь набор темплейтов — хочу пользуюсь, хочу — нет. Это просто еще одна библиотека. И к ней следует точно так же присматриваться как и к другим кандидатам на использование при написании кода для встраиваемых систем. Если она не подходит по своим характеристикам то ничто не мешает от нее отказаться и написать свою. Да и ничто не мешает использовать с С++ проге char[] вместо string.
Или для вас писать на С++ это только STL, Boost, дикие классы с хитрыми наследованиями и боже упаси вызвать sprintf хоть раз.

D>>>- асемблерные вставки в С++ коде смотрятся как .. ээээ короче плакать после такого хочется. А без них никак.
CC>>

Нормально ИМХО смотрятся.

D>Вставки в стиле gcc имеют смысл только для интегральных типов:
D>asm( "CODE", prm1, prm2, prm3 );
D>где prm — описывают входные, выходные и измененные параметры
D>Если вы работайте с объектами, то придется все приводить к этим типам.
D>Если в С асм-овые вставки можно не заморачиваясь встраивать куда угодно, то в С++ надо сначала думать. Пока на все грабли не наступишь будешь рвать волосы.
Ну, положим, думать надо всегда, а не только при программировании на С++.

D>Рыться в стеке перед вызовом вертуальных ф-ии опасно. Кто знает что туда положит компилятор, это в Си все эти тонкости в стандарте описанны, в С++ — нет. После вызова ф-ии анологично.

а зачем там рыться? Если делать асм вставки так делать с умом, там где есть резон и без фанатизма.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

BitField wrote:
>
> BF>>В С99. До этого -- только как расширения компилятора...
> L_L>Так C99 это не диалект С, это стандартный С. Так что не обязательно,
> ИМХО, уточнять, что в С99. В каком-то там С и присваивания структур не
> было, это ж никому не интересно.
> Не обязятельно, но, ИМХО, желательно. Под целевую платформу может не
> быть компилятора с поддержкой С99, только С89.
Пример, MS VC.

Posted via RSDN NNTP Server 2.0

Я бы еще сказал про наличие стандартной библиотеки с контейнерами и алгоритмами, которые избавляют от написания велосипедов. имхо, у С библиотека по сравнению с С++ — просто нищета какая-то

Здравствуйте, Lorenzo_LAMAS, Вы писали:

L_L>Я бы еще сказал про наличие стандартной библиотеки с контейнерами и алгоритмами, которые избавляют от написания велосипедов. имхо, у С библиотека по сравнению с С++ — просто нищета какая-то

Здесь все не так просто. В стандартных контейнерах упрятаны обращения к new/delete. А посему в некоторых real-time приложениях нужно будет внимательно контролировать работу с такими контейнерами чтобы не спровоцировать динамическое выделение памяти в самый неподходящий момент (вроде такого map[key]=value). Так что может быть гораздо проще стандартные контейнеры не использовать вообще.

E>А посему в некоторых real-time

Про библиотеки я говорил не в применении к real-time (да и тут можно было бы извернуться).

Здравствуйте, Lorenzo_LAMAS, Вы писали:

E>>А посему в некоторых real-time

L_L>Про библиотеки я говорил не в применении к real-time (да и тут можно было бы извернуться).

Дык, если не применительно к real-time, то вообще о чем разговаривать

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, dimon0981, Вы писали:

D>> Если стиль процедурный то зачем браться за С++?

E>1. Аргументы-ссылки. В отличии от указателей позволяют обезопасить себя от случайной передачи нулевого указателя туда, где этого не ждали.

примет
extern void f(const std::string&); — библиотека

f(NULL); — так вызвал пользователь библиотеки,

std::string — шедший с компилятором неумел такое обрабатывать = segfault.

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, eao197, Вы писали:
E>Еще можно было бы добавить исключения, т.к. они позволяют избавиться от "лесничного" кода, вроде:
E>

E>if( 0 == ( rc = get_first_action() ) )
E>  if( 0 == ( rc = get_second_action() ) )
E>    if( 0 == ( rc == get_another_action() ) )
E>      if( 0 == ( rc == get_yet_another_action() ) )
E>         if( 0 == ( rc == this_is_not_last_action_too() ) )
E>           rc = and_now_last_action();
E>return rc;
E>

Не понял пример, а почему не
if (f1() == 0 && f2() == 0 &&...
или
if (f1())
goto out;
if (f2())
goto out;

E>Да и работать вариант с исключениями (если исключения редки) будет быстрее из-за отсутствия постоянных проверок.

не помню сколько лет назад проводили сравнение, код с исключениями работал на 15% медленее в самом
лучшем случае, честно говоря что что-нибудь поменялась.

Здравствуйте, mr_jek, Вы писали:

_>примет
_>extern void f(const std::string&); — библиотека

_>f(NULL); — так вызвал пользователь библиотеки,

_>std::string — шедший с компилятором неумел такое обрабатывать = segfault.

И? Имхо, такую ситуацию никакой std::string (если только он не будет сильно заморочен на проверки нулевых указателей) не обработает. Поскольку здесь срабатывает неявное преобразование от const char * к std::string.

В данном случае хорошо уже то, что программа ломается в момент обращения к f(). Т.е. непосредственно в месте возникновения проблемы. Гораздо хуже, если segfault был бы где-нибудь в функции k(), которая вызывается из g(), которую вызывает f().

Ну и закончим тем, что аргументы-ссылки защищают, если ссылка не константная (пропробуйте void f(std::string &) вызвать как f(NULL)) и если у объекта нет implicit преобразований через конструкторы с единственным параметром (а таких не мало).

Здравствуйте, mr_jek, Вы писали:

_>Не понял пример, а почему не
_>if (f1() == 0 && f2() == 0 &&...

Потому, что может быть так:

if( f1() )
 {
  log_1();
  if( f2() )
   {
    log_2();
    if( f3() )
      ...
    undo_f2();
   }
  undo_f1();
 }

_>или
_>if (f1())
_> goto out;
_>if (f2())
_> goto out;

Это хорошо до тех пор, пока out одна. Как только их становится несколько...
Либо даже в одном out нужно будет писать:

out:
  if( r1 ) free_r1();
  if( r2 ) free_r2();
  if( r3 ) free_r3();
...

E>>Да и работать вариант с исключениями (если исключения редки) будет быстрее из-за отсутствия постоянных проверок.

_>не помню сколько лет назад проводили сравнение, код с исключениями работал на 15% медленее в самом
_>лучшем случае, честно говоря что что-нибудь поменялась.

Здесь, возможно, погорячился.

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, mr_jek, Вы писали:

_>>Не понял пример, а почему не
_>>if (f1() == 0 && f2() == 0 &&...

E>Потому, что может быть так:
E>

E>if( f1() )
E> {
E>  log_1();
E>  if( f2() )
E>   {
E>    log_2();
E>    if( f3() )
E>      ...
E>    undo_f2();
E>   }
E>  undo_f1();
E> }
E>

if (!f1())
goto out;
log_1();
if (!f2())
goto f2_failed;
log_2();
if (!f3())
goto f2_failed;

f3_failed:
undo_f2();
f2_failed:
undo_f1();
out:
return;
}

_>>или
_>>if (f1())
_>> goto out;
_>>if (f2())
_>> goto out;

E>Это хорошо до тех пор, пока out одна. Как только их становится несколько...
E>Либо даже в одном out нужно будет писать:

зачем?

Здравствуйте, programmater, Вы писали:

P>со всеми вытекающими автоматическими (а посему прозрачными для программиста) переаллокациями памяти, чем сначала посчитать размер буфера и сделать грамотное копирование. Да, если включить думалку с самого начала, то написать грамотный код на C++ в конечном итоге будет не сложнее, чем на C. Но писанина на C заставляет думать сразу. А у C++ есть другой путь, куда более удобный и привлекательный. И очень многие по этому пути идут, т.к. он уменьшает время разработки. Только вот готовый продукт жрет столько рессурсов, что мало не покажется. Я уже молчу, что вектора иногда передаются в функцию по значению(!), т.к. там есть удобный и красивый перегруженный operator= и копирующий конструктор. И в готовом коде будет минимум строк и смотреться он будет очень красиво. А во что он развернется мало кто из авторов задумывается.

Задумываемся, задумываемся

P>Так что C++ провоцирует на написание диких и рессурсожрущих программ. А для того, чтобы написать на C++ эффективную программу (представьте себе, что такое все же возможно!

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

Весь поинт в С — это думать над аллокациями/ деаллокациями памяти и как сделать некое подобие ООП языка.
Весь поинт в с++ — это думать о цепочках преобразования типов, вызовов операторов и как грамотнее построить ОО архитектуру.

Так что насчет квалификации еще можно поспорить

D>>>>>- асемблерные вставки в С++ коде смотрятся как .. ээээ короче плакать после такого хочется. А без них никак.
CC>>>>

Нормально ИМХО смотрятся.

P>ага.

Здравствуйте, programmater, Вы писали:

P>Так что C++ провоцирует на написание диких и рессурсожрущих программ.
С провоцирует тоже, пусть и немного в меньшей степени...Давайте все писать на Ассемблере тогда..
По поводу ресурсожрущих -- если в качестве ресурса рассматривать память. то С++ -- это "золотая середина" между ручным контролем всех аллокаций и GC.

P>А для того, чтобы написать на C++ эффективную программу (представьте себе, что такое все же возможно!

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

Здравствуйте, CreatorCray, Вы писали:

>Т.е. программа в первую очередь плоха настолько, насколько плох программист ее написавший.

+

Здравствуйте, Шахтер, Вы писали:

Ш>Наоборот. В C даже inline функций нет а их эмуляция макросами порождает трудноуловимые ошибки.
Ш>Твой товарищь явно некомпетентен в вопросе.

<большая лакуна>

Ш>Авторы таких высказываний -- безграмотные люди. Их надо или принудительно учить, или выгонять.

Формулируя свои мысли столь резко, легко можно попасть в просак. Всё-таки, чтобы кто не говорил, у Бога есть чувство юмора. Просто очень своеобразное

Здравствуйте, BitField, Вы писали:

BF>Здравствуйте, mr_jek, Вы писали:

_>>примет
_>>extern void f(const std::string&); — библиотека

_>>f(NULL); — так вызвал пользователь библиотеки,

BF>Если я не ошибаюсь, передача NULL в конструктор std::string запрещена стандартом С++. То есть имеем UB или же ill-formed код. Пользователь библиотеки -- сам себе злобный буратино.

только вот компилятор, зараза не говорит никаких warrnings или errors,
действительно в стандарте?

и получается что я создал небезопасную библиотеку.

Здравствуйте, gear nuke, Вы писали:

GN>Здравствуйте, mr_jek, Вы писали:

_>>не помню сколько лет назад проводили сравнение, код с исключениями работал на 15% медленее в самом лучшем случае, честно говоря что что-нибудь поменялась.

GN>Про это можно где-нибудь почитать? А то похоже на шутку

"Эффективное C++" что-то типа того, не помню точно

GN>Во-первых, существует несколько подходов к обработке исключений. Во-вторых, даже при одном подходе будет разница на разных компиляторах.

GN>Ну и можно самостоятельно измерить, не забывая:
GN>

When considering the overheads of exception handling, we must remember to take into
GN>account the cost of alternative error handling techniques.

можно сравнить приложение на C vs C++ в gcc/g++,
почему-то мне кажется что C++ покажет не лучшие результаты.

	От:	Шахтер
	Дата:	29.05.06 07:35
	Оценка:	5 (5) +5 -1

	От:	CreatorCray
	Дата:	01.06.06 11:06
	Оценка:	18 (3) +2

	От:	dimon0981
	Дата:	29.05.06 07:54
	Оценка:	1 (1) -4

От:	eao197	http://eao197.blogspot.com
Дата:	30.05.06 11:45
Оценка:	1 (1) +3

	От:	CreatorCray
	Дата:	29.05.06 08:11
	Оценка:	+3

	От:	minorlogic
	Дата:	30.05.06 14:28
	Оценка:	1 (1) +1

От:	BitField	http://lazy-bitfield.blogspot.com
Дата:	29.05.06 09:10
Оценка:	1 (1)

	От:	Анатолий Широков
	Дата:	29.05.06 07:37
	Оценка:	+1

	От:	Сергей Мухин
	Дата:	29.05.06 07:20
	Оценка:

	От:	Константин Л.
	Дата:	01.06.06 10:38
	Оценка:

	От:	mr_jek
	Дата:	31.05.06 08:15
	Оценка:

	От:	mr_jek
	Дата:	31.05.06 08:21
	Оценка:

	От:	mr_jek
	Дата:	31.05.06 13:51
	Оценка: