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

ГВ>См. соседнее сообщение. Конечно, я считаю в том числе и OpenOffice/UNO. Вполне себе компонентная приблуда. Всё, что заявляет о себе, как о компонентной среде/инфраструктуре/технологии — является таковым в виду размытости самого термина "компонентность".

UNO, как я понимаю не универсальная вещь. Это только интерфейс к OpenOffice. Если я ошибаюсь, то UNO тоже можно записывать в компонентный фрэймворк. Даже, пожалуй это круче. Это — объеденяющий компонентный фрэймворк. Но что-то мне подсказывает, что за пределами OpenOffice это использовать дует затруднительно.

Что касается ссылки, то там написана чушь. Еще раз предлагаю самостоятельно сделать список и убедиться, что там весма не много пунктов большая часть из которых будет как раз являться реализацией компонентности в других языках или конкретных продуктах (т.е. не универсальные решения).

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

ГВ>>См. соседнее сообщение. Конечно, я считаю в том числе и OpenOffice/UNO. Вполне себе компонентная приблуда. Всё, что заявляет о себе, как о компонентной среде/инфраструктуре/технологии — является таковым в виду размытости самого термина "компонентность".

VD>UNO, как я понимаю не универсальная вещь. Это только интерфейс к OpenOffice. Если я ошибаюсь, то UNO тоже можно записывать в компонентный фрэймворк. Даже, пожалуй это круче. Это — объеденяющий компонентный фрэймворк. Но что-то мне подсказывает, что за пределами OpenOffice это использовать дует затруднительно.

Ну, скажем так, это открытый интерфейс вроде COM и чем-то смахивающий на CORBA. Есть даже примитивный шлюз в COM через IDispatch. Полгода назад, во всяком случае, был только такой.

VD>Что касается ссылки, то там написана чушь.

Так я и не предлагаю читать то, что там написано помимо списка ссылок.

VD>Еще раз предлагаю самостоятельно сделать список и убедиться, что там весма не много пунктов большая часть из которых будет как раз являться реализацией компонентности в других языках или конкретных продуктах (т.е. не универсальные решения).

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

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

ГВ>>Прочесть текст по ссылке до конца тебе, как я понимаю, принципы не позволили:
VD>Там не инфрмструктуры, а специализации которые повтояют исходный список. Например, OLE и DCOM — это все COM.

Хм. Только в разделе Distributed computing software components — 12 ссылок на относительно широко известные инфраструктуры. Мало, что ли? Откуда я знаю, кто ещё чего выдумал?

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


VD>Понимаю. Но понимаю и то, что родилась она (как и альтернатива, коих кот наплакал) в основном потому, что в С++ не было нужных возможностей.

COM родился вместе с OLE, и решал прблему компонентности не С++, а прикладных программ вообще, написанных на различных языках. Да и вообще, обсуждать сейчас это бессмысленно, хотя бы потому, что на тот момент это было отличное решение. У меня на двойке с 2M памяти запускался 2-й виндоуз и я в MS Word писал диплом, с графиками и картинками... Ну разве могли быть тогда компонентые решение навроде .Net, у которой системные сборки (много)метровые?

В общем, было бы что обсуждать.

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

ГВ>С одной стороны часть этого есть в бусте. С другой, преобразования строк — это не настолько большая проблема, как рисуется в воображении, я тебе уже приводил примеры шаблонных реализаций операторов над строками.
Толку-то с этих шаблонных операторов. В любом случае, если одна либа порождает CString, а другая — потребляет QString, то постоянно нужно выполнять операции преобразования.

ГВ>Смена одной либы на другую очень часто требует переработки исходников.
Попробуй попрограммировать на Java. На дотнете не так заметно — там среднее количество библиотек на заданную тему равно единице.

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

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

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

S>В любом случае, если одна либа порождает CString, а другая — потребляет QString, то постоянно нужно выполнять операции преобразования.

Верно. Правда, драматичность этой проблемы серьёзно преувеличена, ИМХО.

ГВ>>Смена одной либы на другую очень часто требует переработки исходников.
S>Попробуй попрограммировать на Java. На дотнете не так заметно — там среднее количество библиотек на заданную тему равно единице.

Это понятно, только ты не путай калий с кальцием. "Разные библиотеки" Java можно, в общем-то, считать разными версиями одной и той же библиотеки, API которой считается референсным, так что, пример не совсем в кассу — для C++, например, тоже есть разные реализации тех же malloc/free или STL. Ну и потом, ИМХО, библиотеки C++ представляют большую функциональность на единицу кода, нежели библиотеки Java, отсюда и большая вариабельность API — каждому же хочется реализовать всего и побольше, понятно, что почти никто друг на друга при этом не оглядывается.

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

