Is there a way for a library to add symbols to the standard headers ?
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 ... Thank you, Timothy Madden
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.
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
On Wednesday 01 September 2010, Timothy Madden wrote:
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.
Is "#include_next" what you are looking for?
On 9/2/2010 3:02 AM, Frank Mori Hess wrote:
On Wednesday 01 September 2010, Timothy Madden wrote:
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.
Is "#include_next" what you are looking for?
Yes, exactly, it is ! Thank you... But since a POSIX emulation layer is only needed on Windows I was wondering if there could be some way to achieve this in the windows-specific compilers ... VS and Borland C++ builder have no such preprocessor directive :( Thank you, Timothy Madden
AMDG Timothy Madden wrote:
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 ?
Boost.TR1 does this and it's a horrible mess that only works most of the time.
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 ...
In Christ, Steven Watanabe
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 ?
Boost.TR1 does this and it's a horrible mess that only works most of the time.
And a complete PITA to maintain. Don't go there unless you have to. John.
On 9/2/2010 4:47 AM, Steven Watanabe wrote:
AMDG
Timothy Madden wrote:
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 ?
Boost.TR1 does this and it's a horrible mess that only works most of the time.
Thank you. I checked how TR1 achieves this functionality. Very ingenious: - check that the standard header <cstdio> is placed in a directory named include/, so the full pathname of the standard header would end in .../include/cstdio - put my own headers in an directory named libposix/ - to get the standard header just #include <../include/cstdio> Since my header would be in <../libposix/cstdio>, there is no recursion problem any more Indeed, you were right, "it is a horrible mess that only works most of the time", for example if some other library wants to use the same trick (like Boost.TR1) to build something on top of my <cstdio>, than the other library needs to know about <../libposix/cstdio>, or else it will effectively get my symbols out of <cstdio>. Also if the compiler implementation changes the name of the include directory with the standard <cstdio>, then <../libposix/cstdio> no longer works, but I guess that would be the case anyway because of content changes that come with a new compiler implementation. Thank you, Timothy Madden
participants (4)
-
Edward Diener -
Frank Mori Hess -
John Maddock -
Steven Watanabe -
Timothy Madden