Может быть сообщение не совсем по теме, но всё же спрошу —
самое дурное (на мой взгляд) в C++ — subj, поделитесь, что
вы используете с WTL: TCHAR*, string или CString? Конкретнее,
меня интересуют 2 пункта:
1. Работа со строками неограниченной переменной длины, причём
используюя WTL-классы (например мне не нравится след код, может
быть и кривой:

TCHAR * str;
//....
int Len=m_Edit.GetWindowTextLength();
free(str);//вот тут м.б ошибка если пер. не инициализировна
str=malloc(sizeof(TCHAR)*(Len+1));
m_Edit.GetWindowText(str,Len+1);

2. Возврат строковых переменных из процедуры(как в возвращаемом
значении функции, так и в изменяемом её параметре).

Если кто может подсказать ссылку на доку в Инете по этому поводу-
буду несказанно рад!
Да ещё хочу подчеркнуть, что буферы фиксированной длины не подходят.
Заранее спасибо!

А что нужно то, нет всё понятно, но что конкретно? )))

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

N>Может быть сообщение не совсем по теме, но всё же спрошу -
N>самое дурное (на мой взгляд) в C++ — subj, поделитесь, что
N>вы используете с WTL: TCHAR*, string или CString? Конкретнее,
N>меня интересуют 2 пункта:
N>1. Работа со строками неограниченной переменной длины, причём
N>используюя WTL-классы (например мне не нравится след код, может
N>быть и кривой:

N>TCHAR * str;
N>//....
N>int Len=m_Edit.GetWindowTextLength();
N>free(str);//вот тут м.б ошибка если пер. не инициализировна
N>str=malloc(sizeof(TCHAR)*(Len+1));
N>m_Edit.GetWindowText(str,Len+1);

N>2. Возврат строковых переменных из процедуры(как в возвращаемом
N>значении функции, так и в изменяемом её параметре).

N>Если кто может подсказать ссылку на доку в Инете по этому поводу-
N>буду несказанно рад!
N>Да ещё хочу подчеркнуть, что буферы фиксированной длины не подходят.
N>Заранее спасибо!

CComBSTR и все просто!!!
1. В WTL есть чувствительные к корректному TCHAR DDX макросы межу CEdit и CComBSTR
DDX_TEXT(IDC_MYEDIT, bstrMyBSTR);
(независимо от размераTCHAR)
2.
void MyProc(BSTR* pbstrResult)
{
CComBSTR bstrMyBstr = L"The result";

bstrMyBstr.CopyTo(pbstrResult);

}

CComBSTR bstrResult;
MyProc(&bstrResult);

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

Спасибки, вроде правда просто, надо попробовать, но тогда в догонку вопрос:
а как ещё их писать в файлы пропроще (чем ReadFile)?
в WTl-ных ресурсах кругом говорят: используйте XML!
А примеров кот наплакал! Точнее я не одного нормального не видал.
А в файле будут храниться числа(double) и строки.

Опять заранее спасибо за любую информацию!

N>в WTl-ных ресурсах кругом говорят: используйте XML!
N>А примеров кот наплакал! Точнее я не одного нормального не видал.
N>А в файле будут храниться числа(double) и строки.

http://www.rsdn.ru/?article/?xml/msxml.xml

Автор(ы): Кен Скрибнер (Kenn Scribner)
Дата: 17.04.2001

В этой статье автор на простом примере демонстрирует применение парсера MSXML для работы с XML-документами (загрузка и сохранение документа, поиск, изменение и добавление узлов, получение и изменение атрибутов). Для работы с MSXML используются средства библиотеки ATL.

А>CComBSTR и все просто!!!
попробовал — полнейшая ерунда про просто!
Внутри DDX_TEXT(точнее CWindow::GetWindowText(BSTR*))примерно такой же код, что я приводил. Но полнейшая ерунда возникает, когда CComBSTR в других функциях испльзовать приходится( к примеру CWindow::SetWindowText) — они LPCSTR требуют, т.е. никакой полседовательности в параметрах!!! Поэтому на данный момент я принял решение использовать TCHAR* и мучаться с выделением и уничтожением памяти. А по поводу XML статью я читал, но хотелось бы чего-нибудь более серёзного, e.g. какую-нибудь прогу, чтоб что-нибудь(настройки к примеру) реально как XML хранила.

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


А>>CComBSTR и все просто!!!
N>попробовал — полнейшая ерунда про просто!
N>Внутри DDX_TEXT(точнее CWindow::GetWindowText(BSTR*))примерно такой....

В WTL (в файле atlmisc.h) есть CString такой-же как в MFC (кроме этого там есть всекие CRect,
CSize и т.д) так этот CString можно использовать вместе с WTL-ными классами в стиле MFC.
Кроме этого в ATL (в файле atlconv.h) объявлено куча макросов для преобразования
(OLE2T, T2OLE, T2BSTR и т.д), кроме этого CString можно инициализировать BSTR строкой
Правда в классе CWindow придется всеже использовать просто LPTSTR.
в простых случаях можно писать:

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

если лень писать free после malloc распределяй память функцией void *_alloca( size_t size ),
при этом память выдиляется на стеке и автоматически освобождается при выходе из функции.
с помощю этой функции можно написать макрос типа GET_WINDOW_TEXT(m_Edit, str)

Здравствуйте Niemiets

А есть вот еще _bstr_t, у него есть и операторы _bstr_t::wchar_t*, _bstr_t::char*

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

А>В WTL (в файле atlmisc.h) есть CString такой-же как в MFC.

Гы-гы. Такой же как в MFC. :)

