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

Нужно используя оператор [] вернуть ссылку на объект 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..
и динамическое создание ему вообще не нужно.. т.е. указатель не нужен.. 

Вы так говорите только потому что не знаете что это за объекты и для чего они собственно нужны.


А чем глобальная переменная отличается от члена класса Form? В этом есть, конечно, определенное удобство (легкий доступ ко всем элементам формы), но проблемы выделения памяти не решает. Какая разница где будет память резервироваться - в глобальной переменной или в переменной формы...


Опять же, вы просто не знаете какую задачу решаю, а уже делаете выводы) Объектов класса GLoads может быть один, а может быть десять, а может и сто. И как тут быть без динамического выделения памяти?

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

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


std::vector для этого 


есть только одно объяснение - типо оптимизация.. которое в дальнейшем выйдет боком..

Предлагаете хранить в векторе сами объекты?) Если объектов будет 100 и мне понадобится передать его в функцию в качестве аргументов, то как будет быстрее - при хранении указателей или самих объектов?

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

но еще раз повторю.. забудьте про скорость.. тут Вы ничего существенного не выйграете.. а вот читабельность загубите.. сами потом не найдете что к чему.. 

Для меня это один из критериев, по которому я оцениваю хороша программа или плоха. Если бы у меня было две программы, скажем, обычного калькулятора, один из которых производит вычисления мгновенно, а второй с задержкой в 5 секунд, то я ничтоже сумняшеся куплю первую программу) 
Читабельность кода тоже важна, а указатели код практически не портят. Во всяком случае для меня отличи незначительны. Мне даже удобнее работать с ->, чем с точкой. Индивидуальное восприятие.
Ну а что касается вектора, который не приспособен для хранения указателей... справляется он с этим неплохо) Да к тому же абстрактные классы не могут иметь экземпляров, посему кроме как используя указатели и не обойтись.
Вобщем это уже больше вопросы философии программирования. Кому-то по душе одно, кому-то другое, исключая объективные ситуации, когда правильное решение существует в единственном числе. Но если вы мне скажете, что серьезные программисты не используют вектора для для хранения указателей, то я очень удивлюсь, потому как во многих книжках по С++ эти самые серьезные программисты приводят именно такие примеры.

а значит какой бы выбрали калькулятор , тот который решает за секунду ? или тот который решает примерно за секунду, но удобный 

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

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

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

1. а ссылки на что ?
2. GLoads тоже абстрактный ?!

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

особенно удобна работа с операторами через указатель, в чем Вы уже успели убедиться..
 

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

понятно,  утечки памяти Вас не беспокоят 

Случаи бывают разные. Может так оказаться, что я выберу более быструю программу, но менее удобную. Но я не об этом говорю. Я говорю о том, что скорость - это важный параметр. Когда-то более важный, когда-то менее важный, но уж никак не абсолютно ненужный.


Ну вам портят, а мне - нет   


std::vector<GLoad&> Loads? (GLoad - абстрактный класс)


Нет, не абстрактный. Преимущества работы с указателями (преимущества для меня) я уже описал выше)

используют , но не для хранения объектов через указатели.. 

Хотите пример?

нет..я не про эти указатели говорил.. 
тут нужeн враппер например shared_ptr..

Добавлено @ 19:55

ну приводите, посмотрим чем Ваш пример особенный 

Добавлено @ 19:59
наверно Вы не до конца поняли 


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

Это сообщение отредактировал(а) mes - 27.2.2011, 20:00

А, ну так понятное дело. 

Вот пример из книги Р.Лафоре "Объектно-ориентированное программирование" 4-е издание:



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

поменяйте comparetenants, чтоб вместо простого сравнения указателей сравнивала бы например по имени.. 
потенциальная утечка обеспечена 

ну а насчет итератора, как и другого кода (специально посмотрел в поиске) увы.. оставляет желать лучшего.. уровень 90х годов.. 

Не совсем понял о чем вы... compareTenants сравнивает жильцов по нужному параметру, будь-то имя, фамилия или стоимость аренды, не суть важно. Важно то, что операция сравнения никак не может привести к утечке памяти. Там ведь не происходит удаления, добавления или перенаправления указателей. Просто считывается информация и меняются местами указатели.


