Пример:

class IClass
{
public:
    IClass& operator[] (int index) {}
};

class B : public IClass
{
public:
    IClass& operator[] (int index) { return this*; } 
};

Хочется так сделать. Но что-то подсказывает что не стоит.
Помогите определиться.

PS. А хочется так потому что есть желание писать obj[i],
а не obj->operator[](i).
Можно конечно указатель превратить в ссылку.
Но с другой стороны, если объекта по данному индексу не
окажется, то что возвращать? Как вариант можно вернуть
ссылку на "пустой" объект, а можно возбудить исключение.
Чем вообще грозит такой подход с ссылками в таком контексте?
Спасибо.

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

А>Пример:

А>

А>class IClass
А>{
А>public:
А>    IClass& operator[] (int index) {}
А>};

А>class B : public IClass
А>{
А>public:
А>    IClass& operator[] (int index) { return this*; } 
А>};

А>

А>Хочется так сделать. Но что-то подсказывает что не стоит.
А>Помогите определиться.

А>PS. А хочется так потому что есть желание писать obj[i],
А>а не obj->operator[](i).
А>Можно конечно указатель превратить в ссылку.
А>Но с другой стороны, если объекта по данному индексу не
А>окажется, то что возвращать? Как вариант можно вернуть
А>ссылку на "пустой" объект, а можно возбудить исключение.
А>Чем вообще грозит такой подход с ссылками в таком контексте?
А>Спасибо.
Да пиши на здоровье, только в IClass лучше тогда абстрактным делать, чем не возвращать ничего )

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

А>Пример:

А>

А>class IClass
А>{
А>public:
А>    IClass& operator[] (int index) {}
А>};

А>class B : public IClass
А>{
А>public:
А>    IClass& operator[] (int index) { return this*; } 
А>};

А>

А>Хочется так сделать. Но что-то подсказывает что не стоит.
А>Помогите определиться.

А>PS. А хочется так потому что есть желание писать obj[i],
А>а не obj->operator[](i).
А>Можно конечно указатель превратить в ссылку.
А>Но с другой стороны, если объекта по данному индексу не
А>окажется, то что возвращать? Как вариант можно вернуть
А>ссылку на "пустой" объект, а можно возбудить исключение.
А>Чем вообще грозит такой подход с ссылками в таком контексте?
А>Спасибо.


Контейнеры стандартной библиотеки все ссылки возвращают из operator[].
И с динамическим полиморфизмом тут проблем не будет.
Если индекс неправильный, можно кидать исключение, это будет нормально.
ИМХО плюс ещё в том, что возвращение указателя имеет ещё такой [психологический] подтекст, что тут может возвращаться NULL, что указатель надо всегда проверять. С ссылкой таких проблем нет: ссылка — это чётко объект.
К тому же всегда можно взять адрес ссылки, если уж очень надо.

> PS. А хочется так потому что есть желание писать obj[i],
> а не obj->operator[](i).

Если obj указатель пиши так: (*obj)[i];


Непонятно зачем тебе вообще перегружать operator [] (будешь менять поведение?)

может вот так?

class IClass
{
public:
IClass& operator [] (int index){return *m_arr[i];}
void add(IClass&);
private:
IClass* m_arr;
};

class B: public IClass
{
};

void main()
{
IClass cl, cl2;
B b, b2;
cl.add(b);
cl[0].add(b2);
cl2 = cl[0];
}

В случае если объекта по индексу нет лучше бросать исключение

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


R>Контейнеры стандартной библиотеки все ссылки возвращают из operator[].
R>И с динамическим полиморфизмом тут проблем не будет.

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

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

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


R>>Контейнеры стандартной библиотеки все ссылки возвращают из operator[].
R>>И с динамическим полиморфизмом тут проблем не будет.

А>-1
А>В том числе из-за этого в контейнерах стандартной библиотеки полно проблем с полиморфизмом, начиная с того, что хранить в них можно лишь указатели на абстрактные классы.

-1

Что хранить и что возвращать — это разные вещи. Тем более, что есть vector<shared_ptr<IBase> > и ptr_vector. И никаких проблем с тем, что возвращается ссылка.

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

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

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


R>>>Контейнеры стандартной библиотеки все ссылки возвращают из operator[].
R>>>И с динамическим полиморфизмом тут проблем не будет.

А>>-1
А>>В том числе из-за этого в контейнерах стандартной библиотеки полно проблем с полиморфизмом, начиная с того, что хранить в них можно лишь указатели на абстрактные классы.

R>-1

R>Что хранить и что возвращать — это разные вещи. Тем более, что есть vector<shared_ptr<IBase> > и ptr_vector. И никаких проблем с тем, что возвращается ссылка.

