Is there a way to get range loops to work with arrays stored in
shared pointers?

eg:

#include <iostream>
#include <memory>

using namespace std;

struct mystruct
{ mystruct() { cout << "Con " << this << endl; };
~mystruct() { cout << "Dest " << this << endl; }
void func() { cout << "Func " << this << endl; }
};

int main()
{ shared_ptr<mystruct[3]> sp(new mystruct[3]);
sp[0].func();
sp[1].func();
sp[2].func();
for(auto &ms: sp.get()) ms.func(); <--- Doesn't compile
return 0;
}

I've tried other combinations too, nothing works.

On 5/18/2023 2:10 AM, Muttley@dastardlyhq.com wrote:
> Is there a way to get range loops to work with arrays stored in
> shared pointers?
>
> eg:
>
> #include <iostream>
> #include <memory>
>
> using namespace std;
>
> struct mystruct
> {
> mystruct() { cout << "Con " << this << endl; };
> ~mystruct() { cout << "Dest " << this << endl; }
> void func() { cout << "Func " << this << endl; }
> };
>
>
> int main()
> {
> shared_ptr<mystruct[3]> sp(new mystruct[3]);

Seems a bit odd:

std::vector<std::shared_ptr<mystruct>> vec(3)?

> sp[0].func();
> sp[1].func();
> sp[2].func();
> for(auto &ms: sp.get()) ms.func(); <--- Doesn't compile
> return 0;
> }
>
> I've tried other combinations too, nothing works.
>

Use this:

#include <iostream>
#include <memory>
#include <array>

using namespace std;

struct mystruct
{ mystruct() { cout << "Con " << this << endl; };
~mystruct() { cout << "Dest " << this << endl; }
void func() { cout << "Func " << this << endl; }
};

int main()
{ using arr3_t = array<mystruct, 3>;
shared_ptr<arr3_t> sp( make_shared<arr3_t>() );
(*sp)[0].func();
(*sp)[1].func();
(*sp)[2].func();
for( auto &ms : *sp.get() )
ms.func();
return 0;
}

