It boils down to the fact that in order to be able to return std::list::iterators rather than std::list::iterators, I was taking advantage of the fact that VS allows me to do:
class node{private: std::list nodes;public: // bleh std::list::iterator begin(){ return nodes.begin(); } std::list::iterator end(){ return nodes.end(); }};
I was messing about on a PC at my girlfriend's parents, where I only have Borland BCC55 installed, and when I got the error, it occured to me that I should have been suprised that that ever compiled under VS.
I'm guessing it must be due to differences in the std::list implementation, but until I get confirmation as to which is standard, I'll have to wait.
I am aware that I can do std::list, but then I have to return iterators of the same type from node::begin() and node::end(), which makes for uncomfortable dereferencing syntax which I am hoping to avoid.
[EDIT]
SiCrane kindly pointed me to this interesting article which explains that the standard does not permit standard library containers to be instantiated with incomplete types.
So my code above is not relying upon a feature of VS2008 - it is relying on undefined behaviour.
Oops. Still, you learn something new every day.
So maybe instead, I could do (simplifying to fixed size array rather than resizing):
class node{private: node *nodes;public: node(); node *begin(){ return nodes; } node *end(){ return nodes+max_node; }};node::node(){ nodes=new node[max_nodes];}
Doesn't seem ideal. Food for thought.
Generally, I don't like using stl containers with structures (because of the copying required). I prefer pointers to avoid all of said copying, even if the usage syntax is dumber.
I'm sure that was worded in a way that makes less sense than it should. I'm not entirely sure if I've had way too much caffeine or not nearly enough.
PROTIP: You can now re-upload your avatar and have it be non-dithery! Superpig fixed it.