--e89a8ff1ce0223fae404f792942f
Content-Type: text/plain; charset=UTF-8

Quick side note:

On Mon, Apr 21, 2014 at 7:27 PM, Vincent Reverdy <vince.rev@gmail.com>wrote:

> and particularly:
>
>    - flat [multi]map/set which will become more and more interesting due
>    to the data locality and cache efficiency they provide (and in my
>    application domain related to supercomputing, they will become a necessity)
>
>
I asked about this months ago on the boost mailing list, see the reactions.

http://boost.2283326.n4.nabble.com/containers-Are-there-flat-map-set-and-stable-vector-proposals-at-work-td4653595.html

So basically,
 - I would like to see these containers in the standard because in my
everyday work and domain they are better alternatives than
std::vector/map/set  (I have more cases for static_vector than for growing
vectors, and all my maps and set are flat_ in my current project, for
efficiency reasons);
 - It appears that some people don't want to add more containers to the
standard just because they seem useful, and I agree, but if I had choice
personnally I would have replaced all associative containers by
 - In my experience flat_ associative containers are easier to teach to
beginners than current standard associative containers, because once you
explain how vector works, it's easy to understand the other containers and
use them immediately (which don't prevent teaching map and set afterward);

I suspect that these containers fill the usual tradeoffs in most domains,
but I guess it would need more expert reviews and feedback to have a clear
idea about if there is enough interest other than just me.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--e89a8ff1ce0223fae404f792942f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">Quick side note:</div><div clas=
s=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Apr 21, 2014 at 7:=
27 PM, Vincent Reverdy <span dir=3D"ltr">&lt;<a href=3D"mailto:vince.rev@gm=
ail.com" target=3D"_blank">vince.rev@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr">and particularly:<br><ul><li>flat [multi]=
map/set which will become more and more interesting due to the data localit=
y and cache efficiency they provide (and in my application domain related t=
o supercomputing, they will become a necessity)</li>
</ul></div></blockquote></div><br>I asked about this months ago on the boos=
t mailing list, see the reactions.=C2=A0</div><div class=3D"gmail_extra">=
=C2=A0<a href=3D"http://boost.2283326.n4.nabble.com/containers-Are-there-fl=
at-map-set-and-stable-vector-proposals-at-work-td4653595.html">http://boost=
..2283326.n4.nabble.com/containers-Are-there-flat-map-set-and-stable-vector-=
proposals-at-work-td4653595.html</a></div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">So basicall=
y,=C2=A0</div><div class=3D"gmail_extra">=C2=A0- I would like to see these =
containers in the standard because in my everyday work and domain they are =
better alternatives than std::vector/map/set =C2=A0(I have more cases for s=
tatic_vector than for growing vectors, and all my maps and set are flat_ in=
 my current project, for efficiency reasons);</div>
<div class=3D"gmail_extra">=C2=A0- It appears that some people don&#39;t wa=
nt to add more containers to the standard just because they seem useful, an=
d I agree, but if I had choice personnally I would have replaced all associ=
ative containers by=C2=A0</div>
<div class=3D"gmail_extra">=C2=A0- In my experience flat_ associative conta=
iners are easier to teach to beginners than current standard associative co=
ntainers, because once you explain how vector works, it&#39;s easy to under=
stand the other containers and use them immediately (which don&#39;t preven=
t teaching map and set afterward);</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I suspect t=
hat these containers fill the usual tradeoffs in most domains, but I guess =
it would need more expert reviews and feedback to have a clear idea about i=
f there is enough interest other than just me.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><=
div class=3D"gmail_extra"><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--e89a8ff1ce0223fae404f792942f--

.

------=_Part_106_27830063.1398111893895
Content-Type: text/plain; charset=UTF-8

In my application domain (numerical cosmology/astrophysics), a rough
evaluation tells me that someone who uses a std::map instead of something
similar to flat_map and who uses approximately the same number of computing
hours per year than me is using between one or two million euros of public
funds for nothing but data transfer, cache misses and indirection (ok it
may be a stupid example, but it is just to illustrate that a std::flat_map
would have some advantages). And there is lot of physicist out there who
have absolutely no idea of the difference between a map and a flat map...

If a standardization of flat_map was proposed, as it targets performance, I
think that the following points should be satisfied:
- guarantee of memory contiguity
- guarantee of no memory overhead per element
(an internal implementation in terms of std::vector would meet these
conditions).

In many scientific domains who needs associative containers, a
flat_[multi]map/set would definitely have a huge success...

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_106_27830063.1398111893895
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">In my application domain (numerical cosmology/astrophysics=
), a rough evaluation tells me that someone who uses a std::map instead of =
something similar to flat_map and who uses approximately the same number of=
 computing hours per year than me is using between one or two million euros=
 of public funds for nothing but data transfer, cache misses and indirectio=
