C++ templaty, member function pointer (diskuse)

[kralyk z abclinuxu]

Proč castuješ tu callback member funkci na member funkci toho funktoru? Pointer na member funkce jsou divný, můžou mít různý velikosti.

Stejnětak mi není jasný, proč castuješ A *o na *functor, možná to jen nechápu...

[vlastikroot]

Ach tak, to vypada jako slusny zlo. Ten cast tam delam kvuli tomu, abych ochcal C++ a mohl ulozit pointer na jakoukoli class. Podle toho co jsi mi poslal by to mohl byt problem, jestli je kazdy pointer fyzicky jiny.

[kralyk z abclinuxu]

Tak si tam dej nějakej datovej typ dostatečně velkej i na fakt obézní member pointery a do nej do kopíruj. Třeba struct { size_t a; size_t b; };

Nejspíš by se i našel způsob, jak během compile-time zjistit, jestli ten member func pointer není větší...

[Sten]

To nebude fungovat v operator (), protože tam se to castuje na jiný typ, než který byl uložený, a každý může mít jinak velké member pointery.

[Jardík]

Jestli kompiluje GCC na x86-64, tak všechny pointery na member fci jsou 16 bytů (8 bytů offset k this a 8 bytů buď adresa member fce, či index do vtable (Itanium C++ ABI). Na x86 je to stejné, akorát je to 4+4 bytů. Pokud by autorovi příspěvku nevadila další indirekce, mohl by urobit template member fci jako wrapper a pak by mu stačil jen obyč pointer na funkci. Protože narozdíl od obyč pointeru na funkci je pointer na member funkci compile-time konstanta a může být použit jako template argument. Úspora je však sporná - zase bude více kódu ve výsledné binárce pro wrapper funkci, ale když se bude opakovat stejný callback a nebudou všechny různé, úspora bude. A ten typeid check vyhoď z release buildu (#ifndef NDEBUG ... #endif)

[vlastikroot]

Nevis jak je to na ARMu? Ten kod je cilenej na ARM.

[Jardík]

Můžeš zkusit web kompilátor tu, vpravo to ukazuje výsledný asm kód. Oba pointery na nevirtuální fce vypadají, že mají stejnou velikost (label .L5, u obou je "word" (asi velikost slova, kolik to je, nevím)). To implikuje i stejnou velikost pointeru na virtuální metodu (pointer na virtuální a nevirtuální metodu stejné signatury stejné třídy musí být kompatibilní).

[pc2005]

16 bajtů složenýho ukazatele? To musí ten C++ kód neskutečně zpomalovat ne? (já jsem teda céčkař)

[Jardík]

To je na member fcu, na statickou je to jen 8, jako v C. Pro každou member fcu je však možné vytvořit statickou wrapper fci, pomocí šablon.

[Josef Kufner]

Nebylo by lepší hodit výjimku namísto ladicího výpisu?

[vlastikroot]

Urcite, to neni hotovy kod, jen takovy napad.

[Jardík]

Používání výjimek na takovéto věci vidím jako zlo. Na programátorské chyby jsou asserty. Je ale smutné, že se místo nich ve standardní knihovně výjimky opravdu používají (třeba member fce at() různých kontejnerů).

[Jardík]

Jinak důvodem je samozřejmě rychlost. Assert zpomalí či zabrání inlinování a optimalizací jen v debug buildu, kdeždo výjimka může mít negativní dopad na inlinování a jiné optimalizace v release buildu.

[Sten]

Většina metod žádné výjimky nehází. at je hází úmyslně, neházející verze je operator [].

GCC má debug verzi STL, která asserty obsahuje.

[Jardík]

Však nejsem blbej, já vím, že at() je hází úmyslně a taky vím, že operator[] ne. Ideální stav je, že je nehází ani at(), protože použití at() s neplatným indexem prostě považuji za programátorskou chybu a tedy by to mělo být ošetřeno assertem a né výjimkou. A operator[] by ten assert neměl obsahovat vůbec, aby nezdržoval debug build.

[kverulant]

IMHO tam nebudou fungovat implicitni konverze.

[kverulant]

A kdyz uz jsme u toho, tak to saskovani s vektorem je zbytecne. Typy argumentu jsou znamy v dobe prekladu, takze staci ulozit a porovnavat jen jeden slozeny typ, treba typeid(void(Ts...)) nebo neco podobneho.

[Sten]

Ten reinterpret_cast nebude fungovat na virtuální metody.

Tohle se dělá tak, že při vytváření toho callbacku se uvnitř alokuje* šablonová implementace pro danou třídu mající virtuální metodu, kterou se to z operátoru () zavolá.

* S trochou čachrování (placement new) to většinou lze alokovat i v prostoru vyhrazeném na zásobníku a ušetřit dynamickou alokaci.

[Sten]

Náčrt takového kódu (netestoval jsem, jestli funguje, ale pro ilustraci, jak by to mělo fungovat, snad stačí):

template <typename ReturnT, typename... ParamTs>
class Callback
{
protected:
    struct Iface
    {
        virtual ~Iface() {}
        virtual ReturnT operator ()(ParamTs... params) = 0;
    };

    template <typename Type>
    struct Impl
        : public Iface
    {
        using Func = ReturnT (Type::*)(ParamTs...);

        Impl(Type &obj, Func func)
            : obj(obj)
            , func(func)
        {}

        virtual ~Impl() {}

        virtual ReturnT operator ()(ParamTs... params)
        {
            return std::forward<ReturnT>(obj.*func(std::forward<ParamTs...>(params)));
        }

        Type &obj;
        Func func;
    };

    Iface& iface()
    {
        return *reinterpret_cast<Iface*>(buf);
    }

    size_t buf[4];

public:
    template <typename Type>
    Callback(Type &obj,
             typename Impl<Type>::Func func)
    {
        // Místo static_assert lze upravit, aby to použilo new
        static_assert(sizeof(Impl<Type>) <= sizeof(buf), "Buffer not large enough to capture callback");
        new (buf) Impl<Type>(obj, func);
    }

    ~Callback()
    {
        iface().~Iface();
    }

    ReturnT operator ()(ParamTs... params)
    {
        return std::forward<ReturnT>(iface()(std::forward<ParamTs...>(params)));
    }
};

Callback callback(t, &Type::getValueForInput);
int value = callback(input);

[Sten]

Pár úprav:

std::forward na návratové hodnoty je zbytečný, navíc nebude fungovat s void.

virtual ReturnT operator ()(ParamTs... params) a virtual ~Impl() v Impl by bylo lepší označit override.

[kralyk z abclinuxu]

Jestli může být Callback templatová třída, pak se rovnou může použít std::function, ne?

[Jardík]

Autor píše, že chce, aby všechny functory měly stejný typ a nebyly šablony. Musí to tedy být wrapper na nějaký objekt s virtual fcemi pro volání, nebo použít ošklivý cast. Jinak reinterpret_cast nemění žádné hodnoty, takže fungovat by měl, pokud to zpět castne na stejně veliký typ.

[Jardík]

Je to ale však prasárnička, o tom žádná. Ale nebude o nic větší, než moje prasárničky, kdy v pointeru vesele skladuju dalších 16 bitů nějakých hodnot, nebo používám double/NaN jako variant (hezky se tam vleze 47bit pointer, int, 47 bitů ze size_t, apod prasárničky, na dispatch tabulku máte celých 5 bitů).

[Sten]

OK, zkusím vymyslet, jak tohle nějak rozumně zabalit. Tuhle implementaci (operator ()) by šlo zabalit přes reinterpret_cast, protože není polymorfní (takže je to jen pointer na funkci, kde první parametr je this), ale nebude to ověřovat typy parametrů.

Ten reinterpret_cast v původní implementaci nebude fungovat, pokud bude castovat z polymorfní třídy na nepolymorfní či obráceně, a nejspíš ani pokud bude mezi různými stromy polymorfních tříd, protože u virtuálních metod je to typicky implementováno jako index do vtable, nikoliv pointer.

[Jardík]

Jak vypadá ukazatel na member funkci vím, psal jsem to někde výše. Na x86-64 je to 2x8 bytů, v jednom je offset pro this pointer (kvůli vícenásobné dědičnosti apod) a druhý je pointer na metodu, popř. offset do vtable (na rozlišení se používá přičtení jedničky, při volání se testuje a podle toho se pak provede buď jump na tu adresu, nebo se fetchne z vtable). Pointery na virtuální i nevirtuální metodu stejné třídy stejné signatury musí být "kompatibilní". ve smyslu stejná velikost a stejný formát, jinak by se pointer nedal předat někam, kde se neví, jak se má zavolat. Na x86-64 jsou takto kompatibilní i pointery na member funkce různých tříd, samozřejmě včetně vícenásobné i virtuální dědičnosti.

[vlastikroot]

Jakto ze nebude fungovat? Muj kod virtualni metody pouziva, takze jsem je zkousel jako prvni. Chovalo se to tak jak bych ocekaval - kdyz vytvorim derived, pretypuju na base a udelam callback na base, volani spusti metodu v derived.

[Jardík]

Pokud použiješ reinterpret_cast na něco o stejné velikosti a pak na výsledek zase použiješ reinterpret_cast zpět na původní typ, tak to fungovat bude. Pouze se jinak interpretuje ta hodnota, ale nemění se. static_cast a dynamic_cast je na pointer na member funkci nepoužitelný, alespoň co já vím.

[vlastikroot]

Tak jsem to predelal podle Stenovych pripominek, na test parametru se pouziva dynamic cast. Tohle se zda o dost cistsi nez ty reintepret casty a zvenku se to chova stejne jako puvodni kod.

class functor
{
protected:
    struct iface { virtual ~iface(){}; };
    template <typename... Ts> struct args : public iface
    {
        virtual void call(Ts...) = 0;
    };

    template <typename A, typename... Ts> struct impl : public args<Ts...>
    {
        A* obj;
        void (A::*func)(Ts...);

        impl(A* o, void (A::*f)(Ts...)) : obj(o), func(f) {}

        void call(Ts... args)
        {
            (obj->*func)(args...);
        }
    };

    size_t i[4];

public:
    template<typename A, typename... Ts> functor(A* o, void (A::*f)(Ts...))
    {
        static_assert(sizeof(impl<A, Ts...>) <= sizeof(i), "Buffer not large enough to capture callback");
        new (i) impl<A, Ts...>(o,f);
    }

    template<typename... Ts> void operator()(Ts... params)
    {
        args<Ts...> *a = dynamic_cast<args<Ts...>*>(reinterpret_cast<iface*>(i));

        if(a) a->call(params...);
        else qDebug() << "bad parameters";
    }
};