Custom container should expand STL containers?

[LinuxCoder]

Hi everyone,

For a personal project i'm working on i need to have a custom container which is supposed to work halfway between a std::list and a lifo stack. According to my calculations i would need the following methods:

• no random access
• ++ and -- operations for traversing the existing nodes
• pop() - pops the current node
• pop_back() - pops the last node
• push_back() - adds a node to the end of the container
• value() - reads the current node

Now i was thinking about taking a std::list and expanding it by encapsulating a std::list object in my own class, but i'm not really sure if that would be the best approach, what do you guys think?

Thanks for your time and help in advance, Cheers.

[Daved]

>> i was thinking about taking a std::list and expanding it by encapsulating a std::list object in my own class
Sounds good to me.

>> pop() - pops the current node
You mean erase? pop() makes me think of popping off the end.

>> i need to have a custom container
You should prefer a built-in solution if one exists unless you are doing it for the learning experience. You may be able to customize std::stack to use a list for the underlying container.

[Daved]

After further research...

Since the standard stack class uses pop() to pop the top of the stack only, it is confusing to change that behavior and use it for erasing a non-top element, so I am even more against the use of that name for that function.

Using std::stack<T, std::list<T> > would work, but would not provide the ability to get the value of or erase a non-top element since std::stack doesn't provide iterators.

If you can, check out Josuttis' The C++ Standard Library. Chapter 10 is about the container adapters like stack, and includes his own implementation that would be a good start for what you want to do. I'm not sure how easily you'll be able to add the extra list-like stuff.

Is there any reason you don't just use std::list?

[LinuxCoder]

Thx for your replies Daved,

I guess there's no reason for not using std::list directly, i was trying to encapsulate the behavior in a more limited interface but i guess there's no real point in doing that, after all this won't be a public interface for other developers anyway. You're right, i'll be using std::list for this.

Cheers