Changing from private to protected is so obvious, I would just assume there are reasons it can't be done. And isn't your other suggestion just a repeat of item 1. in the question?
–
Mark RansomApr 6 '10 at 22:51

1

Yes, my second suggestion is just a repeat of #1 - the idea was if he didn't like protected, my advice would be to prefer #1 over #2.
–
R Samuel KlatchkoApr 6 '10 at 23:00

I've currently got it implemented as #1. Thanks for reminding me to use a const reference.
–
WillApr 6 '10 at 23:11

I don't like the first option, push_back is much better from an encapsulation point of view.
–
Matthieu M.Apr 7 '10 at 7:24

If you can, I would create a protected constructor in Base that accepts the X* argument just like the Derived constructor, and then in Derived's constructor initialization list, pass the argument to Base's protected constructor and have it do the actual insertion.

You should set the member variable to be protected so that classes that inherit Base can access it. Alternatively keep the member variable private but add a protected accessor method to allow classes that inherit base to add to the vector etc

If you want the container in the base class to remain private, you might consider adding a public (or protected) function in Base to allow the derived class to add a range. This way, the Base container type can be encapsulated (Derived doesn't need to know it's a vector), and Derived can still pass the whole thing down in one shot:

It's not much of an encapsulation, but the container could be changed with a changing the derived class, and a derived class could easily be written that takes data in a form different than an array, if desired. And as zdan suggested this functionality could be part of public or protected constructor for Base if that makes more sense (which is likely).

The idea of using iterator ranges to represent the content or subset of a container is widespread in the STL.