V>В общем, было бы что обсуждать.

А кроме того, OLE появился где-то в начале 90-х, когда C++ ещё толком не устоялся и определённо, в роль главного пугала индустрии не вошёл. Скорее наоборот — OLE хаяли все, кому не лень: кто за глючность, кто за сложность.

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

ГВ>Кому как. Можно и шаблонные алгоритмы для разных вариаций строк писать на таких операторах.
Можно. Но никто этого не делает.

ГВ>Верно. Правда, драматичность этой проблемы серьёзно преувеличена, ИМХО.
Да. В С++ драматичных проблем нет. Вот только стандарты в нём по факту отсутствуют. Вот и приходится выбирать нее язык, а платформу — типа MFC, ATL, WTL, QT, boost, или ещё чего-нибудь.

ГВ>Это понятно, только ты не путай калий с кальцием. "Разные библиотеки" Java можно, в общем-то, считать разными версиями одной и той же библиотеки, API которой считается референсным, так что, пример не совсем в кассу — для C++, например, тоже есть разные реализации тех же malloc/free или STL.
Ой-ой-ой. Можно считать их чем угодно. Но по факту, любые сервлеты, к примеру, совместимы между собой. Доступ к реляционнным данным всегда делается через JDBC. Криптография вся делается через стандартизованную механику провайдеров. Что, будем считать SHA и PGP "разными версиями одной и той же библиотеки"?

ГВ>Ну и потом, ИМХО, библиотеки C++ представляют большую функциональность на единицу кода, нежели библиотеки Java, отсюда и большая вариабельность API — каждому же хочется реализовать всего и побольше, понятно, что почти никто друг на друга при этом не оглядывается.
О да. Конечно. Конечно же, не хочется признавать безнадёжную убогость плюсов в плане стандартизации и интеропа по сравнению с практически любой альтернативой.

Вариабельность API — исключительно синдром NIH плюс отсутствие внятного стандарта. Как мы уже выяснили, даже стандарта строк (самый частовстречаемый класс) в природе не существует. Ну вот объясни мне, почему до сих пор, невзирая на 100% внедрение STL, все серъёзные пакеты библиотек делают свои строки? Ну ладно, CString, возможно, старше std::string, к тому же это не один класс, а целая пачка. А QString откуда взялся? Что, кутешники сделали какую-то сильно более хорошую строку? Или, может быть, они не смогли заставить себя оглянуться на std::string?
Покажи мне банальную вещь — библиотеку конверсии кодировок строк, которая совместима с тремя основными семействами строк. Где она? Невозможно написать. Поэтому мы и имеем зоопарк программ на С++, которые работают только с одной кодировкой.

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

На практике в С++ стандартным является только отсутствие сколь бы то ни было поддержанных стандартов.
Есть только STL. Но он покрывает пренебрежимо малую часть потребной функциональности. Ничего сложнее консольной Hello World с таким "стандартом" написать невозможно.

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

ГВ>>Это понятно, только ты не путай калий с кальцием. "Разные библиотеки" Java можно, в общем-то, считать разными версиями одной и той же библиотеки, API которой считается референсным, так что, пример не совсем в кассу — для C++, например, тоже есть разные реализации тех же malloc/free или STL.
S>Ой-ой-ой. Можно считать их чем угодно. Но по факту, любые сервлеты, к примеру, совместимы между собой. Доступ к реляционнным данным всегда делается через JDBC. Криптография вся делается через стандартизованную механику провайдеров. Что, будем считать SHA и PGP "разными версиями одной и той же библиотеки"?
Не надо сказки рассказывать. В Java не меньший зоопарк API. Ты просто выбрал то, что является исключением.

Т.е. интерфейс сервлетов хорошо специфицирован. А вот web framework'и, которые на нём построены, образуют огромный зоопарк, несовместимый ни с чем. И официальный JSF не является даже самым распространённым.

Библиотек криптографии в Java тоже полно, в том числе и не [полностью] предоставляющих интерфейс Java CryptoAPI — http://www.bouncycastle.org/ , к примеру.

S>Вариабельность API — исключительно синдром NIH плюс отсутствие внятного стандарта. Как мы уже выяснили, даже стандарта строк (самый частовстречаемый класс) в природе не существует. Ну вот объясни мне, почему до сих пор, невзирая на 100% внедрение STL, все серъёзные пакеты библиотек делают свои строки? Ну ладно, CString, возможно, старше std::string, к тому же это не один класс, а целая пачка. А QString откуда взялся? Что, кутешники сделали какую-то сильно более хорошую строку? Или, может быть, они не смогли заставить себя оглянуться на std::string?
У QT-шников строка более мощная, чем std::string. И она таки легко преобразуется в std::string.