Мне бы достичь уровня Р.Лафоре - я был бы безмерно счастлив, несмотря на то что, это уровень 90-ых годов   Вообще отличная книга. Простая и доступная. Издание, кстати, 2004 года.

Это сообщение отредактировал(а) Нитонисе - 27.2.2011, 21:10

в сет добавляются только не совпадающие указатели.. и если проверяться будет,  например, по имени,
то при попытки добавить новосозданного объекта с именем, который уже имеется в списке, последний будет "потерян".. 


токое ощущение что все таки в 95м- 96м.. а в 2004 может просто переиздалась... сейчас погуглю.. 

Ваш спор превращается в религиозный. Можно опрос организовать - и думаю будет примерно 40 на 40 процентов- тех кто принципиально не использует в векторе указатели и те кто принципиально использует только указатели.

А оставшиеся 20 - делают и так и так в зависимости от задачи.

Но в процентаже могу конечно и ошибаться.

нда.. прошу "принципиальных" сразу исключить из опроса.. ибо на их мнение нельзя  ориентироваться..

Добавлено @ 21:48

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

поэтому в С++ разумно использовать именно его.. надеюсь в этом аспекте нет несогласных ? 

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

Это сообщение отредактировал(а) mes - 27.2.2011, 21:48

Обычно причина таких споров - как раз в разном предположении о том что является объектом. 
Я  много раз использовал указатели в векторах - так как мне удобнее читать  такой код, но для меня в объектом в таких случаях являлся именно список. И в его деструкторе я само собой убирал мусор. Таким образом вектор являлся частью моего объекта, как правило в защищенной зоне и я не беспокоился ни о каких утечках. Применение автоуказателей для такой вещи слишком накладно с моей точки зрения.

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

Как говорится - любое вещество может быть ядом и лекарством - все зависит от дозы. Многие не думая сразу создают вектор объектов string и радуются жизни до тех пор пока не попробуют отсортировать несколько миллионов строк, другие наоборот - создают навороты в виде указателей на структуры в которых всего три int поля...

Так что не думаю, что в таком споре кто-то выиграет, выигрывает просто здравый смысл.

Я лично запостил свое мнение в основном на эту фразу:


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

Ну а если во всем полагаться на те же автоуказатели и другие мусоросборщики, то скоро весь код будет состоять из оберток и автозачисток, а вот удобоваримая скорость будет отставать безнадежно. Во всем нужна мера. ИМХО.

если внимательно вчитаетесь в названную фразу :

то можно заметить, что речь шла не об указателях как таковых, а о хранении объектов, посредством сохранения указателя на них..
т.е. о политике владения через указатель.. 


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

Вот ссылка http://www.megaupload.com/?d=MG6587O2
Приведенный мной фрагмент находится на 776 странице (774 дежавюшная). Причем где-то в тексте автор как раз и писал о том, что указатели в контейнерах лучше применять из тех соображений, что нет нужды копировать сами объекты при передачи этих контейнеров в качестве аргументов в функции. Этим экономится время работы программы. Само собой разумеется, что если контейнер будет почти пустым, то с указателями можно не заморачиваться.

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

Поиск утечек дело противное, но и оно иногда нужное. А то видимо в том же майкрософте вот так все надеются на автоуказатели, а ведь их тоже люди пишут - в итоге утечек полно + тормоза полные.

Ну и коль мы в билдеровсеом форуме - поделюсь своей страшной тайной, мне намного больше нравится VCL-овский тип TList - гораздо больше чем STL-овский  vector. Он то как раз только указатели хранить и умеет. Почему больше нравится не знаю - он как-то человечнее что-ли. А скорость работы практически одинаковая.

ах да забыл.. гугль выдал, что первое издание датировано 98 годом.. 
что в принципе как раз соответствует ожиданиям.. 