-1
shared_ptr — это не STL, читай внимательнее и не сбивай молодежь

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

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

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

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


R>>>>Контейнеры стандартной библиотеки все ссылки возвращают из operator[].
R>>>>И с динамическим полиморфизмом тут проблем не будет.

А>>>-1
А>>>В том числе из-за этого в контейнерах стандартной библиотеки полно проблем с полиморфизмом, начиная с того, что хранить в них можно лишь указатели на абстрактные классы.

R>>-1

R>>Что хранить и что возвращать — это разные вещи. Тем более, что есть vector<shared_ptr<IBase> > и ptr_vector. И никаких проблем с тем, что возвращается ссылка.

А>-1
А>shared_ptr — это не STL, читай внимательнее и не сбивай молодежь


кроме того shared_ptr это не абстрактный класс.

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

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

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

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


R>>>>Контейнеры стандартной библиотеки все ссылки возвращают из operator[].
R>>>>И с динамическим полиморфизмом тут проблем не будет.

А>>>-1
А>>>В том числе из-за этого в контейнерах стандартной библиотеки полно проблем с полиморфизмом, начиная с того, что хранить в них можно лишь указатели на абстрактные классы.

R>>-1

R>>Что хранить и что возвращать — это разные вещи. Тем более, что есть vector<shared_ptr<IBase> > и ptr_vector. И никаких проблем с тем, что возвращается ссылка.

А>-1
А>shared_ptr — это не STL, читай внимательнее и не сбивай молодежь


А кто говорил, что shared_ptr относится к STL?
Кстати, я вообще ни слова не говорил про STL. И STL меня вообще мало волнует.

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

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

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

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

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


R>>>>>Контейнеры стандартной библиотеки все ссылки возвращают из operator[].
R>>>>>И с динамическим полиморфизмом тут проблем не будет.

А>>>>-1
А>>>>В том числе из-за этого в контейнерах стандартной библиотеки полно проблем с полиморфизмом, начиная с того, что хранить в них можно лишь указатели на абстрактные классы.

R>>>-1

R>>>Что хранить и что возвращать — это разные вещи. Тем более, что есть vector<shared_ptr<IBase> > и ptr_vector. И никаких проблем с тем, что возвращается ссылка.

А>>-1
А>>shared_ptr — это не STL, читай внимательнее и не сбивай молодежь


А>кроме того shared_ptr это не абстрактный класс.

А кто сказал, что shared_ptr это абстрактный класс?

Кстати твой тезис "хранить в них можно лишь указатели на абстрактные классы" неправильный. Вообще не понятно, каким боком к обсуждаемому вопросу притесались абстрактные классы.

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

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

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

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

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


R>>>>>Контейнеры стандартной библиотеки все ссылки возвращают из operator[].
R>>>>>И с динамическим полиморфизмом тут проблем не будет.

А>>>>-1
А>>>>В том числе из-за этого в контейнерах стандартной библиотеки полно проблем с полиморфизмом, начиная с того, что хранить в них можно лишь указатели на абстрактные классы.

R>>>-1

R>>>Что хранить и что возвращать — это разные вещи. Тем более, что есть vector<shared_ptr<IBase> > и ptr_vector. И никаких проблем с тем, что возвращается ссылка.

А>>-1
А>>shared_ptr — это не STL, читай внимательнее и не сбивай молодежь


R>А кто говорил, что shared_ptr относится к STL?
R>Кстати, я вообще ни слова не говорил про STL. И STL меня вообще мало волнует.

Речь шла об STL с самого начала, сам же написал про стандартную библиотеку.
Не понято тогда, с чем ты не согласился, и как workaround НЕ из STL может служить аргументом в разговоре о проблемах при использовании контейнеров STL? Не говоря о том, что в приведенном тобой примере, в контейнере хранятся не объекты-наследники абстрактных классов, а экземпляры вполне конкретного класса shared_ptr.

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


R>А кто сказал, что shared_ptr это абстрактный класс?

R>Кстати твой тезис "хранить в них можно лишь указатели на абстрактные классы" неправильный. Вообще не понятно, каким боком к обсуждаемому вопросу притесались абстрактные классы.

Если shared_ptr не абстрактный класс, то твой пример ничего не доказывает

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

" Аноним " <0@users.rsdn.ru> сообщил/сообщила в новостях следующее: news:1791477@news.rsdn.ru...
> В том числе из-за этого в контейнерах стандартной библиотеки полно проблем с полиморфизмом...

О каких проблемах идет речь? Можно пример, полно не нужно, хотя бы один?

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

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

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


R>>А кто сказал, что shared_ptr это абстрактный класс?

