плюсы...

Думается только чисто виртуальной.

и определять в каждом ребенке

это понятно :-)
с какой сигнатурой ?

ИМХО никак, базовый класс должен быть шаблоном (возвращаемый тип функции должон быть шаблонным же), или заводить функцию уже в дочерних.

да хоть тупо At(int index); или индексирование перегрузить.

возвращаемый тип T канешн

>или заводить функцию уже в дочерних.

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

>возвращаемый тип T канешн

дык в базовом он не известен

а чем плох шаблоный базовый класс?

в моем случае он не сможет быть базовым для всех , ибо зависит от Т

Сделай обертку для классов.

ты ведь понимаешь что base<double> и base<int> - абсолютно разные классы ?

ну как вариант создать отдельный шаблонный интерфеис Indexable и множественное наследование...

а вот это идея ;-)

> base<double> и base<int>

base - не шаблон в приведенном коде

в ответ на
>а чем плох шаблоный базовый класс?

>как реализовать виртуальную функцию или что-нибудь аналогичное в классе base для доступа к values.

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

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

в ООП сила, брат.

а зачем это вообще нужно ? зачем хранить вектор в параметризованном потомке, а доступ получать через родителя ? что-то тут лишнее - либо наследование, либо параметризация :)

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

>в ООП сила, брат

есть мнение, что она не в ООП, а в наличии мозга :) независимо от ООП, шаблонов, и какого-либо иного подхода

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

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

плюсы очень даж конфетка =) но по моем с архитектурой деиствительн что т не так =(

>а зачем это вообще нужно ? зачем хранить вектор в параметризованном потомке, а доступ получать через родителя ? что-то тут лишнее - либо наследование, либо параметризация :)

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

>Я знаю что плюсы не конфетка , но твое "нытье" в каждом топике про них начинает слегка нервировать.

А меня плюсо@бы нервируют, так что мы квиты.

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

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

>А меня плюсо@бы нервируют, так что мы квиты

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

чем неприязнь-то вызвана ? я понимаю там, фанатиков не любить - оно само собой,- но вот чтобы именно избирательно всех программистов на плюсах - как-то странно

>а зачем это вообще нужно ? зачем хранить вектор в параметризованном >потомке, а доступ получать через родителя ? что-то тут лишнее - либо >наследование, либо параметризация :)

Родитель мне нужен только для того , чтобы хранить все елементы в одном контеинере .
Моя задача , в общих чертах
Есть канал , в котором я сохраняю информацию
template<class T>
class channel{
string name,units;
container<T> values;
}

В другом классе запланированa группа каналов и специально для этого я ввел базовый класс , хранить как указатели на базовыи класс .
Осталось только придумать как добраться до values

Ну что диаппазон типов так велик что шаблоны деитсвительно необходимы?

>А меня плюсо@бы нервируют, так что мы квиты.

Кстати что это ?
плюсоыб ? плюсобб ? плюсовб ?

>>А меня плюсо@бы нервируют, так что мы квиты

>оффтоп, но был уверен что это именно ты меня игноришь. оказалось нет, чему однако рад :)

Я не Мицголю. Реально меня достали только iRunix (как страшно жить без Photoshop CS DF MF 2050 и Автокад 100 Супер Пупер Дупел Интерпрайз) и haywire (долбанутый DRM-щик)

>чем неприязнь-то вызвана ? я понимаю там, фанатиков не любить - оно само собой,- но вот чтобы именно избирательно всех программистов на плюсах - как-то странно

Апломба много, а проекты на плюсах как правило очень плохи. Сочиняю патч для linuxdcpp чтобы с русским не косячил - код кошмарен. В Strong DC аналогично.

> Кстати что это ? плюсоыб ? плюсобб ? плюсовб ?

плюсорабы

>Родитель мне нужен только для того , чтобы хранить все елементы в одном контеинере

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

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

если от идеи такой архитектуры ты отказываться не хочешь, то тебя ждёт либо обёртка вроде boost.any вместо указателя на интерфейс; либо извращения, наблюдаемые время от времени на comp.lang.c++.moderated - с гомогенным хранением шаблонов в контейнерах

>>плюсо@бы >плюсоыб ? плюсобб ? плюсовб ?

плюсопёсик бы :)

base* b = ...;
static_cast<child<type>* >(b).values

>base* b = ...; static_cast<child<type>* >(b).values

жестоко :)

> В другом классе запланированa группа каналов и специально для этого я ввел базовый класс , хранить как указатели на базовыи класс . Осталось только придумать как добраться до values

Либо value в родителя, либо виртуальный метода в потомке, остальное - бред.

про boost::any я с самого начала думал , но хотелось избежать явного приведения , так как придётся сначала запрашивать что-то вроде id ,
потом приводить .

> Сочиняю патч для linuxdcpp чтобы с русским не косячил - код кошмарен

Какой плохой сиплюплюс .

>про boost::any я с самого начала думал , но хотелось избежать явного приведения , так как придётся сначала запрашивать что-то вроде id , потом приводить.

Любое решение сведется либо к снижению перформанса либо к раздуванию зависимостей. Например, если взять паттерн Визитор который позволяет добавлять полиморфные функции извне, то Ациклический динамический Визитор будет иметь перформанс на уровне boost::any, а статический Визитор приведет к раздуванию зависимостей.

>>Сочиняю патч для linuxdcpp чтобы с русским не косячил - код кошмарен

>Какой плохой сиплюплюс.

На самом деле, виноваты там не авторы а сиплюсплюс, так как высер при всей его уродливости написан интуитивно, т.е авторы linuxdcpp видимо всегда применяют самый простой подход который будет работать. В случае с С++ это приводит к ужасному коду.

А что понимается под "доступом" к values? Если, допустим, хотим взять i-й элемент, то будет разный тип возвращаемого значения для разного T. И как это можно сделать в базовом классе, в котором T принципиально отсутствует? И, кстати, что первично - скорость работы или читабельность кода?

>А что понимается под "доступом" к values? Если, допустим, хотим взять i-й элемент, то будет разный тип возвращаемого значения для разного T. И как это можно сделать в базовом классе, в котором T принципиально отсутствует?

Сделать в базовом классе метод virtual void inviteVisitor(Visitor* visitor) = 0;.

У самого Visitor будут методы типа virtual void visitIntArray(int* arr, std::size_t lobound, std::size_t hibound) = 0, virtual void visitDoubleArray(double* arr, std::size_t lobound, std::size_t hibound) и пр.

Реализация inviteVisitor(...) в потомке Base будет вызывать один из этих методов. Клиент кода пишет конкретную реализацию Visitor и передает ее методу inviteVisitor.

Это классический Визитор, в котором для каждого потомка Base надо добавлять витуальный метод в класс Visitor. При этом все ABI будет конечно ломаться. Есть еще и ациклический визитор, в котором диспатчинг происходит автоматом с помощью RTTI (у Александреску).

Круто, но это не единственный вариант. Например, если все T имеют общего предка, то это может помочь. Поэтому хочется всё же услышать ответ автора темы. А если уж говорить о вкусах, то я бы предпочёл кастить. Может быть, это более опасно, но зато код будет существенно компактнее, понятнее, и, скорее всего, существенно быстрее.

>А если уж говорить о вкусах, то я бы предпочёл кастить. Может быть, это более опасно, но зато код будет существенно компактнее, понятнее, и, скорее всего, существенно быстрее.

Свитч по метке типа можно и в Си огранизовать. Нафиг тогда тебе наследование и вуртуальные функции?

> Свитч по метке типа можно и в Си огранизовать. Нафиг тогда тебе наследование и вуртуальные функции?

В данном случае - не нафиг. Я же не обязан ими везде пользоваться (даже если это будет написано в 10 учебниках). Может быть, это - как раз тот случай, когда не надо. И, главное, что нужно-то оно не мне, а kitov-у. Т.е., без него вряд ли удастся решить, как делать будет лучше всего.