🚀 go-pugleaf

In article <413kcm$mdu@metro.ucc.su.OZ.AU>,
John Max Skaller <maxtal@Physics.usyd.edu.au> wrote:
>In article <9508170857.ZM22058@jabba>, Ajay Kamdar <ajay@lehman.com> wrote:
>>Given a multimap, this is what I would have *liked* to do:
>>
>>    multimap<int,double> m;
>>    m.insert(3, 5.0);
>>
>>But of course, such a function does not exist. Is there a reason why
>>STL opted not to provide this convenient interface and chose to go
>>with the more tedious (for the user) approach of insert taking
>>a pair<const T1,T2>?
>
>
>	There is a tendancy I have notice amoung C++ programmers
>to prefer member functions to globals. I'm going to put in an argument
>for globals as the right way of doing 75% of what people usually
>want members to do.
>

   --- Long discussion on when a function should be global function or
       member function deleted ---


Very interesting, but I am afraid not very pertinent to *this* question.
STL already defines insert as a member function, and my question is
regarding the signature of that member function.

What I am trying to find out is why the map/multimap interface standardizes
an awkward to use interface rather than a different interface which is
easier to use and also has potential for being more efficient. Is there
a solid technical reason for the current interface of the insert function?
While we are standardizing the map/multimap, (and given that member functions
are being used in favor of global functions) what reasons are there for
not using a more natural signature for insert? I have in the past observed
a strong bias for efficiency in the active participants of the
standardization effort. So I am also hoping that there is a reason why
the potentially more efficient flavor of insert(const Key&, const Val&)
was passed over in favor of insert(const pair<const Key, Val>&).



>	insert_pair(m, 3, 5.0);
>
>is easy to implement -- and will work with ANY
>container taking a pair<> argument, saving adding this
>function to every container.
>

    --- insert_pair definition deleted ---


>In fact, it is "portable". Because it belongs to the USER not
>the container supplier.


Sure, users can write put wrappers around STL to do all sorts of useful
things. Your suggestion is very attractive. But then I can think of a couple
of other attractive solutions as well, and so will the next person, and
so on. If everyone, STL implementation vendors and users, starts inventing
their own syntax to make STL more user friendly, it appears to me that
at least some of the benefits of standardization would be lost. But then
that is a different issue...



-- 
Ajay Kamdar        |    Email: ajay@lehman.com    |    Standard Disclaimer 
Lehman Brothers    |    Phone: (201) 524-5048     |
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]