S>Покажи мне банальную вещь — библиотеку конверсии кодировок строк, которая совместима с тремя основными семействами строк. Где она? Невозможно написать. Поэтому мы и имеем зоопарк программ на С++, которые работают только с одной кодировкой.
Ээээ... А какие проблемы-то? Берёшь любую и используешь — тот же QString это умеет.

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

S>>Покажи мне банальную вещь — библиотеку конверсии кодировок строк, которая совместима с тремя основными семействами строк. Где она? Невозможно написать. Поэтому мы и имеем зоопарк программ на С++, которые работают только с одной кодировкой.
C>Ээээ... А какие проблемы-то? Берёшь любую и используешь — тот же QString это умеет.
Простые очень проблемы — нет никакого стандарта. QString, допустим, умеет. Ну, то есть QString, понятное дело, умеет только латин1 и utf-8, что абсолютно верно. А всё остальное умеет, понятное дело, QTextCodec. И он, конечно же, никакого стандарта не реализует. Поэтому, к примеру, прикрутить это к CString будет крайне затруднительно. Ну, то есть самый простой способ — работать на уровне char*, что и есть единственный реальный "стандарт строки в С++". При этом, конечно же, внезапно окажется, что производительность такого конвертера сильно хуже, чем у соседей — потому, что у char* нет заранее известной длины, и кодеку придётся многократно перевыделять внутренний буфер.

Вот поэтому мы и имеем то, что имеем, а не то, о чем грезят фанаты плюсов. То есть вместо суперомптимальных надёжных программ мы имеем тормозное ненадёжное унылое понятно что.
И куда ни ткни — везде такой бардак.

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

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

Я делаю. Этого вполне достаточно.

ГВ>>Верно. Правда, драматичность этой проблемы серьёзно преувеличена, ИМХО.
S>Да. В С++ драматичных проблем нет. Вот только стандарты в нём по факту отсутствуют.

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

S>Вот и приходится выбирать нее язык, а платформу — типа MFC, ATL, WTL, QT, boost, или ещё чего-нибудь.

Угу. И все платформы на одном и том же языке — красота!

ГВ>>Это понятно, только ты не путай калий с кальцием. "Разные библиотеки" Java можно, в общем-то, считать разными версиями одной и той же библиотеки, API которой считается референсным, так что, пример не совсем в кассу — для C++, например, тоже есть разные реализации тех же malloc/free или STL.
S>Ой-ой-ой. Можно считать их чем угодно. Но по факту, любые сервлеты, к примеру, совместимы между собой.

Между собой? В смысле? Может, ты имел в виду совместимость с контейнерами?

S>Доступ к реляционнным данным всегда делается через JDBC.

Много ты знаешь распространённых "тяжёлых" СУБД, для которых интерфейс Java роднее C? Вот и я не знаю. Далее делаем простые выводы.

S>Криптография вся делается через стандартизованную механику провайдеров. Что, будем считать SHA и PGP "разными версиями одной и той же библиотеки"?

Угу, будем. В случае общего API вполне допустимая абстракция.

ГВ>>Ну и потом, ИМХО, библиотеки C++ представляют большую функциональность на единицу кода, нежели библиотеки Java, отсюда и большая вариабельность API — каждому же хочется реализовать всего и побольше, понятно, что почти никто друг на друга при этом не оглядывается.
S>О да. Конечно. Конечно же, не хочется признавать безнадёжную убогость плюсов в плане стандартизации и интеропа по сравнению с практически любой альтернативой.

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

Давай так: стандартизация API — отдельно, котлеты — отдельно, интероп — на третье. Кому что надо, те то стандартизируют. И вообще, ИМХО, обилие стандартов в Java как раз свидетельствует о неких врождённых недостатках самой Java: без "синергии миллионов стандартизаторов" ни бэ, ни мэ, ни кукареку.

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

S>Вариабельность API — исключительно синдром NIH плюс отсутствие внятного стандарта. Как мы уже выяснили, даже стандарта строк (самый частовстречаемый класс) в природе не существует. Ну вот объясни мне, почему до сих пор, невзирая на 100% внедрение STL, все серъёзные пакеты библиотек делают свои строки? Ну ладно, CString, возможно, старше std::string, к тому же это не один класс, а целая пачка. А QString откуда взялся? Что, кутешники сделали какую-то сильно более хорошую строку? Или, может быть, они не смогли заставить себя оглянуться на std::string?

