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

> gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1)

#include <stdio.h>

template <void (*Init)()>
struct CALL
{
        CALL() { Init(); }
};

void funcInit() { printf("%s\n", __FUNCTION__); }

template <void (*Init)()>
struct WrapCALL
{
        static CALL<Init> II;
};

template <void (*Init)()>
CALL<Init> WrapCALL<Init>::II;

int main()
{
        WrapCALL<&funcInit> tmp;
        return 0;
}

Здравствуйте, Аноним, Вы писали:

А>wtf?
А>результат программы, должно выводиться имя функции funcInit
А>а ничего не выводиться
Почему должно выводится? По правилам языка не так:

Unless a member of a class template or a member template
has been explicitly instantiated or explicitly specialized, the specialization of the member is implicitly in-
stantiated when the specialization is referenced in a context that requires the member definition to exist; in
particular, the initialization (and any associated side-effects) of a static data member does not occur unless
the static data member is itself used in a way that requires the definition of the static data member to exist.

Хочешь чтобы выводилось? Тогда явно нарушь одно из двух условий: либо напиши специализацию для II, либо хотя бы формально сошлись на II для явного инстанциирования.

Здравствуйте, watchmaker, Вы писали:

W>Хочешь чтобы выводилось? Тогда явно нарушь одно из двух условий: либо напиши специализацию для II, либо хотя бы формально сошлись на II для явного инстанциирования.

Кстати, чтобы неявно явно инстанцировать , можно прибегнуть к такому трюку http://ideone.com/LwksAv

#include <iostream>
using namespace std;

typedef void (*F)();

template<F f> struct Goal
{
    Goal() { f(); }
};

template<F f> struct Singleton
{
    static Goal<f> instance;
};
template<F f> Goal<f> Singleton<f>::instance;

// а вот и фокус

template<F f, Goal<f>* I> struct Instantiator {};

template<F f> struct Voila : Instantiator<f, &Singleton<f>::instance> {};

void foo() { cout << "foo" << endl; }
Voila<foo> voici;

int main() {
    // your code goes here
    return 0;
}

Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, watchmaker, Вы писали:

W>>Хочешь чтобы выводилось? Тогда явно нарушь одно из двух условий: либо напиши специализацию для II, либо хотя бы формально сошлись на II для явного инстанциирования.

К>Кстати, чтобы неявно явно инстанцировать
Где тут неявно? Наоборот же — явно, и два раза.

К>можно прибегнуть к такому трюку http://ideone.com/LwksAvэ
Ну да, можно создать зависимость от объекта любого рода (как и в примере, не совсем любого, а желательно, из тех, которые не имеют накладных расходов в run-time).
Только кажется тут чуть-чуть задача другая решена
Смотри, у тебя в программе нет ни одного экземпляра Singleton<foo>, но зато конструируется Goal<foo>. При этом если всё же ввести экземпляр Singleton<T>, то всё равно нужно писать Voila<T>, причём для каждого используемого типа Т, причём даже если потом Singleton<T> перестанет быть нужен, то всё равно Goal<T> будет конструироваться до тех пор, пока явно и Voila<T> не будет убрано. Для примера можно рассмотреть случай с двумя функциями-параметрами шаблона: http://ideone.com/3Hkm9H — создали Singleton<bar>, а напечаталось всё равно "foo" — это даже более загадочно выглядит чем невызов в исходном коде автора
Короче говоря, кажется, что позвать нужный конструктор можно проще.
Ни и гораздо полезнее чтобы код работал так, как, видимо, было задумано автором темы в самом начале — при создании Singleton<T> конструировать и Goal<T>, но только для тех T, которые фактически используются в программе, а не для всех (список которых ещё и перечислить отдельно надо как в твоём примере).

И коли нужно потрогать II/instance, то сделать это можно хоть так: http://ideone.com/oO6iaL

template<F f> struct Singleton
{
    static Goal<f> instance;
    Singleton() { (void)(&instance); }
};

Тут уже не нужно отдельно что-то писать за пределами класса — никаких Voila, забытых или несинхронизированных инициализаций, да и служебный класс Instantiator не нужен (при чём он хоть и служебный, но почему-то должен знать об устройстве Goal — некрасивая неуниверсальность). Впрочем если так уж нравятся шаблоны, то тот же Voila можно и оставить, главное что его нужно также перенести в конструктор Singleton или куда-нибудь в соседнюю функцию.

