
On 9/2/2010 2:02 AM, Edward Diener wrote:
On 9/1/2010 5:16 PM, Timothy Madden wrote:
Hello
To write a library to add a POSIX emulation layer on Windows, is there a way to add symbols from my library to C/C++ standard library headers, without getting into recursive inclusion ?
For example, is there a way to get the 'Additions to fstream' from the boost::filesystem library, actually look like they are added to the standard <fstream> header ?
I know users can use #include "cstdio" (with quotes instead of brackets) throughout a project, in order to later be able to include some local version of the header, if the need for it arise during during some porting at a later time for example.
However this works for user-level code, while for a library it is not that simple any more ...
Why would you want to add functionality to a standard library header/class as opposed to just creating functionality which uses a particular standard library class or function, which anyone can do ?
The only reason to do this is if one is trying to correct a deficiency in some compiler's implementation of a standard library header, but even that is fraught with difficulty and needs to be done very carefully. Usually this is done by adding symbols to namespace std, which is certainly allowed. But adding new things to namespace std which has nothing to do with the actual standard library is not something to be recommended, as it will upset end user's expectation of what is in the standard library as part of the C++ standard.
Perhaps you should rethink your goals for your POSIX emulation layer for Windows and realize that placing it in your own namespace is better than adding it to the std namespace in every way. You should not be trying to confuse end-users as to what is in the std namespace and what is not.
I could hardly place symbols in my own namespace if I want actual /POSIX/ emulation. The bad news is POSIX defines certain symbols directly in the C standard library headers. Do not know about C++ headers though as the last time I checked the POSIX C++ bindings were still a draft specification. But of course I know that messing with the standard library headers is bad practice in the least of it. On the other hand, if you want to supply functionality that should rightfully be in the platform or the OS, you might as well expect to get to mess with such things ... Not to worry, though, POSIX specifies that all those additional symbols exist only if user defines _POSIX_C_SOURCE (or the superseded _POSIX_SOURCE), which in turn is implementation-defined, as it starts with an underscore. So all the bad things should happen only if the user asks for them. Thank you, Timothy Madden