1.Отсутствие модулей. Имитация понятия модуль в виде пары h-файл – cpp-файл приводит к многочасовым компиляциям системы.

2.Использование целочисленных типов данных без знака (unsigned int) для номеров элементов и количественных значений в стандартной библиотеке stdc++. Приводит к следующим ошибкам:

std::vector<int> v;
// Следующий код работает бесконечно, поскольку (size_type)(-1) == 4 млрд.
for (std::vector<int>::size_type i = 0; v.size() - 1; ++i)
{
  ...
}

3.Отсутствие встроенной проверки на выход за диапазоны массива. Приводит к необходимости писать «обертки» для классов-контейнеров (в частности, для класса vector).

4.Отсутствие встроенных средств инициализации динамической памяти нулями при конструировании объектов оператором new. Оборачивается не выигрышем, а проигрышем в производительности, поскольку приводит к необходимости писать код инициализации в конструкторах.

5.«Автоматизм» конструкторов и деструкторов для объектов, создаваемых динамически и имеющих виртуальные методы; работа виртуальных методов как не виртуальных при их вызове из конструкторов и деструкторов; отсутствие стандартного базового класса. Значительно затрудняет решение проблемы повторного входа в объекты (reentrance problem) при создании библиотек визуальных компонентов и систем GUI.

6.Отсутствие оператора try {…} finally {…}. Приводит к созданию программ, неустойчивых к исключительным ситуациям. Попытка имитировать этот оператор с помощью оператора try {…} catch {…} приводит к большой избыточности кода.

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

DB>1.Отсутствие модулей. Имитация понятия модуль в виде пары h-файл – cpp-файл приводит к многочасовым компиляциям системы.

DB>2.Использование целочисленных типов данных без знака (unsigned int) для номеров элементов и количественных значений в стандартной библиотеке stdc++. Приводит к следующим ошибкам:

DB>

DB>std::vector<int> v;
DB>// Следующий код работает бесконечно, поскольку (size_type)(-1) == 4 млрд.
DB>for (std::vector<int>::size_type i = 0; v.size() - 1; ++i)
DB>{
DB>  ...
DB>}
DB>

DB>3.Отсутствие встроенной проверки на выход за диапазоны массива. Приводит к необходимости писать «обертки» для классов-контейнеров (в частности, для класса vector).

DB>4.Отсутствие встроенных средств инициализации динамической памяти нулями при конструировании объектов оператором new. Оборачивается не выигрышем, а проигрышем в производительности, поскольку приводит к необходимости писать код инициализации в конструкторах.

DB>5.«Автоматизм» конструкторов и деструкторов для объектов, создаваемых динамически и имеющих виртуальные методы; работа виртуальных методов как не виртуальных при их вызове из конструкторов и деструкторов; отсутствие стандартного базового класса. Значительно затрудняет решение проблемы повторного входа в объекты (reentrance problem) при создании библиотек визуальных компонентов и систем GUI.

DB>6.Отсутствие оператора try {…} finally {…}. Приводит к созданию программ, неустойчивых к исключительным ситуациям. Попытка имитировать этот оператор с помощью оператора try {…} catch {…} приводит к большой избыточности кода.
Видимо понятие настоящего программиста у нас различное. Тут что-то чедовек занимается системами типа Делфи, Джава, где это как раз-таки есть.
Насчёт первого могу согласится, но только отчасти.

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

DB>2.Использование целочисленных типов данных без знака (unsigned int) для номеров элементов и количественных значений в стандартной библиотеке stdc++. Приводит к следующим ошибкам:

DB>std::vector<int> v;
DB>// Следующий код работает бесконечно, поскольку (size_type)(-1) == 4 млрд.
DB>for (std::vector<int>::size_type i = 0; v.size() - 1; ++i)
^^^^^^
      Это вообще какой-то маразм

Используй итераторы.
Если хочешь индексы, то пиши так:

for (std::vector<int>::size_type i = 0; i < v.size(); ++i)

DB>3.Отсутствие встроенной проверки на выход за диапазоны массива. Приводит к необходимости писать «обертки» для классов-контейнеров (в частности, для класса vector).

А нафиг встроенная поддержка? Если сильно нужно используй STLport в debug режиме

DB>4.Отсутствие встроенных средств инициализации динамической памяти нулями при конструировании объектов оператором new. Оборачивается не выигрышем, а проигрышем в производительности, поскольку приводит к необходимости писать код инициализации в конструкторах.

