[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnulib and C++
From: |
John W. Eaton |
Subject: |
Re: gnulib and C++ |
Date: |
Fri, 19 Feb 2010 18:10:08 -0500 |
On 18-Feb-2010, Bruno Haible wrote:
| Ralf proposes:
| > I suggest you could
| > produce a helper header to #undef them again; you could even do that
| > automatically during bootstrap with above. Then only a portability
| > layer would need to avoid using these symbols in another namespace.
|
| This would only be a makeshift. Your example
|
| > class foo
| > {
| > public:
| > ...
| > int open (some, args);
| > ...
| > };
|
| > int foo::open (some, args) { ... }
|
| clearly indicates that in C++, one should minimize the use of
| preprocessor defines for lowercase identifiers.
|
| C++ has its own, idiosyncratic, ways of aliasing and overriding
| functions. If we were to change gnulib's fcntl.h like this:
|
| *** lib/fcntl.in.h.orig Thu Feb 18 23:44:21 2010
| --- lib/fcntl.in.h Thu Feb 18 23:31:02 2010
| ***************
| *** 79,87 ****
|
| #if @GNULIB_OPEN@
| # if @REPLACE_OPEN@
| ! # undef open
| ! # define open rpl_open
| ! extern int open (const char *filename, int flags, ...) _GL_ARG_NONNULL
((1));
| # endif
| #elif defined GNULIB_POSIXCHECK
| # undef open
| --- 79,89 ----
|
| #if @GNULIB_OPEN@
| # if @REPLACE_OPEN@
| ! # ifndef __cplusplus
| ! # undef open
| ! # define open rpl_open
| ! # endif
| ! extern int rpl_open (const char *filename, int flags, ...) _GL_ARG_NONNULL
((1));
| # endif
| #elif defined GNULIB_POSIXCHECK
| # undef open
| ***************
| *** 111,116 ****
| --- 113,132 ----
| }
| #endif
|
| + #ifdef __cplusplus
| + namespace gnulib
| + {
| + # if @GNULIB_OPEN@
| + int (*const open) (const char *filename, int flags, ...) =
| + # if @REPLACE_OPEN@
| + rpl_open;
| + # else
| + open;
| + # endif
| + # endif
| + }
| + #endif
| +
| /* Fix up the FD_* macros, only known to be missing on mingw. */
|
| #ifndef FD_CLOEXEC
|
|
| Then you can use the identifier 'gnulib::open' on any platform.
| On platforms where REPLACE_OPEN = 1, calls to 'gnulib::open'
| will be automatically inlined to calls to 'rpl_open', on the
| other platforms to calls to the C function 'open'.
Maybe I'm missing something, but what happens if @GNULIB_OPEN@ is 0?
It doesn't look like we get the symbol inside the gnulib namespace in
that case.
To handle all the cases, I find that I need to write
#ifdef __cplusplus
namespace gnulib
{
int (*const open) (const char *filename, int flags, ...) =
# if @GNULIB_OPEN@
# if @REPLACE_OPEN@
::rpl_open;
# else
::open;
# endif
# else
::open;
# endif
}
#endif
I would much prefer to use a solution like this instead of having to
try to dodge the possible symbol redefinitions in my code.
If we can agree on a pattern to use for putting these symbols in a
namespace, I am willing to help make the changes in gnulib.
jwe
Re: gnulib and C++, Bruno Haible, 2010/02/18
Re: gnulib and C++, Bruno Haible, 2010/02/19
Re: gnulib and C++, Ralf Wildenhues, 2010/02/20