gregoire wrote:I am building a plugin system:
do I have to force everybody that might develop plugins to use the same version of MSVC ?
As things currently stand, yes. Either that or you and your users must be very careful not to new/delete across library boundaries. If you ask for advice, I'd force users to compile with same version of MSVC or, if that is not reasonable to expect, then you provide them with POCO binaries compiled with different MSVC versions/options so they can choose the ones matching their environment.
gregoire wrote:if by design plugins are responsible of new/delete operations on the classes they add to my Factory, can I let them use the one they want (with same compiling options: \MD, etc) ?
I'm not quite clear what do you mean by "add to my Factory". Factory is supposed to produce objects and is typically responsible to call new.
With regards to memory management, if you can assure that there is absolutely no new-ing in one module and delete-ing in another, it does not matter - you can mix and match modules at will. For as long as new and delete are called in the same module they are dealing with the same heap. Once you split them and cross the module boundary (i.e. call new in one module and delete in another) all modules must be linked against the same runtime or else you will have undefined behavior. IMO, containment of new/delete within a module will be very hard to achieve so I recommend using the same runtime and same version of MSVC compiler as the safest strategy.
To elaborate a bit (Guenter please comment if you are following) I've looked into what we have and as it currently stands, SharedPtr will call delete in client's module (ReleasePolicy is a template in header), while AutoPtr will call delete in Foundation (RefCountedObject::release() is defined in implementation file). If we are to eliminate naked pointers from the interfaces in 1.4, it could be beneficial to unify this by defining RefCountedObject in the header. Still, though, this would not eliminate but only alleviate the problem by making it less likely to happen. To entirely shield ourselves from this problem, designs like the one for Notifications, where framework is passing both pointers and responsibility to release the memory between clients (which may be in different modules), should be addressed. One scenario could be banning new/delete and naked pointers altogether, provide allocation/deallocation within the framework (i.e. inside smart pointers, which can not be templates) and require all POCO libraries to be linked against the same runtime. There may be some things eluding me at the moment, but I don't think this goal is worth pursuing (i.e. feasible).