Click here to Skip to main content
15,352,974 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.
Paul Michalik 17-Oct-10 4:20am View
   
Added upvote since of all proposed solutions this is the only one I'd really recommend. Though I appriciate the effort invested by @Joe, I'm sorry to say that, don't do it. You just replace one possible source of errors with another one.
Paul Michalik 13-Oct-10 13:50pm View
   
Hm, you are writing the the past form, so does this mean that it is not crashing anymore? It definitely can not crash because of the std::map initialization, if you rewrote DeserializableClassMapEntry as I suggested.

Generally, this kind of 'pluggable' type-dependent information has several drawbacks:
(1) It depends on too much stuff which the standard calls 'implementation defined'. For example, it requires to structure your program to be such that the registrar symbols are not kicked out by the various optimization strategies: Try to compile the auto-deserializable classes into a separate library (static or dynamic) and link them to a test executable. You will see, that depending on what is seen by the program, some registrars get initialized others get not.

To be continued...
Paul Michalik 9-Oct-10 7:11am View
   
it's not a bug it's a feature (see below)
Paul Michalik 28-Sep-10 2:15am View
   
No, it's not since atoi is read-only operation.. Writing to 'buffer' is inherently thread unsafe. You cannot generalize that to the above statement. In Ash's example, A::do_something could be designed to be thread safe. The function from the first example is not safe if looking at it alone: the assignment to a std::string& is not thread-safe. However, if used in thread local context it could be safe to use it, for example:

class A {
private:
void Split_Into_Path_And_File(...);
//...
public:
void DoWork() {

ThreadPool.StartNew([] -> (const char* str) {
std::string p, f;
Split_Into_Path_And_File(str, p, f);
DoSomethingThreadSafe(p, f);
});
}
}; // A end
Paul Michalik 26-Sep-10 5:19am View
   
I vote for the 3rd point.
Paul Michalik 26-Sep-10 5:08am View
   
Hm, I am not sure if I would set "recursive" = "functional"... Anyway, I'd in turn recommend F# and a very interesting concept called "Axum", a language targeting asynchronous applications with functional and imperative features. If I had to summarize that from my point of view: purely functional languages are confusing me. On the other hand, I seem to have much less problems with the functional features of imperative object-oriented languages - which indeed are useful and understandable...
Paul Michalik 22-Sep-10 18:03pm View
   
Because both are references to objects which are "non-local" from the function's perspective. If this function is executed concurrently by different threads you might get a race condition when writing to Path and/or File. With the above version, only a thread local (stack) object is generated, hence it's thread safe.
Paul Michalik 4-Sep-10 7:45am View
   
The and <> tags are driving me crazy - I had the reload and re-edit the post exactly 5 times to get these few lines of text right...!
Paul Michalik 15-Aug-10 7:57am View
   
I am sorry? That is exactly what the first sentence of my post says. Everything is passed by value, unless you explicity require passing by "ref". The key point which is often misunderstod by beginners is that the value of a reference type is a reference (actually a pointer) to object on the heap... You should correct (or better re-write) answer 3, since it contains several misleading statements.