C++‭ ‬2009

Вы принципиальный сторонник "прогресса"?

Ошибаетесь вы. Покурите Рихтера или спецификацию C#.

поржал когда зашел к вам в профиль и увидел "О себе: С# разработчик". это пипец, правда.

Ну я надеюсь, что это не последний мой материал из этой же серии: решил начать издалека. Тем более, если всё заготовленное в одну статью включить, то она получится слишком уж большой.

Добавил, спасибо!

И который, кстати, включен в VS2008 sp1 beta (но не для express).

Быть может, скоро можно будет хоть часть работы для веба писать на C++.

Что мешает сейчас, если уж так хочется, и какие перечисленные нововведения в этом престранном занятии помогут?

Я мог бы указать источники, но их довольно много пришлось анализировать, изучать. И то, немного запоздал с публикацией. Рад, что понравилось.

Да, я, кстати, тоже заметил приближение к C#.

Если смотреть со стороны программирования для Web, то для двусторонних сервисов (с бэкендом и фронтэндом) можно уже сейчас использовать «the powers of C++» для реализации «заширменной» части проектов (с новыми обновлениями это становится ещё удобнее, как мне кажется), а фронтэнд имплементировать через обычные повседневные вещи (Ruby, PHP, Python, и др.).

Быть может, скоро можно будет хоть часть работы для веба писать на C++.

Не надо. Не стоит, право, как истинный (истовый) сиплюсплюсник говорю вам - для всех задач - свои средства. А то у нас тут один «гений» (во всех фирмах есть такие чокнутые гики) написал XML-RPC сервер на чистом С++, с обработкой HTTP запросов и всем прочим....

Да ну, очередное выпячивание. Не учитывается ни контекст ни время создания языка ни его история.
Кстати, когда увидел урл было подумал, что речь пойдет про C--, эдакий эксперимент десятилетней и более давности. Тогда был предложен язык по синтаксису сильно напоминающий С, но смещенный в сторону ассемблера. Тогда такой язык расценивался как вполне жизнеспособный, код на асме еще массово писали. Теперь, наверное, идеи C-- автору статьи, которую вы приводите, вообще покажутся анахронизмом.

Обсуждать там нечего: "Книгой самого Страуструпа вообще убить можно. (А вот прочитать до конца практически нельзя)". Всё-таки, неплохо бы дочитать Страуструпа, прежде чем бросаться на амбразуру с подобными статьями.

Проблема этой статьи в том, что в ней в одну кучу свалены справедливые выпады в сторону далеко не идеального языка и откровенно страные умозаключения.
Разумеется, у С++ есть огромное количество кривостей, неудобств и проблем, но ведь наши недостатки являются продолжениями наших достоинств? Как сказал кто-то, довольно трудно иметь красивую и скромную жену одновременно.
Тот же Страуструп по поводу простоты Джавы говорил: "подождём хотя бы несколько лет и посмотрим, останется ли Джава такой же простой".
Как мы видим, Сишарп сильно расширился к третьей версии. Мой когда-то любимый язык Бейсик на ZX Spectrum был простым, по сравнению с ним QuickBasic показался мне жутким монстром в своё время. Простота любого языка обязательно вылезает боком в другом месте. На эту тему высказывался и Спольски: http://www.joelonsoftware.com/articles/f… Не верю я в бесплатную простоту.

В качестве примера явно предвзятого суждения можно указать на оценку автором библиотеки STL. Только начиная её изучать, я ради интереса написал программу, подсчитывающую частоту встречаемости разных слов во входном тексте. Результаты нужно было печатать с использованием различных критериев сортировки: по алфавиту, по частоте.

Тогда мне показалось (и сейчас кажется), что делается это в STL довольно просто и эффективно. Ничуть не сложнее, чем в той же Джаве.

А всякие разговоры на тему reference semantics vs. value semantics и т.п. — это чистой воды вкусовщина. В Джаве новички тоже пишут string a, b; ... if(a == b) вместо a.equals(b). И что теперь?..

Это же исторический раздел, то есть псевдонастоящее время.

возможно, стоило промолчать?

А что Всас мешает писать на C++? Если можно, то поподробнее.

Скорее не "мало возможностей", а "мало средств".

Более того, ошибкой! Эти усложнения только ухудшат язык.

нет, вы не правы. многие изменения очень логичны (например использование ключевого слова "auto" - аналог c# var), другие приятны - decltype,
третьи... удивительно что их давно не ввели в стандарт (я насчет >> в шаблонах)
единственное что может отразиться на производительности - atomic, thread, etc: эти нововведения целиком на совести разработчиков компиляторов

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

typedef unsigned int samplenum_t;

int i = 10;
samlenum_t current(0);
++current;
current = i; // error: different types

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

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

По пункту 1)
Идея абсолютно не классная и никогда не будет реализована в хорошем языке. Понимаете - конструктор это метод конструирующий объект. Объекты создаются строго в порядке иерархии наследования. Каждый потомок в чём-то потенциально опирается на предка. Возможность вызывать конструктор в любой строке, по сути означает, что будет возможность выполнять некий код потомка до того, как сконструирован его предок. Грубо говоря, детёнок начинает говорить до того, как родилась его мама. :-)
В джава также нельзя этого делать. Там просто синтаксически вызов конструктора предка идёт в первой строке конструктора потомка. Строго в первой и нигде больше. Исключительно для того, что бы показать каким конкретно конструктором мы хотим создать предка. Никакую функцию в параметр также вставить нельзя. Компилятор выдаст ошибку.

А они там были? Разве это всё не буст?..
(с другой стороны, какая разница — 0x или boost — есть буст, и радуемся... :)

приведите пожалуйста пример, когда auto является ошибкоопасной бнёй

> Насчёт rvalue тоже непонятно, зачем? Есть же shared_ptr, который даст в случае чего тот же результат.

Т.е. вы предлагаете вместо:


std::vector<int> gen() { ... }

std::vector<int> x = gen();


Писать:


boost::shared_ptr<std::vector<int> > gen() { ... }

boost::shared_ptr<std::vector<int> > x = gen();


?

Или так:


void gen(std::vector<int> & x) { ... }

std::vector<int> x;
gen(x);


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