Re: Re: Why all the different string types?

kaczoroj wrote:

Jerzy, thank you for taking the time to provide this detailed overview. 
  I had actually spent some time before sending my original email to 
look at these various classes.

> UStr is same as CStr. CString is an MFC classs used on Windows-
> specific code. std::string used by me recently as I was trying to see 
> how would that go if we tried to replace the above string classes with 
> std::string. Mixed feelings about that one - std::string is by far the 
> most crappy string class even invented. Unfortunately we can't use 
> CString (which is superb) so we are stuck with UStr for now. I want to 
> phase out UPStr (and consquently PCPStr) eventually.

I have Visual Studio and took a quick look at CString.  Unfortunately, 
it's copyrighted material so we can't just use it.  But we could 
duplicate it's functionality.

> 
>> Are there any suggestions or guidelines on the appropriate 
>> uses of these different string types?
> 
> Well, you can see how the classes are used and keep the same when 
> making changes - it's not that complicated really. 

That's what I ended up doing.  In CvsPrefs.cpp, I copied an existing 
entry inside a qUnix block that used PCStr.  In the code that uses this 
value, I used UStr.  Everything seems to be working.

> 
> I would advise to use CStr rather than CPStr. 
> 
> I am still not sure about the migration to std::string so for now you 
> can use either one whichever looks more comfortable. Any input on 
> that? This will require writing and re-writing some tool routines and 
> since std::string doesn't take NULLs it will cause some crashes until 
> it's wired properly. But if the general feeling is to go with the 
> standard we could do that.

I took a quick look at Persistent.cpp.  The major contribution it is 
making is to store the instantiated values into a vector so they can be 
processed as a group by SaveAll and LoadAll.  I don't see why that 
behavior has to be built into specialization of native data types.  An 
alternative would be to create a container object (called CvsPrefs 
perhaps ;)) into which things that wish to persist can register 
themselves.  Instead of having a whole bunch of static CPersistentBool, 
CPersistentInt, and PCStr, you can have simple bool, int and strings 
that register themselves into the container.

The existing CvsPrefs class can be reorganized to do that.  The class 
itself could be considerably simplified.  Instead of having individual 
getters and setters for each preference, there could be a single 
SetBoolean, SetInteger and SetString; the first two would just stringize 
their argument and call SetString.  The first parameter would a string 
representing the preference name, and the second the preference value 
(and a third a default, if desired, though it might be better to 
identify the default when the individual preference is defined to the 
container.)

This is the same behavior that is used in Ini files or properties files, 
and in an embellished way, the Windows registry.  With this approach, we 
can then get rid of all these specialized persistent datatypes.  Then we 
can use or implement whatever string class suits our purposes.  I 
haven't used std:string much; I do mostly Java programming at work, and 
I do remember feeling frustrated at how much functionality was missing 
from std::string compared to Java's String class.

> 
> I will see if I can organize all that a little bit better but if I do 
> then it will break gCvs and MacCvs compilation so be prepared for a 
> little catch-up ;)

I'd suggest giving some time to perhaps come to a group consensus on 
what direction would be preferred.

-- 
Guy Rouillier


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/cvsgui-dev/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/