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