C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Why?          C++Talk.NET Forum Index -> C++ language (comp.lang.c++) View previous topic :: View next topic   Author Message Noah Roberts Guest Posted: Thu Oct 30, 2003 12:02 am    Post subject: Why? Many toolkit authors create their own string types instead of using std::string. This includes the likes of Qt and FOX. My question, and perhaps it is not topical, is why would people do this? They also don't provide conversion functions to/from std::string! This makes it so you are always converting to/from std::string yourself to communicate with these APIs. Very annoying. NR Back to top wogston Guest Posted: Thu Oct 30, 2003 12:24 am    Post subject: Re: Why? Quote: Many toolkit authors create their own string types instead of using std::string. This includes the likes of Qt and FOX. My question, and perhaps it is not topical, is why would people do this? They also don't provide conversion functions to/from std::string! This makes it so you are always converting to/from std::string yourself to communicate with these APIs. Very annoying. std::string isn't one of the better parts of the standard library, IMHO. Speaking of which, I started writing prototype of linked-list using Knuth's single-pointer double-linked list technique, I decided to implement it as std::list<> -lookalike, here's URL for work-in-process version (it won't compile w/o metatype.hpp -header, which defines couple of templates and types, and macros, but the idea should be fairly clear to read ;) www.liimatta.org/misc/list.hpp ... and "screenshot" of a small test: www.liimatta.org/misc/list.jpg I haven't really kept thread safety in mind, just want to try out the concept.. so far it appears to be a solid idea. Also get iterator, const_iterator, reverse_iterator and const_reverse_iterator with same template as by-product, less maintenance overhead. I don't throw exceptions either, where std::list might (I haven't looked at the problem from this angle), so that could explain the speed differences. I am testing in release build and the count is 200K in the list.jpg. There are a few design choises I am not completely happy about, but they are trade-offs between speed in different areas. First Issue: the ::begin(), ::end(), etc. return iterators of various types, it would be advantageous to cache the step values so that they don't need to be re-computed, however, the re-computation is only two bitwise xor's so I think that optimization would be defeated when maintenance overhead would attack all other more frequently called methods. This is "problem" only in situation such as this: list<int>::iterator i = v.begin(); for ( ; i != v.end(); ++i ) ; So it would be advantageous to cache the v.end(), unless we write into the container.. etc.. Second Issue is that -- operator must step twice, first to get into the next node, to get new source.. then step over current node to reversed direction, so it's two xor's instead of one. Could cache the source -and- destination pointers, and when --'ing, step to get "new destination", write current to temp, write destination into current, and write current to source. But again, the maintenance overhead would kick in, and the backwards stepping is still virtually same speed as stepping "ahead" (++), so prefer it the way it is. But that did bear mentioning. :) "ahead" (++) and "backwards" (--) are relative concept in this implementation, as the direction is determined by the current state of the iterator (it cannot be switched in-flight, only when iterator is created, this way the reverse_iterator stays reverse_iterator and iterator remains iterator regardless of what the client does. I will propably add bool template parameter to formally enforce the difference between the two, so don't need criticism for that-- consider it being in the TODO -list. I hope I got the semantics nailed down correctly, criticism is welcome, you seem ideal candidate to flame the implementation: :) -w Back to top Jon Bell Guest Posted: Thu Oct 30, 2003 2:40 am    Post subject: Re: Why? In article <vq0l84tl6docd (AT) corp (DOT) supernews.com>, Noah Roberts <nroberts (AT) dontemailme (DOT) com> wrote: Quote: Many toolkit authors create their own string types instead of using std::string. This includes the likes of Qt and FOX. My question, and perhaps it is not topical, is why would people do this? In some cases at least, it's because the toolkit was written before std::string arrived as part of the C++ standard in 1998 or thereabouts. If it ain't broke, don't fix it... -- Jon Bell <jtbellap8 (AT) presby (DOT) edu> Presbyterian College Dept. of Physics and Computer Science Clinton, South Carolina USA Back to top Noah Roberts Guest Posted: Thu Oct 30, 2003 4:40 am    Post subject: Re: Why? Jon Bell wrote: Quote: In article <vq0l84tl6docd (AT) corp (DOT) supernews.com>, Noah Roberts <nroberts (AT) dontemailme (DOT) com> wrote: Many toolkit authors create their own string types instead of using std::string. This includes the likes of Qt and FOX. My question, and perhaps it is not topical, is why would people do this? In some cases at least, it's because the toolkit was written before std::string arrived as part of the C++ standard in 1998 or thereabouts. If it ain't broke, don't fix it... Well in my opinion, if they don't need some sort of extra functionality, it is broke. An addon toolkit should make use of existing, standard features, even if those features are newer; that would be part of maintenence. Even if there is needed functionality they should add the copy constructors and other necissities to make it so I can pass a std::string to any function that expects the non-standard string...and visa versa. In my opinion this sort of thing should not be: string myString(instance.getString().getText()); function(myString.c_str()); Too many conversions are happening here. From their string to char[] from char[] to string from string back to char[] from char[] to their string (keep in mind that the std::string is probably something I am using beyond the simple example above). Even if all of those conversions are necissary, a decent API would hide them. string myString = instance.getString(); function(myString); This is just a major pet-peeve of mine. -- Noah Roberts - "If you are not outraged, you are not paying attention." Back to top Noah Roberts Guest Posted: Thu Oct 30, 2003 4:47 am    Post subject: Re: Why? wogston wrote: Quote: I hope I got the semantics nailed down correctly, criticism is welcome, you seem ideal candidate to flame the implementation: I don't have time to play right now, but when I do I will look it over. I am currently studying that section of knuth so... Right off I would say, have you tested it with the functions in <algorithm>? If your list works with those, has an interface similar to list<>, and can accept something like this: list<int> function(); yourlist<int> myList = function(); then that seems like a very good implementation of a third party add on. If, on the other hand, it works completely different, does not compute with std::list, then no matter how good it is I probably won't want to relearn. -- Noah Roberts - "If you are not outraged, you are not paying attention." Back to top wogston Guest Posted: Thu Oct 30, 2003 6:51 am    Post subject: Re: Why? Quote: Right off I would say, have you tested it with the functions in algorithm>? If your list works with those, has an interface similar to list<>, and can accept something like this: The goal (at first, atleast) wasn't do anything particular at all, except toy around implementing the Knuth -technique as container with std::list semantics. I have at this point only getting the semantics nailed down, so that results are 'as expected', just thought to share what have so far. Quote: If, on the other hand, it works completely different, does not compute with std::list, then no matter how good it is I probably won't want to relearn. The practical problem is, that the implementation is in different scope than std:: , generally I have the impression 3rd party libraries shouldn't be in the std:: namespace. This will create incompatibility for certain, even if methods are same, even if the semantics and behaviour are precisely the same. Basicly, I should inherit from those std types which are required for gluing everything together. For instance, if some algorithm expects iterator, I should use compatible types so that could actually go and pass my iterators as arguments. The std::sort() in <algorithm> for example takes happily my iterators as input (with the compiler I am using), but I am not sure because it that my iterators have the same methods, definitely it isn't because they are derived from same base class. I don't recommend using the code, I posted it out as item-of-interest (to some, not necessarily to everyone!), even if only small minority. I'll try to make it as compatible as possible within the limitations of scope/namespace issues as possible to humor myself only. It's not because I expect re-inventing wheel to be productive. I'm also aware that the speed differences experienced can be remedied by writing custom allocator for std::list, and in this context the caching strategy implemented in core::list<> is irrelevant as far as performance is metric. Typical std implementation, atleast I hope so, is more exception and threading aware and so on. So basicly I am just doing this for fun and educational value, and in the process I hope to learn more of the standard library than I otherwise would in much longer period of "merely using it"-- as far as programming goes, I am one of those "self-learned" types without formal education, so I do things and find out and try to understand things 'right'. I found a bug in MSDN, infact, while I used it as reference... someone look up ::rbegin() and ::rend() for std::list! Is that correct!? Looks like it isn't! The Dinkumware implementation works correctly, ofcourse, so it seems only to be a documentation bug only. -w Back to top wogston Guest Posted: Thu Oct 30, 2003 7:22 am    Post subject: Re: Why? Quote: as arguments. The std::sort() in <algorithm> for example takes happily my iterators as input (with the compiler I am using), but I am not sure because it that my iterators have the same methods, definitely it isn't because they ~clarification: for core::vector<>, occured after posting that someone might think I meant core::list<>, .. -w Back to top Lasse Skyum Guest Posted: Thu Oct 30, 2003 12:43 pm    Post subject: Re: Why? I found my own string-class to be way more "handy" than std::string... it can cast itself to char* without c_str and basic types (int, float, double...) can be added to it. It has lower/upper-case and substring functions... need I say more? -- Lasse Back to top Ahti Legonkov Guest Posted: Thu Oct 30, 2003 2:02 pm    Post subject: Re: Why? Noah Roberts wrote: Quote: ... In my opinion this sort of thing should not be: string myString(instance.getString().getText()); function(myString.c_str()); Too many conversions are happening here. From their string to char[] from char[] to string from string back to char[] from char[] to their string (keep in mind that the std::string is probably something I am using beyond the simple example above). Even if all of those conversions are necissary, a decent API would hide them. string myString = instance.getString(); function(myString); You could write your own string class that does the conversions for you. Something like this: class MyString { public: MyString(std::string const& s); MyString(QString const& s); MyString(MyString const& s); MyString& operator=(std::string const& s); MyString& operator=(QString const& s); MyString& operator=(MyString const& s); operator std::string(); operator QString(); operator char*(); }; Using this kind of string class you would not have to do it as in your example but like so: MyString myString(instance.getString()); function(myString); -- Ahti Legonkov Back to top wogston Guest Posted: Thu Oct 30, 2003 2:49 pm    Post subject: Re: Why? Quote: I found my own string-class to be way more "handy" than std::string... it can cast itself to char* without c_str and basic types (int, float, double...) can be added to it. It has lower/upper-case and substring functions... need I say more? I do the same :) -w Back to top Jerry Coffin Guest Posted: Thu Oct 30, 2003 3:52 pm    Post subject: Re: Why? In article <3fa0f973$0$69991$edfadb0f (AT) dread12 (DOT) news.tele.dk>, "Lasse Skyum" <lskyum(AT)mail.dk> says... Quote: I found my own string-class to be way more "handy" than std::string... it can cast itself to char* without c_str and basic types (int, float, double...) can be added to it. It has lower/upper-case and substring functions... need I say more? I think it's safe to say that nearly everybody who's written C++ for more than a few months has done this at least once. Unfortunately, while handy at first, those implicit conversions tend to cause problems in the long run. -- Later, Jerry. The universe is a figment of its own imagination. Back to top Rolf Magnus Guest Posted: Fri Oct 31, 2003 1:47 pm    Post subject: Re: Why? Noah Roberts wrote: Quote: Jon Bell wrote: In article <vq0l84tl6docd (AT) corp (DOT) supernews.com>, Noah Roberts <nroberts (AT) dontemailme (DOT) com> wrote: Many toolkit authors create their own string types instead of using std::string. This includes the likes of Qt and FOX. My question, and perhaps it is not topical, is why would people do this? In some cases at least, it's because the toolkit was written before std::string arrived as part of the C++ standard in 1998 or thereabouts. If it ain't broke, don't fix it... Well in my opinion, if they don't need some sort of extra functionality, it is broke. An addon toolkit should make use of existing, standard features, even if those features are newer; that would be part of maintenence. No. If write programs using that library and want to update to a new version of the lib, you'd need to rewrite major parts of the program. Just think about the need to replace all the strings used and change the code to use another string class. Also, for the Qt example, std::string is missing some important things. QString has full unicode support on every platform that is supported by Qt, and you can convert between character sets. std::string or std::wstring doesn't even define any character set. Also, Qt was made for many platforms which might even now not have a full implementation of the standard library (some embedded platforms AFAIK), and so Qt offers something independant of it. Quote: Even if there is needed functionality they should add the copy constructors and other necissities to make it so I can pass a std::string to any function that expects the non-standard string...and visa versa. Qt does that. Quote: In my opinion this sort of thing should not be: string myString(instance.getString().getText()); function(myString.c_str()); Too many conversions are happening here. From their string to char[] Which also would mean a conversion of the character set down to an 8bit char set. Quote: from char[] to string from string back to char[] from char[] to their string (keep in mind that the std::string is probably something I am using beyond the simple example above). Even if all of those conversions are necissary, a decent API would hide them. string myString = instance.getString(); function(myString); How would you specify the character set for the intermediate 8 bit characters? Quote: This is just a major pet-peeve of mine. Back to top lilburne Guest Posted: Fri Oct 31, 2003 9:03 pm    Post subject: Re: Why? Noah Roberts wrote: Quote: Well in my opinion, if they don't need some sort of extra functionality, it is broke. An addon toolkit should make use of existing, standard features, even if those features are newer; that would be part of maintenence. Some of our software engineers maintain that unless a line of code needs changing to fix a bug, or provide additional functionality then you don't change it. You don't change the variable or argument names, you don't remove redundant whitespace, you don't rearrange the functions in the source file so that they are in alphabetical order, you don't reformat it to conform to current coding standards, and you don't change the classes it operates on to update them to the latest and greatest alternatives. All such changes are gratuitous, unless properly planned, budgeted and agreed upon, and have a code change document specifying why the work is being undertaken. Back to top Calum Guest Posted: Mon Nov 03, 2003 5:35 pm    Post subject: Re: Why? Noah Roberts wrote: Quote: Many toolkit authors create their own string types instead of using std::string. This includes the likes of Qt and FOX. My question, and perhaps it is not topical, is why would people do this? They also don't provide conversion functions to/from std::string! This makes it so you are always converting to/from std::string yourself to communicate with these APIs. Very annoying. Many of these toolkits were started before a consistently implemented std::basic_string, or even templates were available. I think every toolkit writer should now upgrade their toolkits so their own string classes derive from std::string. This would be better for sharing strings between different toolkits. std::basic_string isn't great - I hate stringstreams - just so slow. But that's the standard so we have to live with it. I've written a nice format_string() that does the same as sprintf() roughly, and a compatible fixed_string<int N, class C> that is a safe version of C[N] that prevents overflow. Calum Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ language (comp.lang.c++) All times are GMT Page 1 of 1   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.