In article <421ri8$k3k@oznet03.ozemail.com.au>,
John Max Skaller  <maxtal@suphys.physics.su.oz.au> wrote:
>
>Well, one reason is consistency. A container has a SINGLE kind of element,
>in the case of map and multimap it's pair<key,value>. Thats what an iterator
>enumerating the container contents sees. This is important in cases like:
>
>    map1.insert( *map2.begin() );
>
>which is very much better than
>
>    pair<key,value> item = *map2.begin();
>    map1.insert( item.first, item.second);

Point taken. I had not thought of this example.
My guess would be that inserting a key and a value is more common
that this particular usage and would have opted to make that easier,
but there is merit to this as well.

--
Ajay Kamdar                               Email: ajay@lehman.com
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. ]

ajay@lehman.com (Ajay Kamdar) wrote:
>>:Given a multimap, this is what I would have *liked* to do:
>>
>>:    multimap<int,double> m;
>>:    m.insert(3, 5.0);
>
>But what I can't understand is why the proposed standard is the way it
>is.

Well, one reason is consistency. A container has a SINGLE kind of element,
in the case of map and multimap it's pair<key,value>. Thats what an iterator
enumerating the container contents sees. This is important in cases like:

    map1.insert( *map2.begin() );

which is very much better than

    pair<key,value> item = *map2.begin();
    map1.insert( item.first, item.second);


. don't you think?

--
John Max Skaller               voice: 61-2-566-2189
81 Glebe Point Rd              fax:   61-2-660-0850
GLEBE NSW 2037                 email: maxtal@suphys.physics.oz.au
AUSTRALIA                      email: skaller@maxtal.com.au

[ 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. ]

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. ]

In article <411h8u$fi8@cyber.tn.tudelft.nl>,
Klamer Schutte <klamer@ph.tn.tudelft.nl> wrote:
>In <9508170857.ZM22058@jabba> ajay@lehman.com (Ajay Kamdar) writes:
>
>:Given a multimap, this is what I would have *liked* to do:
>
>:    multimap<int,double> m;
>:    m.insert(3, 5.0);

>
>I also would like to see the insert member described above.
>
>You of course can make a child class of multimap with the insert member
>you want. Or you can use the function below:
>
>template <class Key, class T, class Compare>
>inline void
>map_insert( multimap<Key,T,Compare > &m, const Key &k, const T &v )
>{
>m.insert( pair<const Key, T>(k, v) );
>}
>
>multimap<int,double,less<int> > m;
>
>map_insert(m, 3, 5.0);
>

Yes, there are a number of reasonable approaches to work around the problem.
But what I can't understand is why the proposed standard is the way it
is. User workarounds tend to not be compatible with each other and defeat
some of the reasons for standardizing in the first place.

It is not as if this is a very subtle usage issue which is easy to miss
when designing the interface or in experimenting it before accepting it as
a part of the DWP. The awkwardness in using insert hits anyone trying
to use a STL multimap right off the bat, starting them immediately on
inventing a workaround. For projects on which I either have direct control
or significant input, I would not propose or accept a syntax which is
so awkward to use, especially when it does not require any great expertise
to come up with an easier to use and more efficient alternative syntax.
The people who designed and approved STL have impressive design and
implementation track records. And they chose the current syntax. I find
it hard to belive that all of them dropped the ball on this. I have been
waiting with bated breath for some one to tell me that I am wrong and to
point out the reason(s) for choosing the current syntax.

I am sure some of the people directly involved in either making the
proposal or moving it through the committee are reading this. I would
very much like to hear from some of them explaining the rationale for
the current choice.

If there is really no strong rationale to support the current insert
signature other than "it is the way it is", then I would hope that
the DWP is tweaked to overcome this shortcoming.

Regards,

- Ajay


--
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. ]

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>? Besides being convenient, it is also possible
that providing the key and the value separately rather than creating
an intermediate pair is actually more efficient.

FYI, ObjectSpace's STL<ToolKit> provides, as an extension, an insert
member function with this signature. But I would much prefer to write
code which can be ported to different STL implementations.

So I wonder why the DWP itself doesn't make calling insert easier and the
code possibly more efficient? Could someone help me understand?

I would have settled for
    m.insert(make_pair(3, 5.0));

But that doesn't work either because there is no conversion from
pair<T1,T2> to pair<const T1,T2>.


--
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. ]

In <9508170857.ZM22058@jabba> ajay@lehman.com (Ajay Kamdar) writes:

: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>? Besides being convenient, it is also possible
:that providing the key and the value separately rather than creating
:an intermediate pair is actually more efficient.

I also would like to see the insert member described above.

You of course can make a child class of multimap with the insert member
you want. Or you can use the function below:

template <class Key, class T, class Compare>
inline void
map_insert( multimap<Key,T,Compare > &m, const Key &k, const T &v )
{
m.insert( pair<const Key, T>(k, v) );
}

multimap<int,double,less<int> > m;

map_insert(m, 3, 5.0);

Klamer
--
Klamer Schutte -- +31-15-786054 -- klamer@ph.tn.tudelft.nl
http://www.ph.tn.tudelft.nl/People/klamer/Klamer.html
---
[ 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. ]