Proto grammars and transforms handle this better than evaluators, which are
deprecated. It would pay to look into some examples that use transforms.
Sorry, that's all the advice I have time for at the moment.
\e
On Apr 14, 2016 10:33 AM, "Mathias Gaunard"
wrote:
> I'd try to use IsVector.
> I'm
On 01/06/2014 07:25 AM, Ole Svensson wrote:
> Hi,
>
> for my vector expression DSEL I would like to be able to write multi
> assignment expressions like
>
> y = x = 3.0 * z;
>
> that effectively translate to
>
> for(i=0; iy[i] = x[i] = 3.0 * z[i];
> }
>
> Currently, my proto-fied vector
On 11/20/2013 02:36 AM, Bart Janssens wrote:
> Hello,
>
> I recently upgraded the OS and XCode on my Mac, resulting in the
> following clang version:
> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn).
> The previous version was "Apple LLVM version 4.2 (clang-425.0.24)
> (based on LL
possible and would it be of any help?
Possible in theory, yes. In practice, it probably doesn't work since
proto-v4 is not C++11 aware. But even if it worked, it wouldn't solve
anything. Rvalue refs have the same lifetime issues that (const) lvalue
refs have. The temporary object to whi
On 9/30/2013 11:08 AM, Mathias Gaunard wrote:
> On 30/09/13 08:01, Eric Niebler wrote:
>
>>> Therefore, to avoid performance issues, I'm considering moving to always
>>> using references (with the default domain behaviour), and relying on
>>> BOOST_F
I still think
this is the right default for C++11, and for most EDSLs. I'll have to be
explicit in the docs about the performance implications, and make it
easy for people to get the by-ref capture behavior when they're ok with
the risks.
--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
On 6/16/2013 11:59 AM, Agustín K-ballo Bergé wrote:
> On 15/06/2013 10:59 p.m., Eric Niebler wrote:
>>> >- Some specific uses of Proto actions in constant expressions fail. GCC
>>> >reports an ambiguity with ref-qualifiers in the following scenario:
On 13-06-15 03:40 PM, Agustín K-ballo Bergé wrote:
> On 15/06/2013 03:43 a.m., Agustín K-ballo Bergé wrote:
>> On 14/06/2013 11:06 p.m., Eric Niebler wrote:
>>>
>>> (Sorry for the top-posting. I'm away from my computer.)
>>>
>>> The repository *is
I've made no effort so far to port Proto v5 to any compiler other than clang.
I'm sure it would be a big job. I welcome any contributions. Otherwise, it'll
get ported eventually, but probably not before I get the API settled.
Eric
Sent via tiny mobile device
-Original Message-
From:
want to use it
with types that aren't expressions, you can already do that:
template
struct maybe_matches
: mpl::if_< proto::is_expr
, proto::matches
, mpl::false_
>::type
{};
Would the above work for you? I realize that's more expe
10/31/2012 12:30 PM, Agustín K-ballo Bergé wrote:
> On 16/10/2012 03:50 p.m., Agustín K-ballo Bergé wrote:
>> On 16/10/2012 02:22 a.m., Eric Niebler wrote:
>>> Hi Agustín,
>>>
>>> This is just a quick note to let you know that I'm currently at the
>&g
ou might also
pose this question on stackoverflow.com.
--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
EAC),
>
> formerly Associate Dean - External Relations,
>
> School of Engineering and Applied Science (EAS),
>
> Aston University, Aston Triangle, BIRMINGHAM B4 7ET U.K.
>
>
>
>
>
>
>
--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
On 7/27/2012 12:19 AM, Joel Falcou wrote:
> Le 27/07/2012 08:11, Eric Niebler a écrit :
>> Naming is becoming an issue, though. We already have proto::transform.
>> You'd be adding proto::functional::transform that would be totally
>> unrelated. I think I screwed up with
ld be totally
unrelated. I think I screwed up with the namespaces. It should probably
be proto::functional::fusion::transform. Urg.
--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
te drop and tell
folks to use let<> explicitly if they need it.
Gotta write let<> first, tho. :-P
--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
On 10/25/2010 10:03 PM, Eric Niebler wrote:
> On 10/25/2010 10:01 PM, joel.fal...@lri.fr wrote:
>>
>>> There, that's better. I don't think I'll mess with it any more. Go ahead
>>> and use it, Thomas.
>>
>> just a small question: what if I n
On 7/17/2012 6:14 PM, Eric Niebler wrote:
> I'm considering adding the slots mechanism to proto-current so that this
> can be made to work there, also. The problem is that once you use a
> slot, the data parameter is no longer just a dumb blob. I can make
> proto::_data ignore t
On 7/18/2012 3:59 PM, Mathias Gaunard wrote:
> On 18/07/2012 18:29, Eric Niebler wrote:
>
>> Is there some code in Proto that is forcing the instantiation of those
>> specializations? Probably, and that would unintended. One approach would
>> be to replace these
e type
and fix all places where the code breaks.
The presence of proto_base() is also going to cause problems. It returns
the normalized form so that Proto can quickly get at child nodes. It's
also used by virtual members to build an expression on the fly. You'd
need to find equivalents for
orms feature to make use of
slots, too (although that might be a breaking change, in which case I'd
wait until proto-11).
BTW, the "unpacking patterns" feature will be part of 1.51.
--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
operator== builds an expression node that has an implicit conversion to
bool IFF the left and right operands are compatible. Likewise for the
other relational operators. This is admittedly a kludge and I'm not sure
how I feel about it.
--
Eric Niebler
BoostP
This
is hard, and nobody has attempted it yet. I can give you encouragement,
but not guidance. If you find a general and elegant solution, it would
certainly be worth putting in Proto, since lots of folks would benefit.
--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
_
On 7/13/2012 6:37 AM, Mathias Gaunard wrote:
> On 07/11/2012 06:55 PM, Eric Niebler wrote:
>
>> You're referring to this:
>>
>> http://lists.boost.org/proto/2010/11/0304.php
>>
>> I should have followed through! The code referenced there isn't
>
On 7/11/2012 10:32 AM, Eric Niebler wrote:
> f0(f1(f2(pack(_))...))
>
> That's no so bad, actually. Now, the question is whether I can retrofit
> this into proto-current without impacting compile times.
This is now implemented on boost trunk for proto-current. Seems
On 7/11/2012 9:55 AM, Eric Niebler wrote:
> I'm going to keep playing with this. Your suggested syntax is nice. I
> wonder how close I can get. (Although I kinda like my pseudo-pack
> expansions, too. :-)
But based on Thomas' suggestion, I'm considering this altern
On 7/11/2012 4:47 AM, Bart Janssens wrote:
> On Tue, Jul 10, 2012 at 11:18 PM, Eric Niebler wrote:
>> The _unpack transform is pretty general, allowing a lot of variation
>> within the pack expansion pattern. There can be any number of Tfx
>> transforms, and the wildcard can
On 7/11/2012 12:42 AM, Thomas Heller wrote:
> On 07/10/2012 11:18 PM, Eric Niebler wrote:
>> I just committed to the proto-11 codebase a new transform called
>> _unpack. You use it like this:
>>
>>_unpack
>>
>> Where Tfx represents any transform (primit
#x27;m still playing around with it, but it seems quite powerful. Thoughts?
Would there be interest in having this for Proto-current? Should I
rename it to _expand, since I'm modelling C++11 pack expansion?
--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
On 6/29/2012 4:49 AM, Mathias Gaunard wrote:
> On 28/06/2012 21:09, Eric Niebler wrote:
>
>> After meditating on this for a bit, a thought occurred to me. Your
>> unpack function is a generalization of the pattern used by the _default
>> transform.
>
> It is indeed
On 6/27/2012 2:11 PM, Mathias Gaunard wrote:
> On 25/06/2012 23:30, Eric Niebler wrote:
>> On 6/25/2012 12:21 PM, Mathias Gaunard wrote:
>
>>> There is a function which is very simple and that I found to be very
>>> useful when dealing with expression trees.
>>
On 6/25/2012 12:44 PM, Bart Janssens wrote:
> On Sun, Jun 24, 2012 at 1:10 AM, Eric Niebler wrote:
>> Data parameter uses a slot mechanism
>>
>> In proto today, transforms take 3 parameters: expression, state and
>> data. As you can
On 6/25/2012 12:21 PM, Mathias Gaunard wrote:
> On 24/06/2012 01:10, Eric Niebler wrote:
>
>> As for what is not changing:
>>
>> Grammars, Transforms and Algorithms
>> ===
>> It would be wonderful if there were a more na
On 6/25/2012 12:39 AM, Joel Falcou wrote:
> On 06/24/2012 01:10 AM, Eric Niebler wrote:
>>int i = LambdaEval()(_1 + 42, 0, proto::tag::data = 8);
>>
>> The 3rd parameter associates the value 8 with the data tag.
&
On 6/24/2012 4:42 PM, Dave Abrahams wrote:
>
> on Sun Jun 24 2012, Eric Niebler
> wrote:
>
>> On 6/24/2012 8:50 AM, Irit Katriel wrote:
>>>
>>> In the accumulators library, all the accumulators are invoked for
>>> every update to the i
t; can skip most of it and just look at the definition of the sample
> application in the beginning, and then the streamulus solution in
> the end.
Looks pretty interesting. Thanks for sharing.
- --
Eric Niebler
BoostPro Computing
http://www.boostpro.com
-BEGIN PGP SIGNATURE-
Vers
bug in my
gcc headers to get the tests to compile. This is still in a very raw
state, and not useful for real work yet.
- --
Eric Niebler
BoostPro Computing
http://www.boostpro.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - ht
new extension mechanism is a breaking interface change
to proto::domain. The proto you know in boost will stay as it is.
--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
On 6/5/2012 11:10 PM, Mathias Gaunard wrote:
> On 03/06/2012 09:41, Eric Niebler wrote:
>>
>> Hey all, this is just an FYI. I've been hard at work at a ground-up
>> redesign of proto for C++11. I've gotten far enough along that I know
>> what expression exten
On 6/4/2012 5:51 PM, Mathias Gaunard wrote:
> On 04/06/2012 17:52, Eric Niebler wrote:
>
>> I don't know what you mean by the "right type". If you want it held by
>> shared_ptr to manage lifetime, then shared_ptr is the right type, it
>> seems to m
On 6/4/2012 6:08 PM, Mathias Gaunard wrote:
>> Eric Niebler wrote:
>>> Proto-11 will probably take many months. I'm taking my time and
>>> rethinking everything. Don't hold your work up waiting for it.
>
> Best thing to do is probably to make it lighter, ke
On 6/4/2012 12:48 PM, Joel Falcou wrote:
> Le 04/06/2012 21:18, Eric Niebler a écrit :
>> Assuming your types are efficiently movable, the default should just do
>> the right thing, and your expression trees can be safely stored in local
>> auto variables without dangling
On 6/3/2012 11:47 PM, Joel Falcou wrote:
> On 03/06/2012 09:41, Eric Niebler wrote:
>> 2) Rather than writing generators, you'll be defining per-domain
>> make_expr function objects that accept a tag and a number of children.
>> How you decide to assemble these into an ex
On 6/3/2012 5:37 PM, Mathias Gaunard wrote:
> On 03/06/2012 18:36, Eric Niebler wrote:
>
>>> Plus I don't have a good way to distinguish between a terminal of
>>> shared_ptr and a terminal of T which is held through a shared_ptr.
>>
>> Have you tried a
On 6/3/2012 6:23 AM, Mathias Gaunard wrote:
> On 03/06/2012 02:59, Eric Niebler wrote:
>
>> There is no way to hook proto::value to return anything but what is
>> stored in the terminal. It's a very dumb, low-level function. You could
>> easily define your own value
mporary hack.
Thanks all for now. Feedback welcome. If you have wishlist features for
proto-11, speak now.
--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
On 5/30/2012 9:26 AM, Eric Niebler wrote:
> On 5/30/2012 4:33 AM, Joel Falcou wrote:
>> Won't having a way to build it properly from the get go be a better
>> solution ?
>>
>> This basically require the feature we spoke about earlier so that
>> building a X *
::_state), proto::_byval(_))>()
)
);
}
int main()
{
eval( 2 * arg1 * 42.0 * arg1 );
}
It takes the multiplication tree, flattens it, and turns it back into a
multiplication tree in reversed order.
HTH,
--
Eric Niebler
BoostPro Computing
http:/
On 5/30/2012 4:33 AM, Joel Falcou wrote:
> On 05/29/2012 08:21 PM, Eric Niebler wrote:
>> On 5/29/2012 1:44 AM, Karsten Ahnert wrote:
>>> I have an arithmetic expression template where multiplication is
>>> commutative. Is there an easy way to order a chain of mu
On 5/29/2012 3:29 PM, Karsten Ahnert wrote:
> On 05/29/2012 08:21 PM, Eric Niebler wrote:
>> On 5/29/2012 1:44 AM, Karsten Ahnert wrote:
>>> I have an arithmetic expression template where multiplication is
>>> commutative. Is there an easy way to order a chain of mu
) be able to use
fusion::fold to build the correct proto tree from it.
--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
sired form
>
> The alternative is for us to not rely on Proto-defined operator
> overloads and to overload all that stuff ourselves.
This seems quite reasonable. Could you file a feature request on trac so
I don't loose track of it? Thanks.
--
Eric Niebler
BoostPro Computing
htt
her_info )
>>
>> basically makign n-ary function node into ternayr node with a specific
>> structures. Of course this new node should live in whatever domain
>> some_terminal is coming from.
And some_terminal is not in your domain? How does your generator get
invoked?
On 4/26/2012 9:35 AM, Mathias Gaunard wrote:
> On 26/04/12 18:02, Eric Niebler wrote:
>
>> Interesting. I avoided this design because I was uncertain whether the
>> compiler would be able to optimize out all the copies of the
>> intermediate nodes. You're saying NT2
On 4/25/2012 1:41 PM, Mathias Gaunard wrote:
> On 24/04/12 22:31, Eric Niebler wrote:
>> On 4/23/2012 10:17 PM, Joel Falcou wrote:
>>> On 04/24/2012 12:15 AM, Eric Niebler wrote:
>>>
>>> I think this is an important issues to solve as far as Proto grokability
On 4/23/2012 10:17 PM, Joel Falcou wrote:
> On 04/24/2012 12:15 AM, Eric Niebler wrote:
>> implicit_expr() returns an object that holds its argument and is
>> convertible to any expression type. The conversion is implemented by
>> trying to implicitly convert all the child exp
is
convertible to any expression type. The conversion is implemented by
trying to implicitly convert all the child expressions, recursively. It
sort of worked, but I never worked out all the corner cases, and
documenting it would have been a bitch. Perhaps I should take another
look. Patches welcome.
type operator()( T & t ) const
{
return unspecified-Proto-expr-object;
}
};
};
In as_child, you'll have to do this (pseudocode):
if (is_expr)
return T &
else if(is_fundamental)
return proto::terminal::type
else
return proto::terminal::type
Th
On Mon, Jan 30, 2012 at 4:53 AM, Mathias Gaunard
wrote:
> For a couple of reasons, I'm considering replacing the proto-provided
> operator tags by my own in the generator of my domain.
>
> What would the easiest and less costly way of doing it?
You mean, for instance, you want Proto's operator+ t
On 1/4/2012 7:37 AM, Thomas Heller wrote:
> Thanks for adding this documentation!
Great feedback. I've just accommodated all of it. Thanks!
--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.
boost-sandbox.sourceforge.net/libs/proto/doc/html/boost_proto/users_guide/back_end/expression_transformation/external_transforms.html
--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boos
ke use of variadic
templates for operator() if available.
Other things to think about: does this really need to be all one big
expression, or can parts of it be broken up and type-erased, as with
spirit::qi::rule?
--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
On 10/28/2011 6:29 AM, Mathias Gaunard wrote:
> On 28/10/2011 07:30, Eric Niebler wrote:
>
>> Regardless, I'm convinced that a complete fix is possible, and I have it
>> mostly coded. It would require you (the user) to disable unary function
>> and assign in your do
On 10/22/2011 3:02 PM, Mathias Gaunard wrote:
> On 10/18/2011 05:53 AM, Eric Niebler wrote:
>> On 10/12/2011 2:24 PM, Mathias Gaunard wrote:
>>> There seems to be a significant problem with the unary function node
>>> (and by that I mean (*this)() ) gene
except to say that
this is on my radar. I hope to look into this soon. But if someone were
to beat me to it, that'd be pretty awesome. :-)
--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http:/
Proto's overloads, and then define
your own.
Admittedly, Proto's docs could be more clear about best practice here.
> You might want to warn other proto users of this potential
> breaking change.
This will need to be mentioned in the release notes, yes.
--
On 10/10/2011 2:08 AM, Joel de Guzman wrote:
> On 10/10/2011 1:52 PM, Joel de Guzman wrote:
>> On 10/10/2011 12:38 PM, Eric Niebler wrote:
>>>
>>> Bummer. I suggest adding an rvalue ref overload of operator%= that
>>> shares an implementation with the co
ummer. I suggest adding an rvalue ref overload of operator%= that
shares an implementation with the const lvalue one. Should just be a few
lines of code. Is that a problem?
As an alternative, you can use a domain/grammar to disable Proto's
operator%= for Spirit rules.
--
Eric N
;>> And here is the ticket : https://svn.boost.org/trac/boost/ticket/5905
Just fyi, this has now been merged to release and the ticket is closed.
Thanks for the contribution!
--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto m
On Monday, September 19, 2011 11:30:17 AM, Eric Niebler wrote:
> On 9/16/2011 9:09 AM, Pierre Esterie wrote:
>> Hi everybody,
>>
>> I'm working with Joel Falcou and I just submitted a patch in the tracker
>> about extending proto::switch_.
>>
>> Here is
here is the ticket : https://svn.boost.org/trac/boost/ticket/5905
>
> All comments and discussions are welcomed !
Thanks for your work on this, Pierre! I just got back from a week-long
vacation. I hope to give this a look in the next few days.
--
Eric Niebler
BoostPro C
On 8/28/2011 6:17 PM, Joel Falcou wrote:
> Le 06/08/2011 08:10, Eric Niebler a écrit :
>> On 8/5/2011 10:55 PM, Joel falcou wrote:
>>> On 06/08/11 07:30, Eric Niebler wrote:
>>>> That wouldn't be enough because proto::matches "knows" about
>>&
On 8/26/2011 11:44 AM, Eric Niebler wrote:
> Proto will
> compute the domain of m*v to be matrix. It will use matrix_domain's
> generator to post-process the new expression. That generator can do
> anything -- including placing the new expression in the vector domain.
> I
On 8/26/2011 11:23 AM, Joel Falcou wrote:
> On 26/08/2011 17:18, Eric Niebler wrote:
>> Why can't you use a grammar to recognize patterns like these and
>> take appropriate action?
>
> we do. Another point is that container based operation in our system
> need to kn
On 8/26/2011 10:56 AM, Joel Falcou wrote:
> On 26/08/2011 16:45, Eric Niebler wrote:
>> Before I answer, can you tell me why you've decided to put vector and
>> matrix operations into separate domains? This seems like an artificial
>> and unnecessary separation to me
decided to put vector and
matrix operations into separate domains? This seems like an artificial
and unnecessary separation to me.
--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
On 8/6/2011 1:26 PM, Joel falcou wrote:
> On 06/08/11 21:01, Eric Niebler wrote:
>> Besides, enable_if is yuk.
>
> Care to elaborate (not like we use it like over 9000 times in our code
> base) /
I just don't like it. SFINAE is an ugly hack. There may also be
compile-time
On 8/6/2011 3:47 AM, Mathias Gaunard wrote:
> On 08/06/2011 07:30 AM, Eric Niebler wrote:
>> On 8/5/2011 8:52 AM, Joel falcou wrote:
>>> There is few use case where I wish i can have a proto::switch_ like
>>> transform being extendable externally but based on something e
On 8/5/2011 10:55 PM, Joel falcou wrote:
> On 06/08/11 07:30, Eric Niebler wrote:
>> That wouldn't be enough because proto::matches "knows" about
>> proto::switch_. It would be easy enough to extend proto::switch_ to take
>> an optional mpl metafunction that
dispatch on. It would default to proto::tag_of. Or for
the sake of consistency with the rest of proto, it should probably be a
transform, in which case it would default to proto::tag_of().
Could you open a feature request?
--
Eric Niebler
BoostPro
:terminal<_>,
proto::nary_expr<
_,
proto::vararg<
proto::when
>
>
>
{};
HTH,
--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
On 6/17/2011 6:46 PM, Joel falcou wrote:
> On 17/06/11 01:25, Eric Niebler wrote:
>> Doable, but not easy. The problem you'll have is that all Proto
>> expression types have a nested fusion_tag that is a typedef for
>> proto::tag::proto_expr. That is how Fusion figures
extension, and hide the fusion_tag typedef in the base with your own.
Then you'll need to implement the necessary Fusion hooks for your custom
Fusion tag type.
HTH,
--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
On 6/2/2011 11:12 AM, Joel falcou wrote:
> On 01/06/11 22:24, Eric Niebler wrote:
>
>> Proto expressions are random access, but flattened views are
>> forward-only. That's a limitation of the current implementation of the
>> segmented Fusion stuff. It's a known
est, and I'm too tired
to climb it again. Some hot-shot metaprogramming wunderkind should try
cutting his/her teeth on that problem. They'd earn my eternal admiration
and appreciation.
--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
__
; ideas, adding
mathematical rigor that Proto currently lacks. I hope they report their
progress here!
--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
#x27;t running right now, so please let me know if
you spot any problems.
Thanks,
--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
up Phoenix, which shows
that you're more hamstrung by lexing. The choice of either proto::expr
or proto::basic_expr doesn't matter for lexing because they're both
going to be lexed regardless.
I know when I introduced basic_expr, I ran tests that showed it was a
perf win for xpressive
otten to the point where a compile can use upwards of 1.5GB for
> a single test, resulting in much swapping, especially when compiling
> with make -j2 (which I try to remember not to do, now ;).
Ouch. Do you have to use gcc? Perhaps clang might give
On 5/10/2011 8:36 AM, Eric Niebler wrote:
> On 5/10/2011 3:22 AM, Joel Falcou wrote:
>> I got these error compiling NT2 with proto trunk
>>
>> /usr/local/include/boost-latest/boost/proto/detail/decltype.hpp:67:56:
>> error: 'M0' has not been declared
>
oing to work. I'm surprised it ever did.
> As for why we do this, we have to fight against some MSVC bug w/r to
> decltype that PROTO_DECLTYPE seemed to fix.
This is what happens to people who use stuff under a detail/ directory
or in a detail namespace. :-) You already know what
es, which swamps
the PP time. I'm guessing MSM is the same. Oh, well. At least we've
fixed the mess with the predefined limits.
--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
rking code crash a VC
> compiler at a user's machine, so I would not welcome another increase.
>
> Thanks for the hard work anyway, I'm happy to get rid of my #define's.
Don't despair yet. I'm not done with the pre-preprocessing work. I'll
let you know w
LIMIT <= 10 Phoenix uses one set of pp files, for LIMITs <= 20
> the next set, etc.
>
> This surely creates some additional burden for the author as you have to run
> wave 5 times, but that's it.
Ah, I see what you mean. Yes, I could do that. I'll add it to the list.
a history of
supporting arities up to 10 and no more. I'm balancing keeping it fast
and light(-ish) and making it useful in the real world.
--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
h
On 5/2/2011 6:18 PM, Thomas Heller wrote:
> On Mon, May 2, 2011 at 12:54 PM, Eric Niebler wrote:
>> Phoenix is changing the following fundamental constants:
>>
>> BOOST_PROTO_MAX_ARITY
>> BOOST_MPL_LIMIT_METAFUNCTION_ARITY
>> BOOST_PROTO_MAX_LOGICAL_ARITY
>&
On 5/5/2011 12:32 AM, Eric Niebler wrote:
> I'll also need to investigate why Proto depends on
> BOOST_MPL_LIMIT_METAFUNCTION_ARITY.
Proto no longer depends on BOOST_MPL_LIMIT_METAFUNCTION_ARITY. At least,
not on trunk.
I'm working on pre-preprocessing stuff. So far, it doesn
On 5/5/2011 2:27 AM, Bart Janssens wrote:
> On Wed, May 4, 2011 at 7:55 PM, Eric Niebler
> wrote:
>> Bart, how high can N go in your EDSL? Is it really arbitrarily large?
>
> I didn't hit any limit in the real application (most complicated case
> is at 9) and just di
your preferred syntax, so not ideal.
> Probably useless
> for phoenix, but I thought I'd mention it anyhow :) I would also be
> interested to go back to the group(...) syntax without needing to
> modify the limits, so any progress on this would be great.
Bart, how high can N go
On 5/4/2011 6:25 PM, Thomas Heller wrote:
> On Wed, May 4, 2011 at 10:58 AM, Eric Niebler wrote:
>> On 5/2/2011 6:18 PM, Thomas Heller wrote:
>>> The default BOOST_PROTO_MAX_ARITY is 5.
>>
>> I see. So this is inherently a limitation in Proto. I set Proto's
1 - 100 of 274 matches
Mail list logo