А ты предлагаешь инициализировать память два раза: один раз нулями, потом актуальными начальными значениями?

DB>6.Отсутствие оператора try {…} finally {…}. Приводит к созданию программ, неустойчивых к исключительным ситуациям. Попытка имитировать этот оператор с помощью оператора try {…} catch {…} приводит к большой избыточности кода.

Зачем он вообще нужен, этот finally? Делай все что нужно в деструкторах автоматических объектов

Как говорилось в известном анекдоте про Вовочку, — "да, Иван Иваныч, мне бы ваши проблемы..."

Мля. Во я дурак! Пашол учица на чиста риальнава праграмиста!!!

На мой нескромный взгляд, стоило бы подобные утверждения хоть немного разбавлять "имхами". А то очень подмывает ответить цитатой из Булгакова:

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

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

A>Мля. Во я дурак! Пашол учица на чиста риальнава праграмиста!!!
И меня с собой возми ТОжа хачу быть чистА рЭальным пац.. ой прохраммистом

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

A>Мля. Во я дурак! Пашол учица на чиста риальнава праграмиста!!!

согласен
[нагло своровано]
ам/кг

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

UGN>Здравствуйте, d Bratik, Вы писали:

DB>>2.Использование целочисленных типов данных без знака (unsigned int) для номеров элементов и количественных значений в стандартной библиотеке stdc++. Приводит к следующим ошибкам:

UGN>

DB>>std::vector<int> v;
DB>>// Следующий код работает бесконечно, поскольку (size_type)(-1) == 4 млрд.
DB>>for (std::vector<int>::size_type i = 0; v.size() - 1; ++i)
UGN>^^^^^^
UGN>      Это вообще какой-то маразм
UGN>

UGN>Используй итераторы.
UGN>Если хочешь индексы, то пиши так:
UGN>

UGN>for (std::vector<int>::size_type i = 0; i < v.size(); ++i)
UGN>

DB>>3.Отсутствие встроенной проверки на выход за диапазоны массива. Приводит к необходимости писать «обертки» для классов-контейнеров (в частности, для класса vector).

UGN>А нафиг встроенная поддержка? Если сильно нужно используй STLport в debug режиме

DB>>4.Отсутствие встроенных средств инициализации динамической памяти нулями при конструировании объектов оператором new. Оборачивается не выигрышем, а проигрышем в производительности, поскольку приводит к необходимости писать код инициализации в конструкторах.

UGN>А ты предлагаешь инициализировать память два раза: один раз нулями, потом актуальными начальными значениями?

DB>>6.Отсутствие оператора try {…} finally {…}. Приводит к созданию программ, неустойчивых к исключительным ситуациям. Попытка имитировать этот оператор с помощью оператора try {…} catch {…} приводит к большой избыточности кода.

UGN>Зачем он вообще нужен, этот finally? Делай все что нужно в деструкторах автоматических объектов

Все эти "комментарии" лишний раз доказывают, что 99% всех программистов на С++ -- просто ламеры. Автор языка, кстати, попадает в эти 99%

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

DB>Все эти "комментарии" лишний раз доказывают, что 99% всех программистов на С++ -- просто ламеры. Автор языка, кстати, попадает в эти 99%

А вот здесь Вы, батенька, нарушаете правила форума RSDN. В баню.

You will always get what you always got
  If you always do  what you always did

DB>

DB>for (std::vector<int>::size_type i = 0; v.size() - 1; ++i)
DB>

А что это за чушь написал здесь настоящий программист?

SWW>А что это за чушь написал здесь настоящий программист?
Понятно что До тех пор, пока в векторе не один элемент, делай...

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

SDB>На мой нескромный взгляд, стоило бы подобные утверждения хоть немного разбавлять "имхами". А то очень подмывает ответить цитатой из Булгакова:

SDB>

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

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

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

SWW>>А что это за чушь написал здесь настоящий программист?
V>Понятно что До тех пор, пока в векторе не один элемент, делай...

Кхм, интересно... Человек приводит заведомо неправильный код и говорит: С++ плохой язык потому что на нем можно написать неправильную программу — вот, видите, я же смог!

А если бы v.size() было знаковым, разве этот код работал бы?

DB>Когда по делу сказать нечего, начинают прикрываться цитатами и ссылаться на авторитетов.

Интересный профиль у вас, сударь: первое сообщение "Почему настоящие программисты избегают C++"

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

