Re: DSEL syntax, or opening the can of worms.

Rene Rivera wrote:
[...]
> namespace_(L,"a")
> [
>    def("f",&a::f),
>    class_<a::A>("A")
>    [
>      def("do",&a::A::do),
>      class_<a::A::B>("B")
>      [
>        def("again",&a::A::B::again)
>      ]
>    ]
> ]
> 
> Which has a one-to-one correspondence with the C++ code. So... Was this 
> ever considered? If it was, why was it not used? Is there a discussion 
> in the list I haven't read about this?

Yes. This was considered and dismissed at one point. The problem is that
you loose access to the class type in your def() calls. It's of course
possible to build an expression template out of the whole thing and
lazily evaluate it, but that would make compile time performance even worse.

It's possible that this performance degradation wouldn't matter that
much in practice, but there are other concerns as well. Off the top of
my head; any compilation problem that happens inside a def() call will
get delayed and happen deeper down in the call stack, since we'd need to
recursively evaluate the expression tree.

-- 
Daniel Wallin
Boost Consulting
www.boost-consulting.com


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/