When designing an interface, should typedef be avoided?

[rozick1]

Hi

I'm designing a library at the moment and have some complex types which I'm renaming with typedef. E.g.:

<code>
class Newthing {};
typedef vector<Newthing> NewthingList;
</code>

This shortens the syntax for the client and might clarify its use. But is it a good idea? How will the client know that NewthingList is a vector?

Thanks

[jlb]

Your documentation?

But to me that typedef is misleading. You named it NewthingList but you're using a vector instead of an actual list?

How will the client know that NewthingList is a vector?

Does the "client" even need to know what the underlying container actually is?

[mbozzi]

Like @jlb, I would ask why std::vector is exposed in the interface at all. Are you really interested in std::vector, or is it incidental to the fact that you're dealing in a collection of NewThings?

To me, the answer depends on the interface's purpose and the particular typedef:
If the typedef just names a fundamental abstraction provided by your library, I don't see any reason not to typedef.
However, if the typedef involves a 3rd party component (e.g. std::vector), I would prefer not to typedef it unless I stood to gain more than brevity. The client can define an alias himself if it is appropriate for his use case.

[jonnin]

isn't using the new typedef?

I would not expose typedefs out to the user. Internally, if you feel it helps, I guess. you can always search and replace it back out after you code it.

[mbozzi]

Isn't using the new typedef?

Yes - it's better than typedef because it can define a family of type aliases:
template <typename T> using vec_of = std::vector<T>;
And because newbies like me don't get confused between
typedef old_type new_type;
and
typedef new_type old_type;
(It happens all the time.)