Подстановка типа\шаблоны с++

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

класс большой

далее, есть предположим 2-3 .cpp файла, который тянут этот хедер с этим классом
в каждом .срр создается объект этого класса, причем в качестве шаблонного параметр всегда одно значение, пусть enum1
сколько раз происходит подстановка этого типа?
если несколько раз, то можно ли ускорить сборку? т.е сделать как то чтобы подстановка производилась 1 раз

0

Т.е. ты перенес инстанцирование класса в одну единицу трансляции, путем указания специализации для функции, которая создает его экземпляры по шаблону.
Функция инстанцироваться перестала вообще, а класс - теперь инстанцируется только в одном файле.
Если класс очень большой, то это дает выигрыш в скорости построения.
Но тем не менее, осталась проблема инстанцирования другими аргументами, отличными от enum1. В этом случае в отсутствие специализации, либо тела шаблона, будет ошибка линкера.
Если ты добавишь тело и прототип специализации как я показал в посте 7 в заголовочный файл, то не получишь замедления компиляции, но и корректность кода восстановишь.

0

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

0

Сообщение от aLarman class Derived : public MyClass<enum1>//явно тип указали

Инстанцирование будет при попытке создать объект Derived. Если создания объекта нет здесь, то и инстанцирования не будет. Не смотря на явную запись аргумента.

1

Сообщение от DrOffset Если класс очень большой, то это дает выигрыш в скорости построения. Но тем не менее, осталась проблема инстанцирования другими аргументами, отличными от enum1. В этом случае в отсутствие специализации, либо тела шаблона, будет ошибка линкера.

я это понимаю, просто при компиляции набора .срр будет использоваться только один тип(MyClass<enum1>)
для другого набора .cpp будет сделана своя специализация
собсно цель - ускорить сборку, ибо тачка 32ядра, и хочется чтобы собиралось все поскорее(собсно .срр это файлы с gtest -ами)

Добавлено через 1 минуту

Сообщение от DrOffset Инстанцирование будет при попытке создать объект Derived

кул

0

Сообщение от aLarman так же неизбежно инстанциирование в каждом .срр

По правилам должно быть. Из-за деструктора, который требуется для delete. Но по факту это почти всегда можно оптимизировать, вынеся деструктор класса, в котором такой авто_птр сидит, в отдельный файл.

0

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

честно не совсем понял как это
auto_prt в .cpp же, как быть то?

0

Сообщение от aLarman auto_prt в .cpp же, как быть то?

Код покажи лучше А то может быть мы о разных вещах говорим.

0

ну из поста 10
было сделать типо того

Добавлено через 1 минуту

Сообщение от DrOffset Из-за деструктора, который требуется для delete.

вот незадача, получается если я сделаю так
в .срр
все таки произодйет инстанциирование?

0

Сообщение от aLarman все таки произодйет инстанциирование?

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

Сообщение от aLarman сделать типо того

В этом смысле нет разницы с примером без умных указателей.

0

Сообщение от DrOffset В этом смысле нет разницы с примером без умных указателей.

т.е когда в качестве параметр для auto_ptr используется шаблонный класс то при инстанциировании auto_ptr типом MyClass<enum1>, cам класс не инстанциируется?

Добавлено через 6 минут
вобщем, нужна теперь конкретика
если я сделаю сырой указатель
то MyClass<enum1> * p- тут нет инстанциирования
если указатель инициализируется вызовом new то будет инстанциирование, т.к. тут уже пригодился конструкор класса
если иницилизировать указатель методом который дергает new и который определел в другой единице трансляции, то тут будет инстанциирование только один раз(в том месте где определн метод)
если я использую delete p то так же будет инстанциирование, т.к пригодился деструктор
если же сделать еще например метод который будет дергать delete то инстанциирование будет произведено там где определн этот метод(например в том же .срр что и getNewInstance)

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

0

Сообщение от aLarman т.е когда в качестве параметр для auto_ptr используется шаблонный класс то при инстанциировании auto_ptr типом MyClass<enum1>, cам класс не инстанциируется?

