views:

181

answers:

4

So I want to have a buffer with an array of structs like this:

EventItem
{
   tag; // some string or array of characters to describe the value;
   value; // some integer or something

}

The value can be anything like int32. What I am concerned about is the tag. If I have an array of these objects, and I make the tag a string, what happens if the user inputs an EventItem into this buffer that has a long tag? Will that cause the buffer or parts of it to be copied to somewhere else in memory to hold this bigger EventItem (bigger because of this long string)?

Would it be better for me to limit the tag by just using a fixed amount of character by using an array instead of a string?

Obviously I don't know exactly what I'm talking about, but I don't know how the buffer can be created with the right amount of contiguous space without knowing the size of the EventItems in advance.

Could someone explain how this situation would go down for me?

Thanks very much in advance!

+7  A: 

What you want is a std::string.

Not only because its c++ and not c, but also because operating on std::strings is much easier than on char[].

Also, the construction of your struct might be easier and more straightforward as well, avoiding copy of char[]

struct EventItem{

   EventItem(const int_32 value,const std::string&tag):m_value(value),m_tag(tag){}

   int_32 m_value;
   std::string m_tag;
};

What I am concerned about is the tag. If I have an array of these objects, and I make the tag a string, what happens if the user inputs an EventItem into this buffer that has a long tag? Will that cause the buffer or parts of it to be copied to somewhere else in memory to hold this bigger EventItem (bigger because of this long string)?

Not clear (IMO), but im leaned towards the "no, and dont worry about it". The only way that could happen would be that the buffer crosses a page boundary (assuming paged memory here). Well, if it happens, it happens. The miracle of virtual memory will take care of it.

Obviously I don't know exactly what I'm talking about, but I don't know how the buffer can be created with the right amount of contiguous space without knowing the size of the EventItems in advance.

Let std::vector take care of that. Of course, situations may arise always where contiguous space may not be available. Why are you so worried. Can you explain to us the situation where this would be a problem?

Tom
The value and tag variables should be accessed with this.value and this.tag (not as you did: this->value and this->tag).
Igor Popov
@Igor We are talking c++ right? Im not sure I follow.
Tom
Please use const references for value parameters. Inconvenient as it is, this should be some of the first things to learn.
Markus Kull
@Tom: Your code is not idiomatic. Here's how it should be: http://pastebin.com/0PeqtvqT
missingfaktor
@Tom: Sorry for the misunderstanding. Your code is correct.
Igor Popov
@Tom: Glad you edited. :-)
missingfaktor
+2  A: 

If I have an array of these objects, and I make the tag a string, what happens if the user inputs an EventItem into this buffer that has a long tag? Will that cause the buffer or parts of it to be copied to somewhere else in memory to hold this bigger EventItem (bigger because of this long string)?

If you're using std::string, then EventItem itself will not increase (or decrease) in size no matter that you do to the string member. std::string manages its actual content by storing it elsewhere. Inside it probably contains a pointer to memory allocated elsewhere (probably using new). If it ever needs to expand to store more content, it simply allocates new memory, copies the data over, and deallocates the old. The std::string object itself always stays the same size.

This applies to pretty much everything in C++. std::vector, std::list, etc. Essentially any object which somehow seems to dynamically expand to store more and more content is actually using pointers and new to store the content elsewhere.

On the other hand, you do have to be wary if you ever store your own pointers to some pieces of content managed inside an object like std::string or std::vector or such. When adding more elements to such a container, the entire set may end up being copied elsewhere and thus invalidating your pointers.

So if you perhaps have std::vector then anytime you add another EventItem to that vector it could possibly move the entire group elsewhere in memory. But of course if you only ever access those elements through methods of the vector (such as at() or operator[]) then you wouldn't even notice the difference.

TheUndeadFish
A: 

Both suck. Use QString instead.

Jim
@Jim - are you suggesting that the solution to every C++ string problem is to import the Qt library?
McDowell
A: 

It depends what the buffer needs to contain. Typically data buffers aren't allowed to have real pointers inside. That precludes data structures even as simple as std::string. If that isn't a requirement, please re-think whether you in fact need a flat data buffer.

Data buffers with fixed allocation for strings have no place in C++. Small embedded systems, yes. Usually such applications don't involve "describing the value."

Most likely, you should scrub the application of any use of arrays, buffers, char[]'s, and persistent raw pointers in favor of vector, string, and managed structures.

Potatoswatter