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

N>Здравствуйте Аноним, вы писали:
А>>Без истерик, юноша!
А>>...
А>>CComBSTR bstrText;
А>>USES_CONVERSION;
А>>m_edMyEdit.GetWindowText(&bstrText);
А>>m_edMyEdit.SetWindowText(W2T(bstrText));
А>>....
А>>CComBSTR и все просто!!!

N>А спрашивается на кой лад эта лишняя конверсия, тьу, преобразование, если в большинстве функций LPCSTR? Вот CascString попробую, вроде попродуманнее штука, хотя документации на библиотеку — лишь исходный текст.

Самое не приятное — что если начать использьвать эти сasc-классы в своем коде, то потом что-бы этот код распространять, надо еще с casc-библиотеку прикладывать. А ведь в современном мире все больше и больше UNICODE программ, для которых W2T — ничто. Так что надо писать как в примере, использовать UNICODE ...и не напрягаться ;)

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


ZORK>Самое не приятное — что если начать использьвать эти сasc-классы в своем коде, то потом что-бы этот код распространять, надо еще с casc-библиотеку прикладывать.

Слушай! А может проще ссылку приложить? Да и чёто не видать шоб ATL-ный код (созданный с его использованием) бесплатно наспространяли. :(

ZORK>А ведь в современном мире все больше и больше UNICODE программ, для которых W2T — ничто. Так что надо писать как в примере, использовать UNICODE ...и не напрягаться ;)

Не, ну напрягаться все же лучше! Если напрячся и посмотреть исходники CComBSTR, то станет ясно, что его использование для конкатинации строк (и т.п.) — это самое неэфективное решение. Если же напрячся еще больше и глянуть на реализацию CascStr, то станет ясно, что в UNICODE-проекте этот клас компилируется в чистый UNICODE-ный код. Я это заявляю как один и создателей этого самого CascStr.

Ну, и на последок о "все больше и больше UNICODE программ"...

У нас (ну, или у вас... там), что Win9x отменили? Ну, а тогда о каких чистых UNICODE-программах может идти речь?

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


VD>Не, ну напрягаться все же лучше! Если напрячся и посмотреть исходники CComBSTR, то станет ясно, что его использование для конкатинации строк (и т.п.) — это самое неэфективное решение. Если же напрячся еще больше и глянуть на реализацию CascStr, то станет ясно, что в UNICODE-проекте этот клас компилируется в чистый UNICODE-ный код. Я это заявляю как один и создателей этого самого CascStr.

Это не безнес-решение. :)
Если ты выполняешь сложнейшие операции со строками в тайм-критикал приложении, то, конечно, нужн думать о неэффективном соединении строк (и о многом другом :)). В заданном же вопросе конкретная ситуация: UI на ATL, который принимает строку из COM-метода (явно в UNICODE :)), отображает и снова отправляет в COM-метод... Выйгрыш в копировании строки/выделении сотни байт бесмысленен. Это же UI, здесь основные усилия уходят на компенсацию "тупости" юзера, а процессор большую часть времени ждет пока юзер дотянет мышой от кнопки до эдита. Тут нужно как можно быстрее написать код и не думать о вещах (типа собственной эффективной строки и, прости господи, явного malloc'a), которые, кроме затрат времени, проблем с отладкой и удорожания продукта, не дадут абсолютно никакого результата.

Здравствуйте Аноним, вы писали:

А>Это не безнес-решение. :)
А>Если ты выполняешь сложнейшие операции со строками в тайм-критикал приложении, то, конечно, нужн думать о неэффективном соединении строк (и о многом другом :)). В заданном же вопросе конкретная ситуация: UI на ATL, который принимает строку из COM-метода (явно в UNICODE :)), отображает и снова отправляет в COM-метод... Выйгрыш в копировании строки/выделении сотни байт бесмысленен. Это же UI, здесь основные усилия уходят на компенсацию "тупости" юзера, а процессор большую часть времени ждет пока юзер дотянет мышой от кнопки до эдита. Тут нужно как можно быстрее написать код и не думать о вещах (типа собственной эффективной строки и, прости господи, явного malloc'a), которые, кроме затрат времени, проблем с отладкой и удорожания продукта, не дадут абсолютно никакого результата.

Согласен, что GUI сильно оптимизировать бессмысленно ...все равно простаивает :) Хотя с VladD2 тоже согласен — иногда вместо String надо использовать string builder'ы, но скорее всего это не в GUI. А вот надежность, простота и четабельность кода действительно важно, особенно для проектов который делается месяцами — я щас раз как раз на таком сижу.

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

ZORK> А вот надежность, простота и четабельность кода действительно важно, особенно для проектов который делается месяцами — я щас раз как раз на таком сижу.

Так и что? При использовании CascStr или CString "надежность, простота и четабельность кода" уменьшается? Или при использовании CComBSTR увеличивается?

Здравствуйте Аноним, вы писали:

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


VD>>Не, ну напрягаться все же лучше! Если напрячься и посмотреть исходники CComBSTR, то станет ясно, что его использование для конкатенации строк (и т.п.) — это самое неэффективное решение. Если же напрячься еще больше и глянуть на реализацию CascStr, то станет ясно, что в UNICODE-проекте этот клас компилируется в чистый UNICODE-ный код. Я это заявляю как один и создателей этого самого CascStr.

А>Это не безнес-решение. :)

