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

Daniel Wallin wrote:
> 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.

Of course I scrolled right to it after reading this.  That's the thread 
started by A. Nasonov, right?

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

Is that true?  We wouldn't necessarily need to build "()" into the DSEL; 
it could be left to be evaluated normally, thus allowing compilation to 
catch bad def() calls at the point of use.

-- 

John Moeller
[email protected]


-------------------------------------------------------------------------
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/