[concept check][mpl] (Conditional) Concept checking for functions

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[concept check][mpl] (Conditional) Concept checking for functions

Jesse Perla
I have a variety of user defined function objects that I will need to call.  Take the following examples:
template<int N1, int N2 = 0>
struct Func1{ double operator()(boost::array<double, N1>& x1, boost::array<double, N2>& x2){...}};

template<int N1>
struct Func2{ double operator()(boost::array<double, N1>& x){...}};

With a function such as 

template<int N1,
               int N2 = 0,
               class F = boost::function<double (boost::array<double, N1>& x1, boost::array<double, N2>& x2)>
class DPP{ void solve(){...... uses F...to be discussed} }; 

I have a few questions:
1) Is there a relatively easy way to use boost concept check to verify that F follows the first function signature so that I can detect compile time the problem?  I can't figure out how to do it from the concept check docs, and they say they are out of date.
Usage I want to check in the instantiation of DPP:
      F f;
      f(boost::array<double, N1>& x1, boost::array<double, N2>& x2)


2) I want the user to be able to pass in a simplified function type if N2 = 0

I assume that to call the actual function I would have some kind of impl function with partial specialization such as:
template<bool use_simplified, int N1, int N2>
struct use_f_impl();

template<int N1, int N2>
struct use_f_impl<true, N1, N2>{
   static double use_f()
   {
      STATIC_ASSERT(N2 == 0);
       F f;
      boost::array<double, N1> x;
       return f(x);
   }
};


template<int N1, int N2>
struct use_f_impl<false, N1, N2>{
   static double use_f()
   {
       F f;
      boost::array<double, N1> x1;
      boost::array<double, N2> x2;
       return f(x1, x2);
   }
};

And then in my solve() function I go:
  double val = use_f<(N2 == 0, N1, N2)>::use_f();

Is this the right idiom, pattern, etc?  Do I need to use the struct with a static function since function templates don't have partial specialization?

3) Now what if I want to do a concept check on the F passed into DPP?  It has to be conditional on the N2 value now.  How would I do this?


4) Lets say that I don't want to force them to use the simplified version of the function signature if they don't want to.
Can I automatically detect the signature and put it into a flag integer in the class?
i.e. inside of the DPP class:
static bool use_simple = IsSimple<F>::value;
Then pass in the use_simple value when calling use_f_impl.
If so, what would the IsSimple metafunction look like and can concept check help?

Thanks,
Jesse

_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

[mpl]... is there an mpl::string

Andy Stevenson-2
Hi,

I recall some discussion of there being an mpl::string template.....
Can't see it in the mpl library. Is it elsewhere?

Regards, Andy
_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [mpl]... is there an mpl::string

Eric Niebler
Andy Stevenson wrote:
> Hi,
>
> I recall some discussion of there being an mpl::string template.....
> Can't see it in the mpl library. Is it elsewhere?

I wrote one once and intended to write docs and tests and integrate it
into MPL but never got around to it. You can find it here:

http://archives.free.net.ph/message/20080324.060757.9880ea2b.el.html

--
Eric Niebler
BoostPro Computing
http://www.boostpro.com

_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [mpl]... is there an mpl::string

Ovanes Markarian
Eric,

I would be interested in that too. I already had to code around in a project, to make smth. similar.


Would be nice to have it in MPL. Many thanks,
Ovanes

On Mon, Mar 30, 2009 at 5:58 AM, Eric Niebler <[hidden email]> wrote:
Andy Stevenson wrote:
Hi,

I recall some discussion of there being an mpl::string template.....
Can't see it in the mpl library. Is it elsewhere?

I wrote one once and intended to write docs and tests and integrate it
into MPL but never got around to it. You can find it here:

http://archives.free.net.ph/message/20080324.060757.9880ea2b.el.html

--
Eric Niebler
BoostPro Computing
http://www.boostpro.com


_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [mpl]... is there an mpl::string

Andy Stevenson-2
In reply to this post by Eric Niebler
Thanks Eric.... would be a useful addition to mpl I think at some point.
Great for DSLs which is how I intend to use it.

Andy

On 30 Mar 2009, at 04:58, Eric Niebler wrote:

> Andy Stevenson wrote:
>> Hi,
>> I recall some discussion of there being an mpl::string template.....
>> Can't see it in the mpl library. Is it elsewhere?
>
> I wrote one once and intended to write docs and tests and integrate it
> into MPL but never got around to it. You can find it here:
>
> http://archives.free.net.ph/message/20080324.060757.9880ea2b.el.html
>
> --
> Eric Niebler
> BoostPro Computing
> http://www.boostpro.com
>
> _______________________________________________
> Boost-users mailing list
> [hidden email]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users

_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [mpl]... is there an mpl::string

Eric Niebler-3
In reply to this post by Ovanes Markarian
Ovanes Markarian wrote:

> Eric Niebler wrote:
>> Andy Stevenson wrote:
>>>
>>> I recall some discussion of there being an mpl::string
>>> template..... Can't see it in the mpl library. Is it elsewhere?
>>
>> I wrote one once and intended to write docs and tests and integrate
>> it into MPL but never got around to it. You can find it here:
>>
>> http://archives.free.net.ph/message/20080324.060757.9880ea2b.el.html
>
> I would be interested in that too. I already had to code around in a
> project, to make smth. similar.
>
> Would be nice to have it in MPL. Many thanks,

I polished this up, wrote some docs and tests and submitted a patch.
It's up to Aleskey now.

https://svn.boost.org/trac/boost/ticket/2905

--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [mpl]... is there an mpl::string

Eric Niebler-3
>>> Andy Stevenson wrote:
>>>>
>>>> I recall some discussion of there being an mpl::string
>>>> template..... Can't see it in the mpl library. Is it elsewhere?

It has been added to trunk as of revision 52208:

https://svn.boost.org/trac/boost/changeset/52208

No doubt the regression tests will reveal portability problems. Once
they have been worked out, we can move this to release.

--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [mpl]... is there an mpl::string

Noah Roberts
Eric Niebler wrote:

>>>> Andy Stevenson wrote:
>>>>>
>>>>> I recall some discussion of there being an mpl::string
>>>>> template..... Can't see it in the mpl library. Is it elsewhere?
>
> It has been added to trunk as of revision 52208:
>
> https://svn.boost.org/trac/boost/changeset/52208
>
> No doubt the regression tests will reveal portability problems. Once
> they have been worked out, we can move this to release.
>

Why is this better than a metafunction c_str< Sequence >?

typedef mpl::vector_c<char, 'h', 'e', 'l', 'l', 'o'> str;

template < char const* sz >
struct x
{};

x< c_str<str>::value > test;

Is there some reason that's not possible or is prone to problems avoided
by mpl::string?

_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [mpl]... is there an mpl::string

Eric Niebler
Noah Roberts wrote:

> Eric Niebler wrote:
>>>>> Andy Stevenson wrote:
>>>>>>
>>>>>> I recall some discussion of there being an mpl::string
>>>>>> template..... Can't see it in the mpl library. Is it elsewhere?
>>
>> It has been added to trunk as of revision 52208:
>>
>> https://svn.boost.org/trac/boost/changeset/52208
>>
>> No doubt the regression tests will reveal portability problems. Once
>> they have been worked out, we can move this to release.
>
> Why is this better than a metafunction c_str< Sequence >?
>
> typedef mpl::vector_c<char, 'h', 'e', 'l', 'l', 'o'> str;
>
> template < char const* sz >
> struct x
> {};
>
> x< c_str<str>::value > test;
>
> Is there some reason that's not possible or is prone to problems avoided
> by mpl::string?


That is certainly a valid design. It's somewhat subjective, but IMO
multi-character literals give a nicer compile-time string interface.
Consider:

