Function expecting char*, does using vector<char> gain me anything?

[Jim Langston]

I'm using a function like this:

char TextBuffer[261];
jGet_DropDown_S elected_Text( cc.ddSex, TextBuffer);

Where the function is filling in the text buffer. I don't have access to
the actual function to change it to a std::string (it's a library function)
so I was thinking, well, I could use a std::vector<cha rinstead of a char
array, but would that actually gain me anything at all? I mean, what's the
difference between calling it like the previous, and calling it like this:

std::vector<cha rTextBuffer;
TextBuffer.resi ze(261);
jGet_DropDown_S elected_Text( cc.ddSex, &TextBuffer[0]);

with any needed casting I may need.

Now, if std::string could be called this way it would be wonderful! I would
just live to do:

std::string TextBuffer;
TextBuffer.resi ze(261); // or similar
jGet_DropDown_S elected_Text( cc.ddSex, TextBuffer.c_st r());

But as I'm sure most of us are aware, c_str() returns a const char * and
can't be used this way (the main reason std::string isn't used instead of
char arrays IMO).

So, should I just stay with the char array?

[rep_movsd]

Jim Langston wrote:

Now, if std::string could be called this way it would be wonderful!

std::string has a begin() and end() so you can use it in the same way
as u did for vector<char>

&*str.begin( ) would give you access to the data in str.

Or you could be bad and cast away the constness:
(char*)str.c_st r()

Regards
Vivek

[Markus Moll]

Hi

Jim Langston wrote:

I'm using a function like this:

char TextBuffer[261];
jGet_DropDown_S elected_Text( cc.ddSex, TextBuffer);

Where the function is filling in the text buffer.

I don't like the design of the library. Is there any guarantee that
jGet_DropDown_S elected_Text will only ever write 261 bytes?
What happens if the "selected text" is longer than that?
I would have expected another parameter (the size of the array) for checking
array bounds. But if you have to work with it... make sure that your buffer
is guaranteed to be large enough.

I don't have access to the actual function to change it to a std::string
(it's a library function) so I was thinking, well, I could use a
std::vector<cha rinstead of a char array, but would that actually gain me
anything at all?

No. Nothing. It would make your code harder to read, yes.

I mean, what's the difference between calling it like the previous, and
calling it like this:

std::vector<cha rTextBuffer;
TextBuffer.resi ze(261);
jGet_DropDown_S elected_Text( cc.ddSex, &TextBuffer[0]);

with any needed casting I may need.

The difference is that the above is a line longer, uses another type and
weird syntax (&TextBuffer[0]) while offering no advantages at all.

Now, if std::string could be called this way it would be wonderful! I
would just live to do:

std::string TextBuffer;
TextBuffer.resi ze(261); // or similar
jGet_DropDown_S elected_Text( cc.ddSex, TextBuffer.c_st r());

This would only be a little better, but I wouldn't call it wonderful.

But as I'm sure most of us are aware, c_str() returns a const char * and
can't be used this way (the main reason std::string isn't used instead of
char arrays IMO).

Who told you std::string isn't used? I think the main reason why it isn't
used in the library you have, is that it is probably a C library.

So, should I just stay with the char array?

Yes, I would. If you feel any need, you can still copy the contents into a
std::string afterwards.

Markus

[benben]

rep_movsd wrote:

Jim Langston wrote:

>Now, if std::string could be called this way it would be wonderful!

std::string has a begin() and end() so you can use it in the same way
as u did for vector<char>

&*str.begin( ) would give you access to the data in str.

Don't do this. The standard library string makes no guarantee that the
buffer is consistent with the plain old char[].

>
Or you could be bad and cast away the constness:
(char*)str.c_st r()

Don't do this either. Both suggestions from rep_movsd produce Undefined
Behavior. Its better to make your program CORRECT; then you can worry
about style.

I guess a better solution is to overload jGet_DropDown_S elected_Text so
it will accept a string:

std::string jGet_DropDown_S elected_Text(wh atever_t whatever)
{
char buff[256];
jGet_DropDown_S elected_Text(wh atever, buff);
return std::string(buf f);
}

// use the overloaded function like
std::string str = jGet_DropDown_S elected_Text(cc .ddSex);

>
Regards
Vivek

Ben

[Earl Purple]

Jim Langston wrote:

I'm using a function like this:

char TextBuffer[261];
jGet_DropDown_S elected_Text( cc.ddSex, TextBuffer);

Where the function is filling in the text buffer. I don't have access to
the actual function to change it to a std::string (it's a library function)
so I was thinking, well, I could use a std::vector<cha rinstead of a char
array, but would that actually gain me anything at all? I mean, what's the
difference between calling it like the previous, and calling it like this:

std::vector<cha rTextBuffer;
TextBuffer.resi ze(261);
jGet_DropDown_S elected_Text( cc.ddSex, &TextBuffer[0]);

with any needed casting I may need.

You don't need any. In your case there is no real gain but that's
because you have hard-coded in a magic number that is 261. If your
number is a variable then you would need to use vector, although
programmers in C99 can dynamically create arrays. However C99
programmers don't have vector available to them.

Now, if std::string could be called this way it would be wonderful! I would
just live to do:

std::string TextBuffer;
TextBuffer.resi ze(261); // or similar
jGet_DropDown_S elected_Text( cc.ddSex, TextBuffer.c_st r());

But as I'm sure most of us are aware, c_str() returns a const char * and
can't be used this way (the main reason std::string isn't used instead of
char arrays IMO).

std::string is not writable in this way. So use vector albeit that it
brings in 2 inefficiencies (that might not be critical) in that (1) it
initialises the buffer and (2) you then have to copy it into a string
to be able to use string functions (wouldn't be necessary if much of
the string functionality were free-functions and could work with
vectors of characters too).

So, should I just stay with the char array?

With the char array you gain 2 advantages: (1) no runtime allocation
(2) no initialisation.
So if you really can guarantee that you want a size of 261 then char
array may be the best option. You might want to "enumerate" your magic
number though.