[C++-sig] Conversion of python files to C++ ostreams
s_sourceforge at nedprod.com
Mon Apr 5 14:03:17 CEST 2010
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
> - 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
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 :)
More information about the Cplusplus-sig