|
Boost : |
From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2002-08-13 08:29:47
>From: "Joel de Guzman" <djowel_at_[hidden]>
>>From: "Terje Slettebø" <tslettebo_at_[hidden]>
>> > That's it, 9 lines of code (7 without braces), one template, two
>> > typedefs, done. :)
>> >
>> > ...relying on a ton of scaffolding, some of which doesn't even exist!
>>
>> Yep, it does. So does C++, compared to the assembly code it's translated
>> too. However, the higher level of abstraction also gives it its power.
>>
>> It's similar with metaprogramming.
>>
>> >No more questions, your honor. I rest my case.
>> >
>> > Besides, I frankly find the code abominable. It attempts to look and
>> > feel like runtime C++, and to me it doesn't do it.
>>
>> Well, I guess this is subjective.
>>
>> Of course, you're free to use "metaprogramming assembler", too.
>I think you missed the point.
>Andrei and Paul never mentioned anything
>about using "metaprogramming assembler".
Right, I did. What I meant with it, was using the C++ constructs, without
library support. You use the "fundamental units" of MP. That's what Loki
essentially does, except where it uses its own algorithms, and what Andrei
argues for.
>They *do* advocate using
>a metaprogramming library.
Really? Paul does, yes. But when it comes to my function examples, there's
no alterative to MPL that I know of, even if you don't make it generic.
So what's the alternative?
Complaining is easy enough, as you know, when the Spirit parser framework
was discussed at Boost a while ago. :) As I recall, complaints about "too
much generality", and "too complex" were being raised there, too. And yet,
the same crowd asked how you would implement complex things in the same
framework, that they criticised as being too complex. Sounds familiar?
>Their point is that the client interface would
>have been more straight-forward (and elegant) without the "unecessary"
>abstractions that might or might not be useful. Everybody pays for features
>they do not need.
I understand the point. The question is whether or not these abstractions ar
e useful.
Regards,
Terje
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk