-
May 11th, 2011, 05:45 AM
#16
Re: Resource management--circular linked list
Originally Posted by superbonzo
uhm, I would advice against such an adaptor because it does not fulfill the container concept requirements ( just consider that size() should be equal to std: istance( begin(), end ) ); IMHO, if one really wants such an infinite sequence view of a bidirectional container It's better to write an iterator adaptor instead. Actually, I don't think the OP really needs one.
True, but I did advise using a circular link to begin with. Maybe adapting just the iterator (which is where the bulk of the code is anyways) is a better idea.
Originally Posted by superbonzo
BTW, unless I'm missing something, the "friend class circular_list;" is unnecessary because member classes have always access to the containing class private data.
That's what I thought, but I get compile errors saying those members are inaccessible, both with mingw and comeau.
Is your question related to IO?
Read this C++ FAQ article at parashift by Marshall Cline. In particular points 1-6.
It will explain how to correctly deal with IO, how to validate input, and why you shouldn't count on "while(!in.eof())". And it always makes for excellent reading.
-
May 11th, 2011, 05:57 AM
#17
Re: Resource management--circular linked list
Originally Posted by monarch_dodra
That's what I thought, but I get compile errors saying those members are inaccessible, both with mingw and comeau.
oh sorry, for some reason I interpreted that friend declaration the other way around, maybe because it's customary to expose the underlying iterator through a public base() member that would render that friend declaration effectively unnecessary ... one more reason to prefer the iterator adaptor approach.
-
May 11th, 2011, 07:01 AM
#18
Re: Resource management--circular linked list
Originally Posted by superbonzo
oh sorry, for some reason I interpreted that friend declaration the other way around, maybe because it's customary to expose the underlying iterator through a public base()
Did not know about this design. Is there an advantage to doing this? Wouldn't the "outside" also have access to this base method?
Originally Posted by superbonzo
... one more reason to prefer the iterator adaptor approach.
Not that I'm arguing against the iterator adaptor aproach, but that's an implementation detail that makes for a poor argument. What's wrong with friend declarations?
Is your question related to IO?
Read this C++ FAQ article at parashift by Marshall Cline. In particular points 1-6.
It will explain how to correctly deal with IO, how to validate input, and why you shouldn't count on "while(!in.eof())". And it always makes for excellent reading.
-
May 11th, 2011, 07:42 AM
#19
Re: Resource management--circular linked list
Originally Posted by monarch_dodra
Did not know about this design. Is there an advantage to doing this? Wouldn't the "outside" also have access to this base method?
Not that I'm arguing against the iterator adaptor aproach, but that's an implementation detail that makes for a poor argument. What's wrong with friend declarations?
I was referring to the iterator adaptor case, where exposing the underlying iterator in that way it's kind of idiomatic. The point is that it's not really an implementation detail given that the user already have to know the to be adapted iterator in order to use the adaptor ( for example guarantees/requirements of the latter are often function of the guarantees/requirements of the former ). Moreover, being able of explicitly passing from/to the base iterator seems reasonably part of the iterator adaptor interface.
Of course, the container adaptor case is more debatable, although IMHO it would be no shame if, say, std::stack exposed a base_sequence() member and allowed some level of interoperability between its own and its base_sequence iterators ...
EDIT: well, just recalled that std::stack has no iterators ... anyway, I meant any container adaptor
Last edited by superbonzo; May 11th, 2011 at 07:54 AM.
-
May 11th, 2011, 04:32 PM
#20
Re: Resource management--circular linked list
So the approach you are advocating is to use two STL lists and to write an adapter iterator that gives the lists any added structure that I need? And that would save me from needing to deal with any memory management directly. I can imagine how that approach would make things much simpler.
Thanks for the example code; it'll definitely be helpful.
The Boost graph library looks featurific. In particular,
http://www.boost.org/doc/libs/1_46_1...traversal.html
looks like it might be what I need if I can figure out how to use it.
Could anyone direct me to a good reference manual for the graph library? By poking around I found http://www.goldenbug.net/wp-content/...ph-library.pdf which looks promising.
-
May 12th, 2011, 02:32 AM
#21
Re: Resource management--circular linked list
Yes, just use dynamic lists as your "data containers", and a "circular iterator adapter" for data traversal.
Boost's graph library is a very powerful tool, but also very complicated to use. I'd advocate against it's use if you can do without.
Is your question related to IO?
Read this C++ FAQ article at parashift by Marshall Cline. In particular points 1-6.
It will explain how to correctly deal with IO, how to validate input, and why you shouldn't count on "while(!in.eof())". And it always makes for excellent reading.
-
May 12th, 2011, 10:25 AM
#22
Re: Resource management--circular linked list
Yeah I see that it would be easy to get bogged down in the Boost docs. It's interesting looking at the way the interfaces for the different algorithms are set up after writing some of my own moderately flexible graph algorithms. I imagine that Boost would subsume nearly everything I've written so far.
That said, I do appreciate the learning experience of writing my own graph algorithms and probably will continue to do so.
Thanks again for all the help!
Tags for this Thread
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|