Re: extern "C" ?

["Brian Weed" <bw@...>]

> // lua.hpp
> extern "C" {
> #include "lua.h"
> }
>
> What's wrong with that?

1) Joe Programmer has to make modifications to a system before it works for
him.  Thats whats wrong.  Some 3rd party libs (like pnglib for example) even
ship with the project files for various compilers so Joe Programmer doesn't
even have to create them.  Anything to save Joe Programmer time is key.
Thats the whole point of 3rd party libs (even the free ones).  Joe could
write his own scripting language or bitmap file format, but these libs exist
to save him time (and to build standards).

2) The .hpp thing would not work for me in my Codewarrior build environment
because of the precompiled Carbon headers.  I had to add the extern "C" to
every header file, not just the public ones, and therefore, I would have had
to modify all Lua files to #include whatever.hpp instead.  It would have
been easier for me to rename every .C to .CPP.  I'm not saying that my
Codewarrior build environment is perfect, but the less mods I have to make
to get something to compile, the better.

3)  This defeats information hiding.  By using that .hpp, you are making
assumptions about the library, and if the library ever changed to be a C++
lib, it would all of a sudden not link for you.  But if it had the #ifdef
__cplusplus thing placed by the "owners", then you would not have to even
think about "what do I need to do to get this thing to compile?".  The
"owners" only have to do it once, where as the 20,000 Joe Programmers using
Lua all have to do it manually.  Here is a similar example.  In the Mac API,
pretty much all header files are included like this.

#ifndef SOMEHEADERFILE
#include "someheaderfile.h"
#endif

#ifndef SOMEOTHERHEADERFILE
#include "someotherheaderfile.h"
#endif

They did this to speed up compiles because the header file is not opened if
it was already included (and therefore defined a SOMEHEADERFILE).  If this
check was inside the header file, then there is a disk hit to open and read
the header only to then find out that it was already included.
In this environment, Joe Programmer must know something about the header
files he is including for fear of including them twice.  I am of the mindset
that all Joe should have to do is just include the header, and not worry
about "gee, did I include it correctly?".  Joe's code should look like this:

#include "one.h"
#include "two.h"
#include "three.h"

and not

#ifndef ONE
#include "one.h"
#endif

#ifndef TWO
#include "two.h"
#endif

#ifndef THREE
#include "three.h"
#endif


I don't want to waste too much more time on this topic, since I'm sure the
Lua guys have heard all this before, and if they haven't changed the code by
now, then we should not bug them any more about it.

Brian.

----- Original Message ----- 
From: "Eric Tetz" <erictetz@yahoo.com>
To: "Lua list" <lua@bazar2.conectiva.com.br>
Sent: Sunday, September 14, 2003 8:12 PM
Subject: RE: extern "C" ?


> --- Vijay Aswadhati <wyseman@pacbell.net> wrote:
> > C++ name mangling is not portable and hence LUA library compiled
> > for C++ by Visual C++ for instance cannot be used by an
> > application that uses Borland compiler (wont link because of name
> > mangling differences).
>
> Well, library files aren't portable either. They may happen to be
> interchangeable between a few Windows compilers (I don't know), but
> this is hardly a guarantee.
>
> > Joe Programmer should not have to modify the source code to make
> > it compile.
>
> That is the current situation. Brian did *not* need to modify the
> Lua headers. Luiz showed a simple, straight-forward solution:
>
> // lua.hpp
> extern "C" {
> #include "lua.h"
> }
>
> What's wrong with that?
>
> Cheers,
> Eric
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
>