On 29/09/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
I'd like to propose we get rid of SDOString and just use std::string. SDOString inherits from std::string but does not add any additional function. The initial idea of having SDOString was to add an additional operator const char*() so that when we changed public API return values from const char* to SDOString a user would not have to ammend their code. However, this didn't quite work so I believe SDOString is redundant.
There were other reasons too, although the only one that remains is my own concern that we might eventually discover some extra functionality that we needed. However, it hasn't happened so far so as you say SDOString probably is redundant. Next, we have many duplicate methods that take parameters as string or
char*. I would like to remove all the methods that take char* as const string& will work just as well without causing users problems. I realise that this is currently being discussed by the spec group and the current spec has the interfaces using char*, however for input paramters this proposal will still support the methods as if they were passing char* so I think we should go for it. I'm sure the spec group will get round to agreeing woth this ;-)
As far as I can tell they will. I had deliberately not made the switch to the string class only methods yet because it seemed premature in advance of the spec being changed. Finally, and a bit later, we need to look at changing the public APIs that
return char* to return std::string but this can wait for the spec group to decide if this is what they want. This will affect users as they will need to use .c_str() on their return values if they require th char* string.
This is another reason why I left it in its current state. I thought it would look a bit odd to have methods with a signature like const char * getSomeValue(const SDOString& key) or whatever, and, as you say we can't change the return parameters in advance of the spec. I agree with everything you are doing or proposing. I was just a bit wary of implementing it in advance of changes in the spec. Geoff.
