How to add a asString() / toString() to std::vector?

Question

My situation is a follows: There is some class MyList that will probably get a specific implemenation later on. For now, behavior like std::vector is fine.

However, I really need an easy way to call some kind of asString() / toString() method on it, because I'll need it in test assertions, debug output and so on. The only options I see are:

1. Public inheritence. I'll never delete such a list through a base-pointer, since there should never be any base pointers. If I do, there will be no pointer members, anyway. However, rule of thumb still states: Don't inherit from stl containers.

2. Some kind of "global" (actually in a namespace, of course) method that takes an instance of MyList as argument and does the asString() magic for me. In that case, MyList could be a simple typedef for std::vector.

I like neither of those options too much. Is there something else I failed to think of? Or if not - which way should I prefer?

Answer 1

what is wrong about the second approach? that is by far the easiest and also pretty elegant.- Imagine the alternative of wrapping the vector. that would cause you alot of extra work and glue code that is error prone! I'd go with the function approach for sure!

edit: btw, i almost exclusively use free functions(sometimes static members) for conversions. Imagine you have a load of types that somehow need to be convertible to string. Having the toString() functions as free functions and not as members does not give you the headache you are heaving right now since you can basically simply overload the function as much as you want and don't have to touch any existing classes (or maybe classes that you don't even have source access to).

Then you can have a function like:

template<class T>
void printDebugInfo(const T & _obj)
{
   std::cout<<toString(_obj)<<std::endl;
}

and you wont have the constraints you are experiencing.

Answer 2

Actually, free functions upon class types are a standard technique and are considered as part of the interface of a type. Read this GotW by Herb Sutter, one of people that have a voice in C++ standardization.

In general, prefer free functions over member functions. This increases encapsulation and re-usability and reduces class bloat and coupling. See this article by Scott Meyers for deeper information (highly regarded for his C++ books that you should definitely read if you want to improve your effective and clean use of C++).

Also note that you should never derive from STL containers. They are not designed as base classes and you might easily invoke undefined behaviour. But see Is there any real risk to deriving from the C++ STL containers? .

Answer 3

I think having a free

std::string toString( const MyList &l );

function is perfectly fine. If you are afraid of name clashes, you can consider a namespace as you said. This function is highly decoupled, and won't be able to tinker with private members of MyList objects (as is the case for a member or a friend function).

The only reason which would justify not making it a free function: you notice that you suddenly need to extend the public interface of MyList a lot just to be able to implement toString properly. In that case, I'd make it a friend function.

Answer 4

If you did something like:

template<typename T>
std::ostream& operator<< (std::ostream &strm, const MyList<T> &list)
{
    if (list.empty())
        return strm;

    MyList<T>::const_iterator iter = list.begin(),
                              end = list.end();
    // Write the first value
    strm << *iter++;

    while (iter != end)
         strm << "," << *iter++;

    return strm;
}

Then you would essentially have a to string for anything in the list, as long as the elements implement the streaming operator

Answer 5

Have you considered composition, as opposed to inheritance? i.e. Your MyList has a member variable of type std::vector.

You may complain that you will now need to replicate the API of std::vector in MyList. But you say that you might change the implementation later, so you'll need to do that anyway. You may as well do it straight away, to avoid having to change all the client code later on.

Answer 6

Inheritance is completely wrong in this case.

Global function approach is perfectly fine.

One of 'the ways' in C++ is to overload operator << and use stringstream, for example, to output your vector or something else.

Answer 7

I would go with global template function printOnStream. That way you can easily add support for other data types and using stream is more general than creating a string.

I would not use inheritance because there might be some tricky cases. Basic thing is as you mentioned - lack of virtual destructor. But also everything that expects std::vector won't work properly with your data type - for example you can run into slicing problem.

Answer 8

Why don't your debug and assert methods do this for you?