Re: Re: Why all the different string types?

Guy Rouillier wrote:
> 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.
> 

I've completed the changes I was working on (popup menu customization 
and sorting by modTime) so I'm now turning my attention back to stored 
settings.  I didn't receive any feedback regarding my idea about 
removing persistence from the data types and making that a property of 
the container, i.e., CvsPrefs.  I'd like to try to convert gCvs settings 
to a plain text file before we release gCvs 2.0, so I'm going to work on 
this next.  If there are no objections on the idea, I can come up with 
an initial implementation for purposes of discussion.  As I said above, 
the resulting CvsPrefs should be much simpler since it would only need a 
single method to store and retrieve any setting (getString, putString.) 
  Of course, we'd add some wrappers around those two to make life 
easier: getInt, getBoolean, etc.

-- 
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/