Jump to content
  • Advertisement


Sign in to follow this  
  • entries
  • comments
  • views

Collections Solution

Sign in to follow this  


Today I decided to use a std::pair to return a range of elements to solve my collection problems. I can make it either const or non-const, without affecting the fact that the container itself cannot be modified. I then quickly remembered vaguely that Boost might contain something like this. I shortly thereafter rediscovered Boost.Range, and boost::iterator_range. That solved that problem. After making a few typedefs, and changing a bunch of return value types throughout the code, I think I'm now in a pretty good position. At any pointer in the future, I should be able to easily make a container-agnostic wrapper and use that instead of the current hard-coded std::vector. Due to the way boost::iterator_range is designed, no source code outside of the input component itself should need to change, which is nice.

Basically, it looks something like this:
class i_Input : public i_Component
public: //classes
class i_Event

typedef boost::iterator_range >::const_iterator> t_ConstEventRange;
typedef boost::iterator_range >::const_iterator> t_EventRange;

public: //functions
virtual t_ConstEventRange Events() const = 0;
virtual t_EventRange Events() = 0;

The Direct Input component that implements the i_Input interface has an implementation of those two functions that looks like this (where mEvents is a std::vector >):
i_Input::t_ConstEventRange c_DirectInput::Events() const
return boost::make_iterator_range(mEvents.begin(), mEvents.end());

i_Input::t_EventRange c_DirectInput::Events()
return boost::make_iterator_range(mEvents.begin(), mEvents.end());

Using this would then look like the following, regardless of whether I use std::vector or std::list or some custom wrapper (if all my assumptions are correct; I haven't test it yet, though):
//mInput is of type boost::shared_ptr
i_Input::t_ConstEventRange events = mInput->Events();
i_Input::t_ConstEventRange::const_iterator eventIterator;
for (eventIterator = events.begin(); eventIterator != events.end(); ++eventIterator)
//examine and handle the event

I also added to the Startup State class, so that it actually initializes an input component with a Direct Input instance, and finds the primary keyboard, mouse, and joystick, to be passed on to other states once all the other necessary components are also initialized.

Next up is deciding what I want to do with making an Ogre component. After that will be CEGUI, and I should at that point be able to add a few more states (menu states) and see something again, though it won't look any different than my previous prototype. But I think the code and design should be somewhat cleaner.
Sign in to follow this  


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!