• entries
743
1924
• views
582804

Hmm

151 views

Depending on the answer to this, my XCS library might need a rewrite to make it standard C++.

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.

having list<node*> has advantages that, in my mind, counter the disadvantage of the...rather unfortunate syntax of having to do (*iter)->wang;

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.

Standards compliance is overrated.

Quote:
 Original post by Drilian 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.

FWIW, I do this too.

Quote:
 Original post by EasilyConfused I was messing about on a PC at my girlfriend's parents, where I only have Borland BCC55 installed,

Something bothers me greatly about the above... I can't put my finger on it... [wink]

Quote:
 Original post by Drilian having list has advantages that, in my mind, counter the disadvantage of the...rather unfortunate syntax of having to do (*iter)->wang; 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.

No - makes sense. I do the same in the majority of my code, but I want the XCS stuff to provide a constant interface and behave like a "normal" container and since all the other access to nodes is by reference, I wanted the iterators to act like pointer-to-node rather than pointer-to-pointer to node.

std::list<> doesn't really copy elements except when doing the push_back, and xcs::node only has a couple of std::strings and the std::list<> as members.

Quote:
 Original post by Drilian PROTIP: You can now re-upload your avatar and have it be non-dithery! Superpig fixed it.

Cheers for that [smile]. I'll have to re-screen-capture mine from Another World and save it as a bitmap, as mine is already dithery as a jpeg.

Create an account

Register a new account