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

ГВ>>Ну да, и что? Ты думаешь, кого-то это смущает?
S>Я не думаю, я знаю. Еще раз: покажите мне хоть одну нормальную реализацию строк, вместе с проектом, который на ней построен.
S>Очевидно, разработчиков каких-нибудь XML парсеров всё-таки смущает то, что в базовой комплектации нет внятных строк. Поэтому имеем то, что имеем. А не возможность подсунуть твою мега-гитлер-строку в XML парсер и ускорить его на порядок.
Фигня эти строки. НАСТОЯЩИЕ пацаны пишут XML-парсеры с использованием SSE-инструкций — работает быстрее раз в 10, чем обычные парсеры.

Или библиотеку контейнеров и алгоритмов с поддержкой SSE.

Повтори такое на C#.

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

PD>А вот что не ладно — какие альтернативы С++ можете предложить в ЕГО НИШЕ ? Вот представьте себе — исчез он. Чем замените ?

Eiffel (есть сравнивать сами языки, а не объем доступных библиотек).
Ada 2005 (она таки родилась, и даже бесплатные версии средств разработки выходят -- http://libre.adacore.com/libre/).

Здравствуйте, Cyberax, Вы писали:
C>Фигня эти строки. НАСТОЯЩИЕ пацаны пишут XML-парсеры с использованием SSE-инструкций — работает быстрее раз в 10, чем обычные парсеры.
Ну что ж, давай ссылку на эти НАСТОЯЩИЕ парсеры в студию. Будем мерить (правда, только через недельку — я в отпуск уезжаю).

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

S>Здравствуйте, Cyberax, Вы писали:
C>>Фигня эти строки. НАСТОЯЩИЕ пацаны пишут XML-парсеры с использованием SSE-инструкций — работает быстрее раз в 10, чем обычные парсеры.
S>Ну что ж, давай ссылку на эти НАСТОЯЩИЕ парсеры в студию. Будем мерить (правда, только через недельку — я в отпуск уезжаю).
http://parabix.costar.sfu.ca/ (http://www.international-characters.com/product)

PS: "А что я? Я сама офигела" (с) анекдот.

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

G>>А кто будет знать? Дева мария или еще кто-то?
G>>Именно процессор и делает такие провеки.
PD>О господи! Ну прочитай же наконец про атрибуты страниц в страничном механизме. Пойми, что процессору все равно, куда писать — он транслирует вирт. адрес в физический через этот механизм, и если при этом атрибут страницы R/O, то возникнет исключение. А проверку эту он делает всегда. Всегда, понимаешь ?
ладно-ладно, а кто сказал что вообще включена страничная адресация? и таки опять же CR0.WP...

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

ГВ>>Ну да, и что? Ты думаешь, кого-то это смущает?
S>Я не думаю, я знаю. Еще раз: покажите мне хоть одну нормальную реализацию строк, вместе с проектом, который на ней построен.

Нормальная — это какая? Список требований в студию!

S>Очевидно, разработчиков каких-нибудь XML парсеров всё-таки смущает то, что в базовой комплектации нет внятных строк. Поэтому имеем то, что имеем. А не возможность подсунуть твою мега-гитлер-строку в XML парсер и ускорить его на порядок.

А с чего ты взял, что подсовывание мега-гитлер-строки в XML-парсер ускорит его на порядок?

ГВ>>Повторюсь: если мне не понравятся строки, то хай ANSI вместе XJ21 подавятся своим стандартом — я сделаю новые хранилища/манипуляторы строк и вся идеология C++ тут мне помощником.
S>Смелая гипотеза. Юношеский задор

Цену якобы догматичности стандарта я знаю очень хорошо и до того, чтобы делать глобальные индукции на его базе не опускаюсь уж лет восемь как. Стандарт — это компромисс, но те, кто его разрабатывал, даже не знали о том, с какой спецификой я столкнусь в своих проектах. И кроме того, стандарт в части core language проработан на порядок лучше, чем в части STL. И что мне теперь, сделать из STL икону только потому, что она под одной обложкой с core language?

S>Нет. Вся идеология С++ тут же гирей повиснет у тебя на ногах. Потому что в современном мире только редкие люди могут себе позволить писать без использования сторонних библиотек.

Прости, я говорю об идеологии C++ core language, а не коктейля C++ core language + STL. Во-вторых, я не сказал, что откажусь от всего STL. В-третьих, даже MFC в своё время не повисала гирей у меня на ногах. ЧЯДНТ?

ГВ>>Единственное место, где неизбежно придётся учитывать наличие ASCIIZ — строковые литералы, так их вообще, чем меньше — тем лучше. А сторонние API — это всегда сторонние API со своими приколами (CRT — тоже один из API).
S>Все приколы сторонних АПИ связаны именно с тем, что нет нормальной архитектуры.

Да??? То есть не с десятилетиями предыдущей истории в которой было всё: от ограничений по объёму памяти до неразберихи с кодировками, а с тем, что сейчас изменились представления о нормальной архитектуре? Welcome to the real world, коллега.

ГВ>>Хорошо, пусть проблема будет в контракте. Но и это не повод переносить недостатки контракта basic_string на весь C++. Если хочешь, давай отдельно поругаем контракт basic_string, я не против. Мне он тоже не во всём нравится.
S>Ишь, какой ты хитрый! Нет уж, хрен там. Это не я придумал вносить STL в стандарт языка. Поэтому я имею полное право критиковать "строки в С++" именно в том виде, в каком их предложил комитет.

Хорошо, понятно. Говоря о строках в C++ ты имеешь в виду "строки, описанные в стандарте C++". Тут есть некоторая разница со "строками в C++", не находишь?

S>Или ты рассчитывал, что я буду обсуждать исключительно компилятор С++? Спору нет, компилятор в С++ просто прекрасен. Но без STL он даже не заработает.

Почему это он без STL не заработает? Ты про type_info и xxxxx_cast, которые поддерживаются компилятором? Это микроскопический кусок STL. Зато ни один из известных мне компиляторов не порождает std::string заметив в тексте программы строковый литерал. И это, ИМХО, хорошо.

ГВ>>Кто тебе сказал такую глупость? Они будут интероперировать через промежуточные абстракции. Никто не мешает выполнять преобразование из rope к ASCIIZ в последний момент перед вызовом функции, требующей именно ASCIIZ. В чём прикол твоего утверждения о невозможности интероперабельности?
S>В том, что нет никакого смысла держать "эффективные строки", которые один хрен нужно неэффективно преобразовывать в непонятно что при отдаче в любой внешний код. Ты не можешь прочитать "эффективную строку" из файла, ты не можешь передать "эффективную строку" для вывода на экран. Всё, что ты можешь делать — это жонглировать ей внутри узкого кусочка своей программы.

Гы-гы. Так затраты на чтение из файла и на выдачу на экран с лихвой покрывают почти любую неэффективность преобразований (кроме того, из файлов читают линейные последовательности байтов, а не строки). Эффективные строки мне понадобятся, когда возникнет необходимость, например, оптимизировать операции модификации строк. Или когда строк окажется тыща мильёнов и понадобится разобраться с фрагментированием памяти. А в "типичных" программах потери на хранение и операции даже с такими строками, как std::wstring так же комичны, как тестирование StringBuilder на неэффективность.

И потом, что за пренебрежительный тон? Жонглировать... Не жонглировать, а решать задачу.

ГВ>>Надо посмотреть, обещать ничего не могу, но, вроде бы, какая-то из реализаций STL выполняла преобразование к ASCIIZ по запросу c_str().
S>А что, не все реализации возвращают ASCIIZ по запросу с_str()???

Вроде бы, не все хранят ASCIIZ. А возвращать должны все. То есть c_str() может неявно вызывать дополнительное распределение буфера под ASCIIZ-представление.

S>Я тебе на всякий случай напомню, что это — небезопасная строка. На ее константность полагаться нельзя, т.к. по контракту std::string рушит этот буфер после первого же неконстантного вызова.

Одно другому не противоречит.

ГВ>>Тройной одеколон вам в перегонку... С++-ники сопротивляются переносу оценки "УГ" по маршруту: std::basic_string -> C++ -> C++-ники. Не трещите так много про унылость "самих C++-ников" и C++ — и прекрасно услышите, как сами C++-ники ругают и ASCIIZ, и std::basic_string. Понимаешь? Вот не надо неправомерных обобщений и всё будет намного проще.
S>Я делаю обобщения совершенно правомерно. Показываю еще раз: std::basic_string, как и std::wstring — отстой. Это мы уже выяснили путём непросредственного сравнения.

Ещё раз. В сравнении участвовала одна из реализаций STL. Проблемы контракта std::basic_string очень далеки от мутабельности/иммутабельности, если тебе это интересно. Например, на мой взгляд, недостатком является засовывание методов find в сам класс строки. Даже не недостатком, а странностью: на фига он там, если есть итераторы?

S>И проблема — не в конкретной реализации, а в том, что хреново спроектированы контракты этих классов.

Ты постулируешь таким образом, что в рамках текущего контракта basic_string нельзя "порвать" StringBuilder? С чего ты взял? Вопрос только в степени наивности индукций о реализации, сделанных разработчиками данной версии STL на основе прочтения контракта. ИМХО — так.

S>Именно контракты являются частью стандарта С++, что даёт мне право говорить о том, что "строки в стандарте С++ — говно".

В стандарте C++, правильно.

S>Про с++ников я такого не говорил, хотя люди, готовые закидать меня минусами только за то, что я повторяю банальную истину, вместо того, чтобы хоть на минуту о ней задуматься, доброго слова не заслуживают. Мне, собственно, всё равно — можете засунуть голову в песок хоть по пояс. Хороших строк в С++ от этого не появится.

Что-то твои "банальные истины" очень сильно граничат с трюизмами.

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

ГВ>Нормальная — это какая? Список требований в студию!
Нет, они таки продолжают вилять тылом.

ГВ>А с чего ты взял, что подсовывание мега-гитлер-строки в XML-парсер ускорит его на порядок?
Ну, к примеру с того, что подсовывание стрингбуфера в своё время на порядок подняло перформанс компилятора Явы.

ГВ>Цену якобы догматичности стандарта я знаю очень хорошо и до того, чтобы делать глобальные индукции на его базе не опускаюсь уж лет восемь как. Стандарт — это компромисс, но те, кто его разрабатывал, даже не знали о том, с какой спецификой я столкнусь в своих проектах.
Мне всё равно, по каким причинам разработчики стандарта сделали его таким. Ну, то есть не всё равно — я читал, к примеру, Дизайн и Эволюцию, и историю вопроса представляю себе достаточно хорошо. Но это никак не отменяет того факта, что результат недостаточно хорош.
ГВ>И кроме того, стандарт в части core language проработан на порядок лучше, чем в части STL. И что мне теперь, сделать из STL икону только потому, что она под одной обложкой с core language?
А куда тебе деваться? Или ты готов объявить "языком C++" только то, что тебе нравится? Отлично. Ну так поздравляю — в твоём С++ недостатков вовсе нет. Потому что твоя позиция позволяет "не делать из них икону".

ГВ>Прости, я говорю об идеологии C++ core language, а не коктейля C++ core language + STL.
Прости, что такое "идеология core language"?
ГВ>Во-вторых, я не сказал, что откажусь от всего STL.
Да? Ты сразу перечисли то, от чего откажешься. Чтобы я знал, что критиковать нельзя.
ГВ>В-третьих, даже MFC в своё время не повисала гирей у меня на ногах. ЧЯДНТ?
Ты? Не сравниваешь с другими возможностями. Я, когда программировал на MFC, тоже не представлял себе, в чём там может быть проблема. Вот только это было десять лет тому назад, и с тех пор я узнал много нового. В том числе и о том, как важно для эффективной реализации построить хороший контракт.

ГВ>Да??? То есть не с десятилетиями предыдущей истории в которой было всё: от ограничений по объёму памяти до неразберихи с кодировками, а с тем, что сейчас изменились представления о нормальной архитектуре?
Да, представления изменились. Увы. Давайте теперь говорить, что ВАЗ 2101 — классная машина, потому что десятилетия назад это был ФИАТ.
Извини, с тех пор представления о "классной машине" немножко изменились. ВАЗ 2101 в этом не виноват. А вот те, кто упорно за него цепляется, отказываясь понимать преимущества инжекторного двигателя, коробки-автомата, кондиционера — виноваты.

ГВ>Хорошо, понятно. Говоря о строках в C++ ты имеешь в виду "строки, описанные в стандарте C++". Тут есть некоторая разница со "строками в C++", не находишь?
Да-да, можно еще и так попытаться выкрутиться. Ок. Давай тогда так: о чём ты говоришь, говоря о "строках в С++"?
Вот варианты:
1. Только строковые константы. STL — не часть языка, а core language ничего, кроме ASCIIZ, не умеет
2. Все стандартизованные строки, то есть std::string и ASCIIZ
3. Все классы строк, реально написанные в реальных фреймворках на основе C++: MFC, ATL, QT, etc.
4. Те классы строк, которые могли бы быть потенциально написаны на C++, если бы кто-то взялся за этот непосильный труд, и это имело какой-то практический смысл, с учётом объема легаси-кода, построенного на строках из п.3.
Я предлагаю пункт 2, но он тебе не подходит. Пункт 3, по какому-то неудачному стечению обстоятельств, тоже предлагает какое-то ужасное г. (по сравнению с CString, STL-ный вариант еще ничо). Опровергни меня, если я неправ.
Против пункта 4 я решительно возражаю: я тогда ему противопоставлю еще более потенциальные строки, которые могли бы быть написаны на гипотетической VM. Я говорил об имеющихся фактах, а не о сослагательном наклонении.


ГВ>Почему это он без STL не заработает?
Потому что RTFM. Потому что ему нечего будет бросать в случае нехватки памяти.

Ты про type_info и xxxxx_cast, которые поддерживаются компилятором? Это микроскопический кусок STL. Зато ни один из известных мне компиляторов не порождает std::string заметив в тексте программы строковый литерал. И это, ИМХО, хорошо.
Это, имхо, плохо. Ну, то есть порождение std::string его бы, конечно, не спасло. Но и то, что он сейчас порождает, плохо. Потому что ASCIIZ-литералы лишены даже длины, что для современных строковых литералов недопустимо. Даже холлеритовские строки в фортране и то были лучше спроектированы (хоть и ужасно выглядели).

ГВ>Гы-гы. Так затраты на чтение из файла и на выдачу на экран с лихвой покрывают почти любую неэффективность преобразований (кроме того, из файлов читают линейные последовательности байтов, а не строки). Эффективные строки мне понадобятся, когда возникнет необходимость, например, оптимизировать операции модификации строк. Или когда строк окажется тыща мильёнов и понадобится разобраться с фрагментированием памяти. А в "типичных" программах потери на хранение и операции даже с такими строками, как std::wstring так же комичны, как тестирование StringBuilder на неэффективность.
А-а, ну-ну. Третий способ вильнуть, значит. Ок, производительность строк вообще никого не интересует. И это у нас, значит, позиция поклонников "самого эффективного в мире языка". Отлично. Можно, я буду ссылаться на этот пост всякий раз, когда кто-то будет гнобить С# за, к примеру, проверки на выход за границы массива?

ГВ>Вроде бы, не все хранят ASCIIZ. А возвращать должны все. То есть c_str() может неявно вызывать дополнительное распределение буфера под ASCIIZ-представление.
Может. Это она запросто.

ГВ>Ещё раз. В сравнении участвовала одна из реализаций STL. Проблемы контракта std::basic_string очень далеки от мутабельности/иммутабельности, если тебе это интересно.
Ок. Приведи хорошую реализацию wstring с тем же контрактом.

ГВ>Например, на мой взгляд, недостатком является засовывание методов find в сам класс строки. Даже не недостатком, а странностью: на фига он там, если есть итераторы?
Недостаток-недостаток. Это правда. Вообще, очень-очень многие фреймворки на C++ грешат злоупотреблением методами экземпляров.

ГВ>Ты постулируешь таким образом, что в рамках текущего контракта basic_string нельзя "порвать" StringBuilder? С чего ты взял?
Из опыта, который сын ошибок трудных.
ГВ>Вопрос только в степени наивности индукций о реализации, сделанных разработчиками данной версии STL на основе прочтения контракта. ИМХО — так.
В таком случае тебя, наверное, не затруднит "починить" данную версию STL так, чтобы она опередила управляемые строки, не изменяя контракта. С потокобезопасностью, всё такое.

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

ГВ>>А с чего ты взял, что подсовывание мега-гитлер-строки в XML-парсер ускорит его на порядок?
S>Ну, к примеру с того, что подсовывание стрингбуфера в своё время на порядок подняло перформанс компилятора Явы.

При чём тут Ява?

ГВ>>Цену якобы догматичности стандарта я знаю очень хорошо и до того, чтобы делать глобальные индукции на его базе не опускаюсь уж лет восемь как. Стандарт — это компромисс, но те, кто его разрабатывал, даже не знали о том, с какой спецификой я столкнусь в своих проектах.
S>Мне всё равно, по каким причинам разработчики стандарта сделали его таким. Ну, то есть не всё равно — я читал, к примеру, Дизайн и Эволюцию, и историю вопроса представляю себе достаточно хорошо. Но это никак не отменяет того факта, что результат недостаточно хорош.

С этим фактом никто и не спорит.

ГВ>>И кроме того, стандарт в части core language проработан на порядок лучше, чем в части STL. И что мне теперь, сделать из STL икону только потому, что она под одной обложкой с core language?
S>А куда тебе деваться? Или ты готов объявить "языком C++" только то, что тебе нравится? Отлично. Ну так поздравляю — в твоём С++ недостатков вовсе нет. Потому что твоя позиция позволяет "не делать из них икону".

Отнюдь. Дело не в том, что мне нравится, а что нет.

ГВ>>Прости, я говорю об идеологии C++ core language, а не коктейля C++ core language + STL.
S>Прости, что такое "идеология core language"?

Не платить за то, чем не пользуешься.

ГВ>>Во-вторых, я не сказал, что откажусь от всего STL.
S>Да? Ты сразу перечисли то, от чего откажешься. Чтобы я знал, что критиковать нельзя.

Да критикуй на здоровье всё, что угодно.

ГВ>>В-третьих, даже MFC в своё время не повисала гирей у меня на ногах. ЧЯДНТ?
S>Ты? Не сравниваешь с другими возможностями.

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

S>Я, когда программировал на MFC, тоже не представлял себе, в чём там может быть проблема.

Оба-на! Какое знаменательное во многих отношения признание. Значит, у нас с тобой диаметрально противоположная оценка MFC. Меня понимание неудобоваримостей MFC вовсе не сковывало, хотя я тоже называл её разными нехорошими словами, мне мешало только то, что я не мог остановиться на какой-то определённой модели её совершенствования. Ах, юность, юность.

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

Ну поздравляю. Тебя ждёт ещё уйма удивительных открытий, например, что корректная и непротиворечивая постановка задачи решающим образом сказывается на скорости производства и качестве ПО, а вовсе не +- 100 строк на сериализацию. А из корректной постановки задачи уже растут остальные хорошо-плохо и правильно-неправильно. Тогда как сама по себе корректная постановка задачи непосредственно касается психологии, подчас — психиатрии.

ГВ>>Да??? То есть не с десятилетиями предыдущей истории в которой было всё: от ограничений по объёму памяти до неразберихи с кодировками, а с тем, что сейчас изменились представления о нормальной архитектуре?
S>Да, представления изменились. Увы. Давайте теперь говорить, что ВАЗ 2101 — классная машина, потому что десятилетия назад это был ФИАТ.
S>Извини, с тех пор представления о "классной машине" немножко изменились. ВАЗ 2101 в этом не виноват. А вот те, кто упорно за него цепляется, отказываясь понимать преимущества инжекторного двигателя, коробки-автомата, кондиционера — виноваты.

Некорректная аналогия. С другой стороны, дороги, которые разбивали вдребезги подвеску ВАЗ 2101 в такой же хлам разнесут современную "классную машину", даже быстрее. Если это не БТР.

ГВ>>Хорошо, понятно. Говоря о строках в C++ ты имеешь в виду "строки, описанные в стандарте C++". Тут есть некоторая разница со "строками в C++", не находишь?
S>Да-да, можно еще и так попытаться выкрутиться. Ок. Давай тогда так: о чём ты говоришь, говоря о "строках в С++"?

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

S>Вот варианты:
S>1. Только строковые константы. STL — не часть языка, а core language ничего, кроме ASCIIZ, не умеет
S>2. Все стандартизованные строки, то есть std::string и ASCIIZ
S>3. Все классы строк, реально написанные в реальных фреймворках на основе C++: MFC, ATL, QT, etc.
S>4. Те классы строк, которые могли бы быть потенциально написаны на C++, если бы кто-то взялся за этот непосильный труд, и это имело какой-то практический смысл, с учётом объема легаси-кода, построенного на строках из п.3.
S>Я предлагаю пункт 2, но он тебе не подходит. Пункт 3, по какому-то неудачному стечению обстоятельств, тоже предлагает какое-то ужасное г. (по сравнению с CString, STL-ный вариант еще ничо). Опровергни меня, если я неправ.

Попробую, но не сейчас. Скорее всего, фактически, в общеиспользуемых фреймворках строки как раз простые — с линейными буферами. В лучшем случае — COW. Сложные реализации используются в специальных случаях.

S>Против пункта 4 я решительно возражаю: я тогда ему противопоставлю еще более потенциальные строки, которые могли бы быть написаны на гипотетической VM. Я говорил об имеющихся фактах, а не о сослагательном наклонении.

Э-э-э... Гипотетическая VM будет проще в реализации, чем гипотетическая строка?

ГВ>>Почему это он без STL не заработает?
S>Потому что RTFM. Потому что ему нечего будет бросать в случае нехватки памяти.

А... Тут ты прав. Исключения описаны в рамках STL. Правда, в стандарте, тем не менее, не сказано, что исключения должны быть реализованы именно через std::string. Кстати, код std::exception из MS STL сюда загнать или сам посмотришь? Там никакими std::string даже не пахнет.

ГВ>>Ты про type_info и xxxxx_cast, которые поддерживаются компилятором? Это микроскопический кусок STL. Зато ни один из известных мне компиляторов не порождает std::string заметив в тексте программы строковый литерал. И это, ИМХО, хорошо.
S>Это, имхо, плохо. Ну, то есть порождение std::string его бы, конечно, не спасло. Но и то, что он сейчас порождает, плохо. Потому что ASCIIZ-литералы лишены даже длины, что для современных строковых литералов недопустимо. Даже холлеритовские строки в фортране и то были лучше спроектированы (хоть и ужасно выглядели).

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

ГВ>>Гы-гы. Так затраты на чтение из файла и на выдачу на экран с лихвой покрывают почти любую неэффективность преобразований (кроме того, из файлов читают линейные последовательности байтов, а не строки). Эффективные строки мне понадобятся, когда возникнет необходимость, например, оптимизировать операции модификации строк. Или когда строк окажется тыща мильёнов и понадобится разобраться с фрагментированием памяти. А в "типичных" программах потери на хранение и операции даже с такими строками, как std::wstring так же комичны, как тестирование StringBuilder на неэффективность.
S>А-а, ну-ну. Третий способ вильнуть, значит. Ок, производительность строк вообще никого не интересует. И это у нас, значит, позиция поклонников "самого эффективного в мире языка". Отлично. Можно, я буду ссылаться на этот пост всякий раз, когда кто-то будет гнобить С# за, к примеру, проверки на выход за границы массива?

Во-первых, не надо обобщать мою позицию на всех. Во-вторых, повторюсь — это всё ровно до той поры, пока производительность на самом деле никого не волнует. Если она вдруг взволнует, то на C++ у меня несколько больше возможностей для манёвра, нежели на C#. Понимаешь, о чём я?

ГВ>>Вроде бы, не все хранят ASCIIZ. А возвращать должны все. То есть c_str() может неявно вызывать дополнительное распределение буфера под ASCIIZ-представление.
S>Может. Это она запросто.

ГВ>>Ещё раз. В сравнении участвовала одна из реализаций STL. Проблемы контракта std::basic_string очень далеки от мутабельности/иммутабельности, если тебе это интересно.
S>Ок. Приведи хорошую реализацию wstring с тем же контрактом.

Осталось её найти... Или написать.

ГВ>>Например, на мой взгляд, недостатком является засовывание методов find в сам класс строки. Даже не недостатком, а странностью: на фига он там, если есть итераторы?
S>Недостаток-недостаток. Это правда. Вообще, очень-очень многие фреймворки на C++ грешат злоупотреблением методами экземпляров.

Да это всему ООП-нутому свойственно. Ладно, фиг с ним.

ГВ>>Ты постулируешь таким образом, что в рамках текущего контракта basic_string нельзя "порвать" StringBuilder? С чего ты взял?
S>Из опыта, который сын ошибок трудных.

Скорее, из того, что ты этого ни разу не видел.

ГВ>>Вопрос только в степени наивности индукций о реализации, сделанных разработчиками данной версии STL на основе прочтения контракта. ИМХО — так.
S>В таком случае тебя, наверное, не затруднит "починить" данную версию STL так, чтобы она опередила управляемые строки, не изменяя контракта. С потокобезопасностью, всё такое.
Лето, солнце, море, почему бы и не переписать std::basic_string? Кстати, потокобезопасность не входит в контракт std::basic_string.

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

ГВ>>Почему это он без STL не заработает?
S>Потому что RTFM. Потому что ему нечего будет бросать в случае нехватки памяти.
Все известные мне компиляторы позволяют обойтись без использования стандартной библиотеки совсем (частью которой и является STL). Стандартные исключения можно заменить на свои с помощью:
1) Своего ::operator new
2) Платформенно-зависимых трансляторов исключений и т.п.

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

