Warp wrote:
>   Using std::string is usually recommended unless there's a compelling
> reason why you would want to use a char* (one good reason for the latter
> is if you are returning a const char* to a string literal, which is ok,
> and would only cause needless overhead as a std::string). Returning a
> char* to a dynamically allocated string (leaving the deallocation duty
> to the caller) is always a bad idea.

The question is: assuming I use a std::string to keep that data internally,
should my getter return a const std::string or a const char* (by calling
c_str())? Note it would be const in any case (I should have mentioned this
in my original message).

>   From an OOD point of view the question is more difficult. If you use
> a certain STL data structure in your public interface you are fixing
> the data structure type and it may make it difficult to change it in
> the future if necessary. Often it would be good to abstract away the
> actual data structure (although it may be laborious to completely hide
> it because, for example, using a typedef basically makes the data
> structure type public).

Hmm true. Then I think I'd use my own abstract class for lists (which wraps
around a standard container).

And actually, a vector wouldn't be a good choice here. I need to do random
deletions (although the speed difference for that wouldn't be noticeable
with the small number of elements I'm handling). And preferably keep
iterators valid after deleting elements - which rules out vectors. And I
might even need lookup by string...

Post a reply to this message