quote author="tabish...@gmail.com"> On Thu, 2011-12-15 at 10:11 +0400, Ivan Pechorin wrote: > 2011/12/14 mikmela <[hidden email]>: > > I'm having a lot of issues passing std::strings into ActiveMQ-CPP > interfaces, > > i.e. Connection, Session, Message and etc. > > Even though I'm using MS VS2010 to build both activemq-cpp dll and my > > application with the same version of multithreaded c-runtime dll > > MSVCP100.dll, MSVCR100.dll(/MD) , string object passed from the app to > > activevemq-cpp dll looks corrupted in debugger when I step into > activemq-cpp > > code... > I suggest to change #define _SECURE_SCL from 1 to 0 in the following 2 > files: > > src\main\activemq\util\Config.h: > src\main\decaf\util\Config.h: > > This is the only change I remember required when using ActiveMQ-CPP > 3.4.x with MS VS2010. > > _SECURE_SCL is defined to 1 by default in VS2005 and VS2008, but this > was changed and VS2010 defines it to 0 by default. > > Compare the first paragraph in the following pages: > http://msdn.microsoft.com/en-us/library/aa985896(v=VS.90).aspx > http://msdn.microsoft.com/en-us/library/aa985896(v=VS.100).aspx
Yes, _SECURE_SCL is the cause std:: string object corruption (Thanks Ivan!). Microsoft introduced it to fight buffer overrun attempts. So, when this flag is on - the size of the any STL container object (and STL string is a container) is increased due to creation of so-called "aux object" that stores pointer the container itself. This allows the iterators to "talk" to their parent container to determine its current location... You can read http://blogs.msdn.com/b/vcblog/archive/2007/08/10/the-future-of-the-c-language.aspx for more details. The bottom line is that STL containter object size will be different in a dll vs a client app or another dll compiled with different value of SECURE_SCL and, as consequence, you'll experience craches if such container objects gets passed back and force... It seams that _SECURE_SCL by default (if not defined by user in project properties) is enabled in src\main\activemq\util\Config.h and src\main\decaf\util\Config.h. I think, it's not a such good idea - 1) it has pretty serious perfomance implications - a)"aux object" is dynamically allocated b)looping using iterators will be much slower as well! 2) activemq should not impose any specific behaviour, but go with Microsoft chosen defaults (According to Microsoft docs: in VS2010 it is disabled by default in release mode and enabled in debug, and in VS2005 and VS2008 it is set to 1). This way, most of the users who are not aware (or do not care) of this Microsoft specific compilation flag and not explicitly setting it in their app projects willl get automatically matching activemq-cpp dll. Microsoft even recommends to have a separate configurations dedicated to this flag, i.e. release+_SECURE_SCL=0 and release+_SECURE_SCL=1. Another, approach is to always use _SECURE_SCL=0 and document it. In this case, users that concerned about buffer overruns and ready to sacrifice performance, will be explicitly overriding it in their environment. -- View this message in context: http://activemq.2283324.n4.nabble.com/Problem-using-ActiveMQ-CPP-interfaces-where-std-string-are-used-as-parameters-tp4196115p4259238.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