R>>Кстати твой тезис "хранить в них можно лишь указатели на абстрактные классы" неправильный. Вообще не понятно, каким боком к обсуждаемому вопросу притесались абстрактные классы.

А>Если shared_ptr не абстрактный класс, то твой пример ничего не доказывает

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


Я написал только, что то, что operator[] у контейнеров возвращает ссылку, не создаёт проблем с использованием полиморфизма, т.к. ссылка и указатель с т.з. полиморфизма равнозначны.

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

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

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

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

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

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


R>>>>>>Контейнеры стандартной библиотеки все ссылки возвращают из operator[].
R>>>>>>И с динамическим полиморфизмом тут проблем не будет.

А>>>>>-1
А>>>>>В том числе из-за этого в контейнерах стандартной библиотеки полно проблем с полиморфизмом, начиная с того, что хранить в них можно лишь указатели на абстрактные классы.

R>>>>-1

R>>>>Что хранить и что возвращать — это разные вещи. Тем более, что есть vector<shared_ptr<IBase> > и ptr_vector. И никаких проблем с тем, что возвращается ссылка.

А>>>-1
А>>>shared_ptr — это не STL, читай внимательнее и не сбивай молодежь


R>>А кто говорил, что shared_ptr относится к STL?
R>>Кстати, я вообще ни слова не говорил про STL. И STL меня вообще мало волнует.

А>Речь шла об STL с самого начала, сам же написал про стандартную библиотеку.
А>Не понято тогда, с чем ты не согласился, и как workaround НЕ из STL может служить аргументом в разговоре о проблемах при использовании контейнеров STL? Не говоря о том, что в приведенном тобой примере, в контейнере хранятся не объекты-наследники абстрактных классов, а экземпляры вполне конкретного класса shared_ptr.


здесь

Автор: remark
Дата: 19.03.06

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


R>" Аноним " <0@users.rsdn.ru> сообщил/сообщила в новостях следующее: news:1791477@news.rsdn.ru...
>> В том числе из-за этого в контейнерах стандартной библиотеки полно проблем с полиморфизмом...

R>О каких проблемах идет речь? Можно пример, полно не нужно, хотя бы один?

Этот один пример обсуждаем уже очень долго И примера этого предостаточно, чтобы сказать, что стандартные контейнеры и полиморфизм — вещи сложно применяемые вместе (разве что с помощью буста )
Другие примеры проблем могу назвать, но наверное их нельзя назвать проблемами полиморфизма. Я имею ввиду многочисленные требования к типам, которые можно хранить в стандартных контейнерах (copyconstructible, assignable), это иногда очень неудобно.

>>...начиная с того, что хранить в них можно лишь указатели на абстрактные классы.
R>В стандартных контейнерах можно хранить любые указатели: на скалярные и пользовательские типы, полиморфные и неполиморфные, тоже не понятно о чем речь. Ниже по ветке почитал — ясности не добавилось.

тут имелось ввиду "лишь указатели на абстрактные классы, а не экземпляры их конкретных реализаций". Из обсуждения это должно было быть предельно понятно

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

А>Этот один пример обсуждаем уже очень долго И примера этого предостаточно, чтобы сказать, что стандартные контейнеры и полиморфизм — вещи сложно применяемые вместе (разве что с помощью буста )
А>Другие примеры проблем могу назвать, но наверное их нельзя назвать проблемами полиморфизма. Я имею ввиду многочисленные требования к типам, которые можно хранить в стандартных контейнерах (copyconstructible, assignable), это иногда очень неудобно.


Если позволите дальнейший оффтопик, то рискну заметить, что проблема ограничения хранимых типов до copyconstructible и assignable фактически обрезает пополам область применимости стандартных контейнеров для хранения в них объектов-сущностей бизнес-логики. Зачастую для них копируемость невозможна по смыслу.

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

R>Я написал только, что то, что operator[] у контейнеров возвращает ссылку, не создаёт проблем с использованием полиморфизма, т.к. ссылка и указатель с т.з. полиморфизма равнозначны.

Если только в этом смысле, то согласен, проблем нету.

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

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

R>>Я написал только, что то, что operator[] у контейнеров возвращает ссылку, не создаёт проблем с использованием полиморфизма, т.к. ссылка и указатель с т.з. полиморфизма равнозначны.

А>Если только в этом смысле, то согласен, проблем нету.
А>


В исходном-то сообщении автор спрашивал, что надо возвращать "ссылку или указатель на абстрактный класс".
Из стандартных контейнеров можно разве что ссылку на указатель на абстрактный класс получить (ссылку на абстрактный класс ну никак не получить), так что пример operator[] из STL не годится как довод в пользу ссылки, а не указателя.