This one is a long shot, but have you tried throwing a breakpoint on the non-ref AddRef and check to see if anything looks weird about the template parameter or the function parameters when it gets called?
And I definately get not being able to share everything, I'm just trying to fill in the gaps where I can
I see what your saying about the non-reffed version. I tried stripping it down some (replaced ai:BehaviorTree with an empty class Test2 since I don't have all your headers), Both calls ended up calling the first version of the function, which would seem to be the correct behavior, since it should only be the wrapper Asset getting manipulated. Now something I notice (and am guessing this is just a bad cut and paste or just not a complete code), is that
shouldn't work in your posted code, since in your example I don't see any kind of constructor of Asset that would pass along the parameter into the ai:BehaviorTree constructor.
It looks like it revolves around your decltype for the returns. When I comment them out, it works fine. I'm guess it has to do with trying to set the return type to void using the decltype (since the function doesn't have a return call). So it is defaulting to the version that already has void as a return type. long and int are effectively the same type in VS, so I don't think that would stop anything.
And thinking about it more (without further testing), void() might be making a return type of a function pointer with a return type of void, not the actual void type.
template <typename ObjectType>
static auto AddRef(ObjectType* pObject)/* -> decltype(AddRef(pObject, 0))*/
return AddRef<ObjectType>(pObject, 0);
template <typename ObjectType>
static auto AddRef(ObjectType* pObject, int)/* -> decltype(pObject->AddRef(), void())*/
static void AddRef(ObjectType* pObject, long)
int main(int argc, char* argv)
Test* test = new Test();
At that moment, you wish you had never heard of constexpr (at least that's what I felt like!). Because if you had been told ahead of time that the function would be evaluated at runtime anyway, you would have used a better algorithm.
I feel the same way. I love the concept, but it can be annoying sometimes. I had a bit counting function implemented that called the Microsoft intrinsic version when it was available. When VS2015 was released, I thought I was being clever and had implemented the fallback as a constexpr function. Only to get smacked in the face by the fact that the intrinsic specializations couldn't coexist with the constexpr version. They had to be named separate, which defeats what I was hoping for (not really thinking about how it would really work)... If it can be at compile-time, do it at compile-time. If it can't be, use the intrinsic version if available, else the fallback.
As for concrete std::string class, it will surely always write '\0' byte - if std::string class is standardized as this (http://www.cplusplus.com/reference/string/string/size/) and std::size() will return amount of bytes of explicit string ,with or without even knowing encoding of the string.
This is semantics. You said characters earlier, now you are saying bytes. The number of bytes is well defined. When they were talking characters; they mean the represented characters, not the number of bytes. In ASCII, the number of bytes = number of characters (1 character fits into 1 byte). When you introduce a multi-byte system like Unicode (UTF-8, UTF-16, etc), multiple bytes may makeup a single represented character. And it is not a straight 2 bytes = 1 character, you might have to iterate over the entire string to determine the number of characters. One character might be a single byte, the next might require 3 bytes, then 4, then 2, then 1 again.
Servant - does the standard guarantee that std::strings data is a contiguous, null-terminated array like that? I was (perhaps mistakenly) under the impression it was not, hence the use of vector which does make such a guarantee I believe.
I believe since C++11, it is. (Following from draft standard - n3376)
21.4.1 basic_string general requirements
5 The char-like objects in a basic_string object shall be stored contiguously. That is, for any basic_string
object s, the identity &*(s.begin() + n) == &*s.begin() + n shall hold for all values of n such that 0
You've got circular dependencies. Your header files are referencing each other. You can probably break some of this by forward declaring BuddyEngine in Manager.hpp instead of including the BuddyEngine header.
I'm on my phone right now, so not easy to go into more detail.