--- "Martin v. Löwis"
Well, yes: the areas are - memory management - stdio - locales for the C library; for the C++, I'm not so sure, but I think one of the areas is - static members of class templates, in particular in STL containers
Thanks for the insight! For Boost.Python users the situation is actually not bad at all: - there is not a single malloc() in the Boost.Python sources - there is only one free(), which is specific to gcc; i.e. this code is not seen by Visual C++. - there is only one FILE* that is seen by Visual C++. It appears in the signature of a function assigned to the tp_print slot. As far as I can tell this is the only soft spot. I'll lobby for having the print function removed since it is optional and both tp_str and tp_repr are defined anyway. - nobody should be mixing C++ libraries compiled with different compilers on any platform; it doesn't get much more dangerous than this. Since Python is pure C "static members of class templates" should therefore be a non-issue. This leaves only "stdio" and "locales" to be considered. We are strictly avoiding both in C++ to maximize portability. I/O is intrinsically slow and therefore there is no point in coding it in C++, especially since Python's I/O is very fast anyway. I am not sure about locales because this is not very interesting at all for scientific code development. Under the assumption that the one tp_print function in the Boost.Python sources is removed, I am arriving at the conclusion that it is more than pure luck that all our tests work. People writing C++ extensions view the compiled layer as low-level number-crunching back-end. It is quite natural not to find I/O and use of locales in such code. And even if there is I/O, chances are it is done via std::cout rather than a raw FILE* obtained from Python via difficult to memorize incantations (I don't even know how to do it). Cheers, Ralf __________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com