Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #119374 > unrolled thread

std::map::emplace useful in any way?

Back to article view | Back to comp.lang.c++

Contents

  std::map::emplace useful in any way? Marcel Mueller <news.5.maazl@spamgourmet.org> - 2024-05-25 17:57 +0200
    Re: std::map::emplace useful in any way? Paavo Helde <eesnimi@osa.pri.ee> - 2024-05-25 20:37 +0300
      Re: std::map::emplace useful in any way? Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-28 17:53 +0200
        Re: std::map::emplace useful in any way? Paavo Helde <eesnimi@osa.pri.ee> - 2024-05-29 11:11 +0300
          Re: std::map::emplace useful in any way? Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-29 11:47 +0200
            Re: std::map::emplace useful in any way? Paavo Helde <eesnimi@osa.pri.ee> - 2024-05-29 15:05 +0300
              Re: std::map::emplace useful in any way? Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-29 18:56 +0200
                Re: std::map::emplace useful in any way? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-29 12:23 -0700
                  Re: std::map::emplace useful in any way? Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-30 16:01 +0200
    Re: std::map::emplace useful in any way? Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-25 19:41 +0200
      Re: std::map::emplace useful in any way? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-06-30 09:47 -0700
        Re: std::map::emplace useful in any way? Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-30 19:15 +0200
          Re: std::map::emplace useful in any way? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-06-30 11:46 -0700
          Re: std::map::emplace useful in any way? usenet@stegropa.de (Stefan Große Pawig) - 2024-06-30 21:21 +0200
            Re: std::map::emplace useful in any way? Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-30 23:49 +0200
              Re: std::map::emplace useful in any way? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-06-30 18:29 -0700
                Re: std::map::emplace useful in any way? Bonita Montero <Bonita.Montero@gmail.com> - 2024-07-01 13:41 +0200
                  Re: std::map::emplace useful in any way? Bonita Montero <Bonita.Montero@gmail.com> - 2024-07-07 13:17 +0200
                    Re: std::map::emplace useful in any way? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-07-07 09:16 -0700
                      Re: std::map::emplace useful in any way? Bonita Montero <Bonita.Montero@gmail.com> - 2024-07-07 18:18 +0200
              Re: std::map::emplace useful in any way? usenet@stegropa.de (Stefan Große Pawig) - 2024-07-01 07:41 +0200
    Re: std::map::emplace useful in any way? Sam <sam@email-scan.com> - 2024-05-25 18:29 -0400
    Re: std::map::emplace useful in any way? usenet@stegropa.de (Stefan Große Pawig) - 2024-06-30 21:09 +0200
    Re: std::map::emplace useful in any way? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-06-30 13:32 -0700
      Re: std::map::emplace useful in any way? Marcel Mueller <news.5.maazl@spamgourmet.org> - 2024-07-07 11:09 +0200

Page 1 of 2  [1] 2  Next page →

#119374 — std::map::emplace useful in any way?

The emplace functions generally allows to construct container objects
directly at the target location. But std::map expects a value type of
std::pair<const Key, T>. Now the implementation of emplace needs to
instantiate the value type just to get the key to find the insert
location. This cannot happen at the target location, isn't it?

I know, this has been solved in C++17 by try_emplace. I just wonder what
was the idea of this function.


Marcel

[toc] | [next] | [standalone]

#119375

On 25.05.2024 18:57, Marcel Mueller wrote:
> The emplace functions generally allows to construct container objects
> directly at the target location. But std::map expects a value type of
> std::pair<const Key, T>. Now the implementation of emplace needs to
> instantiate the value type just to get the key to find the insert
> location. This cannot happen at the target location, isn't it?
> 
> I know, this has been solved in C++17 by try_emplace. I just wonder what
> was the idea of this function.

Most probably it was done just for symmetry with other containers.

The cppreference site also gives an example which uses 
std::piecewise_construct to emulate try_emplace, so it looks like it is 
actually possible to use emplace for a real in-place construction, 
albeit in a pretty convoluted way.

[toc] | [prev] | [next] | [standalone]

#119399

Am 25.05.2024 um 19:37 schrieb Paavo Helde:

> The cppreference site also gives an example which uses 
> std::piecewise_construct to emulate try_emplace, so it looks like it
> is actually possible to use emplace for a real in-place construction, 
> albeit in a pretty convoluted way.

