Так его разтак... Гладко было на бумаге. :-E
Попробовал внедрить это дело в реальном проекте:


И что получаем? Конструкции вида foo[ i].bar() не работают — в классе access_operator нет метода bar. И языковых средств, позволяющих объяснить компилятору, что в таком случае нужно преобразовывать его в val_tp — тоже нет: operator. не перегружается.

А если пару таких контейнеров вложить друг в друга, выяснится, что foo[ i][ j] тоже не работает...

А посему — вопрос снова в силе: Можно ли реализовать subj так, чтобы при этом ничего не отваливалось?

В любой ситуации, когда мы не можем прочитать/записать объект напрямую, а должны что-то еще с ним сделать. Если он shared, нужно делать глубокое копирование перед изменением, если он хранится в где-то в сериализованном виде — его нужно "разархивировать". А может вообще никакого объекта нет и мы его создаем налету... Вариантов может быть много.


Спасибо, только там примерно то же самое, что и у меня, разве что более развернуто... Похоже, это единственный вменяемый способ реализовать такое в этом языке. :-/

Вообще, как я понял, проблема в том, что вызов метода — это не та операция, которую можно описать в терминах сеттеров/геттеров. Нужно добавить в интерфейс контейнера метод modify_item, возвращающий неконстантную ссылку. И юзать в этой ситуации именно его. А раз operator. не перегружается, придется вместо него юзать operator->. Криво, но, видимо, делать нечего...

Я бы сделал как минимум 2е версии класса - одну для простых объектов, вторую для массивов, с переопределённым operator[].
В этом случае запись foo[ i][ j] как раз канает.
Для доступа к членам - перегрузка operator* и operator->.

Так что получается 4 класса: для простых значений (int, char, float...), для массивов простых значений, для сложных значений (структуры, классы), для массивов сложных значений.

Хотя вопрос остаётся - зачем всё это громоздить, если есть get_item, set_item?
И кроме того, кроме индексации есть итераторы - может в их сторону стоит посмотреть? :-)

P.S. В принципе, вместо 4х отдельных шаблонов, всё это можно реализовать в одном конечном шаблоне используя type_traits и enable_if.

Ну конечно, это "синтаксический сахар", как и любая другая перегрузка операторов.
И разумеется, без него можно обойтись. Но с ним удобнее.


Ммм... Или я не врубаюсь, или тут написано про что-то сильно другое.
У меня operator* отлично работает (gcc 3.4.5 и msvc 8, борланд с ваткомом пролетают — туда им и дорога) без перегрузки. С простыми значениями и их массивами никаких проблем нет. С указателями на классы тоже. Проблемы с вызовом методов классов имеются, но лечатся перегрузкой operator-> — и здесь действительно приходится писать специализацию для указателей, потому что иначе эта перегрузка их ломает.

Проблема только с классами, в которых переопределен operator[]. Переопределить его в общем случае проблематично, поскольку мы не знаем заранее тип его возвращаемого значения. Т.е. мы можем, допустим добавить в access_operator<cont_tp,key_tp,val_tp> такой метод:
И если val_tp имеет operator[], возвращающий int& это будет работать. Но только в этом случае. А написать
мы уже не можем. Точнее — можем, но смысла это иметь не будет, потому что по возвращаемому значению темплайты не распознаются, и никуда оно автоматически подставляться не будет.

Собственно, в этом и есть проблема. Если есть идеи, как заставить компилятор распознать это самое возвращаемое значение — буду рад их услышать...

P.S. В новой версии стандарта, 0х которая, для таких вещей, кажется, есть ключевое слово auto. Но оно еще когда будет...

Блин.... йя идиотъ... Достаточно потребовать, чтобы в контейнере был определен value_type с помощью typedef...
Остается, конечно, случай, когда вложенный контейнер "чужой". И вот для этого, как раз, и пригодятся извраты в стиле упомянутого auto_cast. Но это уже экзотика...