// With mpl::vector_c
mpl::vector_c<char, 'h','e','l','l','o',' ','w','o','r','l','d'>

// With mpl::string
mpl::string<'hell','o wo','rld'>

Neither will win a beauty contest, but my preference is strongly for the
latter.

--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [mpl]... is there an mpl::string

Raindog
In reply to this post by Andy Stevenson-2
L$$m$Ll$l$l$
------Original Message------
From: Eric Niebler
Sender: [hidden email]
To: [hidden email]
ReplyTo: [hidden email]
Sent: Apr 7, 2009 10:21 AM
Subject: Re: [Boost-users] [mpl]... is there an mpl::string

Noah Roberts wrote:

> Eric Niebler wrote:
>>>>> Andy Stevenson wrote:
>>>>>>
>>>>>> I recall some discussion of there being an mpl::string
>>>>>> template..... Can't see it in the mpl library. Is it elsewhere?
>>
>> It has been added to trunk as of revision 52208:
>>
>> https://svn.boost.org/trac/boost/changeset/52208
>>
>> No doubt the regression tests will reveal portability problems. Once
>> they have been worked out, we can move this to release.
>
> Why is this better than a metafunction c_str< Sequence >?
>
> typedef mpl::vector_c<char, 'h', 'e', 'l', 'l', 'o'> str;
>
> template < char const* sz >
> struct x
> {};
>
> x< c_str<str>::value > test;
>
> Is there some reason that's not possible or is prone to problems avoided
> by mpl::string?


That is certainly a valid design. It's somewhat subjective, but IMO
multi-character literals give a nicer compile-time string interface.
Consider:

// With mpl::vector_c
mpl::vector_c<char, 'h','e','l','l','o',' ','w','o','r','l','d'>

// With mpl::string
mpl::string<'hell','o wo','rld'>

Neither will win a beauty contest, but my preference is strongly for the
latter.

--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users




Sent from my Verizon Wireless BlackBerry
_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [mpl]... is there an mpl::string

Dominique Devienne
In reply to this post by Eric Niebler
On Tue, Apr 7, 2009 at 12:21 PM, Eric Niebler <[hidden email]> wrote:
> multi-character literals give a nicer compile-time string interface.
> // With mpl::string
> mpl::string<'hell','o wo','rld'>

Hi Eric,

I've been lurking on this thread for a while, and I'm intrigued by
"multi-character literals". Beside being new to me, a Google search
yields little information on them, beside the fact that "The value of
a narrow or wide character literal containing more than one character
or escape sequence is implementation-defined." Isn't this a problem
for mpl::string? Thanks, --DD

[1] http://publib.boulder.ibm.com/infocenter/lnxpcomp/v7v91/index.jsp?topic=/com.ibm.vacpp7l.doc/language/ref/clrc02ccon.htm

[2] http://bytes.com/groups/c/739845-multi-character-constant
_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [mpl]... is there an mpl::string

Eric Niebler-3
Dominique Devienne wrote:

> On Tue, Apr 7, 2009 at 12:21 PM, Eric Niebler <[hidden email]> wrote:
>> multi-character literals give a nicer compile-time string interface.
>> // With mpl::string
>> mpl::string<'hell','o wo','rld'>
>
> Hi Eric,
>
> I've been lurking on this thread for a while, and I'm intrigued by
> "multi-character literals". Beside being new to me, a Google search
> yields little information on them, beside the fact that "The value of
> a narrow or wide character literal containing more than one character
> or escape sequence is implementation-defined." Isn't this a problem
> for mpl::string? Thanks, --DD

"Implementation-defined" means that each compiler vendor is required to
document how multi-character literals are assigned integral values. A
library like MPL can use this information to provide a specialized
implementation for each compiler, presenting the user with a uniform
interface. And as it turns out, there is very little variation among
compiler vendors around the handling of multi-character literals. So
far, just one implementation has sufficed.