S>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>А я что-то говорил про специализацию шаблонов ? Где ? И про string я говорил лишь, что ее не использую.
S>Зато я говорил про специализацию шаблонов. Впрочем, это неважно. Как я понимаю, с С++ ты просто достаточно плохо знаком — либо я неправильно понимаю твои высказывания.

Ну вот, теперь я уже и с С++ плохо знаком. Как мне при этом удается писать эффективные программы — одному богу ведомо

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

Если по-твоему это не может быть правдой — это еще не значит, что твое высказывание есть правда. Но хватит на эту тему.


PD>>Какой-то набор малопонятных высказываний.
S>Не надо объяснять. Я всё прекрасно понимаю. Просто то, что ты называешь программированием — это очень-очень маленький кусочек большой картины. Но как только я пытаюсь тебе рассказать про остальные части картины и про их взаимосвязи, моя речь становится для тебя невразумительной. Ок, оставим.

Возвращаю мяч на твою половину. То, что ты считаешь программированием (web-программирование) — это маленький кусочек большой картины. И перенесение его принципов на все остальное выглядит довольно-таки несерьезно. А вот это ты и не хочешь понять.

PD>>Помнишь Вирта книгу "Алгоритмы + структуры данных == программы". И ни слова про оформление. Или тогда программирования не было ? Я думаю, что все же было. Вот к оформлению относились спокойнее.
S>Ну, во времена Вирта придумывали, грубо говоря, кирпичи. Сейчас кирпичи уже более-менее придуманы. С точки зрения опытного производителя кирпичей, народ занимается непонятно чем.



