On 13 Jan 2015 at 9:01, Sylvester-Bradley, Gareth wrote:
Those unfortunately have even more confusing alternative meanings in C++. AliasLib makes me think pointer aliasing. NamespaceAliasLib is too long I think, and besides you're not aliasing namespaces, you're aliasing types.
FWIW, the "Lib" suffix doesn't follow the usual naming convention for Boost libraries [http://www.boost.org/development/requirements.html] which would make it Boost.NamespaceAlias, the Boost NamespaceAlias library, or NamespaceAlias, a Boost library by Niall Douglas.
However, I can see the point about the meanings of both those suggestions.
Thing is, it is a library for mounting other libraries into a yet another library's local namespace. I figured the Lib ought to be in there somewhere.
I do agree about BindLib being a poor name. It is actually onto its third choice of name now :( but to date, it's the least terrible of the reasonably descriptive library names I have thought of.
Yes, naming is the hardest problem. :-) Not sure what you'll think of this, but how about Boost.Using? Or Boost.NameAlias?
Boost.Using ... Yes, I think I like that a lot. Thank you.
Do bear in mind it doesn't just mount libraries into namespaces, it also provides an emulation of Boost.Test using CATCH,
That's interesting, since I've just had to do that, or rather a shim that can be switched from one to the other, myself.
Yep, exactly my need too. A modular Boost library not requiring Boost needs a substitutable unit testing framework.
I'll have a look at your repo; interested to see how you solved the BOOST_AUTO _TEST_CASE_TEMPLATE mapping to Catch.
Easy: I didn't. AFIO and Spinlock, like probably most Boost.Test users, only use maybe 5% of Boost.Test's capabilities. Essentially auto test casing, requires and checks. So that's what BindLib, soon to become Using, emulates. For most users, Boost.Test is way overkill, it is probably why people get so frustrated when small bugs remain unfixed in release builds for so long. Essentially they don't care about most of Boost.Test or the bigger picture for the library, so small unfixed problems really bug them. For me personally, AFIO simply undef's Boost.Test internal macros and redefs them to working fixed versions. I don't see the issues others do with that, but then my test framework isn't tied deeply into Boost.Test.
I've just read this back and realise BindLib is intended to convey that it's for "binding libraries", rather than being a "binding" library... but maybe I'm not the only one who didn't get that immediately.
People don't get the concept at all yet of mapping APIs from one location into many others. It is very new to C++ still of course. I think the biggest technical problem preventing passing community review is the state of the libclang based bindings generator. It needs a whole load more work on it, but my problem is that it is already good enough that the minor errors in its output are easily hand repaired :( Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/