Да там процентов 90 нет. Бери наш CascStr в нем разные GetWindowText и SysAllocString встроены.

http://www.optim.ru/Software/rus/ascLib/ascLib.asp

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

D>А есть вот еще _bstr_t, у него есть и операторы _bstr_t::wchar_t*, _bstr_t::char*

Уж больно кривая это щнука. Она хранит строку сразу в двух пердставлениях A и OLESTR, и по полной програме цепляет CRT.

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


А>>CComBSTR и все просто!!!
N>попробовал — полнейшая ерунда про просто!
N>Внутри DDX_TEXT(точнее CWindow::GetWindowText(BSTR*))примерно такой же код, что я приводил. Но полнейшая ерунда возникает, когда CComBSTR в других функциях испльзовать приходится( к примеру CWindow::SetWindowText) — они LPCSTR требуют, т.е. никакой полседовательности в параметрах!!! Поэтому на данный момент я принял решение использовать TCHAR* и мучаться с выделением и уничтожением памяти. А по поводу XML статью я читал, но хотелось бы чего-нибудь более серёзного, e.g. какую-нибудь прогу, чтоб что-нибудь(настройки к примеру) реально как XML хранила.

Без истерик, юноша!

...
CComBSTR bstrText;

USES_CONVERSION;
m_edMyEdit.GetWindowText(&bstrText);
m_edMyEdit.SetWindowText(W2T(bstrText));
....

CComBSTR и все просто!!!

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

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

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

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

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

Потому, что UI надо писать быстро и ясным, лего читаемым и форматированым кодом.
В большинтсве функций не LPCSTR, а LPTSTR! Код вверху портабилен между unicode/non-unicode.

А>Потому, что UI надо писать быстро и ясным, лего читаемым и форматированым кодом.
Полностью согласен!
А>В большинтсве функций не LPCSTR, а LPTSTR! Код вверху портабилен между unicode/non-unicode.
Ну и тут нечего сказать,
меня неустраивает 1 — почему в одном месте BSTR, а в другом LPTSTR и зачем перегонять из одного в другое? Ладно ещё в COM, там без BSTR никуда, но в оконных-то процедурах зачем такую путаницу устраивать и лишний, никому не нужный код для конвертации пихать в макросы?

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

Так CascString от и есть TCHAR. Как и CString. CComBSTR для копирований и конкатинаций — это не лучший выбор. Погляди как там все написоно!!!

CComBSTR это класный хелпер для наботы с BSTR, но не для работы со строками.

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

