Planet Chili

This appears to sorta work but I dont like the need for the (extra) move assignment. It also seems to have a hard to deciding which overload to choose. template<typename RT> class FunctionS { public: using Action = std::function<RT()>; template<typename... Args> FunctionS(Args&&... args) : action(Ma...

Okay, so I pretty much got my function class sorted out. The problem now is with my FunctionS constructors. I can't seem to get SFINAE overload resolution to work because of the variadic nature of the template arguments and constructor parameters. I was going to use return type but constructors dont...

Ah, yeah that was the problem. Thanks papa. I was referencing a templated type so I needed both the typename and template keywords. template<CallingConvention CC, typename RT, typename... Args> using PFunc = typename CCHelper<CC>::template PFunc<RT, Args...>; I've just been away from this too long a...

Interesting information there. I haven't really found a use for 'pure' static polymorphism unless you count template specialization. I think in the long run where a variant makes sense, use a variant, where polymorphism makes sense, use polymorphism. I've started focusing less on optimization type s...

Yeah, ik... my naming conventions arent standard pre-se but it works for me I guess lol. Its kinda strange because many of my university classes thus far want different naming conventions. Anyways, thanks. I didn't know about the conjunction/disjunction stuff, tho I did know about the _t variants fo...

Ok this appears to be working. template<typename RT, typename... Args> class Function { public: template<typename FUNC> Function(FUNC&& func, typename std::enable_if_t<!is_function_ptr<FUNC>::value>* = nullptr) : action([func](Args&&... args)->RT {return func(std::forward<Args>(args)...); }) {} temp...

Ok, I think I'm on the right track. The point of the function class to is store any callable as you describe but with a common interface. std::function works for all standard function pointers; you have to change the declaration in order to get it to accept member functions. So, I wrap the function ...

Just curious about your reasoning for avoiding polymorphism. Also I cannot seem to get this template code to compile (fooling around with my function classes) enum CallingConvention { CDECLR, STDCALL, FASTCALL, THISCALL }; template<CallingConvention> struct CCHelper; template<> struct CCHelper<CDECL...

Yeah I would tend to agree papa. std::variant after all is most like a union and a union also has the same requirements of needing to know all the types up front. So where a union wouldn't work a variant also would not. It is nice how you can have static polymorphism through std::visit with variants...

Thanks, I'll probably be fooling around with some of this for the next little while and see what I like. But I have to agree it is cleaner to have the input class rather than a bunch of visitor structs. Pretty neat having that AddDelay function in there too to clean up that little bit of inconsisten...