Hi

I'm facing a problem which I'm unable to solve using STL containers.

Consider this:

class Mesh
{
public:
   const std::list<SubMesh>& getSubmeshList();
}

I want to be able to modify the objects contained in the list returned by Mesh::getSubmeshList, but want to disable access to inserting/erasing items from the collection. However, since I'm returning a const reference to the list, I can only use a const_iterator which only gives me access to const items.

Is there any way around this without using const_cast? Should I rethink my design?

One option is to return a new container that contains pointers to the SubMesh objects that is store in your Mesh object's list. Another is to make your list contain SubMesh pointers in the first case, which would make the const reference contain const pointers to non-const SubMeshes.

Thanks! Great ideas!

I had thought of exposing the iterators before, but it looks like it may polute the method list in case I need to expose many lists.

However I just thought of creating a template wrapper class that could expose this info, like so:

template <class T>
class ReadOnlyContainer
{
public:
    ReadOnlyContainer( T& originalContainer );

    T::iterator begin();
    T::iterator end();
    size_t size();

private:
   T& _container;
}

class Mesh
{
public:
     ReadOnlyContainer< std::list<SubMesh> > getSubmeshes();
}

Do you think it's a nice idea? Am I overlooking anything?

The only thing that really worries me is this: "in case I need to expose many lists." Perhaps too much is being exposed (or too much is being contained in a single class) if you get to this point.

You're right. I don't intend to expose much on this specific Mesh class. I just to avoid an eventual future corner-case where I need to expose several lists. I prefer to think of a better/prettier solution if there is any in order to avoid refactoring later.

Thank you for the heads up though :)

I would just advise you against too much forward-thinking. Code for 'now', because you can't possibly predict the future.

When (or rather, if) you need feature X, you will also need Y. And you will have a concrete use case to reason against. Then you will come up with much better interface.

If you still persist, I'd rather make the Mesh class itself a container, like Cornstalks suggested.