Click here to Skip to main content
15,867,704 members

Comments by Paul Michalik (Top 14 by date)

Paul Michalik 10-Feb-12 2:34am View    
Deleted
Faster? Probably not, a dynamic_cast can have considerable cost with complex type hierarchies. But it is the only safe way to do that.

I also corrected some typos, it's hard to get through all the html tags...
Paul Michalik 30-Apr-11 5:29am View    
Well, the point is that given logically identical high-level code, the native assembly code generated by a "native" compiler can and usually will be different from the code generated by JIT compiler. In many cases the latter has a bigger chance to be optimized better and thus could run faster...
Paul Michalik 28-Nov-10 6:25am View    
No, never do this. This is ill-formed code, since the declaration and the definition of Player's methods are in different namespaces now. Player's declaration is in visual namespace and the definitions of it's methods are in global namespace. The 'using' directive does not open a namespace!
Paul Michalik 23-Oct-10 8:21am View    
No, you cannot make the map const since it needs to be updated by the initializers of your registration objects. There are two problems with this solution:
(1) the initialization of such "Meyer's singleton" is not controllable in concurrent environments
(2) you do not have control over the destrction of the map instance. This is completely up to the runtime.

If this does not matter, you are fine.
Paul Michalik 17-Oct-10 5:06am View    
Oh, I forgot I cannot edit comments. Anyway, I point you to the second paragraph of my previous comment. The pattern, or rather, idiom you are using is called 'pluggable-factories' in the c++ world. I recommend to google for that phrase and read a bit about the common problems.

With regard to your specific problem: Again, there will be no static intialization fiasco if you assure, that the shared map instance gets initialized before any of the DeserializableClassMapEntry objects try to access it. This can be done as sketched above. Then, there is no reason to put all the class statics definitions into one file. The order in which the DeserializableClassMapEntry instances are initialized is unspecified, but it should not matter. The important thing is that they are initialized at all, which depend on the structure of your program, as mentioned above. The problem is that the linker might decide to optimize your DeserializableClassMapEntry instances away completely, if there is not a explicit usage of them. The tricky part of c++ pluggable factory design is to assure that this does not happen.

The macros are quite ugly, I would recommend to completely avoid usage of macros in a c++ program. This is rarely necessary and can be in most cases replaced with type safe and much more powerful template formulation.