Boost logo

Boost :

From: Robert Ramey (ramey_at_[hidden])
Date: 2019-10-23 03:38:56

On 10/22/19 3:42 PM, Emil Dotchevski via Boost wrote:

> I get your point that it's easier to reason about correctness if you can
> trust the individual components.
> This reflects a "white box testing"
> mentality.
I have heard the term - but I never knew what it meant
> But if Spirit is bug-free, logically it does not follow that a
> library that uses it has better chance of being bug-free, compared to a
> library that does not.

> Either way, you ought to test, ignoring any and all knowledge of its internals.
I don't think anyone has suggested otherwise. But some approaches
require much more testing than others.
> Consider also even if using tested components can get you to bug-free
> implementation quicker (which isn't proven in this case),

Hmmm - it's proven to my satisfaction. This is the key point. Using
spirit to generate parser is a fundamentally different task than
crafting a sequential procedure to parse arbitrary text to invoke events
when grammatical elements are recognized. It's very different than what
one is used to so it takes more time to learn than one would think. BUT
it reduces the job to specifying the grammar and specifying the actions.
  There is no coding in the sense that writing a hand rolled parser is.
It's totally static - there is no notion of changing state when
specifying the parser. So it's inherently verifiable - unlike code which
changes state as the instruction pointer passes over the code.

This is why I believe that this approach will get one to a bug free
implementation faster and that one will be able to verify the that the
implementation is correct. I realize that not everyone buys this, but
it's what I believe.

Of course the question is raised about compile time/runtime efficiency.
The above says nothing about these questions. But I would like these
questions to be considered separately from those of correctness. But in
many instances - correctness cannot be compromised and compile/run time
efficiency has to be second priority.

> on balance it is better if you don't depend on another library.

Also I disagree with this. All things being equal, I'd rather depend on
someone else's work than my own. I want to focus on only those things
that are unique to my situation. And I get no satisfaction from doing
something that someone else has already done better.

Of course the rub is "all things being equal" which of course is an
idealization. Some times it's mostly true while other times it not. We
get to decide - that's why we make the big bucks.

As time goes on, the problem of C++ code dependencies have become bigger
issue. Part of this is that there is a whole generation of programmers
who don't need to know about linkers and libraries and that header only
works fine for them. An header only is more convenient. But it does
prejudice code reuse - which has it's own downsides. I would very much
like to see C++ make progress toward making better use of linkers,
separate compilation, better support of control of visibility etc. But
we're stuck here.

Robert Ramey

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