While fixing a bug, I noticed it was caused by something in UString… why are we using UString, anyway? What is wrong with just using the standard string?
I saw the source is with UOX, so I am assuming it is home-brewed… why?
…
Is it OK to replace it with the standard string when I find that UString clobbers things?
UString questions
As the orginal author of UString (although my version has progressed far from what UOX uses), I can take a stab at this.
The reason is simple. There are a vareity of common functions one wants to do with strings. Convert to numbers, trim whitespace, parse off sections, convert to upper, etc. This is so common, that many newer languages include this functionality in their string classes. In addition, many frameworks provide a string class to such functions (versus having to use the old C functions, etc). It keeps the Object concept of putting data and the methods you want to work on that data together. It also encourages one to address conversion in a unified manner, so if a bug is found (or change desires), it can be done in one place.
In actuallity, UString isn't a homebrew string class, as it extends the string class. Many string classes actually reinvent the entire string class functinality, and internally manage memory, etc. This isn't what USTring does at all. So I guess it would be more accurate to classify it as String class extension.
At any rate, its method format and capabilities where based off QT's QString class (version 3.0).
Now, UString has been mofified since then by UOX, as well as still having some of the original bugs that where never updated (for instance, I don't think it ever got the conversion bug check fixed, it still checks on the good() state of the stream, versus the inverse bad() state. The difference being an end of stream will trigger a not good, even though the conversion was valid).
If UString is clobbering things, one would think it may be better to find what in UString is the error (again, as it is based off std::string, it really shouldn't be causing an issue, unless one is misuing a method , thinking it does something different then one expects). But if it is, wouldn't fixing it be better?
The reason is simple. There are a vareity of common functions one wants to do with strings. Convert to numbers, trim whitespace, parse off sections, convert to upper, etc. This is so common, that many newer languages include this functionality in their string classes. In addition, many frameworks provide a string class to such functions (versus having to use the old C functions, etc). It keeps the Object concept of putting data and the methods you want to work on that data together. It also encourages one to address conversion in a unified manner, so if a bug is found (or change desires), it can be done in one place.
In actuallity, UString isn't a homebrew string class, as it extends the string class. Many string classes actually reinvent the entire string class functinality, and internally manage memory, etc. This isn't what USTring does at all. So I guess it would be more accurate to classify it as String class extension.
At any rate, its method format and capabilities where based off QT's QString class (version 3.0).
Now, UString has been mofified since then by UOX, as well as still having some of the original bugs that where never updated (for instance, I don't think it ever got the conversion bug check fixed, it still checks on the good() state of the stream, versus the inverse bad() state. The difference being an end of stream will trigger a not good, even though the conversion was valid).
If UString is clobbering things, one would think it may be better to find what in UString is the error (again, as it is based off std::string, it really shouldn't be causing an issue, unless one is misuing a method , thinking it does something different then one expects). But if it is, wouldn't fixing it be better?
I see, so it is an extension. I had a suspicion that was the case, though I had no time to investigate the inner workings of it at all. I do not so much have a problem with an extension.
At any rate, I decided to replace it with the standard string, because, even if it is an extension, that particular function was either misusing the methods, or else the methods were broke. I found a very simple alternative that did not require any extension, and was based solely upon the standard string.
I could not fix it because I did not fully understand what it is that the methods did. The function was making use of a “section” method, which I did not know the parameters of, and found no commenting about the matter, either. I knew what it was trying to do, though: get a substring. So, I just replaced the UString with std::string, and used the substr method, which worked wonderfully.
I would not rule out the idea that it was just being misused, but either way, if use is going to continue, we should document that whole class extensively since it seems like a very common object.
I see no reason not to use a standard string in its place when the extensions are not needed, though.
At any rate, I decided to replace it with the standard string, because, even if it is an extension, that particular function was either misusing the methods, or else the methods were broke. I found a very simple alternative that did not require any extension, and was based solely upon the standard string.
I could not fix it because I did not fully understand what it is that the methods did. The function was making use of a “section” method, which I did not know the parameters of, and found no commenting about the matter, either. I knew what it was trying to do, though: get a substring. So, I just replaced the UString with std::string, and used the substr method, which worked wonderfully.
I would not rule out the idea that it was just being misused, but either way, if use is going to continue, we should document that whole class extensively since it seems like a very common object.
I see no reason not to use a standard string in its place when the extensions are not needed, though.
The use of UString by UOX is totally up to UOX. It was not developed for UOX, but for what I wanted to do. The reason it references QT (Trolltech) QString class is for documentation (they have documented the methods nicely, and it mimics them). Personally, I found it quite useful, and also felt it could be very useful for UOX.
I can understand the desire for documentation, however, if that rule applies, then most of UOX code would have be removed (so if one is getting into UOX, one has all ready accepted the fact of determining what code does. That isn't unique to UString). And clearly one can update UString to the documentation level required, or remove it (again, I personaly feel it gains more then detracts, even as documented, or what the documentation level would require, but that is a personal feeling). That is totally up to the current UOX developers to decide.
If one really wants to know what section does, it is as follows:
section(delimitor,section#,[section#])
This parses the string based on the delimitor, and breaks it up in sections. One can the extract any section one wants.
So if a string is "one,two,three"
then section(",",1,1) would return "one"
section(",",2) would retrun "two,three" // Note the end section is not speciefied, so it goes to the end of line
section(",",3,3) would return "three"
Note that section does not strip off whitespace, etc (other methods do that). So one needs to be careful if using whitespace as a deliminator. simplifyWhiteSpace() may be a desired method to use after a section call on the substring, dependong on what one wants.
As for fixing, section is used through UOX. So if a bug, by fixing it in UString, it is fixed one time. And keeps it consistent throught the code , so if later one wants a different behavior, one doesn't have to search for variant approachs. But that again is up the UOX developers. Just giving reasons why one MAY want to consider a standard way of doing things from a maintenance perspective.
Personally, given that QT is now gpl for windows, I would just switch over to QT's core library (QString which natively support unicode as well). Eventaully I would migrate in their Javascript engine to eliminate the hassle of building Spidermonkey. But that is just me anyway.
So, up to you, gwio, and Maarc on UString. No worries either way .
I can understand the desire for documentation, however, if that rule applies, then most of UOX code would have be removed (so if one is getting into UOX, one has all ready accepted the fact of determining what code does. That isn't unique to UString). And clearly one can update UString to the documentation level required, or remove it (again, I personaly feel it gains more then detracts, even as documented, or what the documentation level would require, but that is a personal feeling). That is totally up to the current UOX developers to decide.
If one really wants to know what section does, it is as follows:
section(delimitor,section#,[section#])
This parses the string based on the delimitor, and breaks it up in sections. One can the extract any section one wants.
So if a string is "one,two,three"
then section(",",1,1) would return "one"
section(",",2) would retrun "two,three" // Note the end section is not speciefied, so it goes to the end of line
section(",",3,3) would return "three"
Note that section does not strip off whitespace, etc (other methods do that). So one needs to be careful if using whitespace as a deliminator. simplifyWhiteSpace() may be a desired method to use after a section call on the substring, dependong on what one wants.
As for fixing, section is used through UOX. So if a bug, by fixing it in UString, it is fixed one time. And keeps it consistent throught the code , so if later one wants a different behavior, one doesn't have to search for variant approachs. But that again is up the UOX developers. Just giving reasons why one MAY want to consider a standard way of doing things from a maintenance perspective.
Personally, given that QT is now gpl for windows, I would just switch over to QT's core library (QString which natively support unicode as well). Eventaully I would migrate in their Javascript engine to eliminate the hassle of building Spidermonkey. But that is just me anyway.
So, up to you, gwio, and Maarc on UString. No worries either way .
Ah, yes, that does seem useful.
At any rate, you read way too much into what I was saying – I have no problem with it staying, but it either does not work properly, or was being called incorrectly. I think it should have some simple comment about what it does, though.
The code inside that method is far too complex for such a trivial task… I will try to simplify (and perhaps fix) it later…
It just needs to find the n’th delimiter… where n is start, and then repeat with n being stop, then get the substring between the two.
Something like:
int begin = -1;
for(int i = 0; i < start; i++) {
begin = string.find(del, begin + 1);
}
int end = string.find(del, begin + 1);
return string.substr(begin + 1, end - begin);
… granted, that is just pseudo un-error-checked off-the-top-of-my-mind code…
At any rate, you read way too much into what I was saying – I have no problem with it staying, but it either does not work properly, or was being called incorrectly. I think it should have some simple comment about what it does, though.
The code inside that method is far too complex for such a trivial task… I will try to simplify (and perhaps fix) it later…
It just needs to find the n’th delimiter… where n is start, and then repeat with n being stop, then get the substring between the two.
Something like:
int begin = -1;
for(int i = 0; i < start; i++) {
begin = string.find(del, begin + 1);
}
int end = string.find(del, begin + 1);
return string.substr(begin + 1, end - begin);
… granted, that is just pseudo un-error-checked off-the-top-of-my-mind code…
So it basically would be section(del,2,2) (you want the first thing past the deliminator, an before the next one. (It could be 0 based, not sure, haven't looked at it in a while, so then secttion(del,1,1).
Feel free to simplify. It got that complex given all the different possiblities (if no delinators, end of line, resvers section number support, etc).
No question one can always do inline for any given task a straightforward way to do things. But that leads to several spots if one every wants to change behavior that must be updated, and reinventing code each time.
Anyway, sounds like this topic is pretty exhausted.
Summary, UString provides a set of methods that are commonly done on strings, and presents it in a uniform way that can take the place of the string class (given it extends it, it can be used in its place). I beleive UOX converted string over to UString (and char*) to provide a uniform way of doing things to have a standar approach for later maintenance or platform conversions (more in principle, not specifcaly just UString, that was the start).
Feel free to simplify. It got that complex given all the different possiblities (if no delinators, end of line, resvers section number support, etc).
No question one can always do inline for any given task a straightforward way to do things. But that leads to several spots if one every wants to change behavior that must be updated, and reinventing code each time.
Anyway, sounds like this topic is pretty exhausted.
Summary, UString provides a set of methods that are commonly done on strings, and presents it in a uniform way that can take the place of the string class (given it extends it, it can be used in its place). I beleive UOX converted string over to UString (and char*) to provide a uniform way of doing things to have a standar approach for later maintenance or platform conversions (more in principle, not specifcaly just UString, that was the start).
Well… for reverse, you could just do if(stop < start) swap(start, stop); … right?
As for end-of-line checks… well, find returns the end of line if it does not find anything, so it is kinda’ automatic anyway. That would also take care of the case where there is no dels… it would just find the beginning and end to be the end-of-line, and return the string between end-of-line and end-of-line, which is… empty.
I guess you should check for negative start/stop, too, though. Simply clamp them to 0.
As for end-of-line checks… well, find returns the end of line if it does not find anything, so it is kinda’ automatic anyway. That would also take care of the case where there is no dels… it would just find the beginning and end to be the end-of-line, and return the string between end-of-line and end-of-line, which is… empty.
I guess you should check for negative start/stop, too, though. Simply clamp them to 0.
If you post the oringal code (the complete snippet), I could provide the proper ustring use in return. Then one could see if that worked (or a bug in UString). If it works, then it would keep the UOX code consistent.
Up to you
Up to you
-
Maarc
- Developer
- Posts: 576
- Joined: Sat Mar 27, 2004 6:22 am
- Location: Fleet, UK
- Has thanked: 0
- Been thanked: 0
- Contact:
Given the effort that originally went into the implementation of UString and converting everything in UOX to use UString, I would be extremely wary of just discarding it's use, as it is used in a lot of places and used very well. There would have to be a very compelling reason not to use it.
If it really is just a misuse of UString, fix that, rather than throwing out UString
That's like throwing out the baby with the bath water!
If it really is just a misuse of UString, fix that, rather than throwing out UString
That's like throwing out the baby with the bath water!-
lingo
- UOX3 Novice
- Posts: 55
- Joined: Thu Jul 07, 2005 12:26 pm
- Location: Taipei, Taiwan
- Has thanked: 0
- Been thanked: 0
I second that, unless you want a major change in the usage of UString, fixing the bugs is better to replace it,Maarc wrote:Given the effort that originally went into the implementation of UString and converting everything in UOX to use UString, I would be extremely wary of just discarding it's use, as it is used in a lot of places and used very well. There would have to be a very compelling reason not to use it.
If it really is just a misuse of UString, fix that, rather than throwing out UString
The abstraction can be later extended, if it is not already, to use unicode/multibyte characters which the UO protocol supports. The std::wstring along with the conversion functions can be added easily without much change, that is providing all of the code base uses UString as it's default string type (?) So that is one possible benefit or justification of wrapping the default string. Likewise you should use the custom data types like UI08/UI16/etc that UOX3 has setup so they can be properly filtered for the appropiate archiecture. These standards have not been adhered to in the past, so is there little point in sticking to them now?
Also, "fixing" the implementation of a commonly used interface, can have ramifications if other code depends on the broken implementation - if you get my meaning.
Also, "fixing" the implementation of a commonly used interface, can have ramifications if other code depends on the broken implementation - if you get my meaning.
My UString has modified quite a bit, it tracked the changes to QString as it evolved. Not all are "compatable".giwo wrote: If you have updates to UString, punt, I would love to merge them into our slightly-modified UOX3 version of the file.
But you might want to check the conversion check state of the stream as I mentioned previously. I would change that to return !.bad() versus the .good() that it does now (for an end of stream will make it return false on good())