Hi all and thanks Wei Dai for maintaining this great library,
Using Crypto++ 5.1 + STLPort 4.5.3 + VS.NET 2003 + the latest MS
Platform SDK, I had those 2 trivial problems about Windows and C++,
though I had easy workarounds for them.
1. In some header file (HeaderA.h) for my own C++ class,
"using namespace CryptoPP;" had conflict in BOOLEAN in another file
(HeaderB.h) including that header file. No, the header file has an include
guard, so it's not about it. In "HeaderB.h", I have a declaration of a
function with this signature:
static VOID CALLBACK someCallback(
PVOID lpParameter,
BOOLEAN TimerOrWaitFire
)
{
}
It is the signature of this callback function.
http://msdn.microsoft.com/library/en-us/dllproc/base/waitortimercallback.asp
The BOOLEAN type has conflict with ASNTag::BOOLEAN in Crypto++ 5.1
asn.h. Adding :: to BOOLEAN to indicate global namespace had no good
effect.
I removed "using namespace CryptoPP;" from "HeaderA.h" and added
"CryptoPP::" to all Crypto++ symbols and everything goes fine, except
for adding "CryptoPP::" itself. I'm a type of "using namespace std;",
therefore would like to see no conflict like this. It may be bad behaviour
of VC++ 7.1 though.
2. I rarely use MFC, but in using MFC7.1 with the setting stated above,
I built static library of Crypto++ (with STLport, of course) and used it
in Unicode-built MFC app. But only in release build, it crashed at the
place using Crypto++. (It happened on VC++ 7.0 too)
In tracing it I found it crashed at this initialization,
const std::string BufferedTransformation::NULL_CHANNEL;
in cryptlib.cpp. I suspect it's a problem of STLport, for
in stl_msvc.h of STLPort there is a line:
// # define _STLP_STATIC_CONST_INIT_BUG 1
or it may be related to CRT initialization of MFC, for I'm using
my own allocator for STLport that uses CRT.
Then I stopped using static lib and added Crypto++ source codes
directly in the project and built it, and again it worked fine.
I know there's certain merit in using static const string as
NULL_CHANNEL, to achieve higher abstraction in Crypto++,
but not sure about its effect on performance and probability
of conflict with other libraries or difficulty in some environment.
K
