On 11/29/2010 06:10 PM, Joel de Guzman wrote:
On 11/30/2010 6:56 AM, Marsh Ray wrote:
C++ and Boost are well suited for secure coding because of the support for type safety, automatic cleanup, and overall deterministic execution. But probably nothing will replace the need to understand what's going on under the hood as well as the attacker.
If that is your reasoning then you can't use Boost (nor cpp-netlib for that matter).
Yeah. I've met a few developers, hackers, etc working in the data security space. I don't think any of them were particularly into of template metaprogramming. I doubt any would consider using MPL, for instance.
"The number of "eyes" that can grok" Boost internals "and accurately review it are vanishingly small."
That's neither good nor bad, but it does put Boost in a particular place in the design space. Actually, I do think it's good - we need projects that push out the corners to expand that space, and that's what I love about Boost. But a more typical software project being built by mortal men on a schedule usually can't afford the conceptual costs of bringing in more than one or maybe two of those corners. As square as this sounds, you've got to keep a foothold in the mainstream.
Yet, anyone claiming to be a C++ security expert positioned to review code for "software quality" should be able to review any and all sort of C++ code, even the template heavy code like MPL.
That's a really good point, but I think on balance I disagree. Here's why: Someone might know everything there is to know about, say, programming in C, but not be qualified to review hard-real-time robotics systems written in C (though they would obviously have a lot to contribute). So there's a distinction between the language and the problem domain and you need to be able to understand both. Template instantiation is a Turing-complete language and MPL specifically seeks to enable programming in it. So I think it's reasonable that even an experienced team of C++ practitioners might decide that some particular big chunk of metaprogramming wasn't worth the conceptual overhead for a particular project. This stuff has a cost, abstraction isn't free. Witness the threads on template error messages. But when it works out, it can be dynamite: STL.
Spirit is not special. It uses the same template metaprogramming techniques that is prevalent in most of Boost libraries. There is no black magic there.
Haha, I don't think you'll find many people (outside of this list) who don't think it is exactly black magic. :-) Personally I think it's pretty awesome.
[I'll try to reply to your Spirit related comments in another post. As I see it, your comments there (relating to not being able to make it your code work and that JSON is easy to code in C) is totally irrelevant.]
All I was trying to say was that I could really use a no-fuss, bulletproof JSON facility and Spirit seemed like overkill for this simple format. - Marsh