Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #15163

Re: STL Container Choice

Show all headers | View raw

On Thursday, March 29, 2012 1:56:39 AM UTC+2, Mike Copeland wrote:
> In article <slrnjn703s.1ls.grahn+nntp@frailea.sa.invalid>, 
> grahn+nntp@snipabacken.se says...
> > >    I have a data structure (similar to the one below) that contains a 
> > > variety of data types, and I wish to store many objects of this type in 
> > > a container that (1) allows fast retrieval access and (2) is reasonably 
> > > easy to store and update.  Its "access key" is an integer value (e.g. 
> > > bibNum).
> > >    It seems that a vector is my best choice here (fast direct access via 
> > > the key and ease of storage), but map could be better - true?
> > 
> > Not enough information.
> > - if bibNum==4711 exists, do 0--4710 exist, too?
>    No.  Objects would randomly exist throughout, with non-existant 
> objects unknown via any access process.  The range of possible index 
> values is 1..1,000,000,000.
> > - would it be useful for you to have them sorted?
>    No.  I simply want to store the object and easily/quickly retrieve 
> them as needed.  (A binary search is meaningless here, given the random 
> distribution of object.)
> > - how do you plan to modify the container?
>    I (may need to) modify individual data elements of the object.
> > - what does "many objects" mean to you?
>    100-100,000 objects.
> > 
> > The way you speak of the data in terms of <key, value> makes me think
> > you really want std::map or std::tr1::unordered_map. Use the former if
> > it's useful for you to access the entries sorted on bibNum.
> > 
> > > Are there 
> > > guidelines for container selection that could help me decide, or is some 
> > > other container type a better choice?  Pleas advise.  TIA
> > >
> > > struct FD_TYPE                     // .FIN/.CFF file data
> > > {
> > >    int            bibNum;          // Bib #
> > >    int            finTime;         // Finish Time
> > >    short          entDivNum;       // Division
> > ...
> > >    string         entName;         // Entrant Name
> > > } extern FinData;



On Thursday, March 29, 2012 1:56:39 AM UTC+2, Mike Copeland wrote:
> In article <slrnjn703s.1ls.grahn+nntp@frailea.sa.invalid>, 
> grahn+nntp@snipabacken.se says...
> > >    I have a data structure (similar to the one below) that contains a 
> > > variety of data types, and I wish to store many objects of this type in 
> > > a container that (1) allows fast retrieval access and (2) is reasonably 
> > > easy to store and update.  Its "access key" is an integer value (e.g. 
> > > bibNum).
> > >    It seems that a vector is my best choice here (fast direct access via 
> > > the key and ease of storage), but map could be better - true?
> > 
> > Not enough information.
> > - if bibNum==4711 exists, do 0--4710 exist, too?
>    No.  Objects would randomly exist throughout, with non-existant 
> objects unknown via any access process.  The range of possible index 
> values is 1..1,000,000,000.
> > - would it be useful for you to have them sorted?
>    No.  I simply want to store the object and easily/quickly retrieve 
> them as needed.  (A binary search is meaningless here, given the random 
> distribution of object.)
> > - how do you plan to modify the container?
>    I (may need to) modify individual data elements of the object.
> > - what does "many objects" mean to you?
>    100-100,000 objects.

With what we know so far, there's two equally good (IMO) solutions: unorderded_map and a vector that contains pointers to data and stores NULL for "missing" IDs.

Someone mentioned a typedef to avoid future changes. Bad idea IMO. Container type change will break code even if you do that. Less than without a typedef, but a lot still. Instead, create your own type for the container and CONTAIN actual STL container in that type. That way, your "client" code will see a reduced, specific interface to your container, and you can change the implementation at will.

Goran.

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

STL Container Choice mrc2323@cox.net (Mike Copeland) - 2012-03-28 13:20 -0700
  Re: STL Container Choice Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-03-28 21:19 +0000
    Re: STL Container Choice mrc2323@cox.net (Mike Copeland) - 2012-03-28 16:56 -0700
      Re: STL Container Choice Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-03-29 11:48 +0000
        Re: STL Container Choice mrc2323@cox.net (Mike Copeland) - 2012-03-29 08:44 -0700
          Re: STL Container Choice Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-03-29 16:05 +0000
            Re: STL Container Choice Juha Nieminen <nospam@thanks.invalid> - 2012-03-30 06:39 +0000
              Re: STL Container Choice Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-03-30 14:34 +0000
          Re: STL Container Choice Juha Nieminen <nospam@thanks.invalid> - 2012-03-30 06:40 +0000
        Re: STL Container Choice "AnonMail2005@gmail.com" <anonmail2005@gmail.com> - 2012-03-29 06:04 -0700
      Re: STL Container Choice goran.pusic@gmail.com - 2012-03-29 05:22 -0700
  Re: STL Container Choice Sam <sam@email-scan.com> - 2012-03-28 17:56 -0500
    Re: STL Container Choice Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-03-28 23:19 +0000
      Re: STL Container Choice Öö Tiib <ootiib@hot.ee> - 2012-04-02 05:49 -0700
        Re: STL Container Choice Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-04-02 21:20 +0000

csiph-web