Hello Torsten, please keep [EMAIL PROTECTED] in CC: list so that everything get archived on the BTS.
On Thu, Aug 03, 2006 at 09:59:43AM +0200, Harling, Torsten wrote: [...] > > So, to recap, even though I agree that the order of #include should not > > change your program behaviour, not defining _REENTRANT whenever you use > > ACE will *not* work. And defining _REENTRANT will make both programs > > print 36. > > That's correct, I've also found this. > > > > Another way of enforcing correct flags would be to check whether symbol > > _REENTRANT is defined, and if it is not, the header could abort > > compilation with an #error stating _REENTRANT *must* be defined. > > > > I am not convinced this is better. What do you think? > > We first used shared_ptr's about 3 or 4 years ago. That's when > this bug hid itself undetected in our software. We only wondered, > why using a shared_ptr would sometimes cause our software to hang. > > The cause was, that mostly the shared_ptr ended up having no mutex. > But, if a piece of code included the ace headers first, it might > hang when using a shared_ptr, that was constructed in a different > compilation unit. > > An #error stating _REENTRANT *must* be defined, or even better, > saying -pthread(s) *must* be used, would have prevented and fixed > our bug a long time ago. I agree, that the latter would be more > difficult, as you would have to figure out the correct option > for different compilers and architectures. > > So, I would recommend the #error. > > The boost library also #error's out, if it requires multithreading > support. Okay, I'll try to write a patch for this and submit it upstream. More on this issue soon. Regards, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
