STL string : is it any good?
-
I've been tinkering a little with STL after my brief run-in with the map template the other week. It took me a while to recover from that episode; but i've been having a go with the string thing. My current program users c strings (char arrays, not that mfc bunk). I can already hear Christian muttering in the background. I used them becuase my program has the following traits: -> lots of scanf and sprintf type stuff goes on, to jam integers to and from strings. -> I'm using sockets and use char pointers to muck about with the input buffer that i receive through my socket. -> one part of my program decodes a mime- formatted email body. as you may know, this is a hierarchical structure where a section consists of a header and a body. a body could also be a section in it's own right, consisting of a header and a body. Right now, i start with one big char pointer, and i call a function recursively on each body section to decode. This makes extensive use of tricking a c-type string into multiple separate strings by sticking \0 in the correct places. I'm worried that reimplementing my program using stl is going to be a nightmare. Can someone please explain to me how it will in fact be a delightful process instead. Jon Sorry to dissapoint you all with my lack of a witty or poignant signature.
-
I've been tinkering a little with STL after my brief run-in with the map template the other week. It took me a while to recover from that episode; but i've been having a go with the string thing. My current program users c strings (char arrays, not that mfc bunk). I can already hear Christian muttering in the background. I used them becuase my program has the following traits: -> lots of scanf and sprintf type stuff goes on, to jam integers to and from strings. -> I'm using sockets and use char pointers to muck about with the input buffer that i receive through my socket. -> one part of my program decodes a mime- formatted email body. as you may know, this is a hierarchical structure where a section consists of a header and a body. a body could also be a section in it's own right, consisting of a header and a body. Right now, i start with one big char pointer, and i call a function recursively on each body section to decode. This makes extensive use of tricking a c-type string into multiple separate strings by sticking \0 in the correct places. I'm worried that reimplementing my program using stl is going to be a nightmare. Can someone please explain to me how it will in fact be a delightful process instead. Jon Sorry to dissapoint you all with my lack of a witty or poignant signature.
I have done a lot of the same stuff that you are doing, and I started to change my program from char pointers to std::string X| Performance was, err.., one third, and it was a nightmare to change the program. std::string is way too slow for extensive string-stuff ;) - Anders Money talks, but all mine ever says is "Goodbye!"
-
I have done a lot of the same stuff that you are doing, and I started to change my program from char pointers to std::string X| Performance was, err.., one third, and it was a nightmare to change the program. std::string is way too slow for extensive string-stuff ;) - Anders Money talks, but all mine ever says is "Goodbye!"
I have to agree with Anders. For dynamic string intensive stuff, char arrays work best. For general string storage and lightweight processing, std::string is the way to go. I use both extensively. Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
-
I have to agree with Anders. For dynamic string intensive stuff, char arrays work best. For general string storage and lightweight processing, std::string is the way to go. I use both extensively. Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
One minor clarification. If your string intensive stuff just results in always having to reallocate storage space to support changes in the string, then std::string should work just fine too. Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
-
I've been tinkering a little with STL after my brief run-in with the map template the other week. It took me a while to recover from that episode; but i've been having a go with the string thing. My current program users c strings (char arrays, not that mfc bunk). I can already hear Christian muttering in the background. I used them becuase my program has the following traits: -> lots of scanf and sprintf type stuff goes on, to jam integers to and from strings. -> I'm using sockets and use char pointers to muck about with the input buffer that i receive through my socket. -> one part of my program decodes a mime- formatted email body. as you may know, this is a hierarchical structure where a section consists of a header and a body. a body could also be a section in it's own right, consisting of a header and a body. Right now, i start with one big char pointer, and i call a function recursively on each body section to decode. This makes extensive use of tricking a c-type string into multiple separate strings by sticking \0 in the correct places. I'm worried that reimplementing my program using stl is going to be a nightmare. Can someone please explain to me how it will in fact be a delightful process instead. Jon Sorry to dissapoint you all with my lack of a witty or poignant signature.
Hi, You should also consider the use of std::vector To the best of my knowledge, the std requires that elements should be allocated contiguosly (not sure) Consider std::vector buffer; buffer.resize(n); legacy_function(&(buffer.at(0)),buffer.size()); Comments: I am not comparing anything. Just another "tool/way" to do things that is worth be aware of Regards, R.
-
Hi, You should also consider the use of std::vector To the best of my knowledge, the std requires that elements should be allocated contiguosly (not sure) Consider std::vector buffer; buffer.resize(n); legacy_function(&(buffer.at(0)),buffer.size()); Comments: I am not comparing anything. Just another "tool/way" to do things that is worth be aware of Regards, R.
To the best of my knowledge, the std requires that elements should be allocated contiguosly (not sure) The standard does not guarantee this, but later on this was perceived as a defect in the standard itself and a so called "tecnhical corrigendum" was issued in 2000 that fixes the error. Moreover, every compiler known so far stores vectors contiguously (and future ones are compelled to follow the corrigendum as well as the standard). So the moral is: contiguous vectors are a standard guarantee as of today, and every compiler implement them this way. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
-
To the best of my knowledge, the std requires that elements should be allocated contiguosly (not sure) The standard does not guarantee this, but later on this was perceived as a defect in the standard itself and a so called "tecnhical corrigendum" was issued in 2000 that fixes the error. Moreover, every compiler known so far stores vectors contiguously (and future ones are compelled to follow the corrigendum as well as the standard). So the moral is: contiguous vectors are a standard guarantee as of today, and every compiler implement them this way. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
corrigendum Damn, had to look that one up. Either... 1. I am stupid 2. Or in the US we use a different term. I guess I have always called them "errata" Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
-
To the best of my knowledge, the std requires that elements should be allocated contiguosly (not sure) The standard does not guarantee this, but later on this was perceived as a defect in the standard itself and a so called "tecnhical corrigendum" was issued in 2000 that fixes the error. Moreover, every compiler known so far stores vectors contiguously (and future ones are compelled to follow the corrigendum as well as the standard). So the moral is: contiguous vectors are a standard guarantee as of today, and every compiler implement them this way. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
-
I have to agree with Anders. For dynamic string intensive stuff, char arrays work best. For general string storage and lightweight processing, std::string is the way to go. I use both extensively. Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
I read an article in CUJ or DDJ (can't remember which) last fall which dealt with these performance problems. One solution (using storage trade-offs) was to create a std::string compatible class called something like fixed_string. fixed_string would then implement the string using a fixed length char array. You got the best of both worlds: speed and the nice std::string interface. The article also mentioned how you could pool these strings to optimize the performance even more (mostly for threaded environments). I'm sorry I can't give you a correct reference to the article, my magazines are at home, and I'm not online at home anymore :( Sonorked as well: 100.13197 jorgen FreeBSD is sexy.
-
I read an article in CUJ or DDJ (can't remember which) last fall which dealt with these performance problems. One solution (using storage trade-offs) was to create a std::string compatible class called something like fixed_string. fixed_string would then implement the string using a fixed length char array. You got the best of both worlds: speed and the nice std::string interface. The article also mentioned how you could pool these strings to optimize the performance even more (mostly for threaded environments). I'm sorry I can't give you a correct reference to the article, my magazines are at home, and I'm not online at home anymore :( Sonorked as well: 100.13197 jorgen FreeBSD is sexy.
Exactly. Get the safe deallocation (if your strings are that big). Maybe even buffer overrun if you so decide it is needed. As I have always said, know what tools are available and understand the costs involved with each. Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
-
corrigendum Damn, had to look that one up. Either... 1. I am stupid 2. Or in the US we use a different term. I guess I have always called them "errata" Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
Standardese has its lingo, I guess. I find the word somewhat funny, too. PS. If you allow me to go pedantic, for those of you with a leaning towards Latin, erratum (pl. errata) means "error", while corrigendum means something like "to be corrected" (pretty much the same, anyway.) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
-
Standardese has its lingo, I guess. I find the word somewhat funny, too. PS. If you allow me to go pedantic, for those of you with a leaning towards Latin, erratum (pl. errata) means "error", while corrigendum means something like "to be corrected" (pretty much the same, anyway.) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Sort of like the words "feature" and "bug fix" in development. :) Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
-
Hi Joaquín, Interesting. Maybe I'm too lazy, but how do you go about finding that kind of stuff out? What are your sources. We have ways of making you talk. :laugh: Nice, Giles Giles
You just follow discussions. Usenet newsgroups like comp.lang.c++.moderated and comp.std.c++ are two very good sources. C/C++ Users Journal also contains some info.