I agree with terceiro, you do forget how to hide a bike - mine got stolen from the front garden last year because I didn't hide it well enough. (Sorry, Antonio, couldn't resist :-) My bike really did get stolen, but you've made me see a funny side to it! By the way, feel free to add yourself to the PStreams as "Helper" or whatever you think appropriate.)
That reminds me -- cdevienne, to record that you're the maintainer of libxml++ log in to advogato, then go to the libxml++ project page and choose a "Type of relationship" at the bottom of the page.
Been distracted from finishing the next version of PStreams by many things ...
Tweaked Marc Rochkind's Ux code to work with recent versions of GCC and glibc and sent him the updates.
Spent some time reading the strawman proposal for a C++ memory model, got confused by an example until I realised there must be a typo, which has now been corrected. That means I did understand it correctly - good!
Backlog of libstdc++ work is increasing. Lots of half-finished doc updates that I need to polish off. The std::tr1::shared_ptr in libstdc++ is still sub-optimal, using empty critical sections to provide full bi-directional memory barriers. One of the super-optimised asm versions in Boost's shared_ptr has turned out to cause a problem in certain situations with a certain compiler and so there's an update to 1.33.0 already, so there's something to be said for playing it safe - especially when I'm still learning about all this sink/hoist/yo-ho-ho-and-a-bottle-of-rum stuff. "Correctness is a constraint; performance is a goal."
Got sick of poor developer docs for Apache and am improving a small part of them that I happen to be familiar with (actually, the code in question is part of aprlib.) Have some ideas for some C++ types for use with aprlib, to register objects and cleanup functors (not just int (*)(void*) functions) with pools, kinda similar to TnFOX's transaction rollback stuff, but with pools.
I'm about to leave the job I've had for the past 6 years, which was mostly Apache-1.3 module development in C++, so I figure I've got a fair bit of relevant experience to make use of and now that I'm not constrained by business requirements (i.e. only using apache 1.3) I can play with 2.0 and the APR. The state-of-the-art of writing Apache modules in C++ doesn't seem to be very advanced. I see no reason why you shouldn't be able to write modules using exceptions and other modern C++ features and not worry about interfacing with C. I'm probably missing something that already makes it easy. Step 1: make mod_cplusplus exception safe.
Hope the new job lets me contribute to free software, I really don't see myself staying anywhere else for 6 years if I don't have permission to write (and license) my own code in my own time. It'll be nice to finally a recent version of GCC though, so I'll know code I worked on is being used :-)
