c_str like function implementation

Hi...

Does anyone know how to implement a function that returns a const char* for use in this situation:

Code:

---

class foo
{
protected:
  int i_size;
  char* c_data;  // not necesarily null terminated
...
public:
  const char* c_str()
  {
      // - how to implement ?
      // - should add a null terminator to c_data
      // - not neccesary: possybitlity of aditional manipulation of i_data
      //  ( concat with another string )
      // - only the returned string should contain the changes - i_data should
      //    not be changed in the process
  }
...
};

void bar( const char* c  )
{
    // operations on the null terminated c string
}

in main:
  foo test( "abc" );
  bar( test.c_str() );    // this part uses c_str() function to convert data to the bar function
                                    // input type ( const char* )

---

The part that is causing problems is that I don't want to use malloc in c_str() since that would produce a memory leak in such a case.

Any ideas anyone?


Thanks, Domen.

Assuming you reserve space in c_data to hold an extra zero (note that you don't necessarily need to put the zero in there in all places where c_data content is updated), you can implement c_str() as:

Code:

---

  const char* c_str()
  {
      c_data[i_size] = 0;
      return c_data;
  }

---

Obviously, if you need to concatenate multiple strings, this won't work - then you need to use some other type of buffer. If re-entrancy is not a problem, you could implement a further char pointer member of your class, initialize it to 0, and when you need to produce your c_str() result, delete the old one, and allocate a large enough buffer for your string.

--
Mats

On a side note, c_str() really, really should be const.

Yes, c_str() should be const because it returns a pointer to its buffer which shouldn't be modified. But I would say it's stupid in the first place not to NULL terminate strings.
You could also add operator const char* instead of c_str() which IMHO is my preferred way of implementation. Makes it possible to use it more like as if it was a raw char array.

Quote:

---

You could also add operator const char* instead of c_str() which IMHO is my preferred way of implementation. Makes it possible to use it more like as if it was a raw char array.

---

I suggest reading GotW #19: Automatic Conversions

Yes, they're dangerous and all that, due to C/C++ silly implicit conversions, but they are so much more convenient plus it makes it more like a "true" string.
MFC's CString has an operator const char* and thank goodness for that.
So anyway, use with care and use your head and debugger.

Gosh. **shakes head* You can't say that stuff Elysia.

Quote:

---

Yes, they're dangerous and all that, due to C/C++ silly implicit conversions

---

Exactly how you classify implicit conversions as silly. Remember we are talking about a strongly typed language. How else you'd expect the following code to compile without having to explicitly cast every operand and the operation itself?

Code:

---

double res;
float oper1;
int oper2;

// ...

res = oper1 + oper2;

---

Quote:

---

but they are so much more convenient plus it makes it more like a "true" string.

---

If they need to look like a c-string they should be a c-string.

Quote:

---

MFC's CString has an operator const char* and thank goodness for that.

---

Go you. It still doesn't mean it's a smart move. MFC hardly qualifies as a good example we all shall follow.

Quote:

---

So anyway, use with care and use your head and debugger.

---

And exactly how is that different from using a c-string if you do need one or a string-like class without the implicit conversion? With the addition you can't use the debugger so effectively if you have to step through your code to find the bug, whereas removing the implicit conversion from your class will allow you to correct your bug at compile-time.

Quote:

---

Originally Posted by Mario F.

Exactly how you classify implicit conversions as silly. Remember we are talking about a strongly typed language. How else you'd expect the following code to compile without having to explicitly cast every operand and the operation itself?

Code:

---

double res;
float oper1;
int oper2;

// ...

res = oper1 + oper2;

---

---

It means we should have a way to remove implicit conversion in code where we do not want them. Such as returning const char* operator. Implicit conversions do more harm than good here.

Quote:

---

If they need to look like a c-string they should be a c-string.

---

Sigh, no... C-style strings bad. Bad. String classes good.

Quote:

---

Go you. It still doesn't mean it's a smart move. MFC hardly qualifies as a good example we all shall follow.

---

Never said it was a smart move... or good practice.

Quote:

---

And exactly how is that different from using a c-string if you do need one? With the addition you can't use the debugger so effectively if you have to step through your code to find the bug, whereas removing the implicit conversion from your class will allow you to correct your bug at compile-time.

---

Simplicity and convenience.

Quote:

---

Originally Posted by Elysia

Yes, they're dangerous and all that, due to C/C++ silly implicit conversions, but they are so much more convenient plus it makes it more like a "true" string.
MFC's CString has an operator const char* and thank goodness for that.
So anyway, use with care and use your head and debugger.

---

Yeah, C++ has a lot of "silly" things like namespaces, C++ casts, references... Who need those things anyways? ;)