N>Может быть сообщение не совсем по теме, но всё же спрошу -
N>самое дурное (на мой взгляд) в C++ — subj, поделитесь, что
N>вы используете с WTL: TCHAR*, string или CString? Конкретнее,
N>меня интересуют 2 пункта:
N>1. Работа со строками неограниченной переменной длины, причём
N>используюя WTL-классы (например мне не нравится след код, может
N>быть и кривой:

N>TCHAR * str;
N>//....
N>int Len=m_Edit.GetWindowTextLength();
N>free(str);//вот тут м.б ошибка если пер. не инициализировна
N>str=malloc(sizeof(TCHAR)*(Len+1));
N>m_Edit.GetWindowText(str,Len+1);

N>2. Возврат строковых переменных из процедуры(как в возвращаемом
N>значении функции, так и в изменяемом её параметре).

N>Если кто может подсказать ссылку на доку в Инете по этому поводу-
N>буду несказанно рад!
N>Да ещё хочу подчеркнуть, что буферы фиксированной длины не подходят.
N>Заранее спасибо!

I do it this way:
#ifdef _UNICODE
typedef std::basic_string<wchar_t> tstring
#else
typedef std::string tstring
#endif

N>TCHAR * str;
N>//....
N>int Len=m_Edit.GetWindowTextLength();
N>free(str);//вот тут м.б ошибка если пер. не инициализировна
N>str=malloc(sizeof(TCHAR)*(Len+1));
N>m_Edit.GetWindowText(str,Len+1);

Я тоже хочу поделиться :-)

string GetWindowText(HWND hWnd)
{
int len=::GetWindowTextLength(hWnd);

if(len<=0)
return string();

string text((string::size_type)len,(string::value_type)0);

::GetWindowText(hWnd,text.begin(),text.size()+1);//text содержит len+1 символов

return text;
}

это мои заморочки с STL :-)

вообще говоря, код не дуракоустойчивый — вдруг длина строки поменяется между вызовами :)

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

N>Может быть сообщение не совсем по теме, но всё же спрошу -
N>самое дурное (на мой взгляд) в C++ — subj, поделитесь, что
N>вы используете с WTL: TCHAR*, string или CString? Конкретнее,
N>меня интересуют 2 пункта:
N>1. Работа со строками неограниченной переменной длины, причём
N>используюя WTL-классы (например мне не нравится след код, может
N>быть и кривой:

N>TCHAR * str;
N>//....
N>int Len=m_Edit.GetWindowTextLength();
N>free(str);//вот тут м.б ошибка если пер. не инициализировна
N>str=malloc(sizeof(TCHAR)*(Len+1));
N>m_Edit.GetWindowText(str,Len+1);

вообще этот код должен выглядеть так
TCHAR * str = NULL;
//....
int Len=m_Edit.GetWindowTextLength();
if( str )
delete[] str;//вот тут не будет ошибки если корретно все писать
str=new TCHAR[ Len+1 ];
m_Edit.GetWindowText(str,Len+1);


N>2. Возврат строковых переменных из процедуры(как в возвращаемом
N>значении функции, так и в изменяемом её параметре).

как ни крути, а если функция (не твоя ) принимает указатель на буффер и ожидает, что под него выделена память
то прежде чем передать туда строку под нее нужно выделить память, чем бы ты не пользовался, string? CString или char *.
В своих. соотвтетственно, можешь делать как хочешь.

N>Если кто может подсказать ссылку на доку в Инете по этому поводу-
N>буду несказанно рад!
N>Да ещё хочу подчеркнуть, что буферы фиксированной длины не подходят.
N>Заранее спасибо!

если работы со строками не много, то TCHAR *, вполне подходит, только надо почитать как с ним работать.
есть string от STL (определены +=, и еще несколько удобных вещей );
раз уж форум по ATL/WTL :), то еще есть тип BSTR, и его обертка CComBSTR, только, опять же надо внимательно почитать про работу с ними.

в крайнем случае, свой класс строки пишется за час.

best wishes
Ed.ward

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

А не проще ли перед тем как начать писать прочесть все ветки темы?

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

D>А есть вот еще _bstr_t, у него есть и операторы _bstr_t::wchar_t*, _bstr_t::char*

Для ATL у _bstr_t один недостаток — он использует exceptions, так что его можно только использовать с включенной в компиляторе потдержкой exceptions, что в общем случае приводит к увеличению получаемой ATL компоненты.

Здравствуйте 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)