Так он же тоже старше std::string, если мне не изменяет HDD и не привирает википедия:

Haavard Nord and Eirik Chambe-Eng (the original developers of Qt and the CEO and President, respectively, of Trolltech) began development of "Qt" in 1991, three years before the company was incorporated as Quasar Technologies, then changed the name to Troll Tech, and then to Trolltech.

Посему оглядываться им было, ИМХО, некуда.

S>Покажи мне банальную вещь — библиотеку конверсии кодировок строк, которая совместима с тремя основными семействами строк. Где она? Невозможно написать. Поэтому мы и имеем зоопарк программ на С++, которые работают только с одной кодировкой.

Требования по API сформулируешь? Нет требований — нет библиотек. И вообще — что такое "невозможно написать" в смысле упаковки кучи API под другим API? Этих слов моя не знать.

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

"Нет" по последнему утверждению, по остальным — "да". Только ты что-то путаешь, это не мантры, а объективная реальность. Я понимаю, что ступаю тут на зыбкую почву попыток убедить собеседника в том, что он считает нечто действующее мантрами, но...

S>На практике в С++ стандартным является только отсутствие сколь бы то ни было поддержанных стандартов.
S>Есть только STL. Но он покрывает пренебрежимо малую часть потребной функциональности. Ничего сложнее консольной Hello World с таким "стандартом" написать невозможно.

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

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

S>>>Покажи мне банальную вещь — библиотеку конверсии кодировок строк, которая совместима с тремя основными семействами строк. Где она? Невозможно написать. Поэтому мы и имеем зоопарк программ на С++, которые работают только с одной кодировкой.
C>>Ээээ... А какие проблемы-то? Берёшь любую и используешь — тот же QString это умеет.
S>Простые очень проблемы — нет никакого стандарта.

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

S>QString, допустим, умеет. Ну, то есть QString, понятное дело, умеет только латин1 и utf-8, что абсолютно верно. А всё остальное умеет, понятное дело, QTextCodec. И он, конечно же, никакого стандарта не реализует. Поэтому, к примеру, прикрутить это к CString будет крайне затруднительно. Ну, то есть самый простой способ — работать на уровне char*, что и есть единственный реальный "стандарт строки в С++". При этом, конечно же, внезапно окажется, что производительность такого конвертера сильно хуже, чем у соседей — потому, что у char* нет заранее известной длины, и кодеку придётся многократно перевыделять внутренний буфер.

Почему обязательно нужно пользоваться самым простым способом — через char*, когда нужна скорость и под боком имеется длина? Зачем многократно перевыделять буфер? Максимальный размер кода символа в указанной кодировке — неизвестная величина?

Антон, прекращай уже с менеджерами тусоваться, они тебя плохому учат!

S>Вот поэтому мы и имеем то, что имеем, а не то, о чем грезят фанаты плюсов. То есть вместо суперомптимальных надёжных программ мы имеем тормозное ненадёжное унылое понятно что.

Ха-ха. Ну ты молодец, ё-моё. Сам придумал, сам и поругал.

S>И куда ни ткни — везде такой бардак.

Анархия — мать порядка. Как раз в таком "бардаке" и воспитывается умение организовывать свои собственные мысли. А эта пушка посильнее любых стандартов будет.

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

ГВ>Не, это надо писать большими буквами, полужирным курсивом и в тегах заголовка. Иначе на мантру не тянет.
При чём тут мантра? Это — констатация факта. Ты его опровергнуть хочешь? Ну так покажи мне стандарт на приведение кодировок.

S>>QString, допустим, умеет. Ну, то есть QString, понятное дело, умеет только латин1 и utf-8, что абсолютно верно. А всё остальное умеет, понятное дело, QTextCodec. И он, конечно же, никакого стандарта не реализует. Поэтому, к примеру, прикрутить это к CString будет крайне затруднительно. Ну, то есть самый простой способ — работать на уровне char*, что и есть единственный реальный "стандарт строки в С++". При этом, конечно же, внезапно окажется, что производительность такого конвертера сильно хуже, чем у соседей — потому, что у char* нет заранее известной длины, и кодеку придётся многократно перевыделять внутренний буфер.

ГВ>Почему обязательно нужно пользоваться самым простым способом — через char*, когда нужна скорость и под боком имеется длина? Зачем многократно перевыделять буфер? Максимальный размер кода символа в указанной кодировке — неизвестная величина?
Ну, покажи мне непростой способ. Вот есть у меня, скажем CEdit. И хочу введённую туда пользователем строку теперь сконвертировать в, скажем, UTF7 и сохранить в файл. Покажи мне, как это делается умными людьми.

