Boost logo

Boost :

From: Geoff Leyland (geoff.leyland_at_[hidden])
Date: 2002-08-12 11:13:28


On Lundi, août 12, 2002, at 04:10 , "Dylan Cuthbert" <dylan_at_[hidden]>
wrote:

>> template <class T> operator T(void);
>
> *this* is probably Not a Good Idea ;-)

Well, I was a bit suspicious of it, but then, what the hell. And it
hasn't caused me any problems. What are the concrete objections to it?
If people don't like it, tho', there'd be easy ways around it.

a["one.two.three.four"] just returns an object that contains the
interpreted path and a reference to a, which waits till you do something
with it.
If you do a be<>, or a ref<> or an isa<> or a has, it walks down the
path and excepts (or returns false in the case of has) if the path
doesn't exist, and otherwise does what it should.
If you assign to it, it builds the path as it walks down it, so you can
go:
whatever_map a;
a["one.two.three.four"] = 5.0;
without having to go
a["one"] = whatever_map();
a["one.two"] = whatever_map();
and so on for all the parent bits.

So it would be fairly easy to give the interpreted path thing a .guess()
that left behind an object that had the horrible template <class T>
operator T(void) in it. Then those who didn't like it could avoid it.
But then, there's not much difference between a["one.two"].guess() and
a["one.two"].be<double>().

> Also, you will probably have to remove the fixed "class" accessors, like
> c_str() etc. in order for it to be general enough.

Well, they're quite specific ones. The .str() one is so you can get a
string representation of whatever's in the list - I think this comes
free with any - but I haven't really implemented it. The .c_str() one
would be the same, tho' honestly I suspect it wouldn't work. The .map()
and .vector() were just to save me typing .ref<whatever_map>(), which I
end up doing a lot, but I s'pose they could go...

> The only problem of course, is getting the auto-conversion between
> floats/ints (numerics) working. I can't think of a good way
> unfortunately.

I think by having a limited number of storage types you could probably
get it down to trying a couple of dynamic casts, and seeing which
worked. It implies run-time iterating through a (short) compile-time
generated list of types, but isn't that what MPL's all about? Does the
new variant/any not solve this already? (I don't know, I haven't looked)

> This problem and base-classes, ie. say a Dog with an Animal base class
> was
> stored, and I try to access the variable by specifying just "Animal" as
> its
> type, right now, my system will report a mismatched type and not allow
> it.

If you could get the user of the lib to list all the children of a
parent class in some kind of traits template, you might get it to work,
no? Otherwise I'm scratching my head on that one... Luckily for me I
stick parameters for a evolutionary algorithm in mine, and they're
mostly ints, reals and strings.

cheers,
goof

--
"To a man with a hammer, everything looks like a nail."
- Mark Twain
Geoff Leyland, Village Idiot
Laboratoire d'energetique industrielle
LENI-DGM-EPFL, CH-1015, Lausanne, Switzerland
Phone: +41 (21) 693 3505, Fax: +41 (21) 693 35 02

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk