Здравствуйте, Erop, Вы писали:
E>А есть сомнения, в том, что с++-потоки -- это говнокод? 
Если честно — есть.
Ну, то есть претензии к ним
E>Как ты относишься к тамошнему виртуальному наследованию, например?
Плохо. Но оно явно там такое оттого, что в языке не было нормального разделения интерфейсов и реализаций, а также возможности делать external methods.
То есть с точки зрения пользователя библиотеки — всё отлично. А то, какие там ромбики внутрях — это вопрос вторичный.
E>А к "удобству" поддержки юникода?
E>А к невозможности использовать юникод в именах файлов?
E>Ну и т. д.
Это не вина потоков. Это проблема подхода в целом. Сказывается сишное прошлое плюсов, когда "строка" и "набор байтов" было одним и тем же.
Многие разработчики и посейчас так думают. Удивляются потом, почему lowercase строки в современных платформах такой медленный — по сравнению с bit-crinching на SSE3, напедаленным руками.
E>Показанной тобой проблемы не будет. В std нет count, а в глобальном нет cout, если ты сам его не заведёшь, конечно... 
Проблема так и останется — неожиданная смена семантики оператора <<.
Я просто выбрал идентификаторы немножко тролльским способом, чтобы ярче показать эту "проблему".
А вообще, идея была в том, что способ перегрузки операторов для потоков в С++ — далеко не самая "некрасивая" часть. Как раз всё более-менее здорово. Плюс ещё и манипуляторы — тоже круто.
С арифметикой вообще всё достаточно интересно устроено.
С одной стороны, есть "чёрная магия", типа вычитания по оператору +.
С другой стороны, есть "белая магия", когда мы делаем удобные и очевидные вещи, типа прибавления целого к "указателю". Тут мы полностью сохраняем все особенности семантики типа a[i] == a + i == i + a == i[a] (последнее — по желанию)
С третьей стороны, есть "серая магия", когда мы перегружаем операторы логичным способом, но теряем часть эквивалентностей. Например, для матриц мы знаем, что a * b != b * a. И вообще, в целом у нас далеко не всегда есть гарантии типа (a — b) == a + (-1 * b) — скажем, даты можно вычитать (с получением timespan), но умножать дату на интегер не имеет смысла.
E>Так не надо глупости писать, что вот де мол и на С++ так тоже можно.
Я пишу не глупости, а очевидные вещи.
E>Я ещё раз намекаю, что на С++ можно вобще полный аналог линка залудить, если очень хочется. Тока не делают так почему-то 
Делают через STL-way
По-всякому делают. Я же почему писал, что "критики на поверку и С++ не знают". Потому и писал, что на практике оказывается, что они знают только уютную маленькую область С++, в которой всё расположено привычным образом. А настоящий взрослый С++, с шаблонами, частичной специализацией, функторами, и прочим, никакими такими волшебными свойствами, которые ему приписывают (типа предсказуемости асимптотик) совершенно не обладает.
А в ответ на идею кастрировать С++ и запретить писать в "функциональном стиле" я выдвигаю симметричный ответ: на С# тоже можно отказаться от всей этой адской мощи и писать на комфортном подмножестве синтаксиса.
Здравствуйте, Sinclair, Вы писали:
S>assert((cout << 2) == (cout * 4)); // 
а где std:: ?
... << RSDN@Home>>
Здравствуйте, Трололоша, Вы писали:
S>>assert((cout << 2) == (cout * 4)); //
Т>а где std:: ?
Ты же прочитал ответ Sinclair, даже оценку поставил, а тут такое трололо.
Я просто выбрал идентификаторы немножко тролльским способом, чтобы ярче показать эту "проблему".
Здравствуйте, fddima, Вы писали:
S>>>assert((cout << 2) == (cout * 4)); //
Т>>а где std:: ?
F> Ты же прочитал ответ Sinclair, даже оценку поставил, а тут такое трололо.
Я их читал и отвечал в Janus, они там не совсем в той последовательности как в плоском виде.
... << RSDN@Home>>
