Re: [boost] Comment on string / unicode discussion

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-07-06 18:59:09

David Abrahams wrote:
> "Robert Ramey" <ramey_at_[hidden]> writes:
>
>
>>> 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.
>
> Eh?  All I did was make an exact copy of code you posted, and change
> ">" to ">::type" everywhere.

Oh - I only noticed that the word "typedef" was gone.

Without looking at exactly what I did in detail and just commenting
from a users's pespective - I don't see a big problem.  Maybe its
even better in that it is explicit about exactly what we're doing -
composing iterator types to create a new iterator type.

But then - if I want to use base_64_text somewhere - where
does the ::type go?  That is: where would base_64_text::type
come from? Currently - every composed iterator can
be used as a component in another iterator.  In fact, in the
serialization library I did this a couple times just to keep the
code readible.

If STL didn't use pairs of iterators everywhere, we might not
even need the typedef - just make a composed construction - but that
gets very tedious when one needs more than one of the same type.

FWIW - my main interest really wasn't for converting strings of
characters.  I've been thinking for a very long time about what I would
want in a "views" type library for relational algebra.  Hence the name
"Dataflow".  I would really like to use this to generate at compile
time a seqence of operations on data tuples.   That is I would like
to have select, join, project, cat, etc.  I suppose this is probably
very close to what fusion already does - but I havn't looked at it.

Most database systems rely on very elaborate precompiled functions
composed at runtime.  I would hope that using something like
the above along with a very good compiler would result in much
faster programs for database operations.  Heck I would even consider
making a system which compiled each query on the fly.

I've become convinced that with templated constructors and the
iterators that are already in there (zip, filter, etc.) I'm probably
very close to where I wanted to be originally.  However, now
I'm involved in other kinds of applications so I don't have the
motivation to take things to what I see as their logical conclusion.
Oh well.

Robert Ramey