As the C++ standard describes in 3.6.2, the initialisation order of objects defined in different translation units is unspecified. This lead to the problem described below. Now my question is: What is the position of Crypto++ on this issue? Does it allow users to use its classes before entering main(), or doesn't it? If it does, then algparam.* contains a little bug, as described below, if it doesn't, well, then there's nothing to worry for Crypto++ :) I checked about 20 source files of Crypto++, and algparam.cpp seems to be the only one to use dynamic initialisation. Therefor I think that it would be easy for Crypto++ to allow users to use its classes before entering main().
Best regards, Richard Peters Richard Peters wrote: > Alexander Schmitt wrote: >> Hello, >> >> when I use the ECDH<ECP>::Domain class as a member property of a >> class an call the contructor in the of ECDH<ECP>::Domain in the >> following way: >> <snip> >> Then there are occuring a application crash, when the object is >> defined. In my case the object is defined globally in the >> application, so it crashs immediately. > > The global definition seems to be the problem. Inside the constructor, > this is used: > > line 286, file algparam.h: > if (valueType == g_typeidInteger && typeid(T) == typeid(int)) > > line 9, file algparam.cpp: > > const std::type_info &g_typeidInteger = typeid(Integer); > > This is another global definition. The C++ standard doesn't specify > the order in which global definitions are initialised, and in this > case the compiler initialises your TestClass tc first. The reference > g_typeidInteger is still set to *NULL, and the valueType == > g_typeidInteger crashes. The workaround is: put your TestClass tc > inside main(). Another option is to change > > if (valueType == g_typeidInteger && typeid(T) == typeid(int)) > > to > > if (valueType == typeid(Integer) && typeid(T) == typeid(int)) > > inside algparam.h > > > > Best regards, > > Richard Peters
