Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 09 Dec 1999
Offline Last Active Private

#5259511 C++ Interfaces

Posted by on 28 October 2015 - 11:01 PM

You would store a (smart) pointer to the interface type. So IShader * or something like std::shared_ptr<IShader>.

#5257954 Does calling ~myclass() (destructor) deletes the object?

Posted by on 19 October 2015 - 01:44 PM

Manually calling the destructor just runs the destructor code, it doesn't free the memory for the object like delete would. 

#5241137 Md5 Password Hasher would you use this.

Posted by on 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.

#5240873 typeid operator

Posted by on 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.

#5240120 Explain: Finite State Machines

Posted by on 13 July 2015 - 02:09 PM

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

#5238911 Using CComPtr with D3DXFRAME

Posted by on 07 July 2015 - 09:54 PM

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

#5238049 Python Immutable member variables?

Posted by on 02 July 2015 - 02:12 PM

See also property()

#5236794 C++ Best Scripting Language

Posted by on 25 June 2015 - 01:41 PM

If this was an easy question to answer there wouldn't be so many scripting languages around. Scripting languages represent a series of trade-offs. Some major factors are security, speed and developer effort. For example, the C Python implementation is relatively slow, almost famously insecure and exposing your C++ classes and functions to Python is a pain even with helpers like SWIG and boost::python. On the upside, the language itself is very expressive and you can use just about every Python module ever written, so if for some reason you need to do machine learning in your scripts and then pipe your output to a database, then you're covered with minimum effort. On the other hand Lua, especially with LuaJIT, is fast and secure by default. Last I checked, creating bindings is about as easy/hard as for Python, but there are fewer libraries available and the language is arguably less expressive. Other factors to consider are things like memory footprint, developer/community support, portability and learning time.

#5236574 massive allocation perf difference between Win8, Win7 and linux.

Posted by on 24 June 2015 - 10:22 AM

But here, we're talking about allocating 30k integers, this is exactly the kind of things malloc does, and not the OS.

Actually, if you dig through the MSVC standard library source code, malloc() is just a wrapper around the OS HeapAlloc() function.

#5236462 Do you comment Above or Below your code?

Posted by on 23 June 2015 - 05:28 PM

I voted neither as it is what I do most of the time. I consider it a fail if I can't express the intent of code by naming variables or methods in meaningful way smile.png
Luckily I don't have to deal with tools that extract documentation from code comments...

I find that's really only an option when coding by myself with mature APIs. Some of the comments I've written recently are along the lines of "I know I'm requesting read access, but doing a write. Asking for write access gives a permission error", "the synchronous client is actually a wrapper around the asynchronous client, and on exception will leak running threads", "do not rearrange the order of these two statements or we could deadlock", "the standard library function does percent encoding according to RFC 1738, but we need an RFC 3986 percent encoded string", or "the name of this API function is horrible because it shadows a built-in, but management wants it named this way and I'm sick of arguing with them about it".

#5236230 perfect forwarding constructors

Posted by on 22 June 2015 - 05:01 PM

I wouldn't call causing copy constructors to fail a niche case. Especially since you can see the problem with the sample code you just posted:
SocketError a("a");
SocketError b(a);
With MSVC this produces the error: error C2664: 'std::basic_string<_Elem,_Traits,_Alloc>::basic_string(const std::basic_string<_Elem,_Traits,_Alloc> &)' : cannot convert parameter 1 from 'SocketError' to 'const std::basic_string<_Elem,_Traits,_Alloc> &'

#5236076 perfect forwarding constructors

Posted by on 21 June 2015 - 05:10 PM

There can be run time performance issues. When you use template forwarding arguments any conversion operations that need to occur will happen inside the function body rather than outside the function body. For instance, address adjustments when moving from derived to base pointer or references. This inhibits optimizations like redundant COMDAT folding done by MSVC. For that matter if your tool chain doesn't support code folding for functions with identical machine code but different symbol names, then passing different derived type pointer or reference arguments would cause code bloat even if address adjustments aren't necessary. Like most template bloat this can be firewalled to some extent by delegating as much work as possible to non-template code. In this case meaning that damage would be limited if your member variables don't have template constructors. However, your question is specifically about applying template constructors everywhere.... 

#5236062 perfect forwarding constructors

Posted by on 21 June 2015 - 02:56 PM

Off the top of my head: 1) because it makes type mismatch error messages flag an error in the constructor body rather than the caller. 2) it increased compile times 3) it's completely pointless for primitive types. 4) it prevents you from putting the constructor body in a separately compiled source file 5) single argument universal reference constructors can have weird interactions with compiler generated copy constructors. In other words, sometimes you may think you're trying to copy your object but what you're actually going to do is try to initialize the member variable with a reference to your object. Actually it generally has poor interactions with any other overloads, but the compiler generated copy constructor is the one you'll see the most trouble with. 

#5236036 std::bind method not recognized

Posted by on 21 June 2015 - 12:01 PM

Your pointer syntax is for a non-const pointer to member function, but you've got a const member function. Add a const to the end of the pointer type. 

#5236028 Do you comment Above or Below your code?

Posted by on 21 June 2015 - 11:29 AM

Every documentation tool on this planet reads API documentation only from the comment immediately before a given class/function. So class and function comments are always before.

There is an exception for Python, where doc strings are the first line of the function or class. It's still a comment before the code proper, however (unless you embed non-trivial logic inside a default argument I suppose).