"Invalid arguments" для метода шаблонного класса

Всем привет! Разбавлю немного форум практическим вопросом =), а то все вакансии да вакансии... 

К сожалению, дам просто ссылку на вопрос, так как не смог осилить в нормальном виде оформление: http://www.gamedev.ru/code/forum/?id=187290#preview

P.S. кстати, Витя, не смог из под линуха (Firefox) создать тему на форуме, просто не было элемента на форме куда тыкнуть для создания и в раздел "Программирование" лучше еще добавить ветку "Общее".

  1. //Всем привет! И сразу к делу:
  2.  
  3. template< class T >
  4. class MyTemplate
  5. public:
  6.     typedef const T & const_reference;
  7.  
  8.     void push&;const_reference value&;
  9.     &;
  10.  
  11.     &;
  12.     // etc.
  13.  
  14. //Это есть сам шаблонный класс. Теперь реализационный момент:
  15.  
  16. class MyClass &; /* etc. */ &;
  17. // ...
  18. MyTemplate< MyClass * > _myTemplate;
  19. // ...где-то в глубинах кода :)
  20. void MyMethod&;MyClass * myClass&;
  21.     _myTemplate.push&;myClass&;; // -- СМОТРЕТЬ ЗДЕСЬ

 

Последняя правка: пт, 21/03/2014 - 09:26
Submitted by MaxImuS on

Комментарии

С точки зраения компилятора передавать по константной ссылке указатель на обьект это нормально. С точки зрения IDE видимо нет Smile

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

Последняя правка: чт, 03/04/2014 - 02:20
Submitted by Relyer on

Саня, привет! Спасибо за коррекцию Smile

Там же в 6 и 10 посте я прихожу к выводу, что все таки ребята с eclipse что-то натупили. В этот день перед этим моментом я обновил среду. Ну вот и результат.

Submitted by MaxImuS on

Эклипс гонит однозначно -- у нас в движке аналогичный код без проблем билдится ICPP/MSVC/SNC/GCC с макс. варнингами на пяти платформах.

Submitted by BLK Dragon on

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

Последняя правка: ср, 26/03/2014 - 22:38
Submitted by MaxImuS on

Очень интересный код. Я хотел бы для себя уточнить несколько моментов на будущее.

Скажите плиз, а зачем вы в качестве шаблонного параметра передаете указатель? Мне просто любопытно.

 

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

Разве недостаточно в методы передавать объект по указателю или ссылке?

 

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

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

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

 

Не расскажете для чего вам понадобились такие шаблоны?

Submitted by AntonGB on

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

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

>> У вас же получается шаблон для типа указатель, и т.к. данными любого указателя является его адрес ( т.е. 4 байта для х86), то смысл неясен вообще.

А чего тут не понятно... Представь, что у тебя есть, например, объект текстуры, и он лежит, в каком-нибудь менеджере (просто в контейнере или где вам удобнее). Зачме нам иметь 40 экземпляров одного и того же объекта текстуры? Текстура одна, а кто захотел ей воспользоваться - взял указатель на данный объект (или ссылку, но тут все зависит от конкретной задачи), и работает с ним. 4 байта < 4 Мбайта как бы. Это что касается просто указателей.

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

Шаблон - это всего навсего инструмент. За примерами далеко ходить не нужно - stl-контейнеры, создовай списки из чего твоей душе угодно, хоть из интов, указателей или твоих собственных классов. Константный указатель позволяет не допустить того, что бы в него положили указатель на такой же объект, но другой. Логика вычислений то подразумевает, что ты вроде работаешь со старым объектом. На это и указывает само слово const. А защищать данные от из менений нет смысла в данном случаем, а на оборот к этому все и сделано. Например: есть игровая сцена, которая содержит объекты (кубики, цилиндры, или танк =)); для сцены этот объект уникален и, естественно, хранить 40 экземпляров объекта нет никакого смысла; допустим, эти объекты созданы на базе единого интерфейса - StaticObject и есть какой-то обработчик этих объектов на базовом уровне; на каждом кадре формируется список нужных таких объектов (по каким-то заданым критериям) для этого обработчика (в примере MyTemplate как раз и может являтся таким) и потом он просто может, банально, пробегать этот список и вызывать метод update для этих объектов; в конце список чистится. А теперь представь, что для такой задачи ты бы хранил в списке не указатель, а сам объект - каждый кадр создавался бы экземпляр объекта на базе оригинального (конструктор копирования), обрабатывался, а после этого стала бы еще задача, что измененные данные в объекте нужно еще вернуть в оригинал, а после уничтожить при очистке списка. Такие действия уже приводят к фрагментации памяти. Ведь проще то работать с указателем на объект...

Последняя правка: сб, 29/03/2014 - 05:12
Submitted by MaxImuS on

К вышесказанному могу только добавть, что работа с указателями требует осторожности. Приведу пример таких ошибок, которые делают новички (не раз встречался на практике): человек создает vector<TMyObject> и по ходу игры начинает заполнять этот вектор объектами, хотя ситуация такова, что он не знает изначально, сколько таких объектов он положит в вектор (что есть уже одна из ошибок по не знанию как работают stl-контейнеры); далее он начинает запоминать указатели на эти объекты где-то еще и работает с ними в дальнейшем; ну вот пришла пора добавлять 17й объект в вектор и пишет push(TMyObject) без задней мысли что произойдет на самом деле в этой строчке: контейнер увидит, что у него закончилось резервное место и ему нужно расширяться, он выделяет себе новый кусок памяти, равный старому + память под новый объект (на самом деле он резервирует немного больше памяти, что бы не пришлось после каждого push выделять новый кусок заново) и переносит в эту новую область данные из старой, а старую отдает системе обратно; к чему это привело? - конечно же, наши объекты уже лежат в памяти по новым указателям, а старые адреса, которые сохраняли где-то для работы, уже не валиды; ну вот пришло время вызвать какой-то метод у объекта по указателю, который в свою очередь указывает уже фиг знает куда  - следствие - игра падает и человек долго с умным лицом начинает искать в чем же ошибка.

Submitted by MaxImuS on
Quote:

Не расскажете для чего вам понадобились такие шаблоны?

Обана, я дожил до того что массив указателей считают экзотичекой конструкцией Smile

Элементарный пример: функция вида найдите_мне_всех_врагов_в_радиусе(расстояние) -- оно как раз типично выдаст массив указателей на акторов/ентитей.

И конечно же все "тяжелые" объекты типа текстур или акторов хранятся внутри подсистем в виде массива поинтеров (ну или хеш-таблички поинтеров).

Submitted by BLK Dragon on
BLK Dragon wrote:
Quote:

Не расскажете для чего вам понадобились такие шаблоны?

Обана, я дожил до того что массив указателей считают экзотичекой конструкцией Smile

Улыбнуло Smile

Submitted by AntonGB on

GameDev.by