Можно ли хранить в стандартных контейнерах (например, векторе) классы с перегруженными операторами "*, ?, =, ->, =="?
Если нельзя, то может быть можно как-то обойти это ограничение?

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

А>Можно ли хранить в стандартных контейнерах (например, векторе) классы с перегруженными операторами "*, ?, =, ->, =="?
А>Если нельзя, то может быть можно как-то обойти это ограничение?
ИМХО, нельзя хранить только классы с перегруженным &.
Т.к. &vec[0] должен возвращать указатель на внутренний массив.

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

А>Можно ли хранить в стандартных контейнерах (например, векторе) классы с перегруженными операторами "*, ?, =, ->, =="?
Можно. Есть 2 требования к элементам стандартных контейнеров: они должны быть Assignable и CopyConstructable.

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

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

А>>Можно ли хранить в стандартных контейнерах (например, векторе) классы с перегруженными операторами "*, ?, =, ->, =="?
А>>Если нельзя, то может быть можно как-то обойти это ограничение?
S>ИМХО, нельзя хранить только классы с перегруженным &.
S>Т.к. &vec[0] должен возвращать указатель на внутренний массив.
Ничего подобного. vec[0] возвращает ссылку на первый элемент — не больше и не меньше.

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

А>Можно ли хранить в стандартных контейнерах (например, векторе) классы с перегруженными операторами "*, ?, =, ->, =="?
А>Если нельзя, то может быть можно как-то обойти это ограничение?

Можно. Ничему не противоречит. Теже смарт-поинтеры обычно перегружают *, ->.

Спасибо!
Ребилдол — незаменимая вещь

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

S>>ИМХО, нельзя хранить только классы с перегруженным &.
S>>Т.к. &vec[0] должен возвращать указатель на внутренний массив.
B>Ничего подобного. vec[0] возвращает ссылку на первый элемент — не больше и не меньше.

Ага, и чтобы получить массив, нужно сделать boost::addressof(vec[0]), который объезжает перегрузку & на кривой кобыле
примерно так

template<class T>
T* addressof(T& x) { return static_cast<T*>(&static_cast<char&>(x)); }

Беда в том, что реализации vector могут быть неустойчивы к перегрузке &.
Вот например, Dinkum STL для VC8.

template<class _Ty,
    class _Alloc>
    class _Vector_const_iterator
        : public _Ranit<_Ty, typename _Alloc::difference_type,
            typename _Alloc::const_pointer, typename _Alloc::const_reference>
    {    // iterator for nonmutable vector
/*........*/

    pointer operator->() const
        {    // return pointer to class object
        return (&**this);
        }
/*........*/
};

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

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

S>>>ИМХО, нельзя хранить только классы с перегруженным &.
S>>>Т.к. &vec[0] должен возвращать указатель на внутренний массив.
B>>Ничего подобного. vec[0] возвращает ссылку на первый элемент — не больше и не меньше.

К>Ага, и чтобы получить массив, нужно сделать boost::addressof(vec[0]), который объезжает перегрузку & на кривой кобыле
К>примерно так
К>

К>template<class T>
К>T* addressof(T& x) { return static_cast<T*>(&static_cast<char&>(x)); }
К>

Мне кажется, что о получении адреса должен заботиться тот, кто перегрузил &.
Ну и последствия такой перегрузки, конечно, должны быть осознанны.

К>Беда в том, что реализации vector могут быть неустойчивы к перегрузке &.
К>Вот например, Dinkum STL для VC8.

Мда...
Удобнее конечно, когда в контейнере лежат указатели, но ведь не зря в стандарте требуется только реализация *...

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

S>ИМХО, нельзя хранить только классы с перегруженным &.

Поддерживаю. Некоторые реализации stl контейнеров явно используют этот оператор для получения 'указателей', причем не ставят ограничения на тип, возвращаемый оператором. Далее полученные значения используют для поддержания целостности контейнера, и, соответственно, все удачно падает. Насколько помню, так делает stl из поставки gcc 3.4.2

S>Т.к. &vec[0] должен возвращать указатель на внутренний массив.
Не факт, vec[0] должен возвращать ссылку на элемент, а дальше хоть трава не расти (вызывай operator & и получай то что он вернет).

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

B>>Ничего подобного. vec[0] возвращает ссылку на первый элемент — не больше и не меньше.
К>Ага, и чтобы получить массив, нужно сделать boost::addressof(vec[0]), который объезжает перегрузку & на кривой кобыле
Почему на кривой?

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

К>>Ага, и чтобы получить массив, нужно сделать boost::addressof(vec[0]), который объезжает перегрузку & на кривой кобыле
V>Почему на кривой?

Потому что это сомнительный код. Как нам показал

Автор: McSeem2
Дата: 23.08.07

McSeem2.
Честно сказать, пофигу, то ли UB, то ли баг компилятора... но осадочек остался

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

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

К>>>Ага, и чтобы получить массив, нужно сделать boost::addressof(vec[0]), который объезжает перегрузку & на кривой кобыле
V>>Почему на кривой?

К>Потому что это сомнительный код. Как нам показал

Автор: McSeem2
Дата: 23.08.07

McSeem2.
К>Честно сказать, пофигу, то ли UB, то ли баг компилятора... но осадочек остался
Я так понял, что в случае с char-ом все должно работать

Автор: elcste
Дата: 23.08.07

.

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

А>Можно ли хранить в стандартных контейнерах (например, векторе) классы с перегруженными операторами "*, ?, =, ->, =="?
А>Если нельзя, то может быть можно как-то обойти это ограничение?

Если придумаешь, как перегрузить оператор ?: — расскажи!

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

S>Я так понял, что в случае с char-ом все должно работать

Автор: elcste
Дата: 23.08.07

.

Ну тогда слава богу. Будем надеяться, что gcc тоже строго блюдёт этот пункт.

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

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

А>>Можно ли хранить в стандартных контейнерах (например, векторе) классы с перегруженными операторами "*, ?, =, ->, =="?
А>>Если нельзя, то может быть можно как-то обойти это ограничение?

A>Если придумаешь, как перегрузить оператор ?: — расскажи!
Это описка, там '&' должен был быть

К>Беда в том, что реализации vector могут быть неустойчивы к перегрузке &.
К>Вот например, Dinkum STL для VC8.

есть такая проблема. поэтому MS сделала адаптер CAdapt чтобы хранить объекты типа CComPtr в контейнерах STL