This is the mail archive of the
gsl-discuss@sourceware.cygnus.com
mailing list for the GSL project.
Re: C++ support
- To: GSL discussion list <gsl-discuss at sourceware dot cygnus dot com>
- Subject: Re: C++ support
- From: Gerard Jungman <jungman at lanl dot gov>
- Date: Sat, 22 Jan 2000 16:56:20 -0700
- Organization: LANL T-8
- References: <388A3B1C.5E6ACA3C@bnl.gov>
Dave Morrison wrote:
>
> I haven't seen anything on this particular thread since late November,
> so here are my $0.02. I'm sure there are more elegant solutions out
> there, but here's a straightforward prescription for adding the
> requisite 'extern "C"' business in all the externally visible GSL header
> files.
Hi again.
Brian and I discussed this around that time. Here is our
irrevocable propellerhead decision:
This idea that C headers need to "protect themselves" against
inclusion in C++ code is distasteful. The origin of this idea
is apparently in the header files for stdc++ library implementations,
which use available C headers as an implementation decision. Very
reasonable if you are writing a stdc++ library implementation and
want to reuse all those C headers; not particularly relevant
for a C library defined outside a language environment. Our
feeling is that clients should have enough of a clue to know
that they are importing C headers into their C++ code and should
act accordingly. I personally always use 'extern "C"' when I mean it;
I think it is good style.
Now, if we were implmenting a C++ library and wanted to reuse our
own C headers, that would be different. Obviously in that case
the extern "C" decls would be required.
--
G. Jungman