@darkAngel

Пусть есть шаблон-структура.
И есть указатели на объекты:
Можно ли как-то завести общий указатель для них? т.е. чтоб этот указатель мог указывать и на A<int> и на A<float>?

Пробовал завести родителя (пусть parA) для struct A и создавал указатель этого типа и делал так:
Максимум что получилось, это вызвать конструктор через этот указатель:
Доступа же к полям не получил. Пробовал явно преобразовывать тип:
Вылазеет ошибка E2102 Cannot use template 'A<Data>' without specifying specialization parameters
Пробовал сделать родительский класс parA виртуальным и далее через виртуальные методы. Компилятор проглатывает, но ошибка уже на этапе выполнения (ошибка доступа к памяти).

Как быть?


p.s. нужно реализовать стек, элементы которого имеют поля разного типа, а union не охота использовать.

0

@ForEveR

darkAngel, boost::any))

1

@darkAngel

не доверяю я STL.
Сделал стек из union.

0

@Deviaphan

*саркастично* Молодец.

boost::any это не STL, это boost. Но ему тоже доверять не надо, ага.

*ещё более саркастично* Молодец.

3

@darkAngel

Евгений Ваганыч?

0

@ForEveR

darkAngel, не доверять библиотекам, написанным профессионалами по С++ - глупо.

0

@darkAngel

дело в перегрузке функционала + могут понадобиться нестандартные функции + свои структуры данных я могу подстраивать под свою задачу (например правильно расположить данные для SSE-инструкций). Мне важна скорость, а не универсальность.

0

@ForEveR

darkAngel, Не столь сильно уменьшается скорость, все же в boost и stl люди тоже думали о производительности)

0

@volovzi

darkAngel, опиши задачу подробнее. Возможно, можно сделать по-другому.

Кстати, на будущее: важно не абсолютное время работы (одна миллисекунда против двух), а асимптотическое. То есть пропорция, с которой растёт время выполнения программы с увеличением числа входных данных. Так вот в СБШ (стандартной библиотеке шаблонов, она же STL) с этим всё в порядке. Иначе говоря, нужно составлять быстрый алгоритм, а не лезть в дебри излишней оптимизации.

0

@darkAngel

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

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

0

@Deviaphan

Это называется вектор (std::vector), но вы ему тоже не доверяете...

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

По нормальному реализуй полиморфизм и усё.

0

Evg

Это массив из union'ов. Массив можно органищовывать хоть ручками, хоть через std::vector - принципиальной разницы нет. В том числе и с точки зрения скорости. Разница будет только при неправильном подходе к задаче

Когда речь идёт о миллисекундах, то "производительность" и "шаблон" - понятия несовместимые, потому как компилятор не имеет права inline'ить шаблонную функцию или метод. Кроме случаев специализации, но если всё специализировать - тогда нафига вообще связываться с шаблоном.

Бред. Попробуй привести хотя бы один пример, где из-за union'а производительность снижается. И хотя бы одну оптимизацию, которая не сможет построиться

1

@Deviaphan

C какого перепугу?

Если бы я знал, как работает компилятор, я был бы одним из его разработчиков. Модификатор __restrict говорит нам о том, что union мешает оптимизации. Какой именно - вопрос к разработчикам компилятора.

Добавлено через 5 минут
Между прочим, миллисекунда это ОЧЕНЬ много. За одну тысячную секунды столько успевается сделать, что пипец просто...

0

Evg

С такого, что у шаблонной функции может быть специализация. Если компилятор её видит - проинлайнит, но если не видит, то она может быть где-то вдругом месте описана, а потому инлайнить нельзя. И это - 99% случаев

Модификатор restrict говорит о том, то обращения по указателю с модификатором restrict не пересекаются с обращениями по другим указателям. Т.е. если мы имеем код:

То компилятор, ничего не зная о p1 и p2 должен полагать (если не сумеет доказать обратное), что чтение из p2 теоретически может быть по тому же адресу, что и запись в p1, а потому эти два обращения зависимы. Но если ты на один из указателей навесишь модификатор restrict, то это подсказка компилятору, что обращения по этому указателю НЕ пересекаются по адресам с обращениями по другим указателям. При таком раскладе чтение из p2 можно переставить выше записи в p1. Процесс чтения из памяти - это более долгая операция, чем запись, особенно если данных ещё в кэше нет, а потому чтения из памяти компилятор всегда старается закинуть как можно выше (раньше по исполнению). Современные процессоры умеютодновременно исполнять несколько инструкций, а потому пока тормозное чтение долго работает, в параллель что-то другое исполняется. restrict является дополнительной подсказкой для оптимизаций. union тут вообще не при чём

0

@Deviaphan

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

Добавлено через 56 секунд
Заинтересовало. Можно пруф?

Добавлено через 41 секунду
И Link Time Code Generation никто не отменял. А при нём даже из dll инлайнить могёт, не говоря уже о шаблонах.

0

Evg

Можешь ссылку на описание кинуть? Потому что на словах ничегоне понял. Сдаётся мне, это есть какое-то расширение, а не стандарт

Был один из примеров:

Компилируем один файл (когда код со специализацией не попадает в линковку):

Компилируем два файла (при этом в линковку попадает специализация)

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

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

Добавлено через 7 минут
Я правильно понимаю, что про __restrict в отношении union'а имелся в виду пример из
http://msdn.microsoft.com/en-u... s.80).aspx
Так вот это не есть то самое. Это просто следствие из свойства __restrict: еслинаписан такой union, то программист обязан сам следить за тем, чтобы работа одновременно ввелась только с одним из указателей. К тому, что писал darkAngel это не имеет никакого отношения, потому что речь идёт НЕ о чтении значений из union'а, а о чтении значений из указателя (который записан в union'е)

0

@darkAngel

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

Добавлено через 53 секунды
Да не совсем и массив. Т.к. есть удаление элементов из середины.
В принципе ручками и реализовал список, просто было интересно, можно ли через шаблоны.

Добавлено через 5 минут
а шаблоны вообще решил использовать, т.к. часто ими не пользуюсь, а многие утверждают, что конёк С++ это шаблоны. Вот и решил попробовать.. вроде бы и типы данных разные, а не подошли тут шаблоны.

0

@Deviaphan

Да, я про это MSDN ссылку говорил. Возможно я не всё корректно из неё понял.)

LTCG откладывает генерацию кода до этапа компоновки, т.е. когда уже известны все варианты использования, все специализации, все параметры и способы вызовов. Известно всё, что можно узнать. Поэтому компилятор делает туеву хучу оптимизаций. Даже виртуальные вызовы встраивает, если может. А уж шаблоны разрулить для него точно не проблема.
Загляни в STL, например в вектор, там inline куча объявлений.

0

@Manjak

Шаблоны компилируются в отдельные классы(функции и т.д.) для каждого набора параметров в месте инстанциирования, соответственно, в этом месте должна быть видна и реализация шаблона (в основном в конце хедера шаблона пишут #include "*.cpp", но некоторые компиляторы предусматривают #pragma implementation). Соответственно с inline и другими оптимизациями нет никаких проблем.

0

Evg

Шаблоны нужно использовать когда у тебя есть похожие действия над разными типами. Т.е. если бы у тебя был отдельный массив int'ов и отдельный массив float'ов - тут можно шаблоном пользоваться. А вот когда у тебя есть один массив, но элеметом является либо int, либо float, то тут надо union использовать. Поняно, что пацанским принципиальным методом было бы виртуальное наследование, но опять-таки это без шаблонов

Не совсем всё, потому что библиотеки обычно компилируются без il'а, но не суть. Мне бы сейчас хотелось понять, законно ли специализацию ставить в такое место, где её может быть не видно одним из запусков компилятора. В своём примере я сделал один запуск компилятора и подал в него два файла. Более честным было бы сделать два раздельных запуска компилятора. Суть от этогоне меняется, но проблема более явно описывается.

LTCG - это метод для извращенцев, которые пытаются проблемы проектирования переложить на компилятор. Да и нужен он в первую очередь для таких архитектур, как IA-64 - с предикатными кодами

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

0