А посерьезнее у тебя аргументов не найдется ? Кирпичи или не кирпичи — но все же, тогда программы писали или нет ? И если все же писали — как же без паттернов и геттеров обходились, а также без интерфейсов ?

PD>>Конечно, если придумывать решение не надо, поскольку задача стандартная, то все иначе...
S>Ну почему же не надо. Я тебе еще раз намекаю на то, что если перед тобой поставить задачу спроектировать высокопроизводительное веб-приложение или даже веб-сервис, то ты встрянешь, несмотря на отсутствие каких-то сверхеъестествнных алгоритмических задач.

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


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

А кто говорил, что так-таки думать не надо. Вот дали бы тебе спроектировать msdn.microsoft.com — я бы посмтотрел, как бы ты, не думая, начал его писать. Ну а когда речь идет о сайте третьего заборостроительного завода имени четвертой пятилетке — чего там думать, делай, и вперед!

PD>>На мой взгляд многие необоснованно переносят принципы разработки web-приложений на программирование в целом.
S>Совершенно непонятно, откуда взялся такой взгляд. Веб-приложения я привожу всего лишь как примеры. А принципы разработки, вообще говоря, у всего софта примерно одинаковые. Не нужно только считать какие-то локальные практики, уместные в частных задачах невысокой сложности, всеобъемлющими принципами.

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

