Boost logo

Boost :

Subject: Re: [boost] Futures (was: Re: [compute] Some remarks)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-01-13 09:13:20

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 []
> 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

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,

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

> 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 :(


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at