octave-maintainers
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]