PD>>Ничего ты не понял. Увы. При чем тут регистры ? Я тебе сто раз объяснял, что моей задачей было найти эффективное решение задачи, алгоритм.
S>Прекрасно. Что ты называешь алгоритмом?

Ну вот, не хватает еще флейма на тему, что такое алгоритм. Почитай где-нибудь сам.

S>Есть, скажем так, определённый "язык" описания устройства веб-приложения. Адресное пространство там, структуры, всё такое. Это не конкретный язык программирования; это скорее неформальное описание того, на какие запросы и как должно отвечать приложение.
S>Основная задача проектировщика — придумать вот это "описание" так, чтобы оно реализовывало поставленную задачу. Потом нужно будет по этому описанию приложение создать — ну там, скажем, научиться эффективно вычислять last-modified-date для составного ресурса, и всё такое.
S>Это не алгоритм — в том понимании, как его приводят в словарях. Нет там никакой "finite sequence of instructions". Но от этого меньше программирования там не становится.

Я и не спорю, есть там свои задачи.

S>Воот. Есть язык-то! Не может человек думать без языка

. Привет от т. Сталина.

> Он не обязательно весь вербализирован — когда его вербализируешь, остаётся всего лишь один шаг до нотации. Но сам язык есть. Есть некие образы. И вот то, какие там образы, полностью определяет то, какие программы человек может написать. Не имеет смысла оперировать терминами "вызов ядра", "побайтный проход", при разработке БД. Зато имеет смысл оперировать терминами "loop join", "bookmark lookup". Понятно? Ты вот всё время пробуешь применять образы, выработанные для Pascal/C, к управляемой среде. А это не только бесполезно, но и вредно