And this really works ? The key-value pair has still to be built
from the two forwarding tuples.

[toc] | [prev] | [next] | [standalone]

#119408

On 28.05.2024 18:53, Bonita Montero wrote:
> Am 25.05.2024 um 19:37 schrieb Paavo Helde:
> 
>> The cppreference site also gives an example which uses 
>> std::piecewise_construct to emulate try_emplace, so it looks like it
>> is actually possible to use emplace for a real in-place construction, 
>> albeit in a pretty convoluted way.
> 
> And this really works ? The key-value pair has still to be built
> from the two forwarding tuples.
> 

Seems so. To be honest I am not sure I fully understand what it does, 
this is just a slightly modified example from the cppreference site:

#include <iostream>
#include <tuple>
#include <utility>
#include <map>
#include <string>

struct Foo
{
	Foo() {
		std::cout << "Constructed a Foo\n";
		std::cout << "Constructing at address: " << this << "\n";
	}

     Foo(int, float) {
         std::cout << "Constructed a Foo from an int and a float\n";
         std::cout << "Constructing at address: " << this << "\n";
     }

     void Report() const {
		std::cout << "Reporting from address : " << this << "\n";
	}
};

int main() {
     std::map<std::string, Foo> m;

     m.emplace(std::piecewise_construct,
         std::forward_as_tuple("foo"),
         std::forward_as_tuple(10, 3.14f));

     m["foo"].Report();
}

OUTPUT:

Constructed a Foo from an int and a float
Constructing at address: 00000216F1C43F48
Reporting from address : 00000216F1C43F48

[toc] | [prev] | [next] | [standalone]

#119409

Am 29.05.2024 um 10:11 schrieb Paavo Helde:
> On 28.05.2024 18:53, Bonita Montero wrote:
>> Am 25.05.2024 um 19:37 schrieb Paavo Helde:
>>
>>> The cppreference site also gives an example which uses 
>>> std::piecewise_construct to emulate try_emplace, so it looks like it
>>> is actually possible to use emplace for a real in-place construction, 
>>> albeit in a pretty convoluted way.
>>
>> And this really works ? The key-value pair has still to be built
>> from the two forwarding tuples.
>>
> 
> Seems so. To be honest I am not sure I fully understand what it does, 
> this is just a slightly modified example from the cppreference site:
> 
> #include <iostream>
> #include <tuple>
> #include <utility>
> #include <map>
> #include <string>
> 
> struct Foo
> {
>      Foo() {
>          std::cout << "Constructed a Foo\n";
>          std::cout << "Constructing at address: " << this << "\n";
>      }
> 
>      Foo(int, float) {
>          std::cout << "Constructed a Foo from an int and a float\n";
>          std::cout << "Constructing at address: " << this << "\n";
>      }
> 
>      void Report() const {
>          std::cout << "Reporting from address : " << this << "\n";
>      }
> };
> 
> int main() {
>      std::map<std::string, Foo> m;
> 
>      m.emplace(std::piecewise_construct,
>          std::forward_as_tuple("foo"),
>          std::forward_as_tuple(10, 3.14f));

The issue would be that the string constructed from your "foo" would
be consumed if the insertion fails. You're not forwarding a string
object which is used otherwise if insertion fails.

Take this:

#include <iostream>
#include <map>

using namespace std;

int main()
{
	map<string, string> map;
	auto doIt = [&]( bool tryInsert, char const *what )
	{
		cout << what << endl;
		string
			key( "hello"sv ),
			value( "world"sv );
		if( !tryInsert )
			map.emplace( piecewise_construct, forward_as_tuple( move( key ) ), 
forward_as_tuple( move( value ) ) );
		else
			map.try_emplace( move( key ), move( value ) );
		cout << "\tkey: " << key << endl;
		cout << "\tvalue: " << key << endl;
	};
	doIt( false, "before:" );
	doIt( false, "after insertion:" );
	map.clear();
	cout << endl;
	doIt( true, "before / try:" );
	doIt( true, "after insertion / try:" );
}


> 
>      m["foo"].Report();
> }
> 
> OUTPUT:
> 
> Constructed a Foo from an int and a float
> Constructing at address: 00000216F1C43F48
> Reporting from address : 00000216F1C43F48
> 

