c++ metadata

[sylvain]

Hi!

Just a little question: How could I use metadata when compiling a .ice file using slice2cpp?

I am trying to instruct the slice2cpp compiler to use a multimap instead of a map to implement a dictionary.

I tried different variant, including:

["c++:multimap"] dictionary<string,string> myDict;

["cpp:::std::multimap"] dictionary<string,string> myDict;

and stuff like that, following the example at the top of page 123 of Ice-1.1.0b.pdf, but nothing worked.

Thanks in advance for your help!

[mes]

Hi,

Currently you can only modify the Java language mapping in this way.

- Mark

[sylvain]

Ok, I was not aware of that.

Are you planning to include this feature in the next release of Ice?

Thanks!

[marc]

A multimap is problematic, because it is not a mapping change. It is really a type change. In order to support multimaps, we would have to add a new Slice type.

But multimaps can be emulated by using a map with a sequence of values as value type. Can't you use this in your case?

[sylvain]

That's true: a multimap is in fact a new type, not another "interface" for the same type, I did not realize it.

I wil use a dictionary<key,sequence<value> > instead. Thanks.

But things like using a std::list instead of a std::vector for sequence<> could be useful sometimes, no?

Another type of container I like to use are the "set" kind, because the auto-sorting and enhanced find capabilities are sometimes of great use (afaik with my little programming experience).

I would be happy if a could use slice metadata to instruct slice2cpp to use a "vectorized" set for the sequence instead of a vector. "Vectorized" means that I could write a little wrapper for a set that implement push_back and other methods of the vector interface in addition to the set interface, so that Ice doesn't even see it is not a real vector.

Can this be a cause of troubles?

[marc]

Yes, metadata to map a sequence to a list instead of a vector would be useful. Another item to put on our todo list

A "set" container would be a new Slice type, because it's not just a different mapping of sequence. On the other hand, a sequence could be mapped to a multiset, if the sorting is done during unmarshaling. But that's of course not as efficient as having a separate type, which gurantees that the marshalled format is sorted.

But sorting in general is a problem for middleware such as Slice. What sorting criteria should be used? This is really part of implementation, not of specification.