Здравствуйте, 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;

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

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

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

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

Здравствуйте, 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, то вообще о чем разговаривать

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

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

Здравствуйте, 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, Вы писали:

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

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

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

Здравствуйте, 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 нужно будет писать:

зачем?

Здравствуйте, 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.

Здравствуйте, 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>>> Нормально ИМХО смотрятся.

ага.

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

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

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

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

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

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

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

P>ага.

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

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

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

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

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

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

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

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

Да, если включить думалку с самого начала, то написать грамотный код на C# в конечном итоге будет не сложнее, чем на C++. Но писанина на C++ заставляет думать сразу. А у C# есть другой путь, куда более удобный и привлекательный. И очень многие по этому пути идут, т.к. он уменьшает время разработки. Только вот готовый продукт жрет столько рессурсов, что мало не покажется.
Так что C# провоцирует на написание диких и рессурсожрущих программ. А для того, чтобы написать на 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,
действительно в стандарте?

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