Subject: Re: [Boost-users] [mpl]... is there an mpl::string
From: Eric Niebler (eric_at_[hidden])
Date: 2009-04-08 14:16:51
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