ГВ>Анархия — мать порядка. Как раз в таком "бардаке" и воспитывается умение организовывать свои собственные мысли. А эта пушка посильнее любых стандартов будет.
Да-да-да. Это всё мы уже слышали. "С++ — насолько сложный язык, что в нём выживают только самые умные программисты". Увы, это враньё. Практика ничего подобного не показывает.
Всё, чему помогает сложность языка — это удорожание разработки на нём.

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

ГВ>По факту — присутствуют. Только это стандарт на язык, а не на каждый чих.
В наше время это всё равно, что стандарт на кодировку символов в исходниках.

ГВ>Угу. И все платформы на одном и том же языке — красота!
Толку-то! Не получается взять так и просто подружить две платформы — приходится писать много boilerplate кода.
Там, где программист на C# или Java пишет в отчёте "выбор библиотеки — 8 часов, проверка в проекте — 2 часа", С++ программист пишет "выбор библиотеки — 1 час, прикручивание в проект и написание врапперов — 40 часов".

ГВ>Между собой? В смысле? Может, ты имел в виду совместимость с контейнерами?
И между собой, и с контейнерами.
S>>Доступ к реляционнным данным всегда делается через JDBC.
ГВ>Много ты знаешь распространённых "тяжёлых" СУБД, для которых интерфейс Java роднее C? Вот и я не знаю. Далее делаем простые выводы.
Термин "роднее" мне неизвестен. Как неизвестны и СУБД, для которых нет JDBC-драйвера. Вот и делаем простые выводы: низкоуровневые С-библиотеки хороши для написания vendor-specific tools, а для написания бизнес-приложений никто dblib уже десять лет как неиспользует. Спуститесь с небес на землю (или вам там наоборот, подняться надо?)

ГВ>Угу, будем. В случае общего API вполне допустимая абстракция.

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

ГВ>Давай так: стандартизация API — отдельно, котлеты — отдельно, интероп — на третье. Кому что надо, те то стандартизируют. И вообще, ИМХО, обилие стандартов в Java как раз свидетельствует о неких врождённых недостатках самой Java: без "синергии миллионов стандартизаторов" ни бэ, ни мэ, ни кукареку.
Вот то-то и оно. Пока С++ безнадёжно пытается стандартизовать хотя бы compiled templates, то есть самый низкий уровень платформы, парни в Виллариба уже давно стандартизуют что-то поинтереснее.

ГВ>Потом, что касается интеропа, то вот тут как раз C и C++ равных нет в смысле возможностей интеропа с кем угодно. Причины я кратко объяснил чуть выше. И ничего ты с этим не сделаешь, сколько ни исходи. Другой вопрос — насколько это удобно реализовано в том или ином случае.
Да, согласен. В случае С++ всё реализовано максимально неудобно.

ГВ>Посему оглядываться им было, ИМХО, некуда.
А, ну ладно. Тогда интересно то, что STL, который вроде как младше Qt, оказался настолько хуже.

ГВ>Требования по API сформулируешь? Нет требований — нет библиотек. И вообще — что такое "невозможно написать" в смысле упаковки кучи API под другим API? Этих слов моя не знать.
Зачем тут требования по API? Вот у меня есть задача: получив строку unicode символов, перекодировать её в кодировку X. Где X, скажем, заранее неизвестно.
Вторичная задача: эта библиотека должна быть совместима с максимальным количеством других библиотек, которые работают со строками. Потому что сама по себе задача преобразования кодировок не нужна. Нужно, например, уметь читать письма по IMAP протоколу, и я не хочу, чтобы этот конвертер был привязан к конкретной библиотеке работы с IMAP.

Это всё очевидные вещи для всех разработчиков, которые работают на взрослых платформах. См. например System.Text.Encoding.

ГВ>"Нет" по последнему утверждению, по остальным — "да". Только ты что-то путаешь, это не мантры, а объективная реальность. Я понимаю, что ступаю тут на зыбкую почву попыток убедить собеседника в том, что он считает нечто действующее мантрами, но...
Жду в студию убедительных доказательств.