On Thu, 18 May 2023 02:24:51 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
>On 5/18/2023 2:10 AM, Muttley@dastardlyhq.com wrote:
>> Is there a way to get range loops to work with arrays stored in
>> shared pointers?
>>
>> eg:
>>
>> #include <iostream>
>> #include <memory>
>>
>> using namespace std;
>>
>> struct mystruct
>> {
>> mystruct() { cout << "Con " << this << endl; };
>> ~mystruct() { cout << "Dest " << this << endl; }
>> void func() { cout << "Func " << this << endl; }
>> };
>>
>>
>> int main()
>> {
>> shared_ptr<mystruct[3]> sp(new mystruct[3]);
>
>Seems a bit odd:
>

Its new with C++ 2017 apparently. I didn't know about this functionality either
until I watched this youtube video:

https://www.youtube.com/watch?v=Tp5-f9YAzNk

On Thu, 18 May 2023 14:22:57 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Use this:

I wasn't looking for an alternative solution, there are many. I was just
wondering if its possible to iterate the C array stored in a shared pointer.

On 2023-05-18 11:10 AM, Muttley@dastardlyhq.com wrote:
> #include <iostream>
> #include <memory>
>
> using namespace std;
>
> struct mystruct
> {
> mystruct() { cout << "Con " << this << endl; };
> ~mystruct() { cout << "Dest " << this << endl; }
> void func() { cout << "Func " << this << endl; }
> };
>
>
> int main()
> {
> shared_ptr<mystruct[3]> sp(new mystruct[3]);
> sp[0].func();
> sp[1].func();
> sp[2].func();
> for(auto &ms: sp.get()) ms.func(); <--- Doesn't compile
> return 0;
> }

Like this:

#include <iostream>
#include <memory>
using namespace std;

//--------------------------------------- Support machinery:
template< class It >
class Its_range_
{ It m_start;
It m_beyond;

public:
Its_range_( const It start, const It beyond ):
m_start( start ),
m_beyond( beyond )
{}

auto begin() const -> It { return m_start; }
auto end() const -> It { return m_beyond; }
};

template< class Item, int n >
auto its_const_range( const shared_ptr<Item[n]> sp )
-> Its_range_<const Item*>
{ return {sp.get(), sp.get() + n}; }

//--------------------------------------- Example:

struct My_struct
{ My_struct() { cout << "Con " << this << endl; };
~My_struct() { cout << "Dest " << this << endl; }
void func() const { cout << "Func " << this << endl; }
};

auto main() -> int
{ shared_ptr<My_struct[3]> sp( new My_struct[3] );
for( auto& ms: its_const_range( sp ) ) {
ms.func();
}
}

- Alf

On Thu, 18 May 2023 17:33:53 +0200
"Alf P. Steinbach" <alf.p.steinbach@gmail.com> wrote:
> for( auto& ms: its_const_range( sp ) ) {
> ms.func();
> }

Well yes, it works, but I was rather hoping that there was a built in way
to do it! Seems like this functionality is rather half baked - you can store
an array in shared_ptr but you can't iterate it directly in a range loop.
Might as well just use a vector.

Am 18.05.2023 um 17:50 schrieb Muttley@dastardlyhq.com:

> Well yes, it works, but I was rather hoping that there was a built in way
> to do it! Seems like this functionality is rather half baked - you can store
> an array in shared_ptr but you can't iterate it directly in a range loop.
> Might as well just use a vector.

I don't understand why you won't use a std:array<>. I prefer that over
a C-style array because I get bounds-checking for free while debugging.

On Thu, 18 May 2023 17:57:40 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 18.05.2023 um 17:50 schrieb Muttley@dastardlyhq.com:
>
>> Well yes, it works, but I was rather hoping that there was a built in way
>> to do it! Seems like this functionality is rather half baked - you can store
>> an array in shared_ptr but you can't iterate it directly in a range loop.
>> Might as well just use a vector.
>
>I don't understand why you won't use a std:array<>. I prefer that over
>a C-style array because I get bounds-checking for free while debugging.

Its some new functionality I learnt about, was just seeing if it was useful.
Seems not. I would never use it myself anyway, plenty of better alternatives.

On 5/18/2023 8:05 AM, Muttley@dastardlyhq.com wrote:
> On Thu, 18 May 2023 02:24:51 -0700
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
>> On 5/18/2023 2:10 AM, Muttley@dastardlyhq.com wrote:
>>> Is there a way to get range loops to work with arrays stored in
>>> shared pointers?
>>>
>>> eg:
>>>
>>> #include <iostream>
>>> #include <memory>
>>>
>>> using namespace std;
>>>
>>> struct mystruct
>>> {
>>> mystruct() { cout << "Con " << this << endl; };
>>> ~mystruct() { cout << "Dest " << this << endl; }
>>> void func() { cout << "Func " << this << endl; }
>>> };
>>>
>>>
>>> int main()
>>> {
>>> shared_ptr<mystruct[3]> sp(new mystruct[3]);
[...]

struct xxx
{ mystruct m_x[3];
};

std::shared_ptr<xxx> Well, what about that fing shit? ;^)

Muttley@dastardlyhq.com wrote:
> Is there a way to get range loops to work with arrays stored in
> shared pointers?
These shared pointers do not store arrays. They store pointers to memory
object allocated with operator new[].

In other words, the type shared_ptr<mystruct[3]>::element_type is same
as shared_ptr<mystruct>::element_type i.e. mystruct.

To get a feeling of why it's natural, note that the type of the
expression "new mystruct[3]" that you use to initalize sp is mystruct*,
not mystruct (*)[3].

Therefore, it is not possible to iterate the way you want: there is no
either constexpr 3 anywhere in the type of shared_ptr<mystruct[3]> or
non-constexpr 3 that could be extracted from the object in memory in any
implementation-independent way. Thus, there is no way for C++ compiler
to generate the code that would compute the end of the range.

>
> eg:
>
> #include <iostream>
> #include <memory>
>
> using namespace std;
>
> struct mystruct
> {
> mystruct() { cout << "Con " << this << endl; };
> ~mystruct() { cout << "Dest " << this << endl; }
> void func() { cout << "Func " << this << endl; }
> };
>
>
> int main()
> {
> shared_ptr<mystruct[3]> sp(new mystruct[3]);
> sp[0].func();
> sp[1].func();
> sp[2].func();
> for(auto &ms: sp.get()) ms.func(); <--- Doesn't compile
> return 0;
> }
>
> I've tried other combinations too, nothing works.
>

HTH
-Pavel

On Fri, 19 May 2023 23:19:30 -0400
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> wrote:
>Muttley@dastardlyhq.com wrote:
>> Is there a way to get range loops to work with arrays stored in
>> shared pointers?
>These shared pointers do not store arrays. They store pointers to memory
>object allocated with operator new[].
>
>In other words, the type shared_ptr<mystruct[3]>::element_type is same
>as shared_ptr<mystruct>::element_type i.e. mystruct.
>
>To get a feeling of why it's natural, note that the type of the
>expression "new mystruct[3]" that you use to initalize sp is mystruct*,
>not mystruct (*)[3].

Fair enough. Does make me wonder why they bothered to introduce this
particular semantic for shared pointers.

On 2023-05-20 5:19 AM, Pavel wrote:
> Muttley@dastardlyhq.com wrote:
>> Is there a way to get range loops to work with arrays stored in
>> shared pointers?
> These shared pointers do not store arrays. They store pointers to memory
> object allocated with operator new[].
>
> In other words, the type shared_ptr<mystruct[3]>::element_type is same
> as shared_ptr<mystruct>::element_type i.e. mystruct.
>
> To get a feeling of why it's natural, note that the type of the
> expression "new mystruct[3]" that you use to initalize sp is mystruct*,
> not mystruct (*)[3].
>
> Therefore, it is not possible to iterate the way you want: there is no
> either constexpr 3 anywhere in the type of shared_ptr<mystruct[3]> or
> non-constexpr 3 that could be extracted from the object in memory in any
> implementation-independent way. Thus, there is no way for C++ compiler
> to generate the code that would compute the end of the range.

Oh, there is such a way.

`shared_ptr` currently makes available an indexing operator if the item
type is array: <url:
https://en.cppreference.com/w/cpp/memory/shared_ptr/operator_at>.

It could just as easily make available `begin` and `end` operations for
array item type, and then a range based loop would Just Work. My earlier
answer in this thread showed how to do that oneself. And what I can do
(it was trivial enough that a dino could manage) the committee could do.

- Alf

On 5/20/2023 2:38 PM, Alf P. Steinbach wrote:
> On 2023-05-20 5:19 AM, Pavel wrote:
>> Muttley@dastardlyhq.com wrote:
>>> Is there a way to get range loops to work with arrays stored in
>>> shared pointers?
>> These shared pointers do not store arrays. They store pointers to
>> memory object allocated with operator new[].
>>
>> In other words, the type shared_ptr<mystruct[3]>::element_type is same
>> as shared_ptr<mystruct>::element_type i.e. mystruct.
>>
>> To get a feeling of why it's natural, note that the type of the
>> expression "new mystruct[3]" that you use to initalize sp is
>> mystruct*, not mystruct (*)[3].
>>
>> Therefore, it is not possible to iterate the way you want: there is no
>> either constexpr 3 anywhere in the type of shared_ptr<mystruct[3]> or
>> non-constexpr 3 that could be extracted from the object in memory in
>> any implementation-independent way. Thus, there is no way for C++
>> compiler to generate the code that would compute the end of the range.
>
> Oh, there is such a way.
>
> `shared_ptr` currently makes available an indexing operator if the item
> type is array: <url:
> https://en.cppreference.com/w/cpp/memory/shared_ptr/operator_at>.

Thanks! I did not know that.

>
> It could just as easily make available `begin` and `end` operations for
> array item type, and then a range based loop would Just Work. My earlier
> answer in this thread showed how to do that oneself. And what I can do
> (it was trivial enough that a dino could manage) the committee could do.

Alf P. Steinbach wrote:
> On 2023-05-20 5:19 AM, Pavel wrote:
>> Muttley@dastardlyhq.com wrote:
>>> Is there a way to get range loops to work with arrays stored in
>>> shared pointers?
>> These shared pointers do not store arrays. They store pointers to
>> memory object allocated with operator new[].
>>
>> In other words, the type shared_ptr<mystruct[3]>::element_type is same
>> as shared_ptr<mystruct>::element_type i.e. mystruct.
>>
>> To get a feeling of why it's natural, note that the type of the
>> expression "new mystruct[3]" that you use to initalize sp is
>> mystruct*, not mystruct (*)[3].
>>
>> Therefore, it is not possible to iterate the way you want: there is no
>> either constexpr 3 anywhere in the type of shared_ptr<mystruct[3]> or
>> non-constexpr 3 that could be extracted from the object in memory in
>> any implementation-independent way. Thus, there is no way for C++
>> compiler to generate the code that would compute the end of the range.
>
> Oh, there is such a way.
Not without changing the Standard. My understanding is that OP tried to
make his code iterate with the shared pointers *as they are currently
defined* in the Standard.

>
> `shared_ptr` currently makes available an indexing operator if the item
> type is array: <url:
> https://en.cppreference.com/w/cpp/memory/shared_ptr/operator_at>.
>
> It could just as easily make available `begin` and `end` operations for
> array item type, and then a range based loop would Just Work. My earlier
> answer in this thread showed how to do that oneself. And what I can do
> (it was trivial enough that a dino could manage) the committee could do.
They could, for the template parameter of an array type U[N]. It is
unclear what is supposed to be done for the parameter of an array type U[].

But, with the current Standard, the N is lost. I am ok with this though
as adding this "feature" would open the whole new can of warms for
unclear benefit.

E.g. assume that, in line with your example, N becomes part of
shared_ptr instatiation *type* and consider this definition:

shared_ptr<mystruct[3]> sp(new mystruct[2]);

or, even better:

shared_ptr<mystruct[3]> sp(new mystruct[getNOfMyStructs()]);

What can possibly go wrong? (TM)

>
>
> - Alf
>

-Pavel

On Sat, 20 May 2023 23:53:18 -0400
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> wrote:
>Alf P. Steinbach wrote:
>> It could just as easily make available `begin` and `end` operations for
>> array item type, and then a range based loop would Just Work. My earlier
>> answer in this thread showed how to do that oneself. And what I can do
>> (it was trivial enough that a dino could manage) the committee could do.
>They could, for the template parameter of an array type U[N]. It is
>unclear what is supposed to be done for the parameter of an array type U[].
>
>But, with the current Standard, the N is lost. I am ok with this though

N might be lost to the user but the compiler/runtime is quite well aware of
what it is otherwise delete[] couldn't work which makes me wonder why its
not made available to range based loops.

On Sat, 20 May 2023 14:39:39 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
>On 5/20/2023 2:38 PM, Alf P. Steinbach wrote:
>> Oh, there is such a way.
>>
>> `shared_ptr` currently makes available an indexing operator if the item
>> type is array: <url:
>> https://en.cppreference.com/w/cpp/memory/shared_ptr/operator_at>.
>
>Thanks! I did not know that.

Neither did I until I watched the youtube video I linked to a few posts
back. Thats the problem with modern C++, the language is far too big for any
one person to know (probably even Bjarne). Whenever I come across something
new I write a little test program with come keywords in the comments so I
can just grep for them when I need similar functionality in the future because
I know I'm never going to remember all of them if I don't use them much.

Am 22.05.2023 um 10:24 schrieb Muttley@dastardlyhq.com:

> N might be lost to the user but the compiler/runtime is quite well aware of
> what it is otherwise delete[] couldn't work which makes me wonder why its
> not made available to range based loops.

There are specializations for array'd shared_ptr-s / unique_ptr-s.

On Mon, 22 May 2023 10:47:17 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 22.05.2023 um 10:24 schrieb Muttley@dastardlyhq.com:
>
>> N might be lost to the user but the compiler/runtime is quite well aware of
>> what it is otherwise delete[] couldn't work which makes me wonder why its
>> not made available to range based loops.
>
>There are specializations for array'd shared_ptr-s / unique_ptr-s.
>

You missed the point. The compiler is well aware of how many elements are
in the array pointed to by a C pointer created by new[] so why not extend that
awareness to range based loops without any specialisations being required?

Op 22.mei.2023 om 11:22 schreef Muttley@dastardlyhq.com:
> On Mon, 22 May 2023 10:47:17 +0200
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 22.05.2023 um 10:24 schrieb Muttley@dastardlyhq.com:
>>
>>> N might be lost to the user but the compiler/runtime is quite well aware of
>>> what it is otherwise delete[] couldn't work which makes me wonder why its
>>> not made available to range based loops.
>>
>> There are specializations for array'd shared_ptr-s / unique_ptr-s.
>>
>
> You missed the point. The compiler is well aware of how many elements are
> in the array pointed to by a C pointer created by new[] so why not extend that
> awareness to range based loops without any specialisations being required?
>

That is difficult to specify in de standard, because it depends very
much on the context. Given a pointer in an arbitrary context how could
the compiler know that it was created by new[]? There is a reason that
there is a delete and a delete[], because the compiler does not always
know from a pointer alone how it was created, so the programmer has to
help the compiler. Only if the creation of the pointer with new[] is
visible by the compiler, then it could know use that information, but
that is not always the case.

On Mon, 22 May 2023 11:51:48 +0200
"Fred. Zwarts" <F.Zwarts@HetNet.nl> wrote:
>Op 22.mei.2023 om 11:22 schreef Muttley@dastardlyhq.com:
>> On Mon, 22 May 2023 10:47:17 +0200
>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Am 22.05.2023 um 10:24 schrieb Muttley@dastardlyhq.com:
>>>
>>>> N might be lost to the user but the compiler/runtime is quite well aware of
>
>>>> what it is otherwise delete[] couldn't work which makes me wonder why its
>>>> not made available to range based loops.
>>>
>>> There are specializations for array'd shared_ptr-s / unique_ptr-s.
>>>
>>
>> You missed the point. The compiler is well aware of how many elements are
>> in the array pointed to by a C pointer created by new[] so why not extend
>that
>> awareness to range based loops without any specialisations being required?
>>
>
>That is difficult to specify in de standard, because it depends very
>much on the context. Given a pointer in an arbitrary context how could
>the compiler know that it was created by new[]? There is a reason that
>there is a delete and a delete[], because the compiler does not always
>know from a pointer alone how it was created, so the programmer has to
>help the compiler. Only if the creation of the pointer with new[] is
>visible by the compiler, then it could know use that information, but
>that is not always the case.

Ok, so if the *ms pointer below has no attached metadata other than the raw
memory size allocated how does delete[] know to iterate through 3 elements?
Does it literally divide the memory allocation size by individual object size
and use that as the count? There's no reason that approach couldn't be used
in range based loops too.

using namespace std;

struct mystruct
{
mystruct() { cout << "Con " << this << endl; };
~mystruct() { cout << "Dest " << this << endl; }
};

int main()
{ mystruct *ms = new mystruct[3];
delete[] ms;
return 0;
}

Am 22.05.2023 um 11:22 schrieb Muttley@dastardlyhq.com:
> On Mon, 22 May 2023 10:47:17 +0200
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 22.05.2023 um 10:24 schrieb Muttley@dastardlyhq.com:
>>
>>> N might be lost to the user but the compiler/runtime is quite well aware of
>>> what it is otherwise delete[] couldn't work which makes me wonder why its
>>> not made available to range based loops.
>>
>> There are specializations for array'd shared_ptr-s / unique_ptr-s.
>>
>
> You missed the point. The compiler is well aware of how many elements are
> in the array pointed to by a C pointer created by new[] so why not extend that
> awareness to range based loops without any specialisations being required?

Because the shared_ptr would need a .begin(), .end() and further
things required for a loop. And C-style arrays are outdated in
favor of std::array<> anyway.

On Mon, 22 May 2023 17:48:34 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 22.05.2023 um 11:22 schrieb Muttley@dastardlyhq.com:
>> On Mon, 22 May 2023 10:47:17 +0200
>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Am 22.05.2023 um 10:24 schrieb Muttley@dastardlyhq.com:
>>>
>>>> N might be lost to the user but the compiler/runtime is quite well aware of
>
>>>> what it is otherwise delete[] couldn't work which makes me wonder why its
>>>> not made available to range based loops.
>>>
>>> There are specializations for array'd shared_ptr-s / unique_ptr-s.
>>>
>>
>> You missed the point. The compiler is well aware of how many elements are
>> in the array pointed to by a C pointer created by new[] so why not extend
>that
>> awareness to range based loops without any specialisations being required?
>
>Because the shared_ptr would need a .begin(), .end() and further
>things required for a loop. And C-style arrays are outdated in

They could easily be implemented implicitly just like here:

char s[] = "hello";
for(auto c: s) cout << c;

But yet again you missed the point.

Am 22.05.2023 um 18:06 schrieb Muttley@dastardlyhq.com:

> They could easily be implemented implicitly just like here:
>
> char s[] = "hello";
> for(auto c: s) cout << c;
>
> But yet again you missed the point.

No, if the shared_ptr should behave like a container you'd need
an iterator-type with * and ++ and a begin and end-method on the
shared_ptr. I think the C++ designers thought this isn't necessary.

Muttley@dastardlyhq.com wrote:
> On Sat, 20 May 2023 23:53:18 -0400
> Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> wrote:
>> Alf P. Steinbach wrote:
>>> It could just as easily make available `begin` and `end` operations for
>>> array item type, and then a range based loop would Just Work. My earlier
>>> answer in this thread showed how to do that oneself. And what I can do
>>> (it was trivial enough that a dino could manage) the committee could do.
>> They could, for the template parameter of an array type U[N]. It is
>> unclear what is supposed to be done for the parameter of an array type U[].
>>
>> But, with the current Standard, the N is lost. I am ok with this though
>
> N might be lost to the user but the compiler/runtime is quite well aware of
> what it is otherwise delete[] couldn't work which makes me wonder why its
> not made available to range based loops.

Well, there are (up to) 2 different Ns. First N is a bound of template
parameter when it is an array with a known bound. Second N is that
number of elements that compiler knows (in the implementation-dependent
way) when array delete expression destroys the objects.

If begin() and end() on shared_ptr were defined, would these lines
remain legal C++ code?

shared_ptr<mystruct[3]> spt1(new mystruct[2]); // (a)

shared_ptr<mystruct[2]> spt2(new mystrucct[3]); // (b)

shared_ptr<mystruct[2]> spt3(getNFromFile()); // (c)

?

If yes, how many elements would range loop iterate thru?

I think maybe if the Standard only allowed shared_ptr specialization
with an array of unknown bound, the behavior of end() would be
technically easier to define (but still difficult to implement as any
implementation-specific feature).

Still, this would take us beyond smart pointer design goal -- which is
in essence to improve on safety of a raw pointer while preserving as
many of the raw pointer capabilities as possible. If we need an array,
we have std::array; if we have a vector, we have std::vector and
std::valarray.

(I personally think it is a shame that we don't have an exact-size
vector (i.e. a vector sized like valarray, with no capacities) but still
it is not a good excuse to abuse poor little smart pointers. For the
exact-size vector, using new[]- allocated memory and compiler trickery
for N could be justified).

-Pavel