VC++ extension

[Mark Hammond]

[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?

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.

> 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>

> 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

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

Mark.