1

I am looking for the perfect data structure for the following scenario:

I have an index i, and for each one I need to support the following operation 1: Quickly look up its Foo objects (see below), each of which is associated with a double value.

So I did this:

struct Foo {
  int a, b, c;
};

typedef std::map<Foo, double> VecElem;
std::vector<VecElem> vec;

But it turns out to be inefficient because I also have to provide very fast support for the following operation 2: Remove all Foos that have a certain value for a and b (together with the associated double values).

To perform this operation 2, I have to iterate over the maps in the vector, checking the Foos for their a and b values and erasing them one by one from the map, which seems to be very expensive.

So I am now considering this data structure instead:

struct Foo0 {
  int a, b;
};

typedef std::multimap<Foo0, std::map<int, double> > VecElem;
std::vector<VecElem> vec;

This should provide fast support for both operations 1 and 2 above. Is that reasonable? Is there lots of overhead from the nested container structures?

Note: Each of the multimaps will usually only have one or two keys (of type Foo0), each of which will have about 5-20 values (of type std::map<int,double>).

Frank
  • 64,140
  • 93
  • 237
  • 324
  • Are the Foo objects really just 3 integers with two of the integers acting together as a search key or is that an example? – msbmsb Sep 22 '10 at 16:48
  • 1
    Do you need the map to order the `Foo` objects in any particular order? If not, then you could order them lexicographically by a and b first, then c. Then for operation 2, you would not have to iterate over the entirety of each map to find all `Foo` with a given `a` and `b`. Instead, for each map use `map::lower_bound(Foo(a,b,MIN_INT));` and then walk forward. – Steve Jessop Sep 22 '10 at 16:50
  • @msbmsb: They really are just 3 integers. – Frank Sep 22 '10 at 16:50
  • @Steve: That's a very good idea, thanks. Will `map::lower_bound(Foo(a,b,MIN_INT))` give me an iterator into the map, though? And does it compile? I thought `lower_bound` needs at least 3 arguments? – Frank Sep 22 '10 at 17:12
  • If you're using `(a,b)` as a search key and `c` varies for `(a,b)`, you can just typedef `Foo` to a `pair` instead and use `make_pair(x, y)` to search/retrieve from the multimap. I don't see why you'd need the vector storing the multimaps at this point. – msbmsb Sep 22 '10 at 17:18
  • @Frank: I'm talking about the member function, not the free function in ``. The member function takes one argument, and returns an iterator. – Steve Jessop Sep 22 '10 at 17:25
  • @msbmsb: Your `pair` is equivalent to my `Foo0`. It is used as key in the multimap. I store one multimap per index i, where i=0,...,n. So I'll always need the vector, and it seems it should store multimaps mapping from (a,b) keys to (c,double) values. Maybe I'm misunderstanding your point? – Frank Sep 22 '10 at 17:28
  • @Steve: Thanks, I didn't know that member function. – Frank Sep 22 '10 at 17:51

2 Answers2

2

To answer the headline question: yes, nesting STL containers is perfectly fine. Depending on your usage profile, this could result in excessive copying behind the scenes though. A better option might be to wrap the contents of all but top-level container using Boost::shared_ptr, so that container housekeeping does not require a deep copy of your nested container's entire contents. This would be the case say if you plan on spending a lot of time inserting and removing VecElem in the toplevel vector - expensive if VecElem is a direct multimap.

Memory overhead in the data structures is likely to be not significantly worse than anything you could design with equivalent functionality, and more likely better unless you plan to spend more time on this than is healthy.

Steve Townsend
  • 53,498
  • 9
  • 91
  • 140
1

Well, you have a reasonable start on this idea ... but there are some questions that must be addressed first.

For instance, is the type Foo mutable? If it is, then you need to be careful about creating a type Foo0 (um ... a different name may be a good idea hear to avoid confusion) since changes to Foo may invalidate Foo0.

Second, you need to decide whether you also need this structure to work well for inserts/updates. If the population of Foo is static and unchanging - this isn't an issue, but if it isn't, you may end up spending a lot of time maintaining Vec and VecElem.

As far as the question of nesting STL containers goes, this is fine - and is often used to create arbitrarily complex structures.

LBushkin
  • 129,300
  • 32
  • 216
  • 265