STL Composed Types

This is a discussion on STL Composed Types within the C++ Programming forums, part of the General Programming Boards category; Hi all. First of all let me apologize by my english. I've googled a lot about my problem, but I ...

  1. #1
    Registered User
    Join Date
    Nov 2007
    Posts
    2

    STL Composed Types

    Hi all.
    First of all let me apologize by my english.
    I've googled a lot about my problem, but I had not find anything conclusive.
    I have the following piece of code:

    Code:
    vector < map < int , char * > > bank;
          bank . reserve ( 10 );
          if ( bank [ 0 ] [ 0 ] == "a" ) //Memory access error (Access violation at address #blabla)
    which give me the error indicated in comment.
    So, to test, I included the following line before "if", and the error changes to that line

    Code:
    bank [ 0 ] [ 0 ] = "b"; //Same error
    Finally, the following inserted in place of the line above, works.
    Code: ( text )

    Code:
          map < int , char * > data;
          data [ 0 ] = "a";
          bank . push_back ( data );
    But this is hardly an option to me. Mainly because I need, most of times, to test the variable "bank" (even the NULL address existence, which tells me that new item insertion is ok) before I can decide what to do. Beside that, that association grows interactively.
    As I can see, it seems a problem with map allocation.
    So, my exactly question is how can I use this type of association ( vector < map < type1 , type2 > > ) without get into Mermory access violation errors? Is there a way to previously initialize that association in a manner that allow me to insert new element just doing
    Code: ( text )

    Code:
    bank [ i ] [ j ] = "some"
    even after the limits previously defined (growing the association)?
    Please excuse me if this is trivial, but I'm new to STL.
    I appreciate any helps.
    Thanx in advance.

  2. #2
    The larch
    Join Date
    May 2006
    Posts
    3,573
    The reserve() method merely "reserves" memory, but doesn't make it legal to access the reserved elements (the vector's size is still 0). reserve() usually goes hand-in-hand with push_back().

    Another thing is that using a char* for strings may not be a good idea. Use the std::string class instead.
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  3. #3
    Registered User
    Join Date
    Nov 2007
    Posts
    2
    OK. I agree, but there is a way to avoid push_back? I've seen many examples of vectors where elements are created just with "bank [i][j]=some;". push_back means a lot of rework to me.

  4. #4
    The larch
    Join Date
    May 2006
    Posts
    3,573
    Then use resize() instead of reserve(), or a vector constructor that takes the number of items.
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  5. #5
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    The std::string thing is important, too. You cannot compare char*-strings with ==. Nor is it safe to insert string constants into a char* container. (It's just barely legal, even.)
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  6. #6
    Registered User
    Join Date
    Jan 2005
    Posts
    7,317
    Code:
    vector < map < int , string > > bank(10);

  7. #7
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,302
    Quote Originally Posted by tuxman View Post
    OK. I agree, but there is a way to avoid push_back? I've seen many examples of vectors where elements are created just with "bank [i][j]=some;". push_back means a lot of rework to me.
    In a vector elements are never "created" using array syntax, exisitng elements are simply overwritten. You don't have any existing elements, the container size is still zero!
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  8. #8
    Registered User
    Join Date
    Apr 2006
    Posts
    2,027
    Quote Originally Posted by tuxman View Post
    OK. I agree, but there is a way to avoid push_back? I've seen many examples of vectors where elements are created just with "bank [i][j]=some;". push_back means a lot of rework to me.
    If you want elements to be created, use a map<int,map<int,string> >.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  9. #9
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by tuxman View Post
    push_back means a lot of rework to me.
    It's nothing but a slight syntactical difference. Suck it up!

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. The Interactive Animation - my first released C program
    By ulillillia in forum A Brief History of Cprogramming.com
    Replies: 48
    Last Post: 05-10-2007, 02:25 AM
  2. Dikumud
    By maxorator in forum C++ Programming
    Replies: 1
    Last Post: 10-01-2005, 06:39 AM
  3. Stl lists and user defined types
    By figa in forum C++ Programming
    Replies: 8
    Last Post: 03-28-2005, 11:09 AM
  4. include question
    By Wanted420 in forum C++ Programming
    Replies: 8
    Last Post: 10-17-2003, 03:49 AM
  5. putting primitive non pointer data types on stl vector
    By Silvercord in forum C++ Programming
    Replies: 8
    Last Post: 01-19-2003, 10:42 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21