views:

167

answers:

3

I'm trying to write a class which contains several std::vectors as data members, and provides a subset of vector's interface to access them:

class Mesh
{
public:
private:
  std::vector<Vector3> positions;
  std::vector<Vector3> normals;
  // Several other members along the same lines
};

The main thing you can do with a mesh is add positions, normals and other stuff to it. In order to allow an STL-like way of accessing a Mesh (add from arrays, other containers, etc.), I'm toying with the idea of adding methods like this:

public:
  template<class InIter>
  void AddNormals(InIter first, InIter last);

Problem is, from what I understand of templates, these methods will have to be defined in the header file (seems to make sense; without a concrete iterator type, the compiler doesn't know how to generate object code for the obvious implementation of this method).

  1. Is this actually a problem? My gut reaction is not to go around sticking huge chunks of code in header files, but my C++ is a little rusty with not much STL experience outside toy examples, and I'm not sure what "acceptable" C++ coding practice is on this.

  2. Is there a better way to expose this functionality while retaining an STL-like generic programming flavour? One way would be something like this:

(end list)

class RestrictedVector<T>
{
public:
  RestrictedVector(std::vector<T> wrapped)
    : wrapped(wrapped) {}

  template <class InIter>
  void Add(InIter first, InIter last)
  {
    std::copy(first, last, std::back_insert_iterator(wrapped));
  }

private:
  std::vector<T> wrapped;
};

and then expose instances of these on Mesh instead, but that's starting to reek a little of overengineering :P Any advice is greatly appreciated!

A: 
  1. Is this actually a problem? My gut reaction is not to go around sticking huge chunks of code in header files, but my C++ is a little rusty with not much STL experience outside toy examples, and I'm not sure what "acceptable" C++ coding practice is on this.

I'd ask the question do you need to have such generic-ness? Remember STL was written to be extremely generic for everyone's needs. Your code is for you and your team, to solve a very specific problem. A non-generic, problem-specific interface would work fine and be more clear to people in your team/problem domain.

Otherwise... what you've specified is great if you need that level of generic-ness. You've allowed any iterator type to be accepted as an argument. There's nothing wrong with what you have on the face of it. This can be very useful.

Doug T.
Thanks for the reply! It's arguable whether this does need to be as generic as I'm aiming for, but a large part of my motivation for this project is to resuscitate and modernise my C++ skills, sadly neglected since university!
shambulator
+4  A: 

these methods will have to be defined in the header file

They have to be defined in a header file, so that if they're used then they're available in the translation unit where the template function is instantiated. If you're worried about too many templates in header files, slowing down compilation of translation units which use Mesh but don't actually use that template function, then you could move the implementation into a separate header file. Makes life slightly more complicated for clients, deciding whether to include the "full fat" class header or not, but it's not actually difficult.

Alternatively, for this particular example you could define an output iterator for Mesh, which appends Normals. Then clients with their arbitrary iterators can do:

std::copy(first, last, mymesh.normalAdder());

The only header they need with template code in it is <algorithm>, which they quite possibly have already.

To do it yourself, the object returned by normalAdder() needs to overload operator++() and operator*(), which itself needs to return a proxy object (usually *this) which implements operator=(const &Vector3). That appends to the vector of normals. But all that is non-template code, and can be implemented in your .cpp file.

Again in this example, normalAdder() could just return std::back_inserter(this.normals);, a template from <iterator>.

As to whether you need to worry about it - I think when compilation times go skyward, it's more frequently due to unnecessary dependencies rather than due to small bits of template code in headers. Some large projects seem to need drastic measures, but personally I haven't worked with anything over about 100 files or so.

Steve Jessop
Two candidates for solutions, both using what seem like very C++ specific ideas :) Thanks very much, that's enormously helpful.
shambulator
+1  A: 

I'd say just bite the bullet and make a clean, readable, API/header.

Steve's idea of returning a output iterator is clever, but it's going to be counter-intuitive for clients of your class. When someone wants to add some normals, they'll be thinking "where's the method to add normals" not "how do I get a normal output iterator". (Unless you're in a very pro-STL shop.)

The requirement of defining the implementation of templated methods in the header can be mitigated somewhat by moving them outside of the class declaration.

class Mesh
{
    public:
        void    AddPosition     ( Vector3 const & position );
        void    AddNormal       ( Vector3 const & normal );

        template< typename InIter >
        void    AddPositions    ( InIter const begin, InIter const end );

        template< typename InIter >
        void    AddNormals      ( InIter const begin, InIter const end );

    private:
        std::vector< Vector3 > positions;
        std::vector< Vector3 > normals;
};

template< typename InIter >
void
Mesh::AddPositions< InIter >( InIter const begin, InIter const end )
{
    positions.insert( positions.end(), begin, end );
}

template< typename InIter >
void
Mesh::AddNormals< InIter >( InIter const begin, InIter const end )
{
    normals.insert( normals.end(), begin, end );
}
Jon-Eric
Another helpful response, thank you. I like how Steve's output iterator neatly inverts the problem, but can appreciate that it's not the kind of interface you see outside STL C++ code. I'm keen to build up a good mental picture of what is considered clean, idiomatic C++ though.
shambulator