Re: LilyPond 2.5: isinf macro/function/template

2004-11-28 Thread Andreas Scherer 
On Sunday 28 November 2004 16:25, Christian Hitz wrote:
> I got lilypond 2.5.2 to compile by doing the following things:
>
> - set _GLIBCPP_USE_C99 before #include  in the files that use
> isinf/isnan
> - replace each occurrence of isinf/isnan with std::isinf/std::isnan
>
> I don't know if this breaks compilation on linux.

The first step is (at least on /this/ GNU/Linux) already done, so the 
templated versions of the C99 functions do exist after including .  
Plus, gcc/g++ on GNU/Linux readily (too readily?!) puts this stuff in the 
"std::" namespace plus exports it to the global namespace (as shown in my C++ 
example code; maybe one would have to use a commandline option to force some 
specific behaviour).

So, I don't think your approach would (in the short run) break anything for 
Linux.  However, at least the _GLIBCPP_USE_C99 macro setting should be dealt 
with by the auto-configure setup and be put into some central configuration.

At least, there seems to be some light at the end of the tunnel. :-)

Andreas


___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel

LilyPond 2.5: isinf macro/function/template

2004-11-28 Thread Andreas Scherer 
Hello list,

I have tried to analyze the "isinf issue", resulting from my "#include 
cleanup" patch for LilyPond 2.5, and want to submit the following results, 
created with gcc/g++/libc/libstdc++ 3.3.4 on SuSE Linux 9.2.

If you look at the LilyPond C++ sources you find that the issue with "isinf" 
seems to have been addressed before.  Module  looks 
for a /macro/ "isinf" and if such a thing does not exist /and/ if the initial 
configuration finds no "isinf" function in the system libraries 
(!HAVE_ISINF), a local version of "int isinf(double)" is defined.  (I have no 
idea whether this situation ever arises.)  Module  explicitly 
has a "MacOS fix" (with an additional "FIXME"), because "source-file.hh" 
somehow pulls in , thus overriding any "isinf" macro definition.  Of 
course, after my change in  (s/// et al.), 
this "fix" does no longer work.

The attached archive contains two source files in C and C++ calling "isinf" in 
various incantations.  The C version uses  as the interface and in 
one situation I can bring gcc to at least issue a warning regarding an 
"implicit declaration of function isinf" after the line "#undef isinf".  The 
C++ version uses  as the interface and calls "isinf" (before and after 
"#undef isinf"), "::isinf", and "std::isinf" without complaint.  So, on this 
GNU/Linux system, there is no real problem with "isinf", either as a macro, a 
function, or a template.

According to "man isinf" on my configuration, "isinf/isnan/finite" are 
functions (sic!) "conforming to BSD 4.3".  It further states that "C99 
provides additional macros (!), such as the type-independent fpclassify(), 
isinf(), and isnan()" (and with option "--std=c99" plus "#undef isinf" in the 
code, gcc 3.3.4 issues the above-mentioned warning).

IIRC, MacOS X is based upon "BSD", so it is unclear to me, how this 
"BSD-conforming" function/macro should be unavailable for use in C++ 
programs.  My best guess is that BSD /only/ has the "isinf" /macro/ in 
 and no underlying "isinf" system /function/ reachable through a 
different interface (like said /template function/ in  on Linux) /and/ 
 "#undef"ines exactly this macro.

Hopefully, some member with MacOS eXperience can find a compliant solution to 
the problem.

Take care
-- 
Andreas Scherer
Saarstraße 76, 52062 Aachen, Germany
http://people.freenet.net/andreas.scherer


isinf.tar.gz
Description: application/tgz
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel