Есть вот такой класс.

Нужно используя оператор [] вернуть ссылку на объект GLoad, хранящийся в map. Моя реализация не работает, компилятор говорит, что возвращаемый объект является не указателем на GLoad, а самим объектом GLoad. Мне это не подходит, потому что GLoad - абстрактный класс, который не может иметь объектов.

реализация приведенная выше ? ошибки в ней нет.. 
сообщение компилятора в студию.. 


у Вас в коде возвращается указатель.. Вам нужна  там ссылка ?
тогда меняете на ссылку и добавляете разыменнование к секонду..

Добавлено через 1 минуту и 7 секунд

маловероятно, что Вам необходимо делать итератор членном.. лучше оставить локальной переменной.. 

Вот пример использования

На комментированной строке компилятор выдает сообщение

Только сейчас обратил внимание, что оператор [] возвращает не GLoad, а вообще GLoads.



Объявил итератор членом из тех соображений, что его очень часто нужно будет использовать в функциях класса. Каждый раз создавать новый итератор может будет накладно?... не знаю

Покажите декларацию Loads. Очень похоже что это не объект класса GLoads, а массив объектов GLoads.

(кстати другой Loads в мемберах у вас уже есть. вы не путаетесь ?) 

это строка не соответствует коду приведенному в первом посту..

Добавлено через 1 минуту и 58 секунд

не оптимизируйте раньше времени.. тем более если не знаете о расходах этого участка.. сделаете только хуже.. 

Добавлено через 1 минуту и 51 секунду

Где ж она не соответсвует?


А чем это может быть плохо?

и зачем создавать свой тип (Gloads) ? не легче ли просто затайпдефить нужный стандартный контейнер ?

Добавлено через 55 секунд
чем меньше ненужных сущностей, тем меньше шансов у ошибок..

Нет. Ведь класс GLoads будет более функциональным... пока тестирую работу внутри него с мэпом. Да и синтаксис работы с мэпом трудночитаемый для использования его в главном коде.

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

Добавлено через 5 минут и 40 секунд

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


хм.. опять из крайности в крайность..у Вас получается, что если нет Gloads, то главный код становится трудночитаемым..

Добавлено через 7 минут и 53 секунды

тем что, Gloads не возвращает Gloads в оперaторе [], a значит ошибка в другом месте..

Добавлено через 8 минут и 43 секунды
а вот и причина ошибки:

вы оператор[] применяете к указателю.. 

Реализовал доступ к указателям на GLoad не через оператор [], а посредством простой функции

И теперь этот код работает как надо

Интересно, почему ж не работает оператор? С ним запись более удобная.

потому что надо вначале разыменовать указатель.. also :
 

Точно. Запись получается не сильно красивей чем через функцию)

 а зачем контейнер по указателю хранить то ? 
да и это все :

выглядит очень подозрительно.. не говоря о том, что являются глобальными переменными.. 

Действительно) Нужды особой и нет. Разве что способ обращения к функциям через -> выглядит более удобным в свете наиболее частого применения.


Это тестовое приложение для отладки классов. Хотя в реальном приложении эти объекты скорее всего тоже будут глобальными. Дело в том, что данные, которые в них содержатся, могут быть использованы в разное время работы пользователя с приложением. Всякий раз производить массу операций по созданию этих объектов будет накладным. Проще это сделать один раз, сохранить в глобальной переменной и затем использовать в любое время работы приложения. Есть способ лучше решать подобную задачу? Так я бы тоже был не против в локальные переменные это все закинуть, хотя бы из соображений экономии оперативной памяти.

однозначно..  три нижние вобще непонятно зачем нужны.. а Loads просто сделайте членом класса Form..
и динамическое создание ему вообще не нужно.. т.е. указатель не нужен..