Это чистой воды развод. если человек реально уверен в том, что он говорит в данной ветке, чтож я сочувствую...
Фактов не видно. Определение "Настоящего программиста" не было. Даже Страуструпу(апу) Ж) досталось

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

DB>1.Отсутствие модулей. Имитация понятия модуль в виде пары h-файл – cpp-файл приводит к многочасовым компиляциям системы.

1) От компилятора: прекомпиляция заголовков
2) От программиста: идиома pimpl
И всё будет летать.

DB>2.Использование целочисленных типов данных без знака (unsigned int) для номеров элементов и количественных значений в стандартной библиотеке stdc++. Приводит к следующим ошибкам:

DB>

DB>std::vector<int> v;
DB>// Следующий код работает бесконечно, поскольку (size_type)(-1) == 4 млрд.
DB>for (std::vector<int>::size_type i = 0; v.size() - 1; ++i)
DB>{
DB>  ...
DB>}
DB>

Здесь вообще какой-то пьяный бред написан. При чём тут знаковость/беззнаковость?

DB>3.Отсутствие встроенной проверки на выход за диапазоны массива. Приводит к необходимости писать «обертки» для классов-контейнеров (в частности, для класса vector).

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

DB>4.Отсутствие встроенных средств инициализации динамической памяти нулями при конструировании объектов оператором new. Оборачивается не выигрышем, а проигрышем в производительности, поскольку приводит к необходимости писать код инициализации в конструкторах.

Нет, это требует сознательной инициализации.
Не инициализированная переменная — логический баг.

DB>5.«Автоматизм» конструкторов и деструкторов для объектов, создаваемых динамически и имеющих виртуальные методы; работа виртуальных методов как не виртуальных при их вызове из конструкторов и деструкторов; отсутствие стандартного базового класса. Значительно затрудняет решение проблемы повторного входа в объекты (reentrance problem) при создании библиотек визуальных компонентов и систем GUI.

DB>6.Отсутствие оператора try {…} finally {…}. Приводит к созданию программ, неустойчивых к исключительным ситуациям. Попытка имитировать этот оператор с помощью оператора try {…} catch {…} приводит к большой избыточности кода.

Вот именно автоматизм конструкторов/деструкторов позволяет обходиться без finally. Причём обходиться очень избирательно.
Пример

Foo *x = NULL;
Bar *y = NULL;
Buz *z = NULL;
__try
{
  x = make_foo();
  y = make_bar();
  z = make_buz();

  work(x,y,z);
}
__finally
{
  // дофига ручной работы
  if(z) free_buz(z); z = NULL;
  if(y) free_bar(y); y = NULL;
  if(x) free_foo(x); x = NULL;
}

////////////////////////

shared_ptr<Foo> x;
shared_ptr<Bar> y;
shared_ptr<Buz> z;

// блок try-finally вообще не нужен!

x = shared_ptr<Foo>( make_foo(), free_foo );
y = shared_ptr<Bar>( make_bar(), free_bar );
z = shared_ptr<Buz>( make_buz(), free_buz );

work(x,y,z);

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

J>Здравствуйте, d Bratik, Вы писали:

DB>>Все эти "комментарии" лишний раз доказывают, что 99% всех программистов на С++ -- просто ламеры. Автор языка, кстати, попадает в эти 99%

J>А вот здесь Вы, батенька, нарушаете правила форума RSDN. В баню.

Да, тут я был слишком эмоционален. Сам ведь на С++ пишу

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

DB>1.Отсутствие модулей.
DB>2.Использование целочисленных типов данных без знака (unsigned int) для номеров элементов и количественных значений в стандартной библиотеке stdc++.
DB>3.Отсутствие встроенной проверки на выход за диапазоны массива.
DB>4.Отсутствие встроенных средств инициализации динамической памяти нулями при конструировании объектов оператором new.
DB>5.«Автоматизм» конструкторов и деструкторов для объектов, создаваемых динамически и имеющих виртуальные методы;
DB>6.Отсутствие оператора try {…} finally {…}. Приводит к созданию программ, неустойчивых к исключительным ситуациям.
7. Наличием большого количества синтаксических ловушек, вроде

const double PI = 3,1415;

или той, что описана вот здесь

Автор: Кодт
Дата: 17.02.05

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

DB>Автор языка, кстати, попадает в эти 99%

А вот вы ему это сами скажите здесь