Jump to content

  • Log In with Google      Sign In   
  • Create Account

We need your help!

We need 1 more developer from Canada and 12 more from Australia to help us complete a research survey.

Support our site by taking a quick sponsored survey and win a chance at a $50 Amazon gift card. Click here to get started!


Member Since 09 Dec 1999
Offline Last Active Yesterday, 11:58 PM

Posts I've Made

In Topic: Md5 Password Hasher would you use this.

17 July 2015 - 07:09 PM

If you want a one size fits all, don't want to think about it choice for storing password hashes, just use bcrypt. There are situations where it's not the best choice, but it's a good default at the moment.

In Topic: typeid operator

16 July 2015 - 01:11 PM

hash_code() can return the same for different types due to hash collisions. name() can be the same for different types because name isn't guaranteed to be a fully qualified name (if you have class Foo in namespace bar and class Foo in namespace baz, name() might be "Foo" for both, despite being different types).


I've been told that originally people wanted stronger guarantees for name(), but someone noted that with dynamic linking it was possible for two modules to have different types with the exact same qualified name and then all sorts of corner cases came out and we got a water downed type_info specification. I don't know how true this is, but I do know that other aspects of RTTI that seem screwed up are due to supporting dynamic linking. In any case, one way to get around the problem of dynamic libraries containing potentially the same named types is to embed something like the base module address to the name or hash code. However, if you do that, if the module loads in a different address in two different runs, then name() or hash_code() could change between runs.

In Topic: Explain: Finite State Machines

13 July 2015 - 02:09 PM

So what did you not understand about Wikipedia's article on finite state machines?

In Topic: Using CComPtr with D3DXFRAME

08 July 2015 - 02:25 PM

Normally D3DXFRAME objects are allocated via D3DXLoadMeshHierarchyFromX() or D3DXLoadMeshHierarchyFromXInMemory(). As such, only the root node in the D3DXFRAME hierarchy needs to be managed. If you do use a shared_ptr to manage it, make sure you use a custom deleter that uses D3DXFrameDestroy() instead of the default delete. Otherwise you may not free child and sibling nodes in the hierarchy.

In Topic: Using CComPtr with D3DXFRAME

07 July 2015 - 09:54 PM

D3DXFRAME isn't a COM interface, you shouldn't use CComPtr with it.