ГВ>Ну, извини, если ты считаешь, что без оглядки на "стандарты" ничего нельзя писать, это уж и не знаю, прямо. Какое-то сильно крутое колдунство для меня, во всяком случае.
Ну почему же нельзя — можно. Вот только без стандартов это очень неэффективно. Повторное использование затруднено. Получается, что нельзя просто взять и использовать некую произвольную библиотеку "на языке С++". Потому что она не на языке, а на платформе. Ну вот нужна мне, скажем, работа с Zip — архивами. Для MFC-приложения она должна быть написана в одном стиле, для QT — в другом, для boost — в третьем. Либо потребуется некий wrapper для каждой платформы, который буду писать либо я либо автор библиотеки.

Весь этот код — лишний. Вы можете сколько угодно делать вид, что всё в порядке и никаких проблем нету. Суровая реальность от этого никак не изменится: С++ — это не платформа, это инструмент для построения платформ.
А прикладным программистам инструмент не нужен; им нужна платформа, на которой они могут писать полезные приложения. И чем больше вопросов платформа покрывает, и чем больше вариантов ответов на эти вопросы она даёт, тем более зрелой эта платформа является.

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

ГВ>>Не, это надо писать большими буквами, полужирным курсивом и в тегах заголовка. Иначе на мантру не тянет.
S>При чём тут мантра? Это — констатация факта. Ты его опровергнуть хочешь? Ну так покажи мне стандарт на приведение кодировок.

Мантру я углядел в смысле ужасности отсутствия стандартов.

S>>>QString, допустим, умеет. Ну, то есть QString, понятное дело, умеет только латин1 и utf-8, что абсолютно верно. А всё остальное умеет, понятное дело, QTextCodec. И он, конечно же, никакого стандарта не реализует. Поэтому, к примеру, прикрутить это к CString будет крайне затруднительно. Ну, то есть самый простой способ — работать на уровне char*, что и есть единственный реальный "стандарт строки в С++". При этом, конечно же, внезапно окажется, что производительность такого конвертера сильно хуже, чем у соседей — потому, что у char* нет заранее известной длины, и кодеку придётся многократно перевыделять внутренний буфер.

ГВ>>Почему обязательно нужно пользоваться самым простым способом — через char*, когда нужна скорость и под боком имеется длина? Зачем многократно перевыделять буфер? Максимальный размер кода символа в указанной кодировке — неизвестная величина?
S>Ну, покажи мне непростой способ. Вот есть у меня, скажем CEdit. И хочу введённую туда пользователем строку теперь сконвертировать в, скажем, UTF7 и сохранить в файл. Покажи мне, как это делается умными людьми.

MultiByteToWideChar, ы? Уж коль скоро мы про CEdit. Да, если очень захочется универсальности, то придётся накрыть её шаблоном. Возможность предвыделения буфера прямо зависит от того, реализована оная в той или иной строке или нет. CString, например, это допускает. Но если остро нужна скорость, то здесь будут другие подходы, например, буфер сразу полетит на диск, минуя промежуточное заворачивание в строковые объекты. WriteFile, знаешь такую? Буфер для UTF7 вообще можно выделять на стеке, коль острая нужда есть. Я тебя что-то не совсем понимаю, ты точно понял, о чём я говорил?

ГВ>>Анархия — мать порядка. Как раз в таком "бардаке" и воспитывается умение организовывать свои собственные мысли. А эта пушка посильнее любых стандартов будет.
S>Да-да-да. Это всё мы уже слышали. "С++ — насолько сложный язык, что в нём выживают только самые умные программисты". Увы, это враньё. Практика ничего подобного не показывает.

Угу, я уже это давно заметил. Особенно интересно звучит в рамках другой максимы: "Умные нам не нужны, нам нужны послушные". Гы-гы.

S>Всё, чему помогает сложность языка — это удорожание разработки на нём.

Ясное дело, дежурный жупел.

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

ГВ>>Угу. И все платформы на одном и том же языке — красота!
S>Толку-то! Не получается взять так и просто подружить две платформы — приходится писать много boilerplate кода.
S>Там, где программист на C# или Java пишет в отчёте "выбор библиотеки — 8 часов, проверка в проекте — 2 часа", С++ программист пишет "выбор библиотеки — 1 час, прикручивание в проект и написание врапперов — 40 часов".

Ну это твои мрачные фантазии. Заморочки. которые потребуют потратить 40 часов на прикручивание могут встретиться в любой библиотеке на любом языке. Так уж оно всё устроено.

ГВ>>Между собой? В смысле? Может, ты имел в виду совместимость с контейнерами?
S>И между собой, и с контейнерами.

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

