Статья :
ATLArray вместо CArray

Авторы :
Сергей Ермак

Аннотация :
Шаблон класса ATLArray, предлагаемый вашему вниманию, — практически полный аналог класса CArray из библиотеки MFC. Так что не ждите подробного описания его методов и переменных, — читайте хэлп по классу CArray в документации вашей Visual Studio и применяйте полученные знания к объектам, произведенным от класса ATLArray. Все методы, их параметры и возвращаемые значения, а также закрытые и открытые переменные класса полностью идентичны.

Полагаясь на свой большой опыт программирования вогу сказать, что использовать STL гораздо выгоднее. Да и надежнее, потому что MFC до сих пор сожержит массу ошибок и нелепостей. Например, в STL сохраняется один и тот же подход при работе со всеми шаблонами, вам не придется ломать голову и рыть документацию чтобы узнать, как очитить контейнер в MFC — DeleteItems, RemoveAll, ResetContent — это все говорит о неряшливости отпрысков дяди Билла. Или, например, попробуйте сделать такой массив: CArray<CComPtr<IUnknown>>. Не получается? И здесь виноват MFC. Я уже не буду говорить о том, что с MFC в Unix вас никто не "пустит".

Как насчёт сабжа?
Тоже иногда бывает нужно.

Ну опять про то, что вкуснее: помидоры или огурцы. При чем здесь Unix? Зачем человеку STL, когда ему нет необходимости выходить за рамки WinAPI+ATL+WTL ? И при чем здесь MFC и Билл Гейтс (он его писал что-ли?). Я уже встречал не один десяток подобных высказываний. Это из серии — мой сотовый телефон лучше, т.к. у него есть встроенный браузер. Ну когда люди поймут, что каждый пишет на том, что ему больше нравится или что больше подходит к той или иной ситуации. Мне, например, создание мпссива CArray<CComPtr<IUnknown>> даже в страшном сне не понадобится, как, возможно, и многим другим. Так что давайте будем терпимы ко всему, что не Вашего цвета, т.к. на STL можно тоже вылить массу грязи.

Юзайте stl::string

Молодой человек!!!
А чем Вас CComBSTR не устраивает ?????

Упс.. Не заметил ответов :) Жаль нельзя свою мессагу грохнуть :))

Так в WTL же полный аналог есть... в atlmisc.h, если я не ошибаюсь

Odissey правильно заметил насчет CString в AtlMisc.h
Рекомендую обращаться к этой реализации и я.
Если уж сильно хочется иметь отдельный .h файл для CString,
то что мешает вычленить его реализацию из AtlMisc.h ?
Ну а ATLArray это просто для тех, кто ностальгирует
по MFC, не больше и не меньше...
Я просто вычленил CArray из MFC :)
(Надеюсь, Билли не обидится)
C COM-приветом, Mi

Так есть же он там (в WTL) — в AtlMisc.h

З.Ы. И массив кстати есть родной в ATL — CSimpleArray — в atlbase.h живет

Хочу заметить, что CString в WTL вельми убогий. Такое ощущение, что его писал практикант. Нет никакого резервирования для последующей конкатенации, т.е каждый раз, как к строке добавляется хотя бы 1 символ, происходит перераспределение памяти, вдобавок само перераспределение всегда выполняется выделением нового блока, копированием строки и затем освобождением старого, хотя даже без резервирования во многих случаях можно было бы сделать realloc и возможно обойтись без копирования старой строки (если за уже выделенным куском памяти нашелся свободный блок). Я мерил скорость работы строк stl, MFC, WTL и это подтвердилось — WTL в разы медленнее. Для себя я написал шаблонную строку с интерфейсом как у CString. Скорость получилась примерно как MFC-ая, но при определенных настройках обгоняет всех :). stl — строки — рулез. Действительно очень быстрые и хорошо работают с памятью. Правда с windows у них отношения холодные.

Будет работать везде и всегда, без всяких MFC ATL WTL
<CODE>
#include <list>
#include <string>
#include <iostream>

int main(int argc, char* argv[])
{
std::list<std::string> list;
std::list<std::string>::iterator i;

list.push_back( "masha" );
list.push_back( "ela" );
list.push_back( "kashu" );

for ( i = list.begin(); i != list.end(); ++i )
{
std::cout << *i << " ";
}

std::cout << std::endl;
return 0;
}
</CODE>

Тем, что во первом там много чего не хватает (Left, Right, Mid, Trim..., Find, Compare), а во втором он с рождения юникодовский, что мне не годится.

Кстати спасибо Odissey за WTL — это меня и спасло =)

Нам молодым TrimLeft и TrimRight подавай.

Дык тож в WTL, а если он мне только в ATL нужен?

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

Так вот зачем это все нужно!

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

LYA>Юзайте stl::string

неудобно, имхо. string только с char* работает, а для unicode нужен wstring.
если нужно поддерживать оба типа строк, придется два класса использовать и извращаться с преобразованиями.
а WTL::CString тем и хорош что легко преобразуется в BSTR, CComBSTR и обратно
если нужно поддерживать работу со строками в COM, CString однозначно рулит

>Я уже не буду говорить о том, что с MFC в Unix вас никто не "пустит".

вы хоть почитайте ТЕМУ КОНФЕРЕНЦИИ! и при чем тут Unix?
ATL никогда не будет портирована в Unix. а если и будет то вместе со всем содержимым, в т.ч. CAtlArray и т.д.,
для сохранения совместимости

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

V>Для себя я написал шаблонную строку с интерфейсом как у CString. Скорость получилась примерно как MFC-ая, но при определенных настройках обгоняет всех .
Интересно. Не поделитесь? Хотя бы функцию перераспределения буфера...
V> stl — строки — рулез. Действительно очень быстрые и хорошо работают с памятью. Правда с windows у них отношения холодные.
Достаточно много (28 в VS 2003, 16 в VS6) байт на объект, копирование буфера при копировании строки...