lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 2.5.1: Header change breaks MacOS X


From: Christoph Ludwig
Subject: Re: 2.5.1: Header change breaks MacOS X
Date: Thu, 25 Nov 2004 15:35:30 +0100

On Wed, Nov 24, 2004 at 08:22:20PM -0700, Carl Sorensen wrote:
> On Wed, 2004-11-24 at 16:27, Matthias Neeracher wrote:
> > On Nov 24, 2004, at 1:28 PM, Han-Wen Nienhuys wrote:
> > 
> > >
> > > What is the proper fix? Should we be using
> > >
> > >      using std;
> > >
> > > somewhere?
> > 
> > Yes, I think a declaration
> > 
> > using namespace std;
> > 
> > would solve the issue. C++ purists abhor the practice because it 
> > pollutes the program namespace with a potentially large set of symbols. 
> > The stylish solution is
> > 
> > using std::isinf;
> > 
> > in every file using this symbol, but this would be a lot of work, and a 
> > pain to write portably until all C++ platforms are up to date with 
> > their namespace usage.
> 
> Is it possible to to it the stylish way by putting
> 
> using std::isinf;
> 
> in one of the header files that's included in all of the C++ modules?

Most certainly not. Even purists will (grudgingly, perhaps) accept a using
declaration at function scope since the effect is limited to the scope. Some
even don't mind a using declaration at file scope _in your *.cc file_ because
no other translation unit will be affected. But one of the common guidelines
w.r.t. using declarations is to never put them in header files. Exceptions
need good justification.

But the "good style" aspect aside, I think `using std::isinf' will cause more
problems than it attempts to solve. AFAIK isinf() is neither part of the 
library defined by the C++ standard from 1998 nor part of the C90 standard
library. But the ::std namespace is reserved for the C++ standard library (and
those symbols from the C90 library that the C++ standard makes available
through the <cxxx> headers). So `using std::isinf;' will cause new problems on
conforming platforms because it requires that std::isinf was previously
declared.

As a simple fix I'd propose to define a function at global scope

  #if !defined(HAVE_ISINF_IN_GLOBAL_SCOPE)
  inline
  int isinf(double x) {
    return std::isinf(x);
  }
  #endif

and let autoconf determine whether HAVE_ISINF_IN_GLOBAL_SCOPE needs to be
set. It ain't be pretty but I think it gets the job done...

However, if the OP is correct this problem was created by including cmath rather
than math.h. Unless some other header is included that is documented to
declare isinf(), there's a bug waiting to bite. The C++ standard gives no
reason to assume that cmath declares isinf().

Regards

Christoph
-- 
http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html
LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html





reply via email to

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