The main advantage of "dynamic strings" over bstrlib is that a string pointer is also a char * that can be passed to C string functions. You can get exactly the same effect by calling bdata() on your bstrings, provided you don't need embedded NULs, which is what the linked article assumes. I don't think that's a big inconvenience.
The "dynamic strings" technique also has big disadvantages. First of all, suppose you store a pointer to a dynamic string in one part of your program, then modify the string in another. The first pointer will be invalidated if the string needs to be reallocated, because the memory address of the string has changed. In contrast, the memory address of a bstring header never changes, so you don't need to worry about dangling pointers.
The implementation given in the article is horribly inefficient. If you want to implement a similar library, it would be much better to store the string's length and capacity in the same block as the string data, where they could be referenced at negative offsets to the character pointer. Borland Delphi's string implementation works like that, but those strings are reference counted and copy-on-write, so they don't have the problem mentioned above.
My advice would be simply to use bstrlib as-is.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi All,
is there a way to have a dynamic string with bstrlib ?
Something like this:
http://www.ddj.com/web-development/184401650
Thanks in advance for any comments.
Regards,
Pedro
The main advantage of "dynamic strings" over bstrlib is that a string pointer is also a char * that can be passed to C string functions. You can get exactly the same effect by calling bdata() on your bstrings, provided you don't need embedded NULs, which is what the linked article assumes. I don't think that's a big inconvenience.
The "dynamic strings" technique also has big disadvantages. First of all, suppose you store a pointer to a dynamic string in one part of your program, then modify the string in another. The first pointer will be invalidated if the string needs to be reallocated, because the memory address of the string has changed. In contrast, the memory address of a bstring header never changes, so you don't need to worry about dangling pointers.
The implementation given in the article is horribly inefficient. If you want to implement a similar library, it would be much better to store the string's length and capacity in the same block as the string data, where they could be referenced at negative offsets to the character pointer. Borland Delphi's string implementation works like that, but those strings are reference counted and copy-on-write, so they don't have the problem mentioned above.
My advice would be simply to use bstrlib as-is.