странно перерыл всю ATL и не смог решить с виду простейшую задачу страндартными средствами
дело вот в чем есть одна функция принимающая указатель на массив указателей на wchar_t
так вот должен быть контейнер который ей можно скормить как массив указателей и который
сам себя чистит при исключении вопрос в чем хранить чтоб
само себя чистило и чтоб можно было обрабатывать как массив простых
указателей на wchar_t ?

попробую обрисовать ситуацию есть некий класс
у него мембером должен быть массив указателей на wchar_t

sometype_t
{
   wchar_t * arr[...]; // тут должен быть контейнер по задумке чтоб не велосипедить
   void member()
   {
       // processing arr
       ::f(arr);
   }
};

есть внешняя функция с такой сигнатурой экспортируемая системой

void f(wchar_t **array);

и код котопый может вызвать проблемы для wchar_t ** sometype::arr

void otherfunc()
{
sometype_t subj;
call(); // throw probably
subj.member();
call(); // throw probably
}

вот как бы так хранить чтоб было доступно как массив нативных указателей
и если исключение чтоб вызывал delete[] для каждого это важно потому что
указатели на строки
ВАЖНО остаться в рамках ATL

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

J>ВАЖНО остаться в рамках ATL
Если в рамках ATL, то для этого есть соответствующий форум.
А так — http://www.boost.org/libs/ptr_container

You will always get what you always got
  If you always do  what you always did

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

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

J>>ВАЖНО остаться в рамках ATL
J>Если в рамках ATL, то для этого есть соответствующий форум.
J>А так — http://www.boost.org/libs/ptr_container
да это я смотрел но не нашел как застпавить его вызывать delete[] а не delete
это должно как то регулироватся через шаблоны наверное но что то не вижу

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

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

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

J>>>ВАЖНО остаться в рамках ATL
J>>Если в рамках ATL, то для этого есть соответствующий форум.
J>>А так — http://www.boost.org/libs/ptr_container
J>да это я смотрел но не нашел как застпавить его вызывать delete[] а не delete
J>это должно как то регулироватся через шаблоны наверное но что то не вижу

Для массивов есть scoped_array и ко: http://www.boost.org/doc/libs/1_47_0/libs/smart_ptr/smart_ptr.htm

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

Ytz>Для массивов есть scoped_array и ко: http://www.boost.org/doc/libs/1_47_0/libs/smart_ptr/smart_ptr.htm
shared_array так если я создам массив из shared_array то все супер но
этот массив не будет доступен как массив указателей на wchar_t *
это будет уже массив из shared_array<wchar_t*> в этом и проблема
в ATL тоже есть средства например CAutoPtrArray но опять же они
предпологают хранение не просто указателей а умных указателей а мне
надо чтоб были доступны системной функции как массив простых wchar_t *

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

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

J>>ВАЖНО остаться в рамках ATL
J>Если в рамках ATL, то для этого есть соответствующий форум.
более точно остаться в рамках msvcrt.dll не призывая msvcpXX.dll
можно и boost и loki многие средства из них тоже не требуют msvcpXX.dll

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

J>вот как бы так хранить чтоб было доступно как массив нативных указателей
J>и если исключение чтоб вызывал delete[] для каждого это важно потому что
J>указатели на строки
J>ВАЖНО остаться в рамках ATL

В ATL такого и нет. Как вариант, почему бы не использовать std::vector со свои аллокатором.

псевдо:

template< class T >
class Alloc: public std::allocator<T>
{
public:

    template<class _Other>
        struct rebind
        {    
            typedef Alloc<_Other> other;
        };

    void deallocate(pointer _Ptr, size_type)
    {
        delete[] _Ptr;
    }
};

std::vector< wchar_t*, Alloc<wchar_t*> > arr;

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

5er>Здравствуйте, jyuyjiyuijyu, Вы писали:

J>>вот как бы так хранить чтоб было доступно как массив нативных указателей
J>>и если исключение чтоб вызывал delete[] для каждого это важно потому что
J>>указатели на строки
J>>ВАЖНО остаться в рамках ATL

5er>В ATL такого и нет. Как вариант, почему бы не использовать std::vector со свои аллокатором.

5er>псевдо:

5er>

5er>template< class T >
5er>class Alloc: public std::allocator<T>
5er>{
5er>public:

5er>    template<class _Other>
5er>        struct rebind
5er>        {    
5er>            typedef Alloc<_Other> other;
5er>        };

5er>    void deallocate(pointer _Ptr, size_type)
5er>    {
5er>        delete[] _Ptr;
5er>    }
5er>};

5er>std::vector< wchar_t*, Alloc<wchar_t*> > arr;

5er>

вот это первое красивое решение но это потащит за собой msvcpXX.dll

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

J>>>ВАЖНО остаться в рамках ATL
J>>Если в рамках ATL, то для этого есть соответствующий форум.
J>более точно остаться в рамках msvcrt.dll не призывая msvcpXX.dll
J>можно и boost и loki многие средства из них тоже не требуют msvcpXX.dll

А в чем подвох? msvcrXX.dll и msvcpXX.dll — составные части CRT.
Если ты поставляешь свою программу с инсталлятором, то обе длл там будут (не ошибусь, если скажу, что любой инсталлятор поддерживает установку CRT по нажатию крыжика).

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

По теме вопроса:
Создай два CAtlArray: в один положи объекты, а во второй сложи указатели на них. И будет щщщастье

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>А в чем подвох? msvcrXX.dll и msvcpXX.dll — составные части CRT.
SVZ>Если ты поставляешь свою программу с инсталлятором, то обе длл там будут (не ошибусь, если скажу, что любой инсталлятор поддерживает установку CRT по нажатию крыжика).

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

SVZ>По теме вопроса:
SVZ>Создай два CAtlArray: в один положи объекты, а во второй сложи указатели на них. И будет щщщастье

А в чем подвох? msvcrXX.dll и msvcpXX.dll — составные части CRT.

дело в том что CRT мне заменяет не версионная msvcrXX.dll а системная
msvcrt.dll она так же все умеет как и msvcrXX.dll кроме msvcpXX.dll

По теме вопроса:
Создай два CAtlArray: в один положи объекты, а во второй сложи указатели на них. И будет щщщастье

как мне "положить объеты?" это должны быть масивы из wchar_t полностью голые
именно так их рассматривает системная функция

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

J>дело в том что CRT мне заменяет не версионная msvcrXX.dll а системная
J>msvcrt.dll она так же все умеет как и msvcrXX.dll кроме msvcpXX.dll

Ничего не понял, ну да ладно...
Может ты надеешься, что программа, собранная с CRT одной версии, будет работать с другой версией? Бывает, что работает...

J>
J>По теме вопроса:
J>Создай два CAtlArray: в один положи объекты, а во второй сложи указатели на них. И будет щщщастье
J>
J>как мне "положить объеты?" это должны быть масивы из wchar_t полностью голые
J>именно так их рассматривает системная функция

Если я правильно тебя понял, то вот так:

    struct fufel
    {
        wchar_t buf[10];
    };

    CAtlArray<fufel> objects;
    objects.Add();
    objects.Add();
    objects.Add();

    CAtlArray<LPWCH> pointers;
    pointers.Add( objects[0].buf );
    pointers.Add( objects[1].buf );
    pointers.Add( objects[2].buf );

    wchar_t** ppwc = &pointers[0];  //и никаких утечек памяти

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Если я правильно тебя понял, то вот так:
SVZ>

SVZ>    struct fufel
SVZ>    {
SVZ>        wchar_t buf[10];
SVZ>    };

SVZ>    CAtlArray<fufel> objects;
SVZ>    objects.Add();
SVZ>    objects.Add();
SVZ>    objects.Add();

SVZ>    CAtlArray<LPWCH> pointers;
SVZ>    pointers.Add( objects[0].buf );
SVZ>    pointers.Add( objects[1].buf );
SVZ>    pointers.Add( objects[2].buf );

SVZ>    wchar_t** ppwc = &pointers[0];  //и никаких утечек памяти

SVZ>

ага а если
CAtlArray<fufel> objects;
возмет да и переместит объекты в памяти когда будет переаллокацию делать
кто нам скорреуктирует указатели ?
да и потом перерасход памяти с жестко зашитыми размерами массивов я про такое думал но
отверг из за этого

Здравствуйте, Stanislav V. Zudin, Вы писали:

дело в том что там не добавляются сразу все объекты чтоб можно было
потом взять на них указатели в другой контейнер и быть уверенным что
перемещения уже не будет там есть некая функция вызываемая иногда ее задача
создать новую строку в памяти и сохранить на нее указатель за один вызов это
значит что при N-ом добавлении старые указатели собъются после переаллокации а
когда понадобится массив указателей они будут сбиты

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

попробовал это какая то адова затея в отладчике вижу что deallocate
вызывается и между тем как добавляются элементы но вот в чем беда
непонятно толи это переалолокация толи каюк контейнеру если во время
переалолокации освободить указатели то он будет хранить мертвые указатели
как понять что это смерть контейнера и можно освободить указатели а не очередная
переаллокация и трогать ничего не надо

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

J>вот как бы так хранить чтоб было доступно как массив нативных указателей
J>и если исключение чтоб вызывал delete[] для каждого это важно потому что
J>указатели на строки
J>ВАЖНО остаться в рамках ATL

как на счёт просто:

sometype_t
{
   CAtlArray<wchar_t *> arr;
   void member()
   {
       // processing arr
       ::f(arr);
   }
   ~sometype_t() {
       for (size_t i = 0; i < arr.GetCount(); ++i)
           delete[] arr[i];
   }
};

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

это и придется оставить если ничего не придумаем то от чего хотелось уйти
вырвиглазно смотрится ручное удаление памяти

вообщем немного изменил алгоритм и остановился на таком варианте строки добавляются в

CAtlArray<CStringW> m_Media

а когда нужен массив указателей вызывается эта функция создает его

std::auto_ptr<CAtlArray<LPCWSTR>> GetMediaPtrArray()
{
    std::auto_ptr<CAtlArray<LPCWSTR>> arr(new CAtlArray<LPCWSTR>());

    for (size_t i = 0; i < m_Media.GetCount(); i++)
    {
        arr->Add(m_Media[i]);
    }

    arr->Add(UNICODE_NULL);

    return arr;
}

ну а используется так

 
sys_call(..., GetMediaPtrArray()->GetData(), ...)

тут auto_ptr прибивает его сразу после вызова