n (ok it may be a stupid example, but it is just to illustrate that a std::=
flat_map would have some advantages). And there is lot of physicist out the=
re who have absolutely no idea of the difference between a map and a flat m=
ap...<br><br>If a standardization of flat_map was proposed, as it targets p=
erformance, I think that the following points should be satisfied:<br>- gua=
rantee of memory contiguity<br>- guarantee of no memory overhead per elemen=
t<br>(an internal implementation in terms of std::vector would meet these c=
onditions).<br><br>In many scientific domains who needs associative contain=
ers, a flat_[multi]map/set would definitely have a huge success...<br></div=
>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_106_27830063.1398111893895--

.

------=_Part_395_16082239.1398125356532
Content-Type: text/plain; charset=UTF-8

From a my perspective in the game industry, I second that
flat_map/set/multimap/multiset are pretty critical for today's machine and
the necessary move towards more data-oriented processing. We have avoided
map/set like the plague since their inception in any case (node-based == no
thank you).

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_395_16082239.1398125356532
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">From a my perspective in the game industry, I second that =
flat_map/set/multimap/multiset are pretty critical for today's machine and =
the necessary move towards more data-oriented processing. We have avoided m=
ap/set like the plague since their inception in any case (node-based =3D=3D=
 no thank you).</div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_395_16082239.1398125356532--

.

--089e0115f84248d2e704f7968678
Content-Type: text/plain; charset=UTF-8

On Tue, Apr 22, 2014 at 2:09 AM, Sean Middleditch <
sean.middleditch@gmail.com> wrote:

> From a my perspective in the game industry, I second that
> flat_map/set/multimap/multiset are pretty critical for today's machine and
> the necessary move towards more data-oriented processing. We have avoided
> map/set like the plague since their inception in any case (node-based == no
> thank you).


(same industry here, but I also need them in other domains I'm working in
sometime mostly related to highly dynamic interactive manipulations, so
basically very wide use)

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e0115f84248d2e704f7968678
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Tue, Apr 22, 2014 at 2:09 AM, Sean Middleditch <span dir=3D"ltr">&lt;<a =
href=3D"mailto:sean.middleditch@gmail.com" target=3D"_blank">sean.middledit=
ch@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">From a my perspective in the game industry, =
I second that flat_map/set/multimap/multiset are pretty critical for today&=
#39;s machine and the necessary move towards more data-oriented processing.=
 We have avoided map/set like the plague since their inception in any case =
(node-based =3D=3D no thank you).</blockquote>
</div><br>(same industry here, but I also need them in other domains I&#39;=
m working in sometime mostly related to highly dynamic interactive manipula=
tions, so basically very wide use)</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0115f84248d2e704f7968678--

.

Am 22.04.2014 02:16 schrieb Klaim - Jo=EBl Lamotte:
>=20
> On Tue, Apr 22, 2014 at 2:09 AM, Sean Middleditch wrote:
>=20
>     From a my perspective in the game industry, I second that
>     flat_map/set/multimap/multiset are pretty critical for today's
>     machine and the necessary move towards more data-oriented
>     processing. We have avoided map/set like the plague since their
>     inception in any case (node-based =3D=3D no thank you).
>=20
> (same industry here, but I also need them in other domains I'm working
> in sometime mostly related to highly dynamic interactive manipulations,
> so basically very wide use)

different industry (ultrasound non-destructive testing), but in essence,
<set> and <map> are more or less deprecated in our applications and
replaced by their boost::flat_xyz counterparts. static_* variations of
all viable container types would be highly appreciated, too.

Ciao
  Dani

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.