Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 09 Dec 1999
Offline Last Active Private

#5240120 Explain: Finite State Machines

Posted by SiCrane 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 SiCrane 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 SiCrane on 02 July 2015 - 02:12 PM

See also property()

#5236794 C++ Best Scripting Language

Posted by SiCrane 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 SiCrane 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 SiCrane 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 SiCrane 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 SiCrane 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 SiCrane 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 SiCrane 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 SiCrane 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).

#5235981 Do you comment Above or Below your code?

Posted by SiCrane on 21 June 2015 - 12:45 AM

I think the only time I've ever seen comments below code is in Python where there's a comment for what indented block was just exited or in assembly where you also see comments for end of loops, functions, data blocks and so on. Ex:
for loop_variable in range(x):
    # way too many lines of code
# end loop_variable for
Usually curly brace languages put similar comments on the same line as the curly brace, so it's not really below the code.

Actually, I think there was one time I saw an ASCII art comment with arrows pointing to individual characters in a string literal that had the odd characters commented above and the even characters commented below (or maybe vice versa). Something like:
//                          +--- cow is an integer
//                          | +- moose is a float
//                          v v
const char * type_string = "ZZff";
//                           ^ ^
//                           | +- cat is a float
//                           +--- goat is an integer
Hopefully the actual code was less silly than this.

#5235730 Interpreting unordered_map key as blob of bytes for hashing?

Posted by SiCrane on 19 June 2015 - 12:00 PM

If you were summing the hashes, then that would explain getting a lot of collisions. Simple sums have a tendency to introduce non uniform distributions in the bit patterns. You could try using boost's hash_combine algorithm which basically boils down to:
template <class T>
inline void hash_combine(std::size_t& seed, const T& v)
    std::hash<T> hasher;
    seed ^= hasher(v) + 0x9e3779b9 + (seed<<6) + (seed>>2);

#5235044 deprecated conversion from string constant to ‘char

Posted by SiCrane on 16 June 2015 - 02:02 AM

To just get rid of the warning, you could change the type of outre to const char *. Note that your function as written is returning a pointer to a stack allocated buffer, which can cause bad things to happen. Since you're using C++, you may want to consider returning a std::string by value instead. 

#5234805 Simple template doesnt compile

Posted by SiCrane on 14 June 2015 - 06:37 PM

You can't cast a pointer to a member function to a regular function pointer. A pointer to a member function often isn't even the same size as a regular function pointer. A regular function pointer is often just the address of a piece of code, but a member function could be that kind of address, or an index into the vtable or an index into the vtable plus weird bookkeeping information to find the right subobject from a leaf node of a virtual inheritance hierarchy. 


Note that what you're trying to do can already be done in C++ with std::bind().