Suggested changes to the singleton.hpp file to make QuantLib work better with .Net
Locked
Suggested changes to the singleton.hpp file to make QuantLib work better with .Net
 
|
There has been a problem with using QuantLib with .Net Framework. The problem is in the T& Singleton<T>::instance() method in singleton.hpp. The method initializes a static variable. Since singleton.hpp is a header file and if you use it with a cpp file that is complied to managed code, the Common Language Runtime (CLR) will initialized the variable. The CLR has the concept of AppDomains. An AppDomain is a light-weight process. Since native variables does not know anything about AppDomains, native variables does not know why it can leave the its AppDomain.
The lines 69-70 in the singleton.hpp solve this problem some what. #if defined(QL_PATCH_MSVC) inline // this seems to be required when CLR support is enabled #endif This forces the T& Singleton<T>::instance() method to be compiled with the settings.cpp file. This only works if QuantLib is in the Primary AppDomain. If QuantLib is used with ASP.Net or for with Nunit, an error will occur. The better solution is to place the singleton class under the preprocessor "pragma managed" and get rid of lines 69-70. Here is the code for the new singleton.hpp that I included in this email. #ifndef quantlib_singleton_hpp #define quantlib_singleton_hpp #include <ql/types.hpp> #include <boost/shared_ptr.hpp> #include <boost/noncopyable.hpp> #include <map> namespace QuantLib { //! Basic support for the singleton pattern. /*! The typical use of this class is: \code class Foo : public Singleton<Foo> { friend class Singleton<Foo>; private: Foo() {} public: ... }; \endcode which, albeit sub-optimal, frees one from the concerns of creating and managing the unique instance and can serve later as a single implemementation point should synchronization features be added. \ingroup patterns */ #if defined(QL_ENABLE_SESSIONS) // definition must be provided by the user Integer sessionId(); #endif #if defined(QL_PATCH_MSVC) #pragma managed(push, off) #endif template <class T> class Singleton : private boost::noncopyable { public: //! access to the unique instance static T& instance(); protected: Singleton() {} }; // template definitions template <class T> T& Singleton<T>::instance() { static std::map<Integer, boost::shared_ptr<T> > instances_; #if defined(QL_ENABLE_SESSIONS) Integer id = sessionId(); #else Integer id = 0; #endif boost::shared_ptr<T>& instance = instances_[id]; if (!instance) instance = boost::shared_ptr<T>(new T); return *instance; } #if defined(QL_PATCH_MSVC) #pragma managed(pop) #endif } #endif The "pragma managed" preprocessor will force the singleton class to be compiled to native code, if the singleton.hpp is used with a cpp file that is compiled to managed code. If the cpp file is compiled to native code, the preprocessor will do nothing. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ QuantLib-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-users |
singleton.hpp (3K)
Re: [Quantlib-dev] Suggested changes to the singleton.hpp file to make QuantLib work better with .Net
|
|
Re: [Quantlib-dev] Suggested changes to the singleton.hpp file to make QuantLib work better with .Net
|
|
Re: [Quantlib-dev] Suggested changes to the singleton.hpp file to make QuantLib work better with .Net
|
|
| Free forum by Nabble | Edit this page |