Продолжение С++

[MaTBeu]

Сообщение от An1ka

И каких еще недостатков ? В стандарте C++ нет недостатков, там всё строго !

Слишком толсто.

Сообщение от An1ka

Да никто не обожествляет C++, просто C++ является самым лучшим ЯП для ресурсоемких задач на сегодняшний день - это факт

Вы, наверное, забыли про ассемблер. Производительней него только машинный код, но увы, на нем никто не пишет.

Сообщение от An1ka

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

Да ну! Скажите мне, зачем еще нужно ключевое слово auto из стандарта С++0x, кроме как для сокращения кода?

Сообщение от An1ka

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

Вы путаете копипаст с компиляцией.

Сообщение от An1ka

Любую программу на любом ЯП можно сломать

Да, только программу на С++ сломать гораздо легче, чем программу на Ada или COBOL.

[Kostia]

Ох, я совсем офанател от C++, не смотря на его множественные недостатки, удовольствие которое получаешь от того что ты их преодолеваешь стандартными средствами несравнимо ни с чем.
А теперь по порядку:

Сообщение от pu4koff

Ага. На каждую функцию с десяток перегрузок делать на все случаи жизни и плевать на дублирование кода.

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

Сообщение от pu4koff

Почему бы не добавить другие удобные вещи, которые так же необязательно будет использовать, но благодаря которым меньше будет велосипедов?

Сообщение от pu4koff

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

Обоз? Хм, мне лично кажется большинство новшеств является хламом, хотя есть и стоящие расширения.

Сообщение от pu4koff

Можно. Про то, почему мне вектор не нравится, я уже писал. если бы был базовый абстрактный класс std::icollection, то претензий по этому поводу не было бы.

Эмм, списки инициализации, не?
И да, то что Вы писали про общий класс для list и vector, они оба умеют работать с коллекциями, но одна проблема, list работает со списками, а vector с непрерывным куском памяти, теперь как вы представляете хранение информации сразу в обоих представлениях?

Сообщение от pu4koff

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

Сообщение от pu4koff

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

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

Сообщение от An1ka

Есть std::wstring

Есть и wchar_t *. В одном из новых стандартов я бы их сжег! Почему, да только потому, что в linux'е sizeof(wchar_t) = 4 в windows sizeof(wchar_t) = 2!

const char * str = u8"Бла бла бла. 你好"; //utf-8 строка
const char16_t * str = u"Бла бла бла. 你好"; //utf-16 строка
const char32_t * str = U"Бла бла бла. 你好"; //utf-32 строка

В своих приложениях я уже давно перешел на utf-8(utf8 to utf16 для win) и не имею проблем в работе с файлами и каталогами с китайскими и пр. экзотическими символами в именах.

Сообщение от the_deer_one

А в руби вообще может в любой переменной любой тип быть. Можно хоть в одном массиве разные типы хранить. И никакой тебе мощи шаблонов. Мощь костылей - странно звучит.

Про php я вообще молчу, там динамическая типизация. + Богатый набор для метапрограммирования. И да, они интерпретируемые и если бы в них этого не было, то в мусорку!

В новом стандарте появились весьма и весьма полезные вещи. Например тот же bind или function, правда вот про сцепление(chain) я ничего не нашел, хотя все это у меня уже было реализовано в собственных шаблонных классах, приятно понимать, что уже есть готовый стандарт.
Внедрение поддержки многопоточности непосредственно в стандарт языка считаю просто великолепнейшей идеей. А именно std::async.
Есть и несколько забавных штучек, например как объявление собственных суффиксов и появление возможности писать нечто такое:

double weight = 1_kg + 120_gr; // 1.12
complex c = 5 + 3_i;
string s = 5_tostr;

Про стратегии, паттерны и пр. Вы замечали что классы stl принимают в качестве шаблона достаточно много параметров. Например vector принимает 2 параметра. Это тип вектора и стратегия для работы с памятью, что позволяет реализовать собственную стратегию конкретно для своей задачи, которая будет справляться в разы быстрее, чем стандартная и без переписывания классов. Всем известно что стратегии выделения памяти для хранения больших и маленьких объектов сильно отличаются. Хотя разработчик stl предусмотрел это заранее наделив классы методом ::reserve(size_t num);
Если знать и уметь пользоваться стандартными классами C++, то тот же vector<int> практически не будет уступать по скорости int *(а во многих ситуациях обгонит, если не писать свой MyVector<int> также работающий c int * + куча плюшек и оптимизаций), но наградит вас весьма и весьма полезными функциями.

[Kostia]

Извините не удержался )))

Сообщение от MaTBeu

Да ну! Скажите мне, зачем еще нужно ключевое слово auto из стандарта С++0x, кроме как для сокращения кода?

template <typename LHS, typename RHS> 
    auto AddingFunc(const LHS &lhs, const RHS &rhs) -> decltype(lhs + rhs)
{
    return lhs + rhs;
}
...
auto x = AddingFunc(5, 0.5);
cout << x  << " " << typeid(x).name() << endl;

Сообщение от MaTBeu

Вы, наверное, забыли про ассемблер. Производительней него только машинный код, но увы, на нем никто не пишет.

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

[DM_bite]

Сообщение от An1ka

Не мешайте нам любить C++ !

Можно я эту фразу себе в подпись заберу?

[Xezon]

Не мешайте нам любить C++ !

А кто мешает