VC++ extension

[Alex Martelli]

"Mark Hammond" <MarkH at ActiveState.com> wrote in message
news:lo6k5.190$dt3.1162 at news-server.bigpond.net.au...
> [Courageous]
>
> > One: if you are not actually using classes or other C++ features,
> > rename your file from .cpp to .c. The designers of Visual C++,
> > in Their Infinite Wisdom (tm), decided that this would be the
> > way you'd tell their compiler you want ANSI-C compatability.
>
> Choosing the language based on the file extension sounds reasonable to
> me! Do you mean that MSVC would be better if a .cpp extension, by
> default, used ANSI C?  What was your point then?

I think gcc and most other C++ compilers work similarly.  Don't
get me started on Unix compilers that distinguish between foo.C
and foo.c -- case sensitivity being a hot-trigger in general, but
the difference between upper and lower for a 'c' specifically is
*particularly* hard to make out in a typical ls output:-).  At least
.cxx or .cpp are easy to tell apart (I personally prefer .cxx, pity
that .cpp seems to have emerged as a de-facto standard).


> Note that the /Tc option can be used to override its (reasonable, IMO)
> guessing.
>
> > Two: If you persist in using C++, a module called "mymodule"
> > must be defined in a library called "mymodule.dll" and have
> > its init function named "initmymodule".
>
> This is true even if you use ANSI C?  So, persist or not, you need to
> do it.

Yep, this is a Python convention (and a reasonable one IMHO).


> > Three: As one other poster indicated, your init method must
> > be declared 'extern "C" { ... }'.
>
> That was the bit that should be prefixed by "if you persist in using
> C++"
>
> > This is because the designers
> > of C++, in Their Equally Infinite Wisdom (R), ah, well....
> > nevermind. Trust me, they biffed it.
>
> Sorry - I dont trust you.  Please explain, ensuring that you take into
> consideration that a level of link-time type-safety was a goal...  And
> also the fact that it is only an issue for interfacing with C - if
> everyone got modern, there would be no issue here, either <wink>

Only if everyone got modern *WITH THE SAME C++ COMPILER*, as it
happens.  Object files compiled with different C++ compilers can most
often interoperate only through extern "C" function calls (except on a
few fortunate platforms).

But of course that has nothing to do with "the designers of C++".  It's
only amazing that today, in 2000, linkers are _still_ using decorated
names as the mainstream way to support overloading, rather than more
easily generated/viewed/accessed metadata; .NET seems a step forward
in this direction (if I correctly understand the somewhat weasel-wording
on overloading in the docs -- I've just started reading them, so I may
have it all wrong...).


> > All and all, it's really easier to simply do python extensions
> > in pure ANSI-C unless you have some very specific reason to
> > use C++.
>
> Where did this assertion come from?  Simply to avoid a single 'extern
> "C"'?  That is the only point you made in this mail...
>
> There actually are a number of other issues, but they werent addressed
> here...  Personally, I believe using limited C++ for Python extensions
> is _much_ better than sticking to ANSI C

I like the CXX project.  Seems to make it a SNAP to do C++ extensions
to Python, MUCH easier than any C-level approach could ever hope to
be.  "A better C than C"...!-)


> If-for-no-better-reason-than-//-comments ly,

Ah, yes, THE killer-feature of C++, no doubt.  However, that's typically
supported as an extension by every C compiler on the market.  _My_
favourite choice for C++ killer feature is 'just-in-time declaration' --
declaring each variable when you're good and ready to initialize it,
rather than crowd all the declarations at block-start.  Once you get into
this habit, uninitialized variables almost become a non-problem.  But
it's typically not in C compilers (though I think the latest C standard
supports it?).

(Destructors for auto variables, to make sure that some clean-up action
gets executed no matted how I leave a block, are a close third... and no
C support for those, ever...).


Alex