Я уже устал повторять — не собираюсь я применять их к управляемой среде. Не собираюсь, понятно ? Я не принимаю эту управляемую среду именно за то, что к ней нельзя эти образы (коль уж такой термин тебе нравится, пусть так) применить. Именно поэтому она мне и не нравится.


S>>>выделение массива данных размером в 5GB
PD>>Ты или нет ?
S>Ты всё-таки прочитай Эрика. Это полезно. Научишься, к примеру, отличать понятие "выделить" от понятия "отобразить".


S>

S>(*) Хорошо, я соврал. 32хбитная Windows ограничивает общее количество памяти процесса на диске 16ю терабайтами, а в 64хбитной лимит равен 256 Tб. Но нет никакой причины, по которой отдельный процесс не мог бы выделить несколько Гб, если хватает места на диске.

PD>>А больше одновременно -не выйдет!
S>Аллоцировать одновременно можно значительно больше. Отмапить — нельзя. Учим матчасть.

Эту часть дискуссии я прекращаю. Заниматься демагогией на чисто техническую тему незачем. Если ты по-прежнему уверен, что в Win32 можно создать массив (а ты именно это утверждал) размером в 5 GB, добро пожаловать в форум Win API. Задай там вопрос , как это сделать, или выскажи свои соображения. Я обещаю не участвовать в дискуссии. Там найдется достаточно людей, которые тебе все объяснят, коль скоро ты в трех соснах запутался.

