Boost logo

Boost :

From: Geoff Leyland (geoff.leyland_at_[hidden])
Date: 2002-07-31 05:46:25


Sorry I didn't reply sooner, my presence near mail has been a bit patchy
for the last few days, and will continue to be so for a few more, but I
am definitely interested in any/variant.

On Samedi, juillet 27, 2002, at 10:27 , "Itay Maman"
<itay_maman_at_[hidden]> wrote:

> Consider this code:
> map<string, any> x;
> x["a.b"] = 2.0;
> x["a.c.d"] = "hello";
> if(string* p = any_cast<string>(&(x["a.c.d"]))
> cout << *p;
> Isn't it semantically equivalent to your code?

Yes, but I think I didn't explain myself very well, or that I've missed
some cunning ways of doing things. What you've written works fine, and
would be both simpler than what I've done, and maybe faster, but

map<string, any> x, y;
y["a"] = 2.0;
y["b"] = "hello";
x["c"] = y;

ends up with you having to go x["c"].be<map<string, any> >()["b"] to get
"hello" back, whereas I'd rather go x["c.b"] (and this is a case where
you really have to use the "be" or "any_cast", which you can avoid for
assignment and casts). You could get over this by overloading the "="
operator so that it tacked "c." onto the beginning of all the elements
of y and assigned them to x with full names.

Passing a const reference to part of x :


would also be difficult - you could "find" "c." in x, and then make a
new map out of all subsequent things you iterated through that started
with "c.", but this would preclude the use of hash_maps (which never
seem to work for more than one compiler for me anyway, but surely will
one day)

passing a non-const reference would just get too tricky:


because you'd have to somehow recover the values back into x, or pass
copies of the elements (can many anys refer to the same holder?),

and when you started to use vector notation, and wanted equivalence




you'd be all tied up.

So I think it's worth "interpreting" the "addresses" of the members, and
having a structure that contains structures, but I'd be very happy to
hear from anyone who can make my life simpler - not that the address
interpreting is very difficult either.

Do I take it from your mail that I should be looking at variant as the
future of any/variant? Can I check it out of cvs?

A couple of comments about the existing (1.28) any, which may be way out
of date, so please excuse me if I'm wrong.

The current any has a "smart" any containing a pointer to a "dumb"
holder. I would look at doing things the other way round - so that the
holder has all the functionality if possible, and the current "any"
object becomes more or less just a pointer. Why? Because it means you
can use the "holder" independently in lots of different ways - for
example having smart pointers to them, sticking them in maps and so on,
and just using them raw.

Secondly, I use an isa<> to check types rather than checking equivalence
of typeids, and this might be better. Why? When I assign a const
char * to one of my objects, it gets stored as a string. However, you
quite likely want it back as a const char *. I haven't done it yet, but
I can imagine a way to arrange this conversion, and to get an isa<const
char *> to tell me that my string can be a const char *. I don't see
how I can to this by comparing typeids. Thing of the isa<> as a
can_be_a<>, and at least we're getting told what the user would like the
data to be. With the typeid, we don't know what the user wants, and so
can't really help them with it.


"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, gregod at, cpdaniel at, john at