--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [mpl]... is there an mpl::string

Noah Roberts
In reply to this post by Eric Niebler
Eric Niebler wrote:

> Noah Roberts wrote:
>> Eric Niebler wrote:
>>>>>> Andy Stevenson wrote:
>>>>>>>
>>>>>>> I recall some discussion of there being an mpl::string
>>>>>>> template..... Can't see it in the mpl library. Is it elsewhere?
>>>
>>> It has been added to trunk as of revision 52208:
>>>
>>> https://svn.boost.org/trac/boost/changeset/52208
>>>
>>> No doubt the regression tests will reveal portability problems. Once
>>> they have been worked out, we can move this to release.
>>
>> Why is this better than a metafunction c_str< Sequence >?
>>
>> typedef mpl::vector_c<char, 'h', 'e', 'l', 'l', 'o'> str;
>>
>> template < char const* sz >
>> struct x
>> {};
>>
>> x< c_str<str>::value > test;
>>
>> Is there some reason that's not possible or is prone to problems
>> avoided by mpl::string?
>
>
> That is certainly a valid design. It's somewhat subjective, but IMO
> multi-character literals give a nicer compile-time string interface.
> Consider:
>
> // With mpl::vector_c
> mpl::vector_c<char, 'h','e','l','l','o',' ','w','o','r','l','d'>
>
> // With mpl::string
> mpl::string<'hell','o wo','rld'>
>
> Neither will win a beauty contest, but my preference is strongly for the
> latter.
>

After reviewing the code it seems that all my concerns are taken care
of.  It looks like it indeed iterates each individual character, not the
multicharacter literals.  It also looks like iterating <'hel', 'lo w',
'orld', '!'> would be the same as iterating 'hell','o wo','rld!'>.  So
pretty damn cool and some interesting techniques.

That said, I would still contemplate pulling the c_str out of the string
container proper.  I would say that the mpl::string is not similar to
the std::string in that it actually has to be transformed (requiring
complete reconstruction) into a c_str; there's nothing about the
mpl::string that renders c_str easier or particular to this container
besides our prebias that it should be.  That alone would indicate
separation to me but additionally if the c_str was a metafunction
separate from the string container, it could be used on any ForwardSequence.

Something to consider anyway.  Thanks for adding this.

_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [mpl]... is there an mpl::string

Ovanes Markarian


On Wed, Apr 8, 2009 at 6:09 PM, Noah Roberts <[hidden email]> wrote:

After reviewing the code it seems that all my concerns are taken care of.  It looks like it indeed iterates each individual character, not the multicharacter literals.  It also looks like iterating <'hel', 'lo w', 'orld', '!'> would be the same as iterating 'hell','o wo','rld!'>.  So pretty damn cool and some interesting techniques.

I agree with Noah.

One more question, can you point to the compiler docs which you used as reference? I am just interested to read this it for my own.


Many thanks,
Ovanes


_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [mpl]... is there an mpl::string

Eric Niebler-3
Ovanes Markarian wrote:
> Noah Roberts wrote:
>> After reviewing the code it seems that all my concerns are taken
>> care of.  It looks like it indeed iterates each individual
>> character, not the multicharacter literals.  It also looks like
>> iterating <'hel', 'lo w', 'orld', '!'> would be the same as
>> iterating 'hell','o wo','rld!'>.

That's correct.

>> So pretty damn cool and some interesting techniques.
>
> I agree with Noah.

Thanks.

> One more question, can you point to the compiler docs which you used
> as reference? I am just interested to read this it for my own.

You mean, how did I discover the nature of the implementation-defined
behavior for each compiler? It wasn't by reading any docs. I just played
around with various compilers until I found what worked. I found some
compiler bugs in the process, too. See:

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=334208

--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [mpl]... is there an mpl::string

Eric Niebler-3
In reply to this post by Noah Roberts
Noah Roberts wrote:

> After reviewing the code it seems that all my concerns are taken care
> of.  It looks like it indeed iterates each individual character, not the
> multicharacter literals.  It also looks like iterating <'hel', 'lo w',
> 'orld', '!'> would be the same as iterating 'hell','o wo','rld!'>.  So
> pretty damn cool and some interesting techniques.
>
> That said, I would still contemplate pulling the c_str out of the string
> container proper.  I would say that the mpl::string is not similar to
> the std::string in that it actually has to be transformed (requiring
> complete reconstruction) into a c_str; there's nothing about the
> mpl::string that renders c_str easier or particular to this container
> besides our prebias that it should be.  That alone would indicate
> separation to me but additionally if the c_str was a metafunction
> separate from the string container, it could be used on any
> ForwardSequence.
>
> Something to consider anyway.  Thanks for adding this.

That's not a bad suggestions, and I was on the fence myself about making
c_str a class static of mpl::string. My reason for doing so was that
getting a C-style string at compile time is really the only reason to
use mpl::string, and so accessing it shouldn't incur an extra template
instantiation.

A separate c_str metafunction might be useful, but to be a proper
metafunction, it would need to return a type, not a character array. But
as with Integral Constants, we could make:

   mpl::c_str<FwdSeq>::type::value

synonymous with:

   mpl::c_str<FwdSeq>::value

And mpl::c_str<FwdSeq>::type is probably just a typedef for
mpl::c_str<FwdSeq>.

Anyway, I've invested enough time in this already and am happy with the
result. If you'd like to see mpl::c_str<>, would you care to submit a
patch? Or at least open a feature-request Trac ticket?

--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [mpl]... is there an mpl::string

Ovanes Markarian
In reply to this post by Eric Niebler-3


On Wed, Apr 8, 2009 at 6:57 PM, Eric Niebler <[hidden email]> wrote:
You mean, how did I discover the nature of the implementation-defined behavior for each compiler? It wasn't by reading any docs. I just played around with various compilers until I found what worked. I found some compiler bugs in the process, too. See:

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=334208

Interesting. Ok, but if a string maps to an integer it means that I can only pass 4 characters at once on a 32bit platform??? I just looked over your tests and did not get immediately that these all use char test sequences.

I used a slightly different approach in my previous use case.

template<char const* Str>
string
{...};

extern const char some_string[] ={"abcd efg..."};

typedef string<some_string>          my_string_type;


Would be cool to find a solution of really passing strings like:

typedef string<"abcd efg..">     some_other_type;



Regards,
Ovanes
 


_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [mpl]... is there an mpl::string

Noah Roberts
In reply to this post by Eric Niebler-3
Eric Niebler wrote:

> Noah Roberts wrote:
>> After reviewing the code it seems that all my concerns are taken care
>> of.  It looks like it indeed iterates each individual character, not
>> the multicharacter literals.  It also looks like iterating <'hel', 'lo
>> w', 'orld', '!'> would be the same as iterating 'hell','o
>> wo','rld!'>.  So pretty damn cool and some interesting techniques.
>>
>> That said, I would still contemplate pulling the c_str out of the
>> string container proper.  I would say that the mpl::string is not
>> similar to the std::string in that it actually has to be transformed
>> (requiring complete reconstruction) into a c_str; there's nothing
>> about the mpl::string that renders c_str easier or particular to this
>> container besides our prebias that it should be.  That alone would
>> indicate separation to me but additionally if the c_str was a
>> metafunction separate from the string container, it could be used on
>> any ForwardSequence.
>>
>> Something to consider anyway.  Thanks for adding this.
>
> That's not a bad suggestions, and I was on the fence myself about making
> c_str a class static of mpl::string. My reason for doing so was that
> getting a C-style string at compile time is really the only reason to
> use mpl::string, and so accessing it shouldn't incur an extra template
> instantiation.

Well it wouldn't exactly be 'extra' would it?  The mpl::string itself
would then never be instantiated since it contains nothing but typedefs
and such.  You might need to make "size" an enum value...but it should
be at least possible to make string uninstantiated.

>
> A separate c_str metafunction might be useful, but to be a proper
> metafunction, it would need to return a type, not a character array. But
> as with Integral Constants, we could make:
>
>   mpl::c_str<FwdSeq>::type::value
>
> synonymous with:
>
>   mpl::c_str<FwdSeq>::value
>
> And mpl::c_str<FwdSeq>::type is probably just a typedef for
> mpl::c_str<FwdSeq>.

Right, it would be a value metafunction.

>
> Anyway, I've invested enough time in this already and am happy with the
> result. If you'd like to see mpl::c_str<>, would you care to submit a
> patch? Or at least open a feature-request Trac ticket?
>

I could see about doing it at home but I'm notorious for not doing so.
Interesting problem though, I might get to it.

_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [mpl]... is there an mpl::string

Eric Niebler
In reply to this post by Ovanes Markarian
Ovanes Markarian wrote:

> Eric Niebler wrote:
>> You mean, how did I discover the nature of the
>> implementation-defined behavior for each compiler? It wasn't by
>> reading any docs. I just played around with various compilers until
>> I found what worked. I found some compiler bugs in the process,
>> too. See:
>>
>> https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=334208
>
> Interesting. Ok, but if a string maps to an integer it means that I
> can only pass 4 characters at once on a 32bit platform???

Strings don't map to integers. Multicharacter literals do. And yes, that
means in general that you can only reliably count on being able to
encode a 4 char sequence in a multicharacter literal.

> I just looked over your tests and did not get immediately that these
> all use char test sequences.

I don't follow you.

> I used a slightly different approach in my previous use case.
>
> template<char const* Str> string {...};
>
> extern const char some_string[] ={"abcd efg..."};
>
> typedef string<some_string>          my_string_type;

Sure, but that gets hard to use, and you can't use this to compute new
strings at compile time.

> Would be cool to find a solution of really passing strings like:
>
> typedef string<"abcd efg..">     some_other_type;

And if wishes were fishes we'd all cast nets. ;-)

--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [mpl]... is there an mpl::string

Eric Niebler
In reply to this post by Noah Roberts
Noah Roberts wrote:

> Eric Niebler wrote:
>> I was on the fence myself about
>> making c_str a class static of mpl::string. My reason for doing so was
>> that getting a C-style string at compile time is really the only
>> reason to use mpl::string, and so accessing it shouldn't incur an
>> extra template instantiation.
>
> Well it wouldn't exactly be 'extra' would it?  The mpl::string itself
> would then never be instantiated since it contains nothing but typedefs
> and such.  You might need to make "size" an enum value...but it should
> be at least possible to make string uninstantiated.

I doubt any interesting metaprogram that uses mpl::string could avoid
instantiating mpl::string. What I don't know is whether the templates
needed to initialize mpl::string::c_str[] are instantiated even if
c_str[] is never referenced. If so, those instantiations are wasted.
That would be an argument in favor of moving c_str outside mpl::string.

There's another consideration that I've been glossing over. mpl::string
isn't *really* random access. Since mpl::string<'a','b','c'> designates
the same character sequence as mpl::string<'abc'>, it takes O(N)
template instantiations to find the N-th element in the sequence, at
least in the current implementation. I'd like to fix that, but I don't
know how (yet). It'd also be nice to be able to initialize the c_str[]
array without instantiating a pile of templates.

>> Anyway, I've invested enough time in this already and am happy with
>> the result. If you'd like to see mpl::c_str<>, would you care to
>> submit a patch? Or at least open a feature-request Trac ticket?
>
> I could see about doing it at home but I'm notorious for not doing so.
> Interesting problem though, I might get to it.

Yep, interesting. There are no small projects, it seems. <sigh>

--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
12