PD>>И про взаимоотношения я тебе грамотному пользователю смогу объяснить. Напрмер, пользователю Фотошопа. Канва простая — картинки большие, места не хватает, а ты хочешь их много, да одновременно, да еще всякие манипуляции, а это промежуточные картинки, ну вот Windows кое-какие куски их на диск и отправляет иногда, а потом обратно. И он вполне поймет.
S>Тем удивительнее то, что ты, к примеру, не понимаешь разницы между Allocate и Map.



Я вообще ничего не понимаю, из твоих высказываний это давно ясно. Ну и бог с ним.

PD>>>>Так как же лучше ?
S>>>Лучше — вот так:
S>>>1. Задать требования к производительности. Например, время, через которое программа должна выдать ответ.
S>>>2. Написать ту реализацию программы, которая кажется очевидной и простой в реализации
S>>>3. Проверить её производительность
S>>>4. Если она уложилась в требования из п.1., идти делать следующую задачу.
S>>>5. Если нет, то тогда начать оптимизацию:
S>>>6. Запустить профайлер и обнаружить, что всё время уходит на внутренний if
S>>>7. Посидеть, подумать, и свести к 3-циклу
S>>>8. Перейти к п.3

PD>>Нет уж, Антон, давай без общих советов. На тебе эту задачу и напиши план для нее.
S>У меня нет никакой задачи. Есть какой-то "шестикратный цикл", который непонятно откуда взялся, и непонятно что делает. Ты мне дай сначала саму задачу, а потом мы посмотрим, как её решать.

Так, ясно. Начинаем юлить. Потому что понимаешь — как только твои 8 принципов будут применены к данной задаче, так сразу все накроется медным тазом. Ну ладно, тогда сделаю я.

1. Задать требования к производительности. Например, время, через которое программа должна выдать ответ.

Чем быстрее — тем лучше. Точный ответ никто дать не может, заказчик его не знает. И предлагаю на эту тему не спорить. Если у тебя такие задачи, где задать требования всегда можно, то это еще не значит, что не бывает иной ситуации. У меня именно так — as maximum as possible.

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

Сделали 6-кратный цикл.

3. Проверить её производительность

Проверили в тех случаях применения алгоритма, которые уже есть. Вроде терпимо.

4. Если она уложилась в требования из п.1., идти делать следующую задачу.

Пошел делать другую задачу.

А теперь продолжение.

Прошло 3 месяца. Заказчик сообщает, что , используя сей алгоритм еще в одном месте, он обнаружил, что работает все неприемлемо медленно. Обсуждение показало, что эту подзадачу он вызывает в некотором двойном цикле по другим параметрам. Я занят другой задачей в соответствии с п.4 твоих рекомендаций. Мне приходится бросить эту другую задачу и начать исправлять этот алгоритм. Если тебя такой подход устраивает — бога ради. Меня — нет.



PD>>Нет. Там хоть и псевдо-БД, но это лишь по характеру работы ее. Я никакие принципы создания БД там не использовал.
S>Ну, тогда мир СУБД от тебя далёк. Очень жаль — там есть крайне интересные вещи про оптимизацию производительности. Шибко помогает отвлечься от трактовки программирования как == алгоритмы + структуры данных.

"Нелья объять необъятное" (К. Прутков). В мире программирования есть много чего интересного...

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

A>Здравствуйте, Pavel Dvorkin, Вы писали:

G>>>А кто будет знать? Дева мария или еще кто-то?
G>>>Именно процессор и делает такие провеки.
PD>>О господи! Ну прочитай же наконец про атрибуты страниц в страничном механизме. Пойми, что процессору все равно, куда писать — он транслирует вирт. адрес в физический через этот механизм, и если при этом атрибут страницы R/O, то возникнет исключение. А проверку эту он делает всегда. Всегда, понимаешь ?
A>ладно-ладно, а кто сказал что вообще включена страничная адресация? и таки опять же CR0.WP...

Если она не включена, то, очевидно, мы имеем дело с некоторой иной ОС, а там все, конечно, может быть иначе. Я это не обсуждал и не буду.

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

S>>но с реализацией одинаковых интерфейсов.
WH>Одинаковые интерфейсы у изменяемых и неизменяемых структур данных просто сюр.
Зачем прямо уж сюр. Хотя Дали очень нравится. Если для неизменяемых структур метод возвращает новый объект, то для изменяемых
возвращается ссылка на сам объект. Распространнённая практика.

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

PD>>>О господи! Ну прочитай же наконец про атрибуты страниц в страничном механизме. Пойми, что процессору все равно, куда писать — он транслирует вирт. адрес в физический через этот механизм, и если при этом атрибут страницы R/O, то возникнет исключение. А проверку эту он делает всегда. Всегда, понимаешь ?
A>>ладно-ладно, а кто сказал что вообще включена страничная адресация? и таки опять же CR0.WP...

PD>Если она не включена, то, очевидно, мы имеем дело с некоторой иной ОС, а там все, конечно, может быть иначе. Я это не обсуждал и не буду.

а как же:

Процессор будет или не будет делать проверки в зависимости от ОС — это мои слабые нервы
вынести не в состоянии

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

PD>>После всех моих попыток тебе что-то объяснить я уже физически чувствую, что я ни в чем вообще не ориентируюсь .
G>Это почти правда.

Это просто правда — но только после объяснений с тобой.

G>>>Какой тест?
PD>>http://rsdn.ru/forum/flame.comp/3419879.1.aspx

Автор: Pavel Dvorkin
Дата: 08.06.09

G>Прекрасно, а теперь напиши аллокатор для таких "констант" минимально дефрагментирующий память.

Тот же самый, что и в .Net или в C++. Аллокатор не зависит от того, будем ли мы потом изменять объекты или нет. А почему для констант нужен какой-то аллокатор, минимально дефрагментирующий память (минимально по сравнению с чем ?) — не знаю. Просто 2 кучи — для констант и для переменных. Впрочем, не исключаю, что из факта неизменности объектов можно что-то выжать в плане оптимизации, так что эта куча может оказаться более эффективной. Обдумывать детали не буду.

G>А потом подумай, что с иммутабельными типами эффект достигается без выкрутасов во время выполнения.

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

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

_>Да нет, я-то сам его люблю. Случайно наткнулся на статью здесь.
_>Он не просто его, не любит, он его ненавидит. И других заразить пытается.
_>Вот, думаю, тролль Отличная приманка для священной войны.
Да всё ерунда пока я сам не напишу язык программирования так и придётся чем попало пользоваться.

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

G>>>>Какой тест?
PD>>>http://rsdn.ru/forum/flame.comp/3419879.1.aspx

Автор: Pavel Dvorkin
Дата: 08.06.09

G>>Прекрасно, а теперь напиши аллокатор для таких "констант" минимально дефрагментирующий память.

PD>Тот же самый, что и в .Net или в C++.
Это принципиально разные аллокаторы, ты определись.

PD>Аллокатор не зависит от того, будем ли мы потом изменять объекты или нет.
Не надо голословных заявлений. Поркажи код.

PD>А почему для констант нужен какой-то аллокатор, минимально дефрагментирующий память (минимально по сравнению с чем ?) — не знаю. Просто 2 кучи — для констант и для переменных. Впрочем, не исключаю, что из факта неизменности объектов можно что-то выжать в плане оптимизации, так что эта куча может оказаться более эффективной. Обдумывать детали не буду.
Так детали тут — самое интересное. Пока нету практического подтверждения полезности твоей теории все что ты говоришь — фуфло.

