Re: [proto] pod_generator Question
> The second argument to BOOST_PROTO_DEFINE_OPERATORS is a domain. When
> defining a domain you (usually) specify a generator with an expression
> wrapper. What are you using for a domain, and how do you define it?
>
> When I want an end-user-friendly terminal type, I derive it from the
> expression wrapper class, like this:
>
> template struct my_wrapper;
>
> struct my_domain : domain< generator > {};
>
> template struct my_wrapper
> : extends< Expr, my_wrapper, my_domain > {
> ...
> };
>
> class my_int : my_wrapper< terminal::type > {
> ...
> };
>
> Sounds like pod-ness is important to you, so this scheme won't work. Is
> that the problem you're having?
I am trying to allow user defined types to be treated as terminals. I provide
a trait class
template
struct IsMap
: mpl::false_
{};
template
struct IsMap
: mpl::true_
{};
So that only types with a typedef is_map or those that specialize IsMap are
considered valid terminals.
I then use this with BOOST_PROTO_DEFINE_OPERATORS like
namespace MapOps
{
BOOST_PROTO_DEFINE_OPERATORS(IsMap, map_domain)
struct map {};
}
where map_domain is
struct map_domain
: domain< pod_generator, Map >
{};
template
struct map_expr
{
BOOST_PROTO_BASIC_EXTENDS(ProtoExpression, map_expr, map_domain)
};
and Map is the grammar for valid expressions.
I am trying to figure out the most convenient way to have the operator
overloads found properly in user code. So far I see several options,
1) "using namespace MapOps;" where expressions are needed.
2) Have users derive their maps from MapOps::map (I lose pod-ness (in C++03)
here, right?).
3) Have all maps defined in the same namespace as the operations.
4) Define the operators in the global namespace.
Any suggestions on best practice here?
Nate
smime.p7s
Description: S/MIME cryptographic signature
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] pod_generator Question
On 2/13/2011 2:55 AM, Nate Knight wrote:
>
> I have some external non-proto terminals I've adapted using
> BOOST_PROTO_DEFINE_OPERATORS. I was trying to figure out how to get
> the terminals picked up by the operator overloads without importing
> them all from the namespace they are defined in every time I wanted
> to build an expression. I just needed to make sure my terminals were
> tied to the namespace in which I put the
> BOOST_PROTO_DEFINE_OPERATORS.
>
> I think I'm starting to figure this out, but I'm sure I'm going to
> have a few more mixups before I'm done.
The second argument to BOOST_PROTO_DEFINE_OPERATORS is a domain. When
defining a domain you (usually) specify a generator with an expression
wrapper. What are you using for a domain, and how do you define it?
When I want an end-user-friendly terminal type, I derive it from the
expression wrapper class, like this:
template struct my_wrapper;
struct my_domain : domain< generator > {};
template struct my_wrapper
: extends< Expr, my_wrapper, my_domain > {
...
};
class my_int : my_wrapper< terminal::type > {
...
};
Sounds like pod-ness is important to you, so this scheme won't work. Is
that the problem you're having?
--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] pod_generator Question
> On 2/12/2011 7:17 AM, Nate Knight wrote:
>> I see in the Proto documentation a trick for getting the Proto operator
>> overloads found by ADL using something like
>>
>> template
>> struct my_complex
>> {
>>BOOST_PROTO_EXTENDS(
>>typename proto::terminal >::type
>> , my_complex
>> , proto::default_domain
>>)
>> };
>>
>> The proto::pod_generator class template, however, expects its argument to be
>> a one argument class template.
>> So, something like
>>
>> struct my_domain : proto::domain< proto::pod_generator< my_complex> > {};
>>
>> won't work because my_complex is a two argument class template (even though
>> its got one default argument).
>
> It wouldn't work anyway because pod_generator expects that it's
> argument's template parameter is a Proto expression. my_complex's
> template argument is (presumably) a scalar. Generators are for wrapping
> bare expressions in custom wrappers. my_complex is already a wrapped
> Proto expression.
>
Eric, thanks for the response.
I think I misunderstood the intent of these comments in the documentation. I
have some external
non-proto terminals I've adapted using BOOST_PROTO_DEFINE_OPERATORS. I was
trying
to figure out how to get the terminals picked up by the operator overloads
without importing them
all from the namespace they are defined in every time I wanted to build an
expression. I just needed
to make sure my terminals were tied to the namespace in which I put the
BOOST_PROTO_DEFINE_OPERATORS.
I think I'm starting to figure this out, but I'm sure I'm going to have a few
more mixups before I'm done.
smime.p7s
Description: S/MIME cryptographic signature
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] pod_generator Question
On 2/12/2011 7:17 AM, Nate Knight wrote:
> I see in the Proto documentation a trick for getting the Proto operator
> overloads found by ADL using something like
>
> template
> struct my_complex
> {
> BOOST_PROTO_EXTENDS(
> typename proto::terminal >::type
> , my_complex
> , proto::default_domain
> )
> };
>
> The proto::pod_generator class template, however, expects its argument to be
> a one argument class template.
> So, something like
>
> struct my_domain : proto::domain< proto::pod_generator< my_complex> > {};
>
> won't work because my_complex is a two argument class template (even though
> its got one default argument).
It wouldn't work anyway because pod_generator expects that it's
argument's template parameter is a Proto expression. my_complex's
template argument is (presumably) a scalar. Generators are for wrapping
bare expressions in custom wrappers. my_complex is already a wrapped
Proto expression.
> Is there some work around for this, am I missing something, or am I out of
> luck.
If I had a better idea of what you were trying to do, I could help.
--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
