Re: [boost] Futures (was: Re: [compute] Some remarks)

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