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

John Moeller wrote:
> Daniel Wallin wrote:
>> Rene Rivera wrote:
[...]
>> 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?

I think so.

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

Sorry, I don't understand. My point is that in:

  class_<X>() [
     def(..., &X::f); #1
  ]

#1 needs access to `X` from the enclosing class_<>. To do this we'd need
to delay the instantiation so that it happens inside
`class_<>::operator[]`, where `X` is known.

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