------=_Part_4208_898000.1365946366096
Content-Type: text/plain; charset=ISO-8859-1

Hello C++ World,

I'm looking for a T.

T read_file(str_ref);

What should T be if read_file returns the memory mapped data of a file?

My vote would be for a shared_array<unsigned char>. Boost defines a
shared_array, but it doesn't know it's size.

Phrased another way: is there interest in a shared_array proposal?

--

---
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/?hl=en.



------=_Part_4208_898000.1365946366096
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello C++ World,<div><br></div><div>I'm looking for a T.</div><div><br></di=
v><div>T read_file(str_ref);&nbsp;<br><br>What should T be if read_file ret=
urns the memory mapped data of a file?&nbsp;<br><br></div><div>My vote woul=
d be for a shared_array&lt;unsigned char&gt;. Boost defines a shared_array,=
 but it doesn't know it's size.<br></div><div><br></div><div>Phrased anothe=
r way: is there interest in a shared_array proposal?</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_4208_898000.1365946366096--

.

------=_Part_8_11321883.1365949048078
Content-Type: text/plain; charset=ISO-8859-1



On Sunday, April 14, 2013 2:32:46 PM UTC+1, Olaf van der Spek wrote:
>
>
> Phrased another way: is there interest in a shared_array proposal?
>

I think you can easily build a boost type shared_array with a normal
shared_ptr and a custom deleter:

template <typename T>
void array_deleter(T* p) { delete[] p; };

std::shared_ptr<foo> p(new foo[10], array_deleter<foo>);


Cheers,
Cassio.

--

---
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/?hl=en.



------=_Part_8_11321883.1365949048078
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Sunday, April 14, 2013 2:32:46 PM UTC+1, Olaf van der Spek wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><br><div>Phrased another way:=
 is there interest in a shared_array proposal?</div></blockquote><div><br>I=
 think you can easily build a boost type&nbsp;shared_array with a normal sh=
ared_ptr and a custom deleter:<br><br><div class=3D"prettyprint" style=3D"b=
ackground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bord=
er-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"=
prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">template</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">typename</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> array_deleter</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">*</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> p</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">delete</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">[]</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> p</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br><br>std</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">shared_ptr</span><span style=3D"color: #080;" class=3D"styled-by=
-prettify">&lt;foo&gt;</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> p</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">new</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">[</span><span styl=
e=3D"color: #066;" class=3D"styled-by-prettify">10</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">],</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> array_deleter</span><span style=3D"color: =
#080;" class=3D"styled-by-prettify">&lt;foo&gt;</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br>&nbsp;<br></span></div></code></div><br>Ch=
eers,<br>Cassio.<br><br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_8_11321883.1365949048078--

.

------=_Part_1272_7233418.1365954283207
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

That still does not know the size of the array..

It can be a std::shared_ptr<std::vector<unsigned char>> or=20
std::shared_ptr<std::array<unsigned char, 10>>, or if you need constant=20
runtime size arrays - in TR2 / C++14 - std::dyn_array (N2648 maybe, didn't=
=20
check if it has a newer version).

I have started writing a proposal about shared_array, but for different=20
reasons (reflecting the ideas floated in the answer thread for STL's=20
make_unique proposal, about make_*_array() ), but it's on hold while I have=
=20
zero time to allocate.. :-/

Regards, Robert

2013. =E1prilis 14., vas=E1rnap 16:17:28 UTC+2 id=F5pontban Cassio Neri a=
=20
k=F6vetkez=F5t =EDrta:
>
>
>
> On Sunday, April 14, 2013 2:32:46 PM UTC+1, Olaf van der Spek wrote:
>>
>>
>> Phrased another way: is there interest in a shared_array proposal?
>>
>
> I think you can easily build a boost type shared_array with a normal=20
> shared_ptr and a custom deleter:
>
> template <typename T>
> void array_deleter(T* p) { delete[] p; };
>
> std::shared_ptr<foo> p(new foo[10], array_deleter<foo>);
> =20
>
> Cheers,
> Cassio.
>
>

--=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/?hl=3Den.



------=_Part_1272_7233418.1365954283207
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

