David Abrahams wrote:
Maybe you never articulated sufficiently clearly what you added to the basics provided by the iterator library, and why.
LOL - apparently so.
Of course there is another possibility - that it's clear how it works but no one sees the appeal of the approach. A previous time when ranges was being discussed, I flogged this idea and there was a strong objection raised to the nested template syntax. Funny thing was - that is exactly what I love about this. Its the compile time counter-part of the common way of composition invoked at run time. When iostreams code conversion was being discussed I also tried to promote the idea - but I think it was seen as to "far out". I suspect that a large part is aesthetic and what people are familiar with. It started out as an experiment with the then new boost iterators. As I progressed I became more enthusiastic about the idea. It was of immense help with implementing the more tedious aspects of the serialization library and has needed almost no maintainence. So I'm very happy with it. In my view it - or something like it - provides the answer to the question which started this thread- whatever that was.
Thanks; I think I see why you need the templated ctors now.
w.r.t. composing with a typedef, would
boost::archive::iterators::insert_linebreaks< boost::archive::iterators::base64_from_binary< boost::archive::iterators::transform_width< const char *, 6, 8 >::type >::type ,72 ,const char // cwpro8 needs this >::type base64_text;
be much worse, for your purposes?
Hmmm - I read this as creating an instance of base64_text - presumably on the stack. I don't see how I could use this to do:
std::copy( base64_text(address), base64_text( address + count ), oi );
which is what I REALLY wanted to do. Robert Ramey