No, don't take that the wrong way.
I know you can complain about implicit conversion in a lot of classes, but references and namespaces aren't bad things. C++ casts aren't bad either, I'm just not too prone in using them.

Quote:

---

Originally Posted by Elysia

It means we should have a way to remove implicit conversion in code where we do not want them. Such as returning const char* operator. Implicit conversions do more harm than good here.

---

But you yourself said it would be a good idea!

Quote:

---

Originally Posted by Elysia

You could also add operator const char* instead of c_str() which IMHO is my preferred way of implementation. Makes it possible to use it more like as if it was a raw char array.

---

How could you remove an implicit conversion you just created?

Moving on...

Quote:

---

Sigh, no... C-style strings bad. Bad. String classes good

---

The usual misconception. The same thing with arrays and other "evils".

No. c-style strings aren't bad. I specifically said "you should use them when you need them". I don't go about incurring in the extra overhead of std::string if I can create c-strings to feed some library demands. Just an example.

Quote:

---

Originally Posted by Mario F.

But you yourself said it would be a good idea!

---

I don't consider overloading an operator in a class as an implicit conversion, though.
Implicit conversion is calling a bool constructor when passing an int argument.

Quote:

---

The usual misconception. The same thing with arrays and other "evils".

No. c-style strings aren't bad. I specifically said "you should use them when you need them". I don't go about incurring in the extra overhead of std::string if I can create c-strings to feed some library demands. Just an example.

---

With the right implementation, you never need to use them at all. CString has GetBuffer to cover char* and const char* operator for covering const char*. No C-style strings, only CString.

Quote:

---

I don't consider overloading an operator in a class as an implicit conversion, though.

---

In this case you are defining a conversion function.

Quote:

---

Implicit conversion is calling a bool constructor when passing an int argument.

---

The C++ Standard section 12.3 states: "At most one user-defined conversion (constructor or conversion function) is implicitly applied to a single value." Clearly it regards conversion functions as a means of implicit conversion.

Examples of explicit conversion would be having to explicitly use a constructor, or having to use a function like c_str() to perform the conversion.

By the way, built-in types do not have constructors.

OK then, conversion functions are okay, but implicit conversion can be a pain.
The compiler should be able to call the conversion function when calling a function that takes a const char* for example, but calling it to implicitly convert a string to char* so you can subtract pointers may not be what you want.
It would be nice if such things could be restricted.

Oh no.

Anyway, I don't really see what would be the reason not to keep c_data null-terminated (your comments in foo are somewhat confusing - despite of the attempt at Hungarian notation, you keep mentioning something called i_data)? If foo is a string-like class what additional modifications should c_str possibly perform? If foo is not a string-like class, why should it have a method called c_str?

Quote:

---

If foo is a string-like class what additional modifications should c_str possibly perform?

---

Adding a null terminator if the internal string is not null terminated. I note that this is actually an option for implementations of std::basic_string. For example, the data() member function returns a pointer to the first character of an array of characters that is not guaranteed to be null terminated.

Quote:

---

Originally Posted by laserlight

Adding a null terminator if the internal string is not null terminated. I note that this is actually an option for implementations of std::basic_string. For example, the data() member function returns a pointer to the first character of an array of characters that is not guaranteed to be null terminated.

---

