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. Right. 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