S>>>Доступ к реляционнным данным всегда делается через JDBC.
ГВ>>Много ты знаешь распространённых "тяжёлых" СУБД, для которых интерфейс Java роднее C? Вот и я не знаю. Далее делаем простые выводы.
S>Термин "роднее" мне неизвестен. Как неизвестны и СУБД, для которых нет JDBC-драйвера. Вот и делаем простые выводы: низкоуровневые С-библиотеки хороши для написания vendor-specific tools, а для написания бизнес-приложений никто dblib уже десять лет как неиспользует. Спуститесь с небес на землю (или вам там наоборот, подняться надо?)

Земля, небеса... Для всех СУБД есть и ODBC-драйвера. Я имел в виду, что JDBC разрабатывался очень сильно после интерфейсов основных СУБД.

ГВ>>Угу, будем. В случае общего API вполне допустимая абстракция.
S>
S>Боюсь, это всё же разные библиотеки. Особенно с учётом того, что их можно использовать одновременно.

Я сказал про абстракцию использования. Понятно, что "внутри" они разные.

ГВ>>Давай так: стандартизация API — отдельно, котлеты — отдельно, интероп — на третье. Кому что надо, те то стандартизируют. И вообще, ИМХО, обилие стандартов в Java как раз свидетельствует о неких врождённых недостатках самой Java: без "синергии миллионов стандартизаторов" ни бэ, ни мэ, ни кукареку.
S>Вот то-то и оно. Пока С++ безнадёжно пытается стандартизовать хотя бы compiled templates, то есть самый низкий уровень платформы, парни в Виллариба уже давно стандартизуют что-то поинтереснее.

Ну понятно... Пока на C++ решают задачу пользователя, подбирая самые подходящие инструменты, парни из Виллариба озабочены стабилизацией очередного из десятков промежуточных API.

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

По первой части предложения, как я понимаю, возражений нет. Хорошо. А удобство — дело наживное.

ГВ>>Посему оглядываться им было, ИМХО, некуда.
S>А, ну ладно. Тогда интересно то, что STL, который вроде как младше Qt, оказался настолько хуже.

Он не хуже, он другой. Почему разработчики STL должны были оглядываться именно на Qt?

ГВ>>Требования по API сформулируешь? Нет требований — нет библиотек. И вообще — что такое "невозможно написать" в смысле упаковки кучи API под другим API? Этих слов моя не знать.
S>Зачем тут требования по API?

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

S>Вот у меня есть задача: получив строку unicode символов, перекодировать её в кодировку X. Где X, скажем, заранее неизвестно.
S>Вторичная задача: эта библиотека должна быть совместима с максимальным количеством других библиотек, которые работают со строками. Потому что сама по себе задача преобразования кодировок не нужна. Нужно, например, уметь читать письма по IMAP протоколу, и я не хочу, чтобы этот конвертер был привязан к конкретной библиотеке работы с IMAP.

Вот и давай — построй индукцию на обобщённый API для решения этой задачи. Выведи универсальные требования, а там и посмотрим, что реализуемо, а что — нет.

S>Это всё очевидные вещи для всех разработчиков, которые работают на взрослых платформах. См. например System.Text.Encoding.

И почему я не удивлён, что ты отослал меня именно к System.Text.Encoding?

ГВ>>"Нет" по последнему утверждению, по остальным — "да". Только ты что-то путаешь, это не мантры, а объективная реальность. Я понимаю, что ступаю тут на зыбкую почву попыток убедить собеседника в том, что он считает нечто действующее мантрами, но...
S>Жду в студию убедительных доказательств.

Мои доказательства ничего тебе не докажут, и это большая проблема. Ты будешь ждать решения в одну строку, взятое из "стандартов", а меня привлекают понятные механизмы реализации. Не договоримся. Так что, придётся тебе просто принять на веру, что не все умозрительные рассуждения об "ужасах C++" соответствуют практической действительности — в конце концов, это не более, чем эмоционально окрашенные мнения.

ГВ>>Ну, извини, если ты считаешь, что без оглядки на "стандарты" ничего нельзя писать, это уж и не знаю, прямо. Какое-то сильно крутое колдунство для меня, во всяком случае.
S>Ну почему же нельзя — можно. Вот только без стандартов это очень неэффективно. Повторное использование затруднено.

Ошибка. Повторное использование затрудняется при отсутствии повторно используемых компонент. Если таковые или их аналоги есть, то нет проблемы и в повторном использовании. А стандарты — дело десятое.

S>Получается, что нельзя просто взять и использовать некую произвольную библиотеку "на языке С++". Потому что она не на языке, а на платформе. Ну вот нужна мне, скажем, работа с Zip — архивами.

Zlib — и понеслась.

S>Для MFC-приложения она должна быть написана в одном стиле, для QT — в другом, для boost — в третьем. Либо потребуется некий wrapper для каждой платформы, который буду писать либо я либо автор библиотеки.

И снова ошибка. Она никому ничего не должна. И я, как пользователь boost+Qt+zlib тоже никому ничего не должен, враппер над zlib пишется по необходимости и под требования задачи или предполагаемой задачи. Нет никакой нужды пользоваться Qt-specific или boost-specific style исключительно потому, что они вот такие вот большие и красивые. Я уж давно пишу в нескольких стилях одновременно и ни капли не огорчаюсь.

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

Молодец, правильно. C++ никто никогда в здравом уме и трезвой памяти "платформой" и не называл за исключением апологетов разнообразных "платформ". Только это инструмент с богатым выбором дополнительного проблемно-ориентированного инструментария, реализованного на нём же. Понятно, что он не обладает теми же чертами, что и специализированные инструменты для прикладного программирования (GC как раз из этой области). Проблема в другом — это не повод называть его "убогим" на основании, скажем, сравнения ISO/IEC 14882:1998 со спецификацией EJB, само сравнение некорректно. Сравнивайте на здоровье .Net, Java, что там у нас ещё на слуху? C++ вообще ортогонален этим платформам.

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

Угу, им универсальный всемогутер нужен.

ГВ>MultiByteToWideChar, ы?

WideCharToMultiByte, разумеется.

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

ГВ>MultiByteToWideChar, ы?
Пример — в студию. С нетерпением жду применения этой функции для конверсии в UTF7.
ГВ>Уж коль скоро мы про CEdit. Да, если очень захочется универсальности, то придётся накрыть её шаблоном. Возможность предвыделения буфера прямо зависит от того, реализована оная в той или иной строке или нет.
ГВ> CString, например, это допускает. Но если остро нужна скорость, то здесь будут другие подходы, например, буфер сразу полетит на диск, минуя промежуточное заворачивание в строковые объекты. WriteFile, знаешь такую? Буфер для UTF7 вообще можно выделять на стеке, коль острая нужда есть. Я тебя что-то не совсем понимаю, ты точно понял, о чём я говорил?
Я точно уверен только в одном: ты вообще не понял, о чём я говорил. Ты вот не умничай, а напиши пример с записью строки из CEdit на диск в кодировке UTF-7. Желательно, конечно, так, чтобы это не было пессимизацией на ровном месте.
Может быть, после этого на одного из нас снизойдёт просветление?

ГВ>Угу, я уже это давно заметил. Особенно интересно звучит в рамках другой максимы: "Умные нам не нужны, нам нужны послушные". Гы-гы.
Это ты сам себе придумал. Наша практика показывает, что на удобном языке умные достигают лучших результатов, чем на корявом. А неумным никакой язык не помогает.

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

ГВ>>MultiByteToWideChar, ы?
S> Пример — в студию. С нетерпением жду применения этой функции для конверсии в UTF7.

В MSDN посмотри. Только не MultiByteToWideChar, а WideCharToMultiByte, я рядом написал. Для UTF7 применение проще пареной репы.

ГВ>>Уж коль скоро мы про CEdit. Да, если очень захочется универсальности, то придётся накрыть её шаблоном. Возможность предвыделения буфера прямо зависит от того, реализована оная в той или иной строке или нет.
ГВ>> CString, например, это допускает. Но если остро нужна скорость, то здесь будут другие подходы, например, буфер сразу полетит на диск, минуя промежуточное заворачивание в строковые объекты. WriteFile, знаешь такую? Буфер для UTF7 вообще можно выделять на стеке, коль острая нужда есть. Я тебя что-то не совсем понимаю, ты точно понял, о чём я говорил?
S>Я точно уверен только в одном: ты вообще не понял, о чём я говорил.

Тогда объясни так, чтобы стало понятно.

S>Ты вот не умничай, а напиши пример с записью строки из CEdit на диск в кодировке UTF-7. Желательно, конечно, так, чтобы это не было пессимизацией на ровном месте.
S>Может быть, после этого на одного из нас снизойдёт просветление?

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

Зачем тут требования по API? Вот у меня есть задача: получив строку unicode символов, перекодировать её в кодировку X. Где X, скажем, заранее неизвестно.
Вторичная задача: эта библиотека должна быть совместима с максимальным количеством других библиотек, которые работают со строками. Потому что сама по себе задача преобразования кодировок не нужна. Нужно, например, уметь читать письма по IMAP протоколу, и я не хочу, чтобы этот конвертер был привязан к конкретной библиотеке работы с IMAP.

?