views:

122

answers:

2

I stumbled upon multi_index on a lark last night while pounding my had against a collection that I need to access by 3 different key values, and also to have rebalancing array semantics. Well I got one of my two wishes (3 different key values) in boost::multi_index.

I'm curious if anything similar exists in the Java world.

A: 

I have no idea what boost::multi_index means, but based on the rest of your question, I think you might be talking about a multi key map

Fortega
Nope, sorry. That's an example of a weakly-typed, composite key container. boost::multi_index is strongly typed, but more importantly it has multiple, independent keys. I.e. in a multi_index_container of persons, you could look up a person by name, SSN, or date of birth. (obviously the name and DOB won't be unique keys)
MSalters
+1  A: 

I think the short answer is no, there's no obvious equivalent.

The boost multi-index class is very heavily templated, which isn't easily translatable in Java. There are generics, but they're not at all the same. ( http://stackoverflow.com/questions/996135/how-are-java-generics-different-from-c-templates-why-cant-i-use-int-as-a-para ).

So without templating, what would the multi-index class look like?

I imagine you would have your data class, e.g. Person, containing index members like a Map implementation. At this point, you have a choices:

  1. Add some "indexes" directly to the Person class (like some Hashtables) and write lookup functions. Manage index synchronization within the Person class.
  2. Write an "IndexProvider" class that decouples the index functionality entirely from Person - it would have to be able to dynamically create different index types and I would imagine you would handle synchronization via callbacks.
  3. Some mix of 1) and 2) - like an abstract base class for index functionality, which doesn't properly decouple the behaviour but does provide some code reuse.

I think, in the majority of cases 1) is the easiest to write, easiest to maintain and is probably the most performant. 2) seems like over-engineering.

The other option, if you have a lot of data structures that need indexing, is to store them in a database.

Tim Gee