Свежие комментарии

А какой именно знак у типа char? Если я использую char без указания знаковости, значит мне на неё просто плевать.

Если говорит о корпоративной разработки...

Ну, Java и C# только выиграют от развития C++.

Со сравнением перл/С++ - мне очень сложно согласиться.
Это очень, очень грубое сравнение.

(кстати, корпоративная страничка стала содержать C++ программера, перловщик - так и не пропал)

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

Ты извини, я - многословен бываю. :-)
Может сложиться впечатление, что я защищаю Си++.
У тебя есть знакомые, кто уже перешёл на Erlang и Haskell с Ocaml?
Звали тебя?

> По мне, так современный C++ вообще слишком сложен.
Хм. Может быть, вам тема raw-форматов фотографий или параллельных вычислений на GPU - кажется более простой?
Думаю, язык этот сложен не потому, что авторам просто захотелось сделать его настолько сложным.
Суть в том, что если взять пользователей, сферу применения и решаемые задачи - и этот самый язык, который их объединяет, то окажется, что сложность тут не на ровном месте возникла.

Кстати, вот интересно, для чего, лично по твоему мнению, существует современный Си++?
Чтобы создавать KDE?
Чтобы делать обёртки для plain vanilla C библиотеки gtk+?

> идея, что семантику простых типов (операторы, собственно) можно безболезненно *и эффективно* нести на сложные типы - мне кажется немножо неправильной.
Я для себя понял, что этот вопрос - уже пройденный этап.
"Тема закрыта."
Другая тема, которая, вроде бы тоже "закрыта", но ещё "в работе" - это встраивание в язык концептов.

> многие вещи облегчает за счет code reuse
Даже не столько "reuse", сколько просто - "use".
(вот тут один британец очень хорошо закрыл эту тему - на 36:40)

Ещё в прошлом веке, один мой институтский товарищ умело интуитивно пользовался стандартными потоками и свято верил, что конструкции типа cout << "Hello, world!" << endl; - являются встроенной частью языка (т.е. не библиотека тебе поставляет cout, оператор << для потока и других типов, манипулятор endl, а именно язык Си++).

Я к тому, что если ты не писатель библиотек (а ты - писатель), то не все разделы языка тебе так уж обязательно знать для решения насущных задач.

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

Оказывается, тема prefix/postfix - это серьезная такая проблема, дискутируется, люди тесты пишут.

Дык, "unsigned short *" - это вам не std::map::const_iterator!

Или, вот участвовал я в разработке одной системы, там понадобилось для промежуточного представления (есть представление "нетронутое", а есть - "чуть подправленное") писать итератор (разные пользователи параллельно проходят: кто-то по прежнему представлению, кто-то уже по изменённому; кстати, итератор по изменённому представлению - блокирует изменение...).

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

Есссно, главный вопрос в том, что из себя представляет output.

Там, скорее всего - только встроенные типы.
Для них - не так много разницы.

А плюсы стремятся предоставить это не только для встроенных типов.
Вот тут и начинается в Си++ "большАя разница-а-а-а"... (тут вот хорошо агент Смит говорит: "Но это всё - фигня! Кстати, у нас в Матрице - есть истории по-круче...")

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

А, ага, для постфиксной формы нам надо скопировать объект, а для префиксной - достаточно вернуть референс на текущее состояние.

Во, алаверды к Максиму, нашел на Stack Overflow:
===
Herb Sutter and Andrei Alexandrescu, C++ Coding Standards, p.50: "The prefix
form is semantically equivalent, just as much typing, and often slightly
more efficient by creating one less object. This is not premature
optimization; it is avoiding premature pessimization."
===
http://bytes.com/topic/c/answers/168681-why-prefix-increment-faster-than...

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

Может быть, кстати, автор коммита так вычищал предупреждение gcc

Александреску, например, говорит о предположительно большей эффективности префиксных инкрементов. А это голова :)

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

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

Больше всего бесит, когда есть char* и unsigned char *, и gcc ругается на их смешивание. Так что есть у него ненулевое количество бесполезных, а иногда просто отвлекающих предупреждений. Есть много полезных, конечно.

да уж - колоритно

вот уж, где плюсы - лишь наследуют...
Plain Vanilla C