1 / 1 / 0
Регистрация: 08.02.2012
Сообщений: 16
|
||||||||||||||||
1 | ||||||||||||||||
"Двойной" доступ к переменным класса29.11.2012, 17:40. Показов 1130. Ответов 17
Метки нет (Все метки)
Господа, прошу совета в изложенной ниже ситуации. Часто мне встречается в различных вариациях, поэтому есть потребность в изящном решении. Итак, есть, допустим, такой класс:
В голову приходит только один вариант - изначально держать данные в виде контейнера переменных типа UniformType, а в соответсвующих get-ах set-ах конвертировать данные к(из) соответствующему типу, но это как-то не айс. Заранее спасибо.
1
|
29.11.2012, 17:40 | |
Ответы с готовыми решениями:
17
Доступ к переменным класса Доступ к переменным базового класса при наследовании Как получить доступ к переменным одного класса из методов другого Доступ к переменным класса |
1 / 1 / 0
Регистрация: 08.02.2012
Сообщений: 16
|
||||||
30.11.2012, 12:59 [ТС] | 3 | |||||
Тоже думал уже.
Получается тогда так:
А тип переменной-указателя мы как раз и потеряем при записи его в ptrArray. Т.е. перед разыменовыванием указателя нужно будет сделать cast к соответствующем типу, а тип-то мы и не знаем... UPD: Добавить в UniformType конструктор UniformType(void*) тоже не вариант, т.к. внутри реализации он все равно должен помнить тип переменной для корректной обратной конвертации.
0
|
576 / 559 / 47
Регистрация: 16.12.2011
Сообщений: 1,389
|
|||||||||||
30.11.2012, 13:18 | 4 | ||||||||||
А почему бы метод
UniformType можно вообще шаблонным классом сделать
0
|
46 / 46 / 4
Регистрация: 08.12.2010
Сообщений: 161
|
|
30.11.2012, 13:31 | 5 |
как то читал о "двойной передаче" где компилятор определял какой тип при помощи операторов, и я думаю
Джеф Элдер прекрасно описал данный способ в С++ Библиотека Программиста. Где все возлагается на операторы. Но придется делать абстрактный базовый, и при большом количестве типов будет много операторов, оочень много операторов.
0
|
1 / 1 / 0
Регистрация: 08.02.2012
Сообщений: 16
|
|||||||||||
30.11.2012, 13:36 [ТС] | 6 | ||||||||||
I.M., согласен, решение проблемы, тоже рассматривалось.
Только методов
Тогда возникает компромисс - или вдвое увеличивается количество методов, или потом где мне нужен "родной" тип делать
dederkay, спасибо, почитаю на досуге. Правда, здесь это едва будет уместно - не такая уж и глобальная проблема в конце концов Можно и switch'ами обойтись, но уж больно не хочется
0
|
46 / 46 / 4
Регистрация: 08.12.2010
Сообщений: 161
|
||||||
02.12.2012, 18:42 | 7 | |||||
доброго, меня вот что интересует нельзя ли использовать
0
|
576 / 559 / 47
Регистрация: 16.12.2011
Сообщений: 1,389
|
|
02.12.2012, 19:36 | 8 |
dederkay, "для данного случая" - для какого? auto позволяет программисту не писать длинные типы данных, но auto заменяется на них во время компиляции. Иначе говоря типы должны быть известны во время компиляции.
0
|
46 / 46 / 4
Регистрация: 08.12.2010
Сообщений: 161
|
|
02.12.2012, 21:39 | 9 |
да вы правы, тут ведь внешний модуль, как то не досмотрел, извините. Да прочитал This type is easily determined procedurally by the compiler as part of its semantic analysis duties. Тупанул(
0
|
576 / 559 / 47
Регистрация: 16.12.2011
Сообщений: 1,389
|
|
02.12.2012, 22:09 | 10 |
scriptus, а как вообще вся эта система должна работать?
представим, что у вас есть клевый get метод в виде оператора [], возвращающий нужное поле с данными в виде класса UniformType. Что дальше? как вы хотите дальше работать с этим классом? как вы узнаете, что за тип данных внутри?
0
|
1 / 1 / 0
Регистрация: 08.02.2012
Сообщений: 16
|
||||||
03.12.2012, 11:39 [ТС] | 11 | |||||
I.M., конкретно сейчас все эти танцы нужны для third-party модуля, который понимает входные данные только в формате UniformType. Модуль закрытый и все что мне доступно - конструкторы UniformType для классов, с которыми работает система в целом (а их много). "Родные" же типы данных нужны для корректной работы моей части системы.
Вообще изначально это проблема плохой проработки интерфейса стороннего модуля (имхо). Другой пример (навскидку) из Qt - класс QAbstractItemModel (и наследуемые от него) - модель данных для qt'шной парадигмы Model-View (разновидность классической MVC). Там есть такая штука:
В Qt же такой интерфейс используется для взаимодействия с виджетами (QListView, QTableView и т.п.) для отображения данных модели. Добавлено через 33 минуты Сорри, не ответил на вопрос. Дальше с преобразованным типом работает сторонний модуль, как и что там - хз. Судя по доступному заголовочнику могу предположить, что UniformType нужен для корректного хранения данных в некоторой специфичной железке. Как конвертируется назад - тоже загадка. Все, что я могу сделать - а) построить UnifromType из поддерживаемого им типа данных, б) конвертнуть назад в любой другой поддерживаемый тип и посмотреть на bool& ok. Есть подозрение, что в конструкторе просто проставляется определенный флаг, который запоминает исходный тип данных и в дальнейшем определяет, во что можно конвертировать UniformType обратно.
0
|
Делаю внезапно и красиво
1313 / 1228 / 72
Регистрация: 22.03.2011
Сообщений: 3,744
|
|
03.12.2012, 13:09 | 12 |
boost.variant или полиморфизм.
0
|
576 / 559 / 47
Регистрация: 16.12.2011
Сообщений: 1,389
|
|
03.12.2012, 13:12 | 13 |
scriptus, т.е. насколько я понимаю, менять класс UniformType нельзя? но гарантируется, что в нем есть все нужные конструкторы для ваших типов?
0
|
1 / 1 / 0
Регистрация: 08.02.2012
Сообщений: 16
|
|
03.12.2012, 17:04 [ТС] | 14 |
Deviaphan, думал. Не вижу существенных преимуществ, ибо уже есть UniformType, обладающий в этом конкретном случае схожим функционалом. Имхо, только геморрой приобретается, т.к. компилятор в этом случае не выполняет проверку типа при обратном преобразовании. Это я про boost::variant.
Может, я что-то не понимаю и Вы объясните свою позицию чуть подробнее? I.M., верно. И первое, и второе.
0
|
Делаю внезапно и красиво
1313 / 1228 / 72
Регистрация: 22.03.2011
Сообщений: 3,744
|
|
03.12.2012, 17:43 | 15 |
Аргументирую: ты хочешь реализовать переключение типов, а в ООП переключение типов - зло. буст.вариант лучше тем, что его сотни тысяч раз использовали и отлаживали.
Вопрос в другом: зачем тебе индексированный доступ к объектам РАЗНОГО типа. Ты не сможешь работать с ними в цикле, значит, тебе не нужен индексированный доступ. Если же ты хочешь однообразно работать с ними в цикле, то у них должен быть общий предок и решение твоей проблемы - полиморфизм.
0
|
1 / 1 / 0
Регистрация: 08.02.2012
Сообщений: 16
|
|
03.12.2012, 18:11 [ТС] | 16 |
Deviaphan, аргумент принят. Хотя это не умаляет того, что в compile-time я не поймаю ошибку неверной конверсии variant'а к нужному мне типу. Как в принципе и в случае использования контейнера из UniformType. Но это неизбежно.
Ответ на вопрос: см. первый пост. Индексированный доступ нужен не по родному типу, а по преобразованному (UniformType). Если бы его не было изначально, то вопрос с boost::variant или boost::any не стоял бы. А использовать два контейнера со схожим функционалом одновременно как-то не хочется. Тем более, что без UniformType все равно не обойтись. По поводу полиморфизма. Увы, в данном случае все классы существуют и определенны, иначе бы я все типы данных наследовал от UniformType изначально и данного вопроса бы не стояло.
0
|
Делаю внезапно и красиво
1313 / 1228 / 72
Регистрация: 22.03.2011
Сообщений: 3,744
|
|||||||||||
03.12.2012, 19:16 | 17 | ||||||||||
Т.е. ты хочешь (например) получить элемент типа UniformType, расположенного по индексу 1 и вызвать для него метод toTypeB и, чтобы при попытке вызова других методов происходила ошибка, желательно времени компиляции? Теперь я правильно тебя понял?
Если сделать индексацию через параметр шаблона, то можно и в compile-time реализовать. В 11 версии, возможно, и без шаблонов можно будет, если обозначить функцию как константу времени компиляции, но в этом вопросе я не компетентен, так что сомневаюсь. В runtime можно реализовать с использованием RTTI. Добавлено через 1 минуту Если не секрет, что за внешний модуль? Хочется знать, чтобы держаться от этого разработчика подальше.) Добавлено через 5 минут И ещё смущают вот эти методы:
Добавлено через 24 минуты Невинная фантазия на данную тему. Только тебе не подойдёт, скорее всего, потому что состав объектов другой получился
1
|
1 / 1 / 0
Регистрация: 08.02.2012
Сообщений: 16
|
||||||
03.12.2012, 19:33 [ТС] | 18 | |||||
В целом - да, верно. Только вот методы toTypeX() мне вообще хотелось бы не использовать (не доверяю я им что-то).
Поэтому (см. первый пост) хотелось бы юзать родные типы. Но вот чтобы сторонний модуль мог со мной работать, ему нужен поиндексный доступ к переменным класса и причем непременно в виде UniformType.
0
|
03.12.2012, 19:33 | |
03.12.2012, 19:33 | |
Помогаю со студенческими работами здесь
18
Доступ к переменным внутри класса Доступ к переменным другого класса Доступ к классам и переменным класса Ограниченный доступ к переменным класса Доступ к переменным и функциям класса из потока Доступ к переменным класса из обработчика события KeyPress Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |