[C++-sig] Conversion of python files to C++ ostreams

[Niall Douglas]

On 4 Apr 2010 at 19:29, troy d. straszheim wrote:

> The first main change was to gut a bunch of the old preprocessor gunk 
> and replace with boost.fusion.  This would make my branch incompatible 
> with Niall's threadsafety changes;  on the other hand, it would probably 
> be much easier to implement them.  as<...> and scored overload 
> resolution are built on top of the fusionization stuff.   I've removed a 
> great many old workaround #ifdefs.

If I have to rewrite the patch because you have eliminated 
preprocessor complexity then I am extremely happy!

Back in the day when I was first developing the patch there was a 
discussion about how best to modularise the threading support such 
that *any* threading system could be added. The upshot that I 
remember (and I might add that my memory is definitely increasingly 
rewriting itself with age) was that Boost was going to be getting its 
own threading support module and then thereafter C++ itself. I have a 
vague recollection of strongly criticising the POSIX thread API which 
in my opinion is very poorly thought through, and then a discussion 
erupted about how a proper threading API should look. Needless to 
say, it all culminated in nothing.

I think, with hindsight, that we all were going at it wrong at that 
time. What we *ought* to have been doing is an upcall mechanism such 
that routine X is always called just before entering C++ space and 
routine Y is always called just before entering Python space. That 
way you get the best of all worlds.

> * None of it is integrated with boost.build:  the branch builds against 
> any boost >= 1.38 or so.  It uses CMake.

I've said it before and I'll say it again: Boost.Python ought to have 
SCons build files in there as standard. Moreover, SCons just keeps on 
getting better with age too, the most recent version allowed me to 
greatly simplify my previous SCons setup. It's getting a real good 
balance of power and simplicity, though the learning curve is still 
extremely steep.

> - Figure out what else should go in there, e.g.
> 
> --- Niall's threadsafety patches
> --- the recent std::ostream& stuff
> --- better indexing suites (I have an improved map_indexing_suite 
> sitting around that should go in)
> --- maybe some of your numpy stuff?
> --- things laying around on various wiki pages
> --- docs, docs, docs
> --- examples, examples, examples
> 
> - Get all that implemented separate from boost trunk, beat on it at 
> length, including having "power users" actually try it with their 
> production apps:  py++, TnFOX, my physics stuff, etc.
> 
> Then boost.buildize and commit wholesale back to trunk.   That's my two 
> cents, anyway.

The older I get the more I like encapsulating-but-abstracting 
template parameter classes. I think that the threading support is 
best implemented as a simple upcall hook for C++ <=> Python 
traversal, then you get lots of other potential applications of the 
upcall too.

This time last year I had thought that I'd have GSoc mentoring time 
during the summer. I'm sure had I been allocated a slot I'd have 
created the time, but as it happened most of the summer got sucked up 
in all sorts of unforeseen events created by the starting of my 
consulting company. This summer shouldn't be so unpredictable - I 
might even get a TnFOX release out, hopefully with OpenCL and AVX 
support - but sadly paying work must take precedence above all else. 
I like consulting more than any other job I've ever had, but I do 
find that paying work tends to skirt major refactoring in favour of 
patching up cracks even if it costs them a lot more in the long run. 
Understandable I suppose given the money hole refactoring can become.

Anyway, if you'd like me to contribute the generic upcall support 
complete with docs and unit tests to your new code branch then let me 
know. I'll create the time necessary :)

Cheers,
Niall