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