Hello, One thing I feel concern about Crypto++ these days is its dependency to platform-specific tools, such as sockets and file operations, though it's a bit misleading to call it as "dependency". It contains very useful tools for those who use them, but for others, that dependency sometimes increases build time very much and call in other unwanted effects. I use Crypto++ as neither static nor dynamic lib, but rather I use it per class to get necessary functions, because I sometimes modify STL itself that is also used in Crypto++, or add whole program optimization to make executable size smaller.
For example, basic class such as integer.h/cpp includes iosfwd/iostream and you need iostream at link time. iostream is one of C++ standard, but very dependent on platform and library implementation, as you find old iostream / new iostream, SGI iostream, and so on. Another example is socket-related, in Windows, winsock2.h/winsock.h/windows.h/mswsock.h/ws2tcpip.h conflict occurs even when I use none of those network sink in Crypto++. More obscure problem is, I need to link to hex.cpp though all stages in my use of Crypto++ there's apparently no operation that requires hex encoding/ decoding! If Crypto++ is pure algorithmic/arithmetic collection, it will have algorithms in pure / lightweight form like STL <algorithm> and should have other sink/source interface helpers separated from algorithms themselves. In my observation, current Crypto++ abstracts them, but not separates / encapsulates them in effective manner. To sum it up, is there any future design plan of Crypto++ for this issue of lightweightness/less-dependency/shorter-build-time? Best, Kenneth
