[C++-SIG] Restarting

Geoffrey Furnish furnish at actel.com
Thu Apr 29 18:04:04 CEST 1999

David Beazley writes:
 > Geoffrey Furnish writes:
 > > 
 > > I've discussed this with Guido a few times over the last two years.
 > > He's a little concerned about the idea of absorbing too much code that 
 > > he doesn't understand, into the core, because of the support issues.
 > > And he wants to see a serious consensus emerge on the SIG.  [Guido,
 > > please feel free to further clarify here].
 > > 
 > At the risk of having to go find my flame suit, I am opposed to the
 > idea of adding C++ (at the level of sophistication described) to the
 > Python core unless it can be added (or disabled) as an optional
 > feature.

The autoconf patch I will post, introduces a --with-cxx=<compiler>
option.  If you /don't/ configure with --with-cxx, then you get just
the usual Python build.  If you /do/ configure --with-cxx, then you
get main() compiled with C++, which makes global ctors get
bootstrapped, and you /could/ depending on what we all work out here,
perhaps get another translation unit folded into the build, with some
C++ support.

I do not propose a trojan horse.  I propose a configure time
selectable additional support facility for C++ based extension writing.

 > Otherwise, I fear that this will be nothing short of a
 > maintenance nightmare for Guido and the rest of us who are quite happy
 > with the current C API.  

I've heard this man times, but I don't really think what we're talking 
about here is that big a deal.  Sure, if one doesn't know /any/ C++, I
suppose anything could look a little intimidating.  But the Python/C++ 
code I envision, is pretty tame.  What you can do with it, sure,
that's supposed to be aggressive.  But the actual support facility
itself, that I think should be bundled with the Python distribution,
is not rocket science.

 > The fact that this "enhancement" only works with a few compilers
 > also suggests that it would create problems for anyone wanting to
 > write a portable extension using this interface.

I think its important to project a sense of calm on this topic.  We
should all keep in mind that C++ got its first official international
standard, in July of 98.  C was standardized in '89.  The quality of
C++ implementations has been improving at a never-before-seen rate of
convergence.  egcs in particular, is by now better than practically
every vendor compiler on the market, by a wide margin, and is free.
Only the EDG strains, and maybe the IBM Visual Age C++ compiler, are
actually better in an objective sense.  The egcs strain that I'm
talking about hasn't been "released" yet, but authoritative
word on the street says, "keep your eyes open".

 > With that said, I'm not entirely opposed to having better C++ 
 > support.   I can only hope that it is done in a halfway sensible 
 > and portable manner.   Just my 0.02.

Well, I hope you will define those terms a little more precisely.
No need for the flame suit, but please do just say clearly what you
mean.  I don't know what part of what has been proposed looks
"nonsensical" to you, and also "portable" is not a very precise word.

To me, "portability" is best achieved by writing to an ISO standard.
The company I work for now, for instance, has been playing the
portability game according to the rules of Sun and Microsoft for a
long time.  The result is that our code base has hundreds of
constructs that are flat out illegal according to the ISO C++
stnadard, and /will not complie/ with gcc or KCC.  Is that "portable"?
Not in my book.  Sun and MS love it, ISO won't recognize it.  I don't
call that "portable".

Okay, so suppose we consider "ISO C++" to be the measuring stick for
Py::C++ bindings.  Then we can consider the fact that not all vendor
compilers currently in service on the workstations of all Python
users, will compile the code.  What conclusion is to be drawn?  That
we should down grade the Py::C++ code so that it compiles on a subset
of the language which is disjoint with any official standards
document, and is consequently not even actually clearly defined in
writing anywhere in the world--or that maybe some people need better
compilers in order to use the code?  Which viewpoint is actually
harsher on the Python customer?

Remember, we are not proposing that any of this code be introduced in
a way that would require /all/ Python customers to "go get new
compilers".  configure without --with-cxx, and all is as before.  So
people who want to use the C++ binding, would need compilers up to a
certain grade.  What grade should that be?  Remember, egcs is free,
and is extremely close to total ISO compliance at this point, and
moreover, is going to be relabeled as GCC 3.0 shortly.

Maybe it would be useful to be even more specific.  Then people can
comment on this one feature at a time, rather than Yes/No ISO.

I think the Python C++ bindings should live in namespace Py.
I think we should keep avoid use of partial specialization since MS
won't have it until at least VC++ 7.0.
I think we should avoid having any part of the C++ binding /depend/ on 
member templates, because Sun 5.0 doesn't have them.
I think we should provide some conveniences as optional facilities
that are implemented with member templates.  By making these "inline
member templates", they'll work with MS VC++ 6.0, Code Warior, EDG
variants, egcs.  Perhaps this could be controlled via "member template 
autodetection" in the configure, resulting in a config.h flag that
would allow CPP based inclusion or exclusion of these facilities,
depending on whether the compiler the user is using at configure time, 
is up to the task or not.

Peronally, I see this as a very sensible, extremely portable,
deployment plan.  What do David and others think?

Geoffrey Furnish            Actel Corporation        furnish at actel.com
Senior Staff Engineer      955 East Arques Ave       voice: 408-522-7528
Placement & Routing     Sunnyvale, CA   94086-4533   fax:   408-328-2303

"... because only those who write the code truly control the project."
						      -- Jamie Zawinski

More information about the Cplusplus-sig mailing list