Что-то, это Ваше, бизнес решение на откровенное хамство (по отношению к пользователю) смахивает. :(

А>Если ты выполняешь сложнейшие операции со строками в тайм-критикал приложении, то, конечно, нужн думать о неэффективном соединении строк (и о многом другом :)). В заданном же вопросе конкретная ситуация: UI на ATL, который принимает строку из COM-метода (явно в UNICODE :)), отображает и снова отправляет в COM-метод...

Я очень ценю творческий подход, но может чем домысливать, просто, взять и прочитать исходный вопрос целиком?

В вопросе фигурирует WTL, а это значит, что речь не идет о приеме или возврате данных в формате BSTR. Niemiets спрашивал "что
вы используете с WTL: TCHAR*, string или CString". Думаю, подразумевалось, что string (видимо std::string) и CString цепляют CRT.

Теперь о конвертации. Все эти рассуждения от лени! Ну, напрягитесь, гляньте как (!) реализованы вызовы API-шных функций в CComBSTR! И вы увидите, что перед вызовом (при компиляции без UNICODE) происходит конвертация в ANSI и обратно. Причем каждый раз. Даже при выполнении такого кода под управлением NT/W2k все равно вызываются ANSI-версии. Конкатенации, модификации да и любые действия со строкой приводят к многократным перезаёмам памяти, а это дико медленно (медленней чем копирование небольших кусков памяти). CascStr проводит все операции в TCHAR, что приводит к минимизации конвертаций. Получается, даже в случае BSTR-методов, одна конвертация на входе/выходе. Естественно, что речь идет о случаях где надо работать со строкой. Если нужно просто запомнить строку в переменной или передать другой BSTR-функции, то нужно использовать CComBSTR.

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

Это говорит о том, что Вы просто не сталкивались с задачами требующими высокой производительности. Представьте себе, что Вам нужно выбрать сроки из БД-курсора (20 колонок * 10000 строк) и канканировать их в одну, ну, например, с целью создания отчета в текстовом (TXT, HTML, XML, VCS...) виде.

А>Тут нужно как можно быстрее написать код и не думать о вещах (типа собственной эффективной строки и, прости господи, явного malloc'a), которые, кроме затрат времени, проблем с отладкой и удорожания продукта, не дадут абсолютно никакого результата.

Так возьмите класс типа CascStr или CString (если плевать на цепляние CRT) и не думайте! Писать будет проще и код будет близким к оптимальному, без дополнительных затрат. А проблем с отладкой с CascStr или CString будет даже меньше чем при не целевом использовании CComBSTR.

PS

В конце концов CComBSTR имеет очень убогие возможности по работе со строками.

Целиком и полностью согласен с предыдущим автором!

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

VD>Здравствуйте ZORK, вы писали:

ZORK>> А вот надежность, простота и четабельность кода действительно важно, особенно для проектов который делается месяцами — я щас раз как раз на таком сижу.

VD>Так и что? При использовании CascStr или CString "надежность, простота и четабельность кода" уменьшается? Или при использовании CComBSTR увеличивается?

Сложный вопрос. Что-б было по понятнее, от чего я отталкиваюсь — я работаю щас в конторе, где народ типа стандартно подготовлен (курсы, лицензирования, индийские университетмы) работать с C++, и им объяснять что вот есть еще одна библиотека, которую надо бы тоже подключить к проекту, иногда большой геморой. Так что, если говорить о бизнесс решениях, то иногда и это тоже надо брать в расчет. CComBSTR идет с ATL. Для CString уже надо ставить WTL — с учетом ограниченной информации о ней, народ ее уже побаивается. Ну a CascStr можно только скопировать в проект, так как иначе менеджеры не пропустят библиотеку, к которой не прилогается потдержки, да и не совсем понятны условия лицензирования.

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

Здравствуйте Аноним, вы писали:

А> TCHAR str[MAX_PATH];
А> m_Edit.GetWindowText(str, MAX_PATH);

Мда. Предлагаю решение НА ПОРЯДОК проще. Идите на http://www.codeproject.com, там найдите в разделе о строках класс CStdString И ЗАБУДТЕ О ПРОБЛЕМАХ! Класс состоит из ОДНОГО header file (stdstring.h) и включает огромное количество возможностей. В частности, работа с _bstr_t, загрузка/выгрузка в IStream, совместимость со стандартными std::string и делами. Не завязан ни на MFC, ни на ATL. Я в свое время так сделал и забыл. Вышенаписанный код выглядел бы приблизительно так:

CStdString szEditText;
m_Edit.GetWindowText(szEditText.GetBuffer(MAX_PATH), MAX_PATH);
szEditText.ReleaseBuffer();

Да, класс построен на основе STL, так что, чем эффективнее STL установлена, тем эффективнее будет этот CStdString. А, он еще переносим. В общем, Joe O'Leary проделал просто потрясающую работу.

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

MS> ... Не завязан ни на MFC, ни на ATL. Я в свое время так сделал и забыл.

Главное что он завязан на CRT. При разработке на WTL — это может быть намного хуже завязки на ATL. ;о) Ведь WTL априори завязана на ATL (см. собственно начальный вопрос)

MS>Вышенаписанный код выглядел бы приблизительно так:

MS>CStdString szEditText;
MS>m_Edit.GetWindowText(szEditText.GetBuffer(MAX_PATH), MAX_PATH);
MS>szEditText.ReleaseBuffer();

Ну, так на CascStr это выглядит так:

szEditText.GetWindowText(m_Edit);

MS> Да, класс построен на основе STL, так что, чем эффективнее STL установлена, тем эффективнее будет этот CStdString. А, он еще переносим. В общем, Joe O'Leary проделал просто потрясающую работу.

Да переносимость для WTL-приложения — это главное достоинство. ;o)