c++ char*/vector hell

[eon]

i have concluded the simplest way to implement something with my current code would involve something like this:

vector<char*[10]> q;
vector<char*[10]>::iterator i;
char* a[10] = blah;
q.insert(i, 1, a);

however the compiler doesnt like this and gives a ton of errors on the insert statement. Anyone see the problem?
thanks

 

[eloj]

Beyond the obvious, like your iterator not being initialized with anything, I'd suggest something like...

typedef struct vec_t
{
  char* data[10];
} vec_t;

int main(int argc, char* argv[])
{
  std::vector<vec_t> q;
  vec_t a = { "0", "1", "2", "3", "4", "5", "6", "7", "8", "9" };
  vec_t b = { "a", "b", "c", "d", "e", "f", "g", "h", "i", "j" };

  q.push_back(a);
  q.push_back(b);

  std::vector<vec_t>::iterator it = q.begin();
  while( it != q.end() )
  {
    for(int i=0 ; i<sizeof(it->data)/sizeof(it->data[0]) ; ++i)
    {
      printf("%d=%s\n", i, it->data[i]);
    }
    ++it;
  }

}

You can of course change the push_backs to something like the following, if you _really_ want to insert objects in a vector (there's a reason you're not using a list?)

  q.insert(q.begin(), 1, a);
  q.insert(q.begin(), 1, b);

 

[Arainach]

What are you trying to do? If you want to store strings, you'll need something like

char[10] a = "blah"

char* is a pointer. Nothing more, nothing less. If you want a vector of character strings, you'll want vector<char*>. I'm pretty sure Arrays are not valid template types for use with vectors and such. Even if they are, they make an ugly unreadable mess of code and probably aren't what you should be doing anyhow. Pointers are valid template candidates, however, and pointers and arrays are at a fundamental level the same thing.

 

[eon]

ya i omitted the iterator initializing in a copy paste error

im trying to write a shell which uses alot of functions with char* parameters. What I was trying to do was store the previous states of a char* c[10] but i fortunately found an easier way by copying the input string before before it gets parsed.
next assignment im just going to convert back and forth from strings to avoid the hassle of char pointers.

 

[mikeblas]

STL collections like to own their own data. You're taking that right away from them by collecting a pointer type. If you think that writing inefficient code is worth avoiding some "hassle", that's up to you -- but it's something that I work very hard to avoid.

 

[Tramontane]

STL collections like to own their own data. You're taking that right away from them by collecting a pointer type. If you think that writing inefficient code is worth avoiding some "hassle", that's up to you -- but it's something that I work very hard to avoid.

Could you elaborate on this a bit more? I often use STL containers to maintain collections of pointers since adding items to these containers is a copy operation. In fact, I try to avoid storing objects in them. When working with heap-allocated objects I think it makes more sense to store their pointers, rather than calling an assignment operator or invoking a copy constructor. This way you save on space and processing.

 

[mikeblas]

You're trading space for some efficiency for programming convenience. If you build a std::list<struct*>, then you have to allocate each item you intend to put into the collection. At that point, since you're "manually" doing the allocation, you're losing most of the benefits of the STL. You have to allocate yourself, and you also have to deallocate by yourself. The collection no longer manages the references itself, so you can't safely call any of the copy or separation operators. Worse yet, the template doesn't know about that and can't cause a compile-time warning for you. You'll have to destroy and destruct the objects within the collection yourself, too -- another error prone process that the STL was meant to remedy for you.

Ironically, having the collections only maintain pointers ends up being somewhat more efficeint at runtime because the STL classes will only ever manipulate a pointer and never have the opportunity create and destroy expensive temporary objects. std::list<std::string> has your code building temporary objects in many places where you might not have expected it. If your memory allocator is inefficient for runtime or prone to frameneting itself, you're just asking for trouble with STL use.