Hi Christian,
I have repeatedly stated my belief that it is futile, if not insane, to attempt to make a system that uses either DirectX or OpenGL.
That is the reason that I explicitly suggested boost::directx, rather than boost::killmenow.
My apologies if you understood this as being targeted against you. I was strictly commenting joel's remark. No offense.
In short, even then we don't even have something useful for boost.
Perhaps. I only wished to raise the issue and provide some demo code. What happens after that is up to the boost community.
Yes, indeed. This is what this thread is about. As for the actual thread topic, you have a flaw in your logic. Many people use WinAPI. Should boost include a WinAPI library? Many people use Qt for their C++ GUIs. Should boost include Qt support? Etc. Your proposal, while intriguing, is very domain specific. No problem there, which boost library isn't? However, the domain here is a library tied to a few platforms (PC, XBox360) instead of language constructs (lambda, phoenix, fusion), common tasks such as parsing (Xpressive, Spirit, regex), common functionality (bind, any, signals/signals2, threads)... At first glance, Boost.Python breaks this pattern. However, Python is a freely available language, and Boost.Python concerns itself with the *language* Python, not with a specific Python interpreter or similar. I strongly suggest you do the same as Adobe did (stlab.adobe.com). They have their own open source libraries. Many of them are very useful. Out of this codebase, GIL was added to Boost. Perhaps your library yields at least a subset that can be added to Boost. But for now, "let it grow". Regards, Carlos