Видимость шаблонной специализации функции C++
Помимо playerPrefs, другой грязный способ заключается в том, чтобы сохранить объект во время загрузки уровня, вызывая DontDestroyOnLoad на нем.
DontDestroyOnLoad (transform.gameObject);
Любой скрипт, прикрепленный к игровому объекту, сохранится, а также переменные в скрипте. Функция DontDestroyOnLoad обычно используется для сохранения целого GameObject, включая прикрепленные к нему компоненты, и любые дочерние объекты, которые он имеет в иерархии.
Вы можете создать пустой GameObject и поместить только скрипт, содержащий переменные, которые вы хотите сохранить на нем.
8 ответов
Это ошибка для имения специализации для шаблона, который не видим при вызове. К сожалению, компиляторы не требуются, чтобы диагностировать эту ошибку и могут тогда сделать то, что они любят с Вашим кодом (в, стандартизируют его, "плохо формируется, никакая диагностика, требуемая").
Технически, необходимо определить специализацию в заголовочном файле, но примерно каждый компилятор обработает это, как Вы могли бы ожидать: это фиксируется в C++ 11 с новым "шаблонным средством" экстерна:
extern template<> SomeFunc<int>();
Это явно объявляет, что конкретная специализация определяется в другом месте. Много компиляторов уже поддерживают это, некоторых с и некоторых без extern.
Вы добавили прототип с параметрами к Вашему заголовочному файлу?
я имею в виду, находится там где-нибудь в fileA.h
template<> SomeFunc<int>();
, Если не это - вероятно, причина.
На спецификации Ваш специализированный шаблон функции никогда нельзя называть внешним fileA.C, если Вы export шаблонное определение, которое в настоящее время не поддерживает никакой компилятор (кроме Comeau) (или запланировали его обозримое будущее).
, С другой стороны, как только шаблон функции инстанцируют, существует функция, видимая к компилятору, который больше не является шаблоном. GCC может снова использовать это определение через различные единицы компилятора, потому что в стандарте говорится, что каждый шаблон нужно только инстанцировать однажды для данного набора аргументов типа [temp.spec]. Однако, так как шаблон не экспортируется, это должно быть ограничено единицей компиляции.
я полагаю, что GCC может представить ошибку здесь в совместном использовании ее списка инстанцированных шаблонов через единицы компиляции. Обычно, это - разумная оптимизация, но она должна взять функциональные специализации во внимание, которые это, кажется, не делает правильно.
Brandon: это - то, что я думал - специализированная функция никогда не должна вызываться. Который верен для второго приложения, я упомянул. Первое приложение, однако, ясно называет специализированную форму даже при том, что специализация не объявляется в заголовочном файле!
я главным образом ищу просвещение здесь:-), потому что первое приложение является модульным тестом, и неудачно иметь ошибку, которая не появляется в тесте, но в реальном приложении...
(PS: Я исправил эту определенную ошибку, действительно путем объявления специализации в заголовке; но что могли бы все еще быть скрыты другие подобные ошибки?)
В Microsoft C ++, я сделал эксперимент с подставляемыми функциями. Я хотел знать то, что произошло бы, если бы я определил несовместимые версии функции в других источниках. Я получил различные результаты в зависимости от того, использовал ли я Отладочную сборку или Сборку конечных версий. В Отладке компилятор отказывается встраивать что-нибудь, и компоновщик связывал ту же версию функции, неважно, что было в объеме в источнике. В Выпуске компилятор встроил, какой бы ни версия была определена в то время, и Вы получили отличающиеся версии функции.
Ни в том, ни в другом случае были там любые предупреждения. Я отчасти подозревал это, которое является, почему я сделал эксперимент.
я предполагаю, что шаблонные функции вели бы себя то же, как будет другие компиляторы.
[anthony-williams],
действительно ли Вы уверены, что не путаете extern объявления шаблона с extern template инстанцирования? Из того, что я вижу, extern template может [только 117] использоваться для явного инстанцирования, не для специализации (который подразумевает неявное инстанцирование). [temp.expl.spec] не упоминает extern ключевое слово:
явная специализация :
template<> объявление
Если специализированная шаблонная функция не будет также перечислена в заголовочном файле, другое приложение будет не знать о специализированной версии. Решением является добавление SomeFunc<int>() к заголовку также.
У меня была такая же проблема с gcc4, вот как я ее решил. Это было более простое решение, чем то, во что я верил предыдущими комментариями. Идеи предыдущих постов были верны, но их синтаксис не работал для меня.
----------header-----------------
template < class A >
void foobar(A& object)
{
std::cout << object;
}
template <>
void foobar(int);
---------source------------------
#include "header.hpp"
template <>
void foobar(int x)
{
std::cout << "an int";
}