[boost] Re: stream_cast

From: Kevlin Henney (Kevlin.Henney_at_[hidden])
Date: 2000-01-13 09:24:22

Nick Ambrose writes:
>I actually wrote (and used) a similar system for use with a database
>conversion application.
>We were convering a database to a set of flattened files for (supposedly)
>faster access to data and custom queries that were difficult to formulate
as
>SQL.
>It was required to attach objects of essentially arbitrary type to any
item
>in the database.
>
>To achieve this, i used a class called "attribute" which essentially had a
>SetValue/GetValue and stored an internal std::string
>on set, I serialized into the string, on get i serialized out of the
string.
>There were two versions of get/set - one that used operator << >> and
>another that allowed a user to pass in a specific conversion function.

This achieves similar aims, but through a variant type concept rather than
a conversion function. I have written a variety of classes for this in the
past, each with slightly different aims and consequences. However, I hadn't
used one so directly based on strings -- rather, union / class hierarchy
bodies -- so that's another to experiment with -- thanks. I can see the
implementation of such a type could be built directly on stream_cast.

>This allowed you to serialize in as one type and serialize out as
basically
>any other type you wanted to - the main problem I had with it was the
total
>disrespect for the type-system - i.e. there seemed (to me at the time) to
be
>no way of accidentally reading something from an incompatible object and
>ending up with garbage. Maybe there is a decent way to prevent this, I
don't
>know. Unfortunately, I don't have the code anymore (my previous employer
>owns it now I guess) but it was interesting for sure.

I think that goes with the territory: if you have variant types that
support conversions (as opposed to those that are just neutral containers,
eg CORBA::Any) you will end up with some of the negatives of softer,
script-like typing, as well as the positives.

Kevlin