Здравствуйте, watchmaker, Вы писали:
...

Это все, конечно, прекрасно, но определен ли макрос __FUNCTION__ ? У меня, например, нет такого макроса

void foo()
{
#ifndef __FUNCTION__
#error("__FUNCTION__ is not defined")
#endif
}


int main()
{
    return 0;
}

error: #error ("__FUNCTION__ is not defined")

Здравствуйте, slava_phirsov, Вы писали:

_>Это все, конечно, прекрасно, но определен ли макрос __FUNCTION__ ? У меня, например, нет такого макроса

Что за компилятор?
__FUNCTION__ одинаково определяется и в VC, и в gcc.
Вот типизированное имя называется по-разному, __FUNCSIG__ и __PRETTY_FUNCTION__

Здравствуйте, Кодт, Вы писали:

К>Что за компилятор?

gcc 4.4.7

Здравствуйте, slava_phirsov, Вы писали:

_>Здравствуйте, Кодт, Вы писали:

К>>Что за компилятор?

_>gcc 4.4.7


ТДБ: согласно документации gcc, __FUNCTION__ — не макрос

Здравствуйте, slava_phirsov, Вы писали:

_>gcc 4.4.7

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

Здравствуйте, Кодт, Вы писали:

К>Ещё, небось, сборка какая-нибудь корявая кастомная?

Корявая-корявая, прямиком из официального репозитория RedHat 6, на минуточку

К>Короткое гугление показало, что 4.4, действительно, не поддерживает этот дефайн.

Насчет #define написал чуть выше, ну на всякий случай повторюсь — не макрос это. Официально не макрос

Здравствуйте, slava_phirsov, Вы писали:

_>Корявая-корявая, прямиком из официального репозитория RedHat 6, на минуточку

Закопай стюардессу вместе с фюзеляжем.

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

RHEL/CentOS 6.5 уже используют 4.7.2 в качестве штатного компилятора.


К>>Короткое гугление показало, что 4.4, действительно, не поддерживает этот дефайн.
_>Насчет #define написал чуть выше, ну на всякий случай повторюсь — не макрос это. Официально не макрос

Один чёрт, как это называется. Предопределённый препроцессорный символ, такой же, как __cplusplus и т.п.

Здравствуйте, Кодт, Вы писали:

К>RHEL/CentOS 6.5 уже используют 4.7.2 в качестве штатного компилятора.

Ну вот только что специально посмотрел, на машине с Centos 6.5 у меня те же фаберже версии 4.4.7

К>Один чёрт, как это называется. Предопределённый препроцессорный символ, такой же, как __cplusplus и т.п.

здесь

These identifiers are not preprocessor macros. In GCC 3.3 and earlier, in C only, __FUNCTION__ and __PRETTY_FUNCTION__ were treated as string literals; they could be used to initialize char arrays, and they could be concatenated with other string literals. GCC 3.4 and later treat them as variables, like __func__. In C++, __FUNCTION__ and __PRETTY_FUNCTION__ have always been variables.

Раз не макросы — значит #ifndef отработает так, как если бы этот символ не определен (что и наблюдалось в приведенном примере), не?

Здравствуйте, slava_phirsov, Вы писали:

_> #ifndef отработает так, как если бы этот символ не определен (что и наблюдалось в приведенном мной, а не ТС примере)

Здравствуйте, slava_phirsov, Вы писали:

_>Здравствуйте, Кодт, Вы писали:

К>>Ещё, небось, сборка какая-нибудь корявая кастомная?

_>Корявая-корявая, прямиком из официального репозитория RedHat 6, на минуточку

вот это официальный RH way иметь современный компилятор (и прочий инструментарий), чтобы девелопить софт, который будет работать даже на RH5 (не говоря уже про 6).

https://access.redhat.com/site/documentation/en-US/Red_Hat_Developer_Toolset/2/html/2.1_Release_Notes/index.html

Здравствуйте, zaufi, Вы писали:

Z>вот это официальный RH way иметь современный компилятор (и прочий инструментарий), чтобы девелопить софт, который будет работать даже на RH5 (не говоря уже про 6).

Z>https://access.redhat.com/site/documentation/en-US/Red_Hat_Developer_Toolset/2/html/2.1_Release_Notes/index.html


А под CentOS 6 есть только неофициальный порт от tru_tru, да и тот уже зачах