Re: [boost] [BGL] why not breakup put_get_helper into three structs?

From: Mostafa (mostafa_working_away_at_[hidden])
Date: 2008-08-06 15:32:40

>>However,  building property maps is pretty trivial: it's just a structure 
>>with 1-3 operations and a couple of free functions.

I agree.  But if I am going to write a property map class with operator[], then
why should I have to write a global put, or a global get, or "global put and
global get" when I can use template helper class(es) to automate that task for
me.  Rewriting very similar code is tedious and error-prone because it is
tedious - I'm speaking from personal experience of writing put/get global
functions and forgetting a const here or a reference there ... And the problem
with forgetting references is that the compiler doesn't complain and I will
potentially incur a runtime penalty which will be hard to track to down. (Just
because something is trivial, doesn't negate the possibility that it will be
tedious or error prone.)

Currently if i want to avoid rewriting code that can easily be automated (via
templates) I'm relegated to using put_get_helper which gives me both put AND get
global functions.  This is undesirable for reasons I've outlined in my rationale
in my first post.

>>I don't really see the need for an expanded framework to help build them.

>From a client's perspective it's not needed, but it will be very useful in
helping to avoid missing reference mistakes and in reducing what needs to be
coded.

As for an "expanded framework", what I'm proposing is pretty trivial change to
existing code and what's more it's entirely backward compatible
(<----**emphasis**), so no other preexisting code using BGL needs to be changed
to accommodate my proposition.

>>You might also consider that the BGL is fairly dated and stagnant,  
>>and in need of some serious TLC. Whether or not property maps  
>>continue to exist in the same form in future renditions of the  
>>library is anybody's guess - I'm leaning towards "no".

Valid point.  But if for the next release(s) of BGL no changes have been made to
property maps, I would argue that my original proposition will be a non-trivial
aide for clients of the library.