[boost] Re: Any, variant and more, and Sobol sequences

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: [phone], Fax: [phone]