|
Boost Users : |
Subject: [Boost-users] [optional] boost improvement over std::map, the default initialization requirement
From: alfC (alfredo.correa_at_[hidden])
Date: 2010-07-18 03:36:03
Hi,
The STL has an implementation of std::map<T1, T2>. It has some
designs drawbacks in my opinion. For example, the fact that T2 has to
have a default copy constructor. Even if for T2, by design, doesn't
make sense to have a copy constructor.
The problem boils down to the fact that, in the STL design, if an key
element of the map is referenced with the operator[] and it doesn't
exist then an 'empty' (default) object T2 is created. In my opinion
this feature is independent of the other features of a map. For
example if the element doesn't exists and the context is not
assignment then it could give an exception.
One option would be to use std::map<T1, boost::optional<T2> >. But I
am not sure if that creates other problems. It at least creates the
problem of having to access elements with the ugly syntax (*m[key])
The question is, does boost have another more complete solution for
this problem?
(something that I would call optional_map<T1, T2>,
uninitializing_map<T1, T2>, elegant_map<T1,T2>)
Thank you,
Alfredo
BTW, This is a simple implementation that I imagine, although in my
opinion a clever implementation does not even need to use the
indirection of boost::optional, because the context of assigment
m[key]=val can be detected with template expressions, and only the
copy constructor is needed in this case.
(code not tested)
template<class T1, class T2>
class optional_map : protected std::map<T1, boost::optional<T2> >{
typedef std::map<T1, boost::optional<T2> > base;
public:
using std::map<T1, boost::optional<T2> >::size;
using std::map<T1, boost::optional<T2> >::empty;
T2& operator[](T1 const& key){return *base::operator[](key);}
T2 const& operator[](T1 const& key) const{return *base::operator[]
(key);}
};
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net