G>>А потом подумай, что с иммутабельными типами эффект достигается без выкрутасов во время выполнения.
PD>А ты подумай насчет того, что это можно применть к объектам любого типа, а не только к тем, что объявлены иммутабельными по типу.
Я то подуал, и пришел к мысли что нафиг оно не надо. Если компилятор и так будет анализировать неизменность объекта, то зачем лишние действия в рантайме?

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

PD>>Если она не включена, то, очевидно, мы имеем дело с некоторой иной ОС, а там все, конечно, может быть иначе. Я это не обсуждал и не буду.

A>а как же:
A>

A>Процессор будет или не будет делать проверки в зависимости от ОС — это мои слабые нервы
A>вынести не в состоянии

Имелось в виду, разумеется, при включенном страничном механизме.

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

G>Здравствуйте, Pavel Dvorkin, Вы писали:

G>>>>>Какой тест?
PD>>Тот же самый, что и в .Net или в C++.
G>Это принципиально разные аллокаторы, ты определись.

Незачем мне определяться. Если речь идет о добавлении этой функциональности к C++, то и куча типа C++. Если к .Net — то и куча от .Net. Если к некоей мной системе — то ее куча.


PD>>Аллокатор не зависит от того, будем ли мы потом изменять объекты или нет.
G>Не надо голословных заявлений. Поркажи код.

Ничего себе! Я , видимо, должен для тебя прямо-таки менеджер кучи написать! Сейчас и не сходя с места.
А впрочем, исходники CRT кучи для С++ есть в комплекте VS. Исходники .Net кучи где взять — тебе лучше знать

PD>>А почему для констант нужен какой-то аллокатор, минимально дефрагментирующий память (минимально по сравнению с чем ?) — не знаю. Просто 2 кучи — для констант и для переменных. Впрочем, не исключаю, что из факта неизменности объектов можно что-то выжать в плане оптимизации, так что эта куча может оказаться более эффективной. Обдумывать детали не буду.
G>Так детали тут — самое интересное. Пока нету практического подтверждения полезности твоей теории все что ты говоришь — фуфло.

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

G>>>А потом подумай, что с иммутабельными типами эффект достигается без выкрутасов во время выполнения.
PD>>А ты подумай насчет того, что это можно применть к объектам любого типа, а не только к тем, что объявлены иммутабельными по типу.
G>Я то подуал, и пришел к мысли что нафиг оно не надо. Если компилятор и так будет анализировать неизменность объекта, то зачем лишние действия в рантайме?

М-да... Хоть кол на голове теши... Ему объясняешь, что это может применяться к любым объектам — а он все за свое.

Ладно, все, с меня хватит.

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

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

G>>Здравствуйте, Pavel Dvorkin, Вы писали:

G>>>>>>Какой тест?
PD>>>Тот же самый, что и в .Net или в C++.
G>>Это принципиально разные аллокаторы, ты определись.

PD>Незачем мне определяться. Если речь идет о добавлении этой функциональности к C++, то и куча типа C++. Если к .Net — то и куча от .Net. Если к некоей мной системе — то ее куча.
Ну и каким образом это для С++ поможет? Как компилятор будет определять что поместить в "неизменяекмую кучу"?

PD>>>А почему для констант нужен какой-то аллокатор, минимально дефрагментирующий память (минимально по сравнению с чем ?) — не знаю. Просто 2 кучи — для констант и для переменных. Впрочем, не исключаю, что из факта неизменности объектов можно что-то выжать в плане оптимизации, так что эта куча может оказаться более эффективной. Обдумывать детали не буду.
G>>Так детали тут — самое интересное. Пока нету практического подтверждения полезности твоей теории все что ты говоришь — фуфло.

PD>Пока такие аргументы применяются — дискутировать не имеет смысла. По очень простой причине — если принять твою точку зрения, то обсуждать что бы то ни было можно только тогда, когда это уже сделано. Я считаю, что наоборот
Так ты не смог доказать послезность своего подхода.

G>>>>А потом подумай, что с иммутабельными типами эффект достигается без выкрутасов во время выполнения.
PD>>>А ты подумай насчет того, что это можно применть к объектам любого типа, а не только к тем, что объявлены иммутабельными по типу.
G>>Я то подуал, и пришел к мысли что нафиг оно не надо. Если компилятор и так будет анализировать неизменность объекта, то зачем лишние действия в рантайме?

PD>М-да... Хоть кол на голове теши... Ему объясняешь, что это может применяться к любым объектам — а он все за свое.
Покажи полезность этого.

PD>Ладно, все, с меня хватит.
Ну не сливай так быстро, момент истины близок.

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

PD>Я уже устал повторять — не собираюсь я применять их к управляемой среде. Не собираюсь, понятно ? Я не принимаю эту управляемую среду именно за то, что к ней нельзя эти образы (коль уж такой термин тебе нравится, пусть так) применить. Именно поэтому она мне и не нравится.
Этим ты выдал всю свою сущность.
Ты не хочешь учится.
А это значит что как профессионал ты уже мертв.

PD>Пошел делать другую задачу.
PD>А теперь продолжение.
А чаще всего нету этого продолжения...

S>>Ну, тогда мир СУБД от тебя далёк. Очень жаль — там есть крайне интересные вещи про оптимизацию производительности. Шибко помогает отвлечься от трактовки программирования как == алгоритмы + структуры данных.
PD>"Нелья объять необъятное" (К. Прутков). В мире программирования есть много чего интересного...
Можно и нужно.
Я имею в виду не детали как работает оракл версии ХХХ, а общие принципы.