That still does not know the size of the array..<br><br>It can be a std::sh=
ared_ptr&lt;std::vector&lt;unsigned char&gt;&gt; or std::shared_ptr&lt;std:=
:array&lt;unsigned char, 10&gt;&gt;, or if you need constant runtime size a=
rrays - in TR2 / C++14 - std::dyn_array (N2648 maybe, didn't check if it ha=
s a newer version).<br><br>I have started writing a proposal about shared_a=
rray, but for different reasons (reflecting the ideas floated in the answer=
 thread for STL's make_unique proposal, about make_*_array() ), but it's on=
 hold while I have zero time to allocate.. :-/<br><br>Regards, Robert<br><b=
r>2013. =E1prilis 14., vas=E1rnap 16:17:28 UTC+2 id=F5pontban Cassio Neri a=
 k=F6vetkez=F5t =EDrta:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br><br=
>On Sunday, April 14, 2013 2:32:46 PM UTC+1, Olaf van der Spek wrote:<block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><br><div>Phrased another way: is there in=
terest in a shared_array proposal?</div></blockquote><div><br>I think you c=
an easily build a boost type&nbsp;shared_array with a normal shared_ptr and=
 a custom deleter:<br><br><div style=3D"background-color:rgb(250,250,250);b=
order-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:=
break-word"><code><div><span style=3D"color:#008">template</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#660">&lt;</span><span style=
=3D"color:#008">typename</span><span style=3D"color:#000"> T</span><span st=
yle=3D"color:#660">&gt;</span><span style=3D"color:#000"><br></span><span s=
tyle=3D"color:#008">void</span><span style=3D"color:#000"> array_deleter</s=
pan><span style=3D"color:#660">(</span><span style=3D"color:#000">T</span><=
span style=3D"color:#660">*</span><span style=3D"color:#000"> p</span><span=
 style=3D"color:#660">)</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#660">{</span><span style=3D"color:#000"> </span><span style=3D"=
color:#008">delete</span><span style=3D"color:#660">[]</span><span style=3D=
"color:#000"> p</span><span style=3D"color:#660">;</span><span style=3D"col=
or:#000"> </span><span style=3D"color:#660">};</span><span style=3D"color:#=
000"><br><br>std</span><span style=3D"color:#660">::</span><span style=3D"c=
olor:#000">shared_ptr</span><span style=3D"color:#080">&lt;foo&gt;</span><s=
pan style=3D"color:#000"> p</span><span style=3D"color:#660">(</span><span =
style=3D"color:#008">new</span><span style=3D"color:#000"> foo</span><span =
style=3D"color:#660">[</span><span style=3D"color:#066">10</span><span styl=
e=3D"color:#660">],</span><span style=3D"color:#000"> array_deleter</span><=
span style=3D"color:#080">&lt;foo&gt;</span><span style=3D"color:#660">);</=
span><span style=3D"color:#000"><br>&nbsp;<br></span></div></code></div><br=
>Cheers,<br>Cassio.<br><br></div></blockquote>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1272_7233418.1365954283207--

.

On Apr 14, 2013, at 10:17 AM, Cassio Neri <cassio.neri@gmail.com> wrote:

>
> On Sunday, April 14, 2013 2:32:46 PM UTC+1, Olaf van der Spek wrote:
>
>> Phrased another way: is there interest in a shared_array proposal?
>
> I think you can easily build a boost type shared_array with a normal shared_ptr and a custom deleter:
>
> template <typename T>
> void array_deleter(T* p) { delete[] p; };
>
> std::shared_ptr<foo> p(new foo[10], array_deleter<foo>);

It would be easier to just use std::default_delete<foo[]>:

    std::shared_ptr<foo> p(new foo[10], std::default_delete<foo[]>());

That being said, the resulting syntax of accessing those elements is clumsy:

    p.get()[3].bar();

It is this clumsy syntax that was in part responsible for std::unique_ptr<foo[]>.  If we are to standardize shared_array, I much prefer to name it:

   std::shared_ptr<foo[]> p(new foo[10]);
   p[3].bar();

for consistency with unique_ptr.

Howard

--

---
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/?hl=en.



.

------=_Part_1348_32873568.1365963335997
Content-Type: text/plain; charset=ISO-8859-1



On Sunday, April 14, 2013 6:44:49 PM UTC+1, Howard Hinnant wrote:
>
> It is this clumsy syntax that was in part responsible for
> std::unique_ptr<foo[]>.  If we are to standardize shared_array, I much
> prefer to name it:
>
>    std::shared_ptr<foo[]> p(new foo[10]);
>    p[3].bar();
>
> for consistency with unique_ptr.
>

+1

--

---
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/?hl=en.



------=_Part_1348_32873568.1365963335997
Content-Type: text/html; charset=ISO-8859-1

<br><br>On Sunday, April 14, 2013 6:44:49 PM UTC+1, Howard Hinnant wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
It is this clumsy syntax that was in part responsible for std::unique_ptr&lt;foo[]&gt;. &nbsp;If we are to standardize shared_array, I much prefer to name it:
<br>
<br>&nbsp; &nbsp;std::shared_ptr&lt;foo[]&gt; p(new foo[10]);
<br>&nbsp; &nbsp;p[3].bar();
<br>
<br>for consistency with unique_ptr.
<br></blockquote><div><br>+1 <br></div>

<p></p>

-- <br />
&nbsp;<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 email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1348_32873568.1365963335997--

.

On Sun, Apr 14, 2013 at 5:44 PM, R=F3bert D=E1vid <lrdxgm@gmail.com> wrote:
> It can be a std::shared_ptr<std::vector<unsigned char>> or

How does one get the memory mapped data into a vector? Obviously the
data shouldn't be copied.

> std::shared_ptr<std::array<unsigned char, 10>>, or if you need constant

Are you seriously suggesting a fixed-size array?

--=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/?hl=3Den.



.

On Sun, Apr 14, 2013 at 7:44 PM, Howard Hinnant
<howard.hinnant@gmail.com> wrote:
> It is this clumsy syntax that was in part responsible for std::unique_ptr<foo[]>.  If we are to standardize shared_array, I much prefer to name it:
>
>    std::shared_ptr<foo[]> p(new foo[10]);
>    p[3].bar();
>
> for consistency with unique_ptr.

Would this provide begin(), end() etc members too?

--

---
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/?hl=en.



.

On Apr 14, 2013, at 2:22 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote=
:

> On Sun, Apr 14, 2013 at 7:44 PM, Howard Hinnant
> <howard.hinnant@gmail.com> wrote:
>> It is this clumsy syntax that was in part responsible for std::unique_pt=
r<foo[]>.  If we are to standardize shared_array, I much prefer to name it:
>>=20
>>   std::shared_ptr<foo[]> p(new foo[10]);
>>   p[3].bar();
>>=20
>> for consistency with unique_ptr.
>=20
> Would this provide begin(), end() etc members too?

I haven't seen a proposal, so I don't know.

In the design of unique_ptr<T[]> I had to decide just how far to push uniqu=
e_ptr<T[]> towards vector<T>.  I decided to draw the line using what could =
be implemented without more overhead than using new[]/delete[] manually.  I=
..e. if unique_ptr<T[]>, at least the version using default_delete<T[]>, had=
 more overhead than a pointer, then it had gone too far towards vector.

I recommend the same restraint if someone wants to design shared_ptr<T[]>. =
 Without such restraint, you will get clients that say: shared_ptr<T[]> is =
too expensive for my use case, I have to continue to use shared_ptr<T> with=
 default_delete<T[]> and ugly syntax.

Less is more.

Howard

--=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/?hl=3Den.



.

On Sun, Apr 14, 2013 at 8:36 PM, Howard Hinnant
<howard.hinnant@gmail.com> wrote:
>> Would this provide begin(), end() etc members too?
>
> I haven't seen a proposal, so I don't know.
>
> In the design of unique_ptr<T[]> I had to decide just how far to push uni=
que_ptr<T[]> towards vector<T>.  I decided to draw the line using what coul=
d be implemented without more overhead than using new[]/delete[] manually. =
 I.e. if unique_ptr<T[]>, at least the version using default_delete<T[]>, h=
ad more overhead than a pointer, then it had gone too far towards vector.
>
> I recommend the same restraint if someone wants to design shared_ptr<T[]>=
..  Without such restraint, you will get clients that say: shared_ptr<T[]> i=
s too expensive for my use case, I have to continue to use shared_ptr<T> wi=
th default_delete<T[]> and ugly syntax.
>
> Less is more.

What about users (like me) that really are looking for a
shared_array<> that knows it's size?
I understand the rationale for shared/unique_ptr<T[]>, but that just
doesn't solve the original problem.

--=20
Olaf

--=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/?hl=3Den.



.

On Apr 14, 2013, at 2:40 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote=
:

> On Sun, Apr 14, 2013 at 8:36 PM, Howard Hinnant
> <howard.hinnant@gmail.com> wrote:
>>> Would this provide begin(), end() etc members too?
>>=20
>> I haven't seen a proposal, so I don't know.
>>=20
>> In the design of unique_ptr<T[]> I had to decide just how far to push un=
ique_ptr<T[]> towards vector<T>.  I decided to draw the line using what cou=
ld be implemented without more overhead than using new[]/delete[] manually.=
  I.e. if unique_ptr<T[]>, at least the version using default_delete<T[]>, =
had more overhead than a pointer, then it had gone too far towards vector.
>>=20
>> I recommend the same restraint if someone wants to design shared_ptr<T[]=
>.  Without such restraint, you will get clients that say: shared_ptr<T[]> =
is too expensive for my use case, I have to continue to use shared_ptr<T> w=
ith default_delete<T[]> and ugly syntax.
>>=20
>> Less is more.
>=20
> What about users (like me) that really are looking for a
> shared_array<> that knows it's size?
> I understand the rationale for shared/unique_ptr<T[]>, but that just
> doesn't solve the original problem.

I haven't studied your problem at all.  But is it possible for you to combi=
ne a shared_ptr<T[]> that doesn't know its size, with a size_t, into a sing=
le type that perfectly solves your problem?

Since I don't have a shared_ptr<T[]> to experiment with, I just spent the l=
ast 15 minutes experimenting with the same question but using unique_ptr<T[=
]>.  Here's what I came up with:

#include <memory>
#include <cstddef>
#include <cassert>

template <class T>
class sized_array
{
    std::unique_ptr<T[]> data_;
    std::size_t size_;
public:
    sized_array() noexcept : size_(0) {}
    explicit sized_array(std::size_t s)
        : data_(new T[s]),
          size_(s)
        {}

    sized_array(sized_array&& sa) noexcept
        : data_(std::move(sa.data_)),
          size_(sa.size_)
    {
        sa.size_ =3D 0;
    }

    sized_array& operator=3D(sized_array&& sa) noexcept
    {
        data_.reset();
        size_ =3D 0;
        data_ =3D std::move(sa.data_);
        size_ =3D sa.size_;
        sa.size_ =3D 0;
        return *this;
    }

    std::size_t size() const {return size_;}

    T& operator[](std::size_t i) noexcept {assert(i < size_); return data_[=
i];}
    const T& operator[](std::size_t i) const noexcept {assert(i < size_); r=
eturn data_[i];}

    T* begin() noexcept {return data_.get();}
    const T* begin() const noexcept {return data_.get();}
    T* end() noexcept {return data_.get() + size_;}
    const T* end() const noexcept {return data_.get() + size_;}
};

It probably isn't perfect.  It may solve my problem better than it solves y=
ours, or vice-versa.  But it was cheap and easy to construct. I relegated a=
ll nearly all memory management issues to unique_ptr, and added on those bi=
ts that I needed for my problem.

The std::lib doesn't need to contain every single solution to every single =
problem.  It needs to contain things that are difficult or impossible, or e=
rror prone for clients to create themselves.  And those things that everyon=
e would have to constantly reinvent all the time.

Do I think everyone should write their own sized_array?  No.  I think every=
one should use vector instead.  But for that small set of problems that vec=
tor doesn't address, there's unique_ptr<T[]>. And for that even smaller set=
 of problems that are only addressed by a data structure that lies somewher=
e between unique_ptr<T[]> and vector<T>, building your own on top of unique=
_ptr<T[]> does not seem like a bad answer to me.  Ditto for the reference c=
ounted versions of these data structures.

Howard

--=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/?hl=3Den.



.

------=_Part_1454_26560893.1366014177434
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



2013. =E1prilis 14., vas=E1rnap 20:21:59 UTC+2 id=F5pontban Olaf van der Sp=
ek a=20
k=F6vetkez=F5t =EDrta:
>
> On Sun, Apr 14, 2013 at 5:44 PM, R=F3bert D=E1vid <lrd...@gmail.com<javas=
cript:>>=20
> wrote:=20
> > It can be a std::shared_ptr<std::vector<unsigned char>> or=20
>
> How does one get the memory mapped data into a vector? Obviously the=20
> data shouldn't be copied.=20
>

I don't see an issue, it's the same way it is going to get into an array..


> > std::shared_ptr<std::array<unsigned char, 10>>, or if you need constant=
=20
>
> Are you seriously suggesting a fixed-size array?=20
>
=20
You didn't tell any details, I just suggested three possible return types,=
=20
based on "how const" your data is.

Regards, Robert

--=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/?hl=3Den.



------=_Part_1454_26560893.1366014177434
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>2013. =E1prilis 14., vas=E1rnap 20:21:59 UTC+2 id=F5pontban Olaf va=
n der Spek a k=F6vetkez=F5t =EDrta:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">On Sun, Apr 14, 2013 at 5:44 PM, R=F3bert D=E1vid &lt;<a href=3D"java=
script:" target=3D"_blank" gdf-obfuscated-mailto=3D"qlwVq_eaiN0J">lrd...@gm=
ail.com</a>&gt; wrote:
<br>&gt; It can be a std::shared_ptr&lt;std::vector&lt;<wbr>unsigned char&g=
t;&gt; or
<br>
<br>How does one get the memory mapped data into a vector? Obviously the
<br>data shouldn't be copied.
<br></blockquote><div><br>I don't see an issue, it's the same way it is goi=
ng to get into an array..<br><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;">
<br>&gt; std::shared_ptr&lt;std::array&lt;<wbr>unsigned char, 10&gt;&gt;, o=
r if you need constant
<br>
<br>Are you seriously suggesting a fixed-size array?
<br></blockquote><div>&nbsp;<br>You didn't tell any details, I just suggest=
ed three possible return types, based on "how const" your data is.<br><br>R=
egards, Robert<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1454_26560893.1366014177434--

.

On Mon, Apr 15, 2013 at 10:22 AM, R=F3bert D=E1vid <lrdxgm@gmail.com> wrote=
:
>> > It can be a std::shared_ptr<std::vector<unsigned char>> or
>>
>> How does one get the memory mapped data into a vector? Obviously the
>> data shouldn't be copied.
>
>
> I don't see an issue, it's the same way it is going to get into an array.=
..

And what way would that be?
When you memory map a file, the OS basically returns a pointer and a
size. I really don't know how to get this pointer and size into a
vector (without copying data).

>> > std::shared_ptr<std::array<unsigned char, 10>>, or if you need constan=
t
>>
>> Are you seriously suggesting a fixed-size array?
>
>
> You didn't tell any details, I just suggested three possible return types=
,
> based on "how const" your data is.

I told you I wanted to read a file. That should've told you it's not fixed-=
size.

--=20
Olaf

--=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/?hl=3Den.



.

On Sun, Apr 14, 2013 at 9:08 PM, Howard Hinnant
<howard.hinnant@gmail.com> wrote:
>> What about users (like me) that really are looking for a
>> shared_array<> that knows it's size?
>> I understand the rationale for shared/unique_ptr<T[]>, but that just
>> doesn't solve the original problem.
>
> I haven't studied your problem at all.  But is it possible for you to com=
bine a shared_ptr<T[]> that doesn't know its size, with a size_t, into a si=
ngle type that perfectly solves your problem?

Yes, that'd solve it. In fact, I've had a class like that for over a decade=
..

> Since I don't have a shared_ptr<T[]> to experiment with, I just spent the=
 last 15 minutes experimenting with the same question but using unique_ptr<=
T[]>.  Here's what I came up with:

> It probably isn't perfect.  It may solve my problem better than it solves=
 yours, or vice-versa.  But it was cheap and easy to construct. I relegated=
 all nearly all memory management issues to unique_ptr, and added on those =
bits that I needed for my problem.
>
> The std::lib doesn't need to contain every single solution to every singl=
e problem.  It needs to contain things that are difficult or impossible, or=
 error prone for clients to create themselves.  And those things that every=
one would have to constantly reinvent all the time.
>
> Do I think everyone should write their own sized_array?  No.  I think eve=
ryone should use vector instead.  But for that small set of problems that v=
ector doesn't address, there's unique_ptr<T[]>. And for that even smaller s=
et of problems that are only addressed by a data structure that lies somewh=
ere between unique_ptr<T[]> and vector<T>, building your own on top of uniq=
ue_ptr<T[]> does not seem like a bad answer to me.  Ditto for the reference=
 counted versions of these data structures.

Why do you think shared_ptr<T[]> solves a bigger set of problems than
shared_array<T>?
The former is simpler than the latter, but for a lot of cases it's too simp=
le.

https://www.google.nl/search?q=3Dshared_array+size

size() for shared_array seems to come up time and time again.



--=20
Olaf

--=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/?hl=3Den.



.

------=_Part_219_18856063.1368798296914
Content-Type: text/plain; charset=ISO-8859-1

Op maandag 15 april 2013 15:03:38 UTC+2 schreef Olaf van der Spek het
volgende:

> On Sun, Apr 14, 2013 at 9:08 PM, Howard Hinnant
> <howard.hinnant@gmail.com> wrote:
> >> What about users (like me) that really are looking for a
> >> shared_array<> that knows it's size?
> >> I understand the rationale for shared/unique_ptr<T[]>, but that just
> >> doesn't solve the original problem.
> >
> > I haven't studied your problem at all.  But is it possible for you to
> combine a shared_ptr<T[]> that doesn't know its size, with a size_t, into a
> single type that perfectly solves your problem?
>
> Yes, that'd solve it. In fact, I've had a class like that for over a
> decade.
>
> > Since I don't have a shared_ptr<T[]> to experiment with, I just spent
> the last 15 minutes experimenting with the same question but using
> unique_ptr<T[]>.  Here's what I came up with:
>
> > It probably isn't perfect.  It may solve my problem better than it
> solves yours, or vice-versa.  But it was cheap and easy to construct. I
> relegated all nearly all memory management issues to unique_ptr, and added
> on those bits that I needed for my problem.
> >
> > The std::lib doesn't need to contain every single solution to every
> single problem.  It needs to contain things that are difficult or
> impossible, or error prone for clients to create themselves.  And those
> things that everyone would have to constantly reinvent all the time.
> >
> > Do I think everyone should write their own sized_array?  No.  I think
> everyone should use vector instead.  But for that small set of problems
> that vector doesn't address, there's unique_ptr<T[]>. And for that even
> smaller set of problems that are only addressed by a data structure that
> lies somewhere between unique_ptr<T[]> and vector<T>, building your own on
> top of unique_ptr<T[]> does not seem like a bad answer to me.  Ditto for
> the reference counted versions of these data structures.
>
> Why do you think shared_ptr<T[]> solves a bigger set of problems than
> shared_array<T>?
> The former is simpler than the latter, but for a lot of cases it's too
> simple.
>
> https://www.google.nl/search?q=shared_array+size
>
> size() for shared_array seems to come up time and time again.
>
>
Howard? Or someone else?

--

---
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/?hl=en.



------=_Part_219_18856063.1368798296914
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Op maandag 15 april 2013 15:03:38 UTC+2 schreef Olaf van der Spek het volge=
nde:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Sun, Apr 14, 2013 a=
t 9:08 PM, Howard Hinnant
<br>&lt;<a href=3D"mailto:howard.hinnant@gmail.com" target=3D"_blank">howar=
d.hinnant@gmail.com</a>&gt; wrote:
<br>&gt;&gt; What about users (like me) that really are looking for a
<br>&gt;&gt; shared_array&lt;&gt; that knows it's size?
<br>&gt;&gt; I understand the rationale for shared/unique_ptr&lt;T[]&gt;, b=
ut that just
<br>&gt;&gt; doesn't solve the original problem.
<br>&gt;
<br>&gt; I haven't studied your problem at all. &nbsp;But is it possible fo=
r you to combine a shared_ptr&lt;T[]&gt; that doesn't know its size, with a=
 size_t, into a single type that perfectly solves your problem?
<br>
<br>Yes, that'd solve it. In fact, I've had a class like that for over a de=
cade.
<br>
<br>&gt; Since I don't have a shared_ptr&lt;T[]&gt; to experiment with, I j=
ust spent the last 15 minutes experimenting with the same question but usin=
g unique_ptr&lt;T[]&gt;. &nbsp;Here's what I came up with:
<br>
<br>&gt; It probably isn't perfect. &nbsp;It may solve my problem better th=
an it solves yours, or vice-versa. &nbsp;But it was cheap and easy to const=
ruct. I relegated all nearly all memory management issues to unique_ptr, an=
d added on those bits that I needed for my problem.
<br>&gt;
<br>&gt; The std::lib doesn't need to contain every single solution to ever=
y single problem. &nbsp;It needs to contain things that are difficult or im=
possible, or error prone for clients to create themselves. &nbsp;And those =
things that everyone would have to constantly reinvent all the time.
<br>&gt;
<br>&gt; Do I think everyone should write their own sized_array? &nbsp;No. =
&nbsp;I think everyone should use vector instead. &nbsp;But for that small =
set of problems that vector doesn't address, there's unique_ptr&lt;T[]&gt;.=
 And for that even smaller set of problems that are only addressed by a dat=
a structure that lies somewhere between unique_ptr&lt;T[]&gt; and vector&lt=
;T&gt;, building your own on top of unique_ptr&lt;T[]&gt; does not seem lik=
e a bad answer to me. &nbsp;Ditto for the reference counted versions of the=
se data structures.
<br>
<br>Why do you think shared_ptr&lt;T[]&gt; solves a bigger set of problems =
than
<br>shared_array&lt;T&gt;?
<br>The former is simpler than the latter, but for a lot of cases it's too =
simple.
<br>
<br><a href=3D"https://www.google.nl/search?q=3Dshared_array+size" target=
=3D"_blank">https://www.google.nl/search?<wbr>q=3Dshared_array+size</a>
<br>
<br>size() for shared_array seems to come up time and time again.
<br><br></blockquote><div><br></div><div>Howard? Or someone else?&nbsp;</di=
v><div><br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_219_18856063.1368798296914--

.

------=_Part_595_82345208.1417800096715
Content-Type: multipart/alternative;
 boundary="----=_Part_596_1126374410.1417800096719"

------=_Part_596_1126374410.1417800096719
Content-Type: text/plain; charset=UTF-8



On Sunday, April 14, 2013 3:32:46 PM UTC+2, Olaf van der Spek wrote:
>
> Hello C++ World,
>
> I'm looking for a T.
>
> T read_file(str_ref);
>
> What should T be if read_file returns the memory mapped data of a file?
>
> My vote would be for a shared_array<unsigned char>. Boost defines a
> shared_array, but it doesn't know it's size.
>
> Phrased another way: is there interest in a shared_array proposal?
>


Bump! :D
Still looking for a dynamic / shared array type with size().
Anybody else?

--

---
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_596_1126374410.1417800096719
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Sunday, April 14, 2013 3:32:46 PM UTC+2, Olaf v=
an der Spek wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hello C++ Wo=
rld,<div><br></div><div>I'm looking for a T.</div><div><br></div><div>T rea=
d_file(str_ref);&nbsp;<br><br>What should T be if read_file returns the mem=
ory mapped data of a file?&nbsp;<br><br></div><div>My vote would be for a s=
hared_array&lt;unsigned char&gt;. Boost defines a shared_array, but it does=
n't know it's size.<br></div><div><br></div><div>Phrased another way: is th=
ere interest in a shared_array proposal?</div></blockquote><div><br></div><=
div><br></div><div>Bump! :D</div><div>Still looking for a dynamic / shared =
array type with size().</div><div>Anybody else?&nbsp;</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 />

------=_Part_596_1126374410.1417800096719--
------=_Part_595_82345208.1417800096715--

.