Is it a good idea to have STL classes in a public interface? That is,
returning a std::string or std::vector from a public method, or taking them
as arguments. I recall seeing recommendations against this somewhere, but I
don't remember the reasons.

If my library returns STL objects, and an app using my library is compiled
with a different STL implementation, that will definitely not work. (and if
it's compiled with a different C++ compiler, even basic classes may fail
due to ABI differences :P). But other from mixing STL implementations, is
there any reason why returning a string instead of a char* could be a bad
idea?

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> Is it a good idea to have STL classes in a public interface?

  That depends on whether you are talking from a technical point of view
or from an object-oriented design point of view.

  From a technical point of view I see no reason why it would be a bad
idea to use STL classes in your public interface. Those classes are
standardized and thus they are practically as good as using any basic type.

  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.

  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).

> If my library returns STL objects, and an app using my library is compiled
> with a different STL implementation, that will definitely not work.

  That's not limited to STL alone.

-- 
                                                          - Warp

Post a reply to this message

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

Nicolas Alvarez wrote:
> And I might even need lookup by string...

Wait, "might even need"? I just noticed/remembered I'll need to lookup
objects by string *quite often*; at least in the internal code.

*goes read about maps*

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> 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).

  Returning a const char* would be useless overhead if your data is already
in a std::string, and would only potentially cause the calling code to be
considerably slower (for example if the calling code wants to know the
size of the string).

-- 
                                                          - Warp

Post a reply to this message