Boost logo

Boost :

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2006-07-15 16:03:40

On 7/15/06, Alberto Ganesh Barbati <abarbati_at_[hidden]> wrote:
> Thanks for the explanation.

My pleasure. Thanks for taking the time to ask the very important questions. :)

> Your two hints about validation/routing
> being optional makes me think that you think I am objecting those
> concepts. Contrariwise, I do think the concepts of validation/routing
> are interesting *per se*. Those concepts can of course be applied to
> dispatching (or retrieving/calling runtime functions, or whatever you
> prefer to call that) but have a much more general value, IMHO.

I agree with you on this -- it seems like they themselves are very
handy concepts and implementing a common and reusable/extensible
interface for validation and routing along with a more generic
associative container are very interesting to implement indeed.

> For example, here's my use case: I am writing a videogame and I need to
> load a lot of texture images from disk files. Of course I don't want to
> load the same image twice. A simple map where the key is the file
> pathname is not a good tool, because there may be different pathnames
> pointing to the same file. Let's assume that using some kind of
> canonical form of pathnames is sufficient to uniquely identify the file.
> So my "routing" step is a conversion from a pathname to its canonical
> form. My "validation" step is a check that the file actually exists and
> identifies a supported image format. See? A container like the one you
> described could be very useful to me, yet I am going to store objects
> which are not functions nor related in any ways to functions.
> Does it make sense?

Yes, this makes a lot of sense. It seems like the dispatcher concept
in itself can exist separately or along with the
validator+router+associative_container concepts. Definitely it makes a
lot of sense to have an implementation such as what you are
suggesting, and it looks like I already have some code work with to
come up with something generally useful -- aside from the dispatcher.

Thanks very much for the ideas! :)

Dean Michael C. Berris
C/C++ Software Architect
Orange and Bronze Software Labs
Mobile: +639287291459
Email: dean [at] orangeandbronze [dot] com

Boost list run by bdawes at, gregod at, cpdaniel at, john at