Boost logo

Boost :

Subject: Re: [boost] [GSoC] [Boost.Hana] Formal review request
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-07-31 18:28:24

On 31 Jul 2014 at 10:11, Eric Niebler wrote:

> On 07/29/2014 05:14 PM, Niall Douglas wrote:
> > I'm all for Concepts as in compiler enforced ones, and I'll add them
> > to AFIO when and only when C++ gets them. But for documentation they
> > don't help.
> Wow, I couldn't disagree more. I can't imagine how the standard
> algorithms would be specified without the use of concepts like
> "RandomAccessIterator", for instance. Clustering requirements into
> meaningful abstractions and assigning them names makes it possible to
> document library interfaces without an explosion of verbosity and
> repetition.

Oh I know programmers similar to how you visualise code in your head
would agree with you absolutely. But you must remember programmers
like me don't see C++ as really in fact having types nor classes nor
concepts - I just see methods of programming the compiler to output
patterns of assembler code, and I think primarily in terms of chains
of assembler instructions. My type of programmer learns just enough
of the verbiage to understand C++ Now presentations by programmers
such as you (and I haven't failed to learn something new from yours
yet), but we'll never think like you any more than you'll think like

None of this a bad thing of course, diversity of approach and all.
But to me and people like me a RandomAccessIterator is a pointer and
is little different to a ForwardIterator. I care about the difference
only in so far as I can use it to get the compiler to generate code
one way or another according to need. I furthermore care about the
difference only in so far as it will get later maintainers and team
members to behave one way instead of another. Past that I feel no
issue reinterpret casting STL internal types to bypass the type
system if that gets me the assembler output I want and doesn't create
maintenance debt later.

It's the essential difference between language-focused coders and err
... mongrel coders? I have to admit I'm not sure what to call myself
really. Either way, I see ConceptCheck as a half baked feature giving
me nothing useful but bloat and complexity and significantly adding
mess to documentation and steepening my learning curve. I absolutely
can't wait for language support for Concepts, and will use them with
vengence when they turn up as they're another great tool for bending
the compiler in new ways, but until it's fully baked as a language
feature they get in my way. And hence I don't use them personally,
and groan every time I'm faced with code by someone who has (no
offence intended here, we all have our own personal likes and
dislikes, and I entirely understand your opinions on this and respect
them, I just don't have those opinions myself).


ned Productions Limited Consulting

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