[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: compiling development sources
From: |
Jaroslav Hajek |
Subject: |
Re: compiling development sources |
Date: |
Wed, 10 Feb 2010 22:08:25 +0100 |
On Wed, Feb 10, 2010 at 9:58 PM, John W. Eaton <address@hidden> wrote:
> On 10-Feb-2010, Jaroslav Hajek wrote:
>
> | I consider defining macros for replacing identifiers as a *very* bad
> | idea in C++.
>
> | I think these gnulib headers should only be included in
> | isolated files.
>
> I'm OK with trying to limit where these headers are included. In some
> cases, it is easy to do that and provide wrappers for the functions.
> But in others, it is not so simple. For example, if you need to use
> an interface that depends on a structure that is defined in a header
> file, like "struct tms" from <sys/times.h>.
>
> Also, we can't control whether a C++ header like <ctime> will
> ultimately include the C header <time.h>, can we?
>
> Is it a violation of the C standard to have C headers #define the
> symbols they provide?
>
> jwe
>
I don't know, but I bet it's a violation of the C++ standard if
<cstdio> includes some #define for fprintf, so that
std::fprintf ultimately becomes std::rpl_fprintf (even if it actually
worked). In C++, common identifiers can appear in multiple scopes, so
if nothing else it's very bad manners for a C++ library to have such
#defines.
If some of these leaks really can't be avoided, we should put
somewhere a big fat warning "DON'T use" with a list of identifiers
possibly broken by gnulib. I can easily imagine myself using an ad hoc
variable called tms.
--
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
- Re: compiling development sources, (continued)
- Re: compiling development sources, Carlo de Falco, 2010/02/10
- Re: compiling development sources, Carlo de Falco, 2010/02/10
- Re: compiling development sources, John W. Eaton, 2010/02/10
- Re: compiling development sources, Michael D Godfrey, 2010/02/10
- Re: compiling development sources, Jaroslav Hajek, 2010/02/10
- Re: compiling development sources, John W. Eaton, 2010/02/10
- Re: compiling development sources, Jaroslav Hajek, 2010/02/11
Re: compiling development sources, John W. Eaton, 2010/02/10
Re: compiling development sources, Carlo de Falco, 2010/02/10
- Re: compiling development sources, Ben Abbott, 2010/02/10
- Re: compiling development sources, Jaroslav Hajek, 2010/02/11
- Re: compiling development sources, Carlo de Falco, 2010/02/11
- Re: compiling development sources, Jaroslav Hajek, 2010/02/11
- Re: compiling development sources, Carlo de Falco, 2010/02/11
- Re: compiling development sources, Jaroslav Hajek, 2010/02/11
- Re: compiling development sources, Carlo de Falco, 2010/02/11