Yes, but what would be a good reason not to keep the internal data null-terminated (even if it doesn't use the terminator for any internal purpose and allows null-characters within the string)?

[quoteYes, but what would be a good reason not to keep the internal data null-terminated (even if it doesn't use the terminator for any internal purpose and allows null-characters within the string)?[/quote]
Saving space is the only reason I can come up with.

Quote:

---

Saving space is the only reason I can come up with.

---

Perhaps it has something to do with basic_string being a template (although I can't see why I'd make a string of something that is not a character-like)?

Anyway, how can you save space (1 byte), if you probably need to add a whole char pointer to the class to be able to implement c_str()?

Quote:

---

Originally Posted by anon

Perhaps it has something to do with basic_string being a template (although I can't see why I'd make a string of something that is not a character-like)?

Anyway, how can you save space (1 byte), if you probably need to add a whole char pointer to the class to be able to implement c_str()?

---

You may want to store the string as a chain of buffers to avoid unneded reallocation on string growth... and only in the c_str() function reallocate the whole contents into one continues buffer and return pointer to the first char

Quote:

---

Originally Posted by laserlight

By the way, built-in types do not have constructors.

---

Code:

---

#include <iostream>

int main()
{
    int i(10);  // default constructor, right?

    return 0;
}

---

>> // default constructor, right?
Actually, no. The default constructor for a class takes no arguments. Besides, that code works like a copy constructor, but it is still not considered a constructor call.

Quote:

---

Originally Posted by robwhit

int i(10); // default constructor, right?

---

It's called direct-initialization. As opposed to copy-initialization which would be int i = 10;

The distinction becomes apparent with objects of a class type in which copy-initialization involves the construction of a temporary.

Code:

---

std::string str1 = "Hello"; // temporary is created
std::string str2("Hello"); // direct initialization through constructor taking const char*

---

For built-in types the notations are kept, although I think is treated in no different way by the compiler. Defintely, no constructors are involved

Quote:

---

If foo is a string-like class what additional modifications should c_str possibly perform?

---

I'm not saying that it should, I yust added that so that if there would be a possibility of creating a pointer to a string + some aditional characters without malloc, return it without the bad pointer problem and then using it as another function parameter, someone would point it out.

Btw while researching this I read somewhere that this is OK ( unfortunately I don't remember wher this was posted ):

Code:

---

const char* s = "hello";

---

Howcome that is permited while this can create problems with the pointer:

Code:

---

const char* c_str()
{
  char* s = i_string;  // char* i_string;
  s[ i_size ] = '\0';
  return s;
}

---

Ah. Thanks.

"hello" is a string literal. It is constant and cannot be changed. Therefore, this second line of code is illegal:

Code:

---

const char* s = "hello";
s[0] = 'b';

---

Your second piece of code is also perfectly legal:

Code:

---

const char* c_str()
{
  char* s = i_string;  // char* i_string;
  s[ i_size ] = '\0';
  return s;
}

---

Since your c_str() method is not a const function (there is no const at the end of the first line), you are allowed to modify the i_string member variable. Assigning it to a char* is allowed. You then modify the characters pointed to by s, which also modifies i_string, which is still allowed. Finally, you return the pointer s as a const char *, meaning whichever code saves the return value is not allowed to modify the characters.

So I don't understand why you think that code "can create problems with the pointer". Can you elaborate?

Quote:

---

hello" is a string literal. It is constant and cannot be changed. Therefore, this second line of code is illegal:

const char* s = "hello";

---

OK now I filaly get it. My stupid mistake that I thought that this is wrong because of the pointer to a constant string ( didn't know that that was legal).

Quote:

---

So I don't understand why you think that code "can create problems with the pointer". Can you elaborate?

---

I once had some problems in one test case ( don't remember anymore what it was ). In all the other test cases it worked so perhaps I made a mistake somewhere else back then.

I thouhth that the problem was caused because if you have a pointer of some length and then add aditional characters over the allocated size it could overwrite some other part of the memory that contains other data. Is that not so?

>> Is that not so?
You are correct. My statement wasn't complete, I assumed that there was enough space. That code will cause problems if the allocated space for i_string is smaller than i_size+1.

A common implementation for c_str() is to allocate at least size+1 characters for your character array. That way, data[size] = '\0' will be valid. This is what matsp was suggesting in the first response.

Quote:

---

A common implementation for c_str() is to allocate at least size+1 characters for your character array. That way, data[size] = '\0' will be valid. This is what matsp was suggesting in the first response.

---

I intend to keep the null character now that I know that I can't easily write it otherwise.
Thanks to all for the explanations.

Did you mean you intend to keep room for the null character or that you intend to always add the null character?

You can do it either way, there's nothing wrong with waiting until they call c_str() to add the null character if you always make sure there is enough space for it, and that isn't difficult either as long as you add one to whatever value you are allocating.