Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 03 Nov 2004
Offline Last Active Today, 07:54 PM

#5288016 Going multi-threaded | Batches and Jobs

Posted by Rattrap on 21 April 2016 - 12:08 PM

To my knowledge, C/C++ by itself has no notion of multi-threading.


As of C++11, C++ does have native thread support.

#5276198 [Visual C++] *.obj creation folder

Posted by Rattrap on 17 February 2016 - 03:38 PM

What I do to get around this is have VC++ makes all of the sub directories in the object folders.


In the Project Property Pages -> C/C++ -> Output Files

Object File Name = $(IntDir)%(RelativeDir)\

#5276148 VS2015 without internet explorer

Posted by Rattrap on 17 February 2016 - 11:07 AM

Suppose i get to register it somehow - will it keep working without internet explorer?


It does require an occasional re-checkin, so you might have issues.

#5270888 Wrong template instantiation with SFINAE

Posted by Rattrap on 13 January 2016 - 11:11 AM

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 :)

#5270878 Wrong template instantiation with SFINAE

Posted by Rattrap on 13 January 2016 - 10:38 AM

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

TestAsset asset(L"Testing");

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.

#5270862 Wrong template instantiation with SFINAE

Posted by Rattrap on 13 January 2016 - 09:23 AM

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.

class Test
  void AddRef(){}
struct refCountHelper
  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())*/
    if (pObject)
  template<typename ObjectType>
  static void AddRef(ObjectType* pObject, long)
int main(int argc, char* argv[])
Test* test = new Test();
return 0;

#5269673 Criticism of C++

Posted by Rattrap on 06 January 2016 - 01:06 PM

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.

#5265613 std::thread arguments and copies

Posted by Rattrap on 09 December 2015 - 12:59 PM

I think you're right, it's a bug in the MSVC implementation that non-copyable arguments don't work. I remember looking this up before. I wonder if it's fixed in the VS2015 compiler.

Tried it in VS2015.
Only got

constructed in 8456

as the result.
Added a sleep before the end of the code and got

constructed in 1216
called in 5312
destroyed in 5312

So it looks like it was probably fixed in 2015.

#5261758 [c++ | asm x64] I think I call a function in the wrong way

Posted by Rattrap on 12 November 2015 - 09:49 AM

Somebody help - Please!
What's the proper way to call a 'void Func (void)' function in x64 assembly??


Have you tried using the disassembler and debugger to see what a call look like?



Drop a break point on a function call.  Run the program.  After debugger stops at the break point, Go to the Windows menu and choose Disassembly (or ctrl + alt +d).

#5255732 Problem with reading a binary file into a vector

Posted by Rattrap on 05 October 2015 - 06:09 PM

Additionally, you can move the vector declaration after you have determined the size of the file and pass the size through the constructor.

#5255731 Problem with reading a binary file into a vector

Posted by Rattrap on 05 October 2015 - 06:05 PM

Try using resize instead of reserve. Resize will allocate enough usable space, reserve is used to prevent reallocations when using push_back and emplace_back.

Try calling size after you called reserve to see how much space you had available.

#5255675 Cross platform execution branching?

Posted by Rattrap on 05 October 2015 - 10:40 AM

But I don't think #defines are globally recognized right?


No, but instead of defining those in a file, you could feed it "globally" through the compiler.  Most compilers will allow you defined values as part of the compile settings.

#5253710 can anyone explain const char*, char, strings, char array

Posted by Rattrap on 23 September 2015 - 12:54 PM

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.

#5253487 can anyone explain const char*, char, strings, char array

Posted by Rattrap on 22 September 2015 - 11:48 AM

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

<= n < s.size().


I don't believe it was pre C++11.

#5247539 Lots of syntax errors when using abstract classes

Posted by Rattrap on 18 August 2015 - 07:15 PM

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.