Внутри auto_ptr тот же самый указатель.
До тех пор, пока ты не дергаешь у него методы или не зовешь delete, то инстанцирования точно не будет.
Если например код такой:
То при подключении этого кода в другой файл и создание там объекта не приведет к инстанцированию MyClass<enum1>.
Вот это я имел в виду.
В случае, если ты используешь методы шаблона в данной единице трансляции, то инстанцирование будет.

0

Сообщение от DrOffset В случае, если ты используешь методы шаблона в данной единице трансляции, то инстанцирование будет.

а если так вот создал я указатель а потом где то то И В текущей единице трансляции будет произведено инстанциирование?

0

aLarman, вообще тут надо внести ясность.
Говоря про необходимость или отсутствие необходимости инстанцирования нужно меть в виду, что компилятор в этом плане не должен следовать какому-то конкретному алгоритму (в стандарте есть кое-какие указания, но это скорее сглаживание углов, чем алгоритм "от и до"). Но он всегда исходит из того, чтобы генерировать как можно меньше. Поэтому везде выше, где я говорил, что инстанцирование будет, означает, что оно потенциально возможно, но это не значит, что оно будет в 100% случаев. Важно тут всего несколько вещей:
1) ODR не должно нарушаться, но если оно нарушится, то компилятор ничего про это не обязан говорить.
2) Компилятор не будет генерировать лишнего, если это возможно.

Сообщение от aLarman то И В текущей единице трансляции будет произведено инстанциирование?

Если я правильно понял, то нет.

0

Сообщение от DrOffset Если я правильно понял, то нет.

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

0

aLarman, Вот кое-какая информация насчет реализации инстанцирования в конкретных компиляторах.

Добавлено через 13 минут

Сообщение от aLarman просто уже не логично выходит, если нам нужен конструктор или деструктор(т.е дергаем new или delete) то вроде инстанциирование есть, а если конструктор и декструктор обернуть в методы, и реализовать их в другой единице трансляции то инстанциирование будет там, то почему тогда если дергаем другие методы(не конструктор и не деструктор) через указатель, то вроде и нет инстанциирования, честно, не сходится как то...

Не сходится, потому что ты пытаешься все уложить в одну стратегию поведения.
Вот есть файл a.cpp и файл b.cpp, которые независимо подключают h с шаблоном.
Каждый файл совокупно с своими включаемыми файлами представляет собой единицу трансляции. Файлы компилируются независимо, естественно.
Теперь ты начинаешь работать с классом, в каждом из файлов. Ты вызываешь методы и т.п.
В общем виде, т.е. в той модели компиляции, которая считается основной в С++ (однопроходная компиляция), никак нельзя быть увереным, что соседний файл тоже использует этот класс. Следовательно нельзя положиться на то, что методы, которые мы тут используем, уже содержаться в объектном коде. Поэтому он генерирует и для этого файла и для того, а на этапе линковки убирает лишнее. Но тут возможно варианты. Современные компиляторы в принципе не обязаны поддерживать однопроходную модель компиляции и могут сперва собрать базу данных об использовании шаблонов, что позволит генерировать инстанцию сразу только в одном месте. Или можно использовать, например, предкомпилированные заголовки. Или собирать информацию об инстанциях в процессе компиляции. Или еще как. Это не регламентируется строго.
Теперь касаельно твоего недоумения.
В чем нелогичность? Ты передаешь указатель в функцию, которая неизвестно что делает: неизвестно что - для данной единицы трансляции, т.к. реализация находится в другой. Это не тоже самое, что позвать конкретный известный метод у шаблона. С учетом того, что компилятор не может знать без дополнительных ухищрений о том, что этот метод уже сгенерирован в другой единице трансляции.

1

собсно вывод какой?

0

Сообщение от aLarman p->SomeMethod();//вызывает инстанциирование?

Да. Вызывает. Опять же в общем случае. Но может не вызывать для конкретной ситуации.
Например, если попытаться смоделировать тест, с функций класса, которая не касается состояния класса, а просто, например, выводит hello world на экран, то компилятор может не генерировать ничего, видя из контекста, что это ни к чему, и сразу вывести текст на экран, без промежуточных вызовов.

1

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

0

Сообщение от aLarman DrOffset, вот плохо что некоторые вещи все таки не однозначны, нельзя на что то положиться

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

Вложения

test-tmpl.7z (1.5 Кб, 3 просмотров)

1