On 29/09/06, Geoffrey Winn <[EMAIL PROTECTED]> wrote:
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.
Leaving SDOString as typedef'd will allow us to change it back to a class inheriting from std::string if necessary later.
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 think SDOString should not be exposed to the user: const char * getSomeValue(const std::string& key) is how I think the public API's should look. Cheers, -- Pete