Библия учит - не сотвори себе кумира. У меня есть очень древнее издание Страуструпа (одно из первых). Там многие примеры приведены достаточно сомнительные, но это никак не умаляет авторитет Страуструпа как и не делает его кумиром - человек все-таки. Лафоре - также, можно какие-то его подходы принять,  какие-то нет, но главное - он действительно помогает научиться, как и Страуструп. И если думать головой, то все будет нормально, а если не думать - то никакая автоматика не поможет, утечка начинается из головы программиста.

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

еще для избавления лишних копирований есть идеология CoW (CopyOnWrite) - которая копирует объект, только при внесении в него изменений..  в остальном фактически идет просто передача указателя.. некоторые реализации std::string реализованны с ее применением.. 

это я к тому, что автоматические политики хранения, дают фору ручным... 


Добавлено @ 22:59

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



Это сообщение отредактировал(а) mes - 27.2.2011, 23:03

Зато с вектором идет огромный набор собственных полезных функций и общих STL-алгоритмов. У TList тоже полезностей немало, но чисто умозрительно вектор значительно мощнее.

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

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

вряд ли приходят такие идеи для голых указателей, объекты для которых создаются "снаружи".. 

вот для заметки, (первое что нашел, но по теме) : 
http://blog.alno.name/ru/2008/05/using-boost-smart-pointers

Интересные указатели... это стандарт С++ или какая-то стороння разработка?

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



Это сообщение отредактировал(а) mes - 27.2.2011, 23:55

Я так понимаю она имеется в свободном доступе? И использование этих указателей нынче распространено?

http://www.boost.org
http://www.boost.org/doc/libs/1_46_0/libs/...r/smart_ptr.htm


угу, а с принятием нового стандарта еще все будет в стандартной библиотеке.. 

Так я с этого и начинал.
Не надо категорично говорить, что вектор не предназначен для хранения объектов через указатели, а надо обязательно использовать обертки в виде "умных" указателей. Без головы - можно и с умными напортачить, а с головой - в нужной ситуации и без них обойтись. При большом количестве объектов - умный указатель может замедлять работу, а при неправильном применении - можно и пару часов какой-нибудь идиотский баг поискать. Умный указатель - далеко не панацея, а в сочетании с вектором - тут уж фиг его знает как дело повернется. ИМХО.


Кто же спорит. Я же не сказал, что TList всегда вместо вектора использую - я сказал, что он мне больше нравится. Кстати функционал вектора сам по себе не такой уж и крутой - просто к нему удобно применять общие алгоритмы STL - а это действительно мощно. А так - для самых распространенных задач - сохранить список неких объектов, количество которых заранее неизвестно, отсортировать и что-то с ним еще сделать согласно бизнес-логике - TList вполне применим. Для более крутой математики с STL уже не поспоришь.

вектор действительно не предназначен для описанной в той цитате работы.. 


можно и обойтись, кто-то сказал иное ?


может и такое быть.. 


прошу пример, где я сказал обратное.. 

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

Предмет спора - ваше утверждение о неприменимости указателей в векторе, которое выглядело чересчур категоричным))

прошу не путать, не о неприменимости, а о не предназначении, в контексте владения объектом  

сравните хотя бы с тем же boost.ptr_vector 
http://www.boost.org/doc/libs/1_46_0/libs/..._container.html
или вот из гугля на русском :
http://blog.alno.name/ru/2009/04/using-boost-ptr-containers



Это сообщение отредактировал(а) mes - 28.2.2011, 09:37

Библиотека boost очень интересная, особенно математические функции, но чтобы освоить - понадобится уйма времени)

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

Как вернуть из функции ссылку на объект?
Допустим есть вектор структур:

Правильная запись функции, вовращающей некий элемент будет такой?

исключение..

Добавлено через 37 секунд

(Т&) - лишнее 

А кроме исключения? Я пока с ними плохо знаком. Вот в случае с возвращением указателей проще. Если не удается вернуть указатель на запрашиваемый объект - можно вернуть NULL. В вызывающей функции обрабатывается этот указатель и понятно - нашли мы то что искали или нет. Впринципе и нет никаких проблем работать с указателем, но интересно как тут быть при работе со ссылками.

Добавлено через 27 секунд

Точно? Ведь тогда возвращается сам объект.

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



А   возвращаемый параметр утверждает обратное   

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

грубо да..