[toc] | [prev] | [next] | [standalone]

#119410

On 29.05.2024 12:47, Bonita Montero wrote:
> Am 29.05.2024 um 10:11 schrieb Paavo Helde:
>> On 28.05.2024 18:53, Bonita Montero wrote:
>>> Am 25.05.2024 um 19:37 schrieb Paavo Helde:
>>>
>>>> The cppreference site also gives an example which uses 
>>>> std::piecewise_construct to emulate try_emplace, so it looks like it
>>>> is actually possible to use emplace for a real in-place 
>>>> construction, albeit in a pretty convoluted way.
>>>
>>> And this really works ? The key-value pair has still to be built
>>> from the two forwarding tuples.
>>>
>>
>> Seems so. To be honest I am not sure I fully understand what it does, 
>> this is just a slightly modified example from the cppreference site:
>>
>> #include <iostream>
>> #include <tuple>
>> #include <utility>
>> #include <map>
>> #include <string>
>>
>> struct Foo
>> {
>>      Foo() {
>>          std::cout << "Constructed a Foo\n";
>>          std::cout << "Constructing at address: " << this << "\n";
>>      }
>>
>>      Foo(int, float) {
>>          std::cout << "Constructed a Foo from an int and a float\n";
>>          std::cout << "Constructing at address: " << this << "\n";
>>      }
>>
>>      void Report() const {
>>          std::cout << "Reporting from address : " << this << "\n";
>>      }
>> };
>>
>> int main() {
>>      std::map<std::string, Foo> m;
>>
>>      m.emplace(std::piecewise_construct,
>>          std::forward_as_tuple("foo"),
>>          std::forward_as_tuple(10, 3.14f));
> 
> The issue would be that the string constructed from your "foo" would
> be consumed if the insertion fails. You're not forwarding a string
> object which is used otherwise if insertion fails.
> 
> Take this:
> 
> #include <iostream>
> #include <map>
> 
> using namespace std;
> 
> int main()
> {
>      map<string, string> map;
>      auto doIt = [&]( bool tryInsert, char const *what )
>      {
>          cout << what << endl;
>          string
>              key( "hello"sv ),
>              value( "world"sv );
>          if( !tryInsert )
>              map.emplace( piecewise_construct, forward_as_tuple( move( 
> key ) ), forward_as_tuple( move( value ) ) );
>          else
>              map.try_emplace( move( key ), move( value ) );
>          cout << "\tkey: " << key << endl;
>          cout << "\tvalue: " << key << endl;


I see you are focusing on another aspect of try_emplace(). Indeed, 
try_emplace() is documented to leave any rvalue reference parameters 
unchanged if insertion does not happen, which seems to be not possible 
with emplace().

However, I do not like that the code uses values after std::move() has 
been called on them. Maybe define a synonym like move_if_needed()?

[toc] | [prev] | [next] | [standalone]

#119413

Am 29.05.2024 um 14:05 schrieb Paavo Helde:

> I see you are focusing on another aspect of try_emplace(). Indeed, 
> try_emplace() is documented to leave any rvalue reference parameters 
> unchanged if insertion does not happen, which seems to be not possible 
> with emplace().

Therefore it isn't possible to emulate try_emplace with that as you
mentioned. I just wanted to demonstrate that with as less code as
possible.

[toc] | [prev] | [next] | [standalone]

#119421

On 5/29/2024 9:56 AM, Bonita Montero wrote:
> Am 29.05.2024 um 14:05 schrieb Paavo Helde:
> 
>> I see you are focusing on another aspect of try_emplace(). Indeed, 
>> try_emplace() is documented to leave any rvalue reference parameters 
>> unchanged if insertion does not happen, which seems to be not possible 
>> with emplace().
> 
> Therefore it isn't possible to emulate try_emplace with that as you
> mentioned. I just wanted to demonstrate that with as less code as
> possible.
> 

thanks.

[toc] | [prev] | [next] | [standalone]

#119429

Am 29.05.2024 um 21:23 schrieb Chris M. Thomasson:
> On 5/29/2024 9:56 AM, Bonita Montero wrote:
>> Am 29.05.2024 um 14:05 schrieb Paavo Helde:
>>
>>> I see you are focusing on another aspect of try_emplace(). Indeed, 
>>> try_emplace() is documented to leave any rvalue reference parameters 
>>> unchanged if insertion does not happen, which seems to be not 
>>> possible with emplace().
>>
>> Therefore it isn't possible to emulate try_emplace with that as you
>> mentioned. I just wanted to demonstrate that with as less code as
>> possible.
>>
> 
> thanks.

❤

[toc] | [prev] | [next] | [standalone]

#119376

Am 25.05.2024 um 17:57 schrieb Marcel Mueller:
> The emplace functions generally allows to construct container objects
> directly at the target location. But std::map expects a value type of
> std::pair<const Key, T>. Now the implementation of emplace needs to
> instantiate the value type just to get the key to find the insert
> location. This cannot happen at the target location, isn't it?
> 
> I know, this has been solved in C++17 by try_emplace. I just wonder
> what was the idea of this function.
> 
> 
> Marcel

You can find() your key and if it doesn't exist you emplace() the
new node.

[toc] | [prev] | [next] | [standalone]

#119585

On 05/25/24 10:41 AM, Bonita Montero wrote:
> 
> You can find() your key and if it doesn't exist you emplace() the
> new node.

Which is completely unacceptable, since it will perform key search 
twice. This is a huge problem, which the interface of all associative 
containers is designed to avoid. If your code performs redundant 
searches, you are using the container incorrectly.

-- 
Best regards,
Andrey

[toc] | [prev] | [next] | [standalone]

#119586

Am 30.06.2024 um 18:47 schrieb Andrey Tarasevich:
> On 05/25/24 10:41 AM, Bonita Montero wrote:
>>
>> You can find() your key and if it doesn't exist you emplace() the
>> new node.
> 
> Which is completely unacceptable, ...

Depends on your constraints. Before C++17 there was no other solution
for that and you had to accept that.

[toc] | [prev] | [next] | [standalone]

#119587

On 06/30/24 10:15 AM, Bonita Montero wrote:
> Am 30.06.2024 um 18:47 schrieb Andrey Tarasevich:
>> On 05/25/24 10:41 AM, Bonita Montero wrote:
>>>
>>> You can find() your key and if it doesn't exist you emplace() the
>>> new node.
>>
>> Which is completely unacceptable, ...
> 
> Depends on your constraints. Before C++17 there was no other solution
> for that and you had to accept that.

It depends on what problem you are referring to. In C++98 you could 
still work around both the "redundant search" problem and "unnecessary 
construction of the pair" problem by performing insertions through 
`std::map<>::operator[]`. Although in order to make it work efficiently 
you'd also have to ensure that the `mapped_type` default construction is 
lightweight and detectable

   Map map; // `Map` is `std::map<whatever>`
   ...
   Map::mapped_type &data = map[key];
   if (`data` has just been constructed)
   {
     // Build the new element in `data`
   }

This is inelegant in a sense that you have to make the `mapped_type` 
default-constructible and also force the default-construction behavior 
to obey the demands of the above pattern. But it worked.

-- 
Best regards,
Andrey

[toc] | [prev] | [next] | [standalone]

#119589

Bonita Montero <Bonita.Montero@gmail.com> writes:
> Am 30.06.2024 um 18:47 schrieb Andrey Tarasevich:
>> On 05/25/24 10:41 AM, Bonita Montero wrote:
>>>
>>> You can find() your key and if it doesn't exist you emplace() the
>>> new node.
>> Which is completely unacceptable, ...
>
> Depends on your constraints. Before C++17 there was no other solution
> for that and you had to accept that.

What about using lower_bound() and emplace_hint() instead? That is
available since C++11.

And while C++98 does not have emplace_hint(), the insert() overload that
takes an iterator as first argument can be used.

  Stefan

[toc] | [prev] | [next] | [standalone]

#119592

Am 30.06.2024 um 21:21 schrieb Stefan Große Pawig:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 30.06.2024 um 18:47 schrieb Andrey Tarasevich:
>>> On 05/25/24 10:41 AM, Bonita Montero wrote:
>>>>
>>>> You can find() your key and if it doesn't exist you emplace() the
>>>> new node.
>>> Which is completely unacceptable, ...
>>
>> Depends on your constraints. Before C++17 there was no other solution
>> for that and you had to accept that.
> 
> What about using lower_bound() and emplace_hint() instead? That is
> available since C++11.

lower_bound() needs a random-access iterator since it does a binary
search.

> 
> And while C++98 does not have emplace_hint(), the insert() overload that
> takes an iterator as first argument can be used.
> 
>    Stefan

[toc] | [prev] | [next] | [standalone]

#119593

On 06/30/24 2:49 PM, Bonita Montero wrote:
>>
>> What about using lower_bound() and emplace_hint() instead? That is
>> available since C++11.
> 
> lower_bound() needs a random-access iterator since it does a binary
> search.
> 

That's actually one of those curious spots in the standard library: it 
doesn't needs a random-access iterator. It needs a forward iterator.

I presume I simply uses `std::distance` and `std::advance` to manipulate 
the iterators, thus paying a pretty penny for "simulating" random-access 
through forward iterators, but that's just the way it is.

-- 
Best regards,
Andrey

[toc] | [prev] | [next] | [standalone]

#119595

Am 01.07.2024 um 03:29 schrieb Andrey Tarasevich:
> On 06/30/24 2:49 PM, Bonita Montero wrote:
>>>
>>> What about using lower_bound() and emplace_hint() instead? That is
>>> available since C++11.
>>
>> lower_bound() needs a random-access iterator since it does a binary
>> search.
>>
> 
> That's actually one of those curious spots in the standard library: it 
> doesn't needs a random-access iterator. It needs a forward iterator.

Interesting, but the algorithm for MSVC is still binary partitioning.
Internally a sth. like find_first_if would make more sense. But I think
most developers would be intelligent enough to use find_first_if their-
selfes.

[toc] | [prev] | [next] | [standalone]

#119610

Am 01.07.2024 um 13:41 schrieb Bonita Montero:
> Am 01.07.2024 um 03:29 schrieb Andrey Tarasevich:
>> On 06/30/24 2:49 PM, Bonita Montero wrote:
>>>>
>>>> What about using lower_bound() and emplace_hint() instead? That is
>>>> available since C++11.
>>>
>>> lower_bound() needs a random-access iterator since it does a binary
>>> search.
>>>
>>
>> That's actually one of those curious spots in the standard library: it 
>> doesn't needs a random-access iterator. It needs a forward iterator.
> 
> Interesting, but the algorithm for MSVC is still binary partitioning.
> Internally a sth. like find_first_if would make more sense. But I think
> most developers would be intelligent enough to use find_first_if their-
> selfes.
> 

I checked the source and found that the MSVC-code simply uses distance()
and advance(), and both are specialized for non random-access iterators.

[toc] | [prev] | [next] | [standalone]

#119611

On 07/07/24 4:17 AM, Bonita Montero wrote:
> Am 01.07.2024 um 13:41 schrieb Bonita Montero:
>> Am 01.07.2024 um 03:29 schrieb Andrey Tarasevich:
>>> On 06/30/24 2:49 PM, Bonita Montero wrote:
>>>>>
>>>>> What about using lower_bound() and emplace_hint() instead? That is
>>>>> available since C++11.
>>>>
>>>> lower_bound() needs a random-access iterator since it does a binary
>>>> search.
>>>>
>>>
>>> That's actually one of those curious spots in the standard library: 
>>> it doesn't needs a random-access iterator. It needs a forward iterator.
>>
>> Interesting, but the algorithm for MSVC is still binary partitioning.
>> Internally a sth. like find_first_if would make more sense. But I think
>> most developers would be intelligent enough to use find_first_if their-
>> selfes.
>>
> 
> I checked the source and found that the MSVC-code simply uses distance()
> and advance(), and both are specialized for non random-access iterators.

This approach, when random-access is emulated through sequential access 
(seemingly unnecessarily), is present in other places of the library and 
not only in MSVC's implementation

https://stackoverflow.com/questions/40622430/stdlistsort-why-the-sudden-switch-to-top-down-strategy

-- 
Best regards,
Andrey

[toc] | [prev] | [next] | [standalone]

#119612

Am 07.07.2024 um 18:16 schrieb Andrey Tarasevich:

> This approach, when random-access is emulated through sequential access 
> (seemingly unnecessarily), is present in other places of the library and 
> not only in MSVC's implementation ...

And I'm pretty sure they take the same way like MSVC.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web