On 2023-05-21 5:53 AM, Pavel wrote:
> 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*

It is.

For example, otherwise my example of how to do this would not work.

> 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)

You shot your leg off.

C++ allows that, in general.

shared_ptr provides support for arrays, including I believe restrictions
on conversions, but not total type safety enforcement.

- Alf

On Tuesday, 23 May 2023 at 06:22:18 UTC+3, Pavel wrote:
>
> (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).
>
IOW it is shame that the implementation-dependent way of figuring
how many destructors to call with delete[] to pointer allocated with
new[] is not exposed to programmers for to write such a class
themselves if the standard library does not bother.

On Mon, 22 May 2023 18:10:54 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>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.

Well they thought it necessary to be able to store arrays and index them
inside a shared pointer, so why didn't they complete the job?

Am 23.05.2023 um 10:17 schrieb Muttley@dastardlyhq.com:

> Well they thought it necessary to be able to store arrays and index
> them inside a shared pointer, so why didn't they complete the job?

No need to worry about that because there is a workaround that has
other benefits as well.

On Tue, 23 May 2023 10:20:08 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 23.05.2023 um 10:17 schrieb Muttley@dastardlyhq.com:
>
>> Well they thought it necessary to be able to store arrays and index
>> them inside a shared pointer, so why didn't they complete the job?
>
>No need to worry about that because there is a workaround that has
>other benefits as well.

Yes I know, but thats not the point. If they going to add features to the
language why don't they do it properly instead of some half assed job?

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

> Yes I know, but thats not the point. If they going to add features to the
> language why don't they do it properly instead of some half assed job?

For me the current solution is proper enough.
C-style arrays aren't very common in C++.

On Thursday, May 18, 2023 at 5:10:57 AM UTC-4, Mut...@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]);
> 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.

Would this be an acceptable alternative? It compiles and executes as I expected it to:

#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[1][3]> sp(new mystruct[1][3]);
sp[0][0].func();
sp[0][1].func();
sp[0][2].func();
for(auto &ms: sp.get()[0]) ms.func(); // <--- Doesn't compile
return 0;
}

On Tue, 23 May 2023 21:39:46 -0700 (PDT)
"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> wrote:
>On Thursday, May 18, 2023 at 5:10:57=E2=80=AFAM UTC-4, Mut...@dastardlyhq.c=
>om wrote:
>> I've tried other combinations too, nothing works.
>
>Would this be an acceptable alternative? It compiles and executes as I expe=
>cted it to:

Clang doesn't like it I'm afraid:

fenris$ c++ -std=c++17 t.cc
t.cc:16:32: error: no matching constructor for initialization of 'shared_ptr<mys
truct[1][3]>'
shared_ptr<mystruct[1][3]> sp(new mystruct[1][3]);

Am 24.05.2023 um 10:50 schrieb Muttley@dastardlyhq.com:
> On Tue, 23 May 2023 21:39:46 -0700 (PDT)
> "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> wrote:
>> On Thursday, May 18, 2023 at 5:10:57=E2=80=AFAM UTC-4, Mut...@dastardlyhq.c=
>> om wrote:
>>> I've tried other combinations too, nothing works.
>>
>> Would this be an acceptable alternative? It compiles and executes as I expe=
>> cted it to:
>
> Clang doesn't like it I'm afraid:
>
> fenris$ c++ -std=c++17 t.cc
> t.cc:16:32: error: no matching constructor for initialization of 'shared_ptr<mys
> truct[1][3]>'
> shared_ptr<mystruct[1][3]> sp(new mystruct[1][3]);
>

It compiled for me with clang++ 14.

On Wednesday, May 24, 2023 at 4:51:07 AM UTC-4, Mut...@dastardlyhq.com wrote:
> On Tue, 23 May 2023 21:39:46 -0700 (PDT)
> "james...@alumni.caltech.edu" <james...@alumni.caltech.edu> wrote:
> >On Thursday, May 18, 2023 at 5:10:57=E2=80=AFAM UTC-4, Mut...@dastardlyhq.c> >om wrote:
> >> I've tried other combinations too, nothing works.
> >
> >Would this be an acceptable alternative? It compiles and executes as I expe=
> >cted it to:
>
> Clang doesn't like it I'm afraid:
>
> fenris$ c++ -std=c++17 t.cc
> t.cc:16:32: error: no matching constructor for initialization of 'shared_ptr<mys
> truct[1][3]>'
> shared_ptr<mystruct[1][3]> sp(new mystruct[1][3]);

On my machine, it works:

clang++-14 -std=c++17 shared_pointer.cpp -o shared_pointer

clang++-14 --version
Ubuntu clang version 14.0.6
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

Öö Tiib wrote:
> On Tuesday, 23 May 2023 at 06:22:18 UTC+3, Pavel wrote:
>>
>> (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).
>>
> IOW it is shame that the implementation-dependent way of figuring
> how many destructors to call with delete[] to pointer allocated with
> new[] is not exposed to programmers for to write such a class
> themselves if the standard library does not bother.
>
Actually, I meant someone slightly different. The shame is that the
vector class is not factored onto an exact-size array (let's call it
"block") and the rest of vector functionality.

vector has the design flaw that it is too many things: it is the owner
of several contiguous objects in memory but also the growth strategy.

The block is useful independently of vector if:

a) a custom growth strategy is needed; or
b) no growth is needed at all (a very often case in my practice).

For small vectors, replacing them with blocks could provide significant
space savings (not limited by only capacity even when compiler trickery
is not used; e.g. block<size_t> could be specialized so that the
underlying storage layout is implemented like this:

struct { const size_t N; size_t data[]; }; // or like this
struct { const size_t *end; size_t data[]; };

This way, 2 words of memory are saved (capacity and begin pointer) and
one indirection is also saved when one needs to access elements in a
block passed by reference or pointer so this brings both performance and
space savings.

Then, as I said, for the purpose of implementing the block (again, maybe
of only some specializations), using compiler trickery for computing N
*could* be justified. *could* is a keyword here. It *could* also be
useless or even detrimental performance-wise. It is feasible that the

operator new[]

would actually take more memory from the OS for N elements than
(non-array) allocation function

void* operator new(size[, align_val_t]...)

would for the same N elements. In this case, no gain is achieved from
using operator new[] and compiler trickery over using the single-object
form of allocation function "operator new" and system-independent
implementation.

-Pavel

Muttley@dastardlyhq.com wrote:
> On Mon, 22 May 2023 18:10:54 +0200
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> 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.
>
> Well they thought it necessary to be able to store arrays and index them
> inside a shared pointer, so why didn't they complete the job?
>
The support of indexing can be considered to be the support of the
existing functionality of a raw pointer as it also supports indexing,
but not iteration.

-Pavel

Alf P. Steinbach wrote:
> On 2023-05-21 5:53 AM, Pavel wrote:
>> 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*
>
> It is.
>
> For example, otherwise my example of how to do this would not work.
Yes, but notice that for Mutley, it seemed more natural that N was the
the run-time size of the array (somewhere up this thread he used the
argument that the compiler is able to get N to destroy every of N
allocated objects when delete[] is called -- on raw pointer -- that does
not have compile-time N). This tells me that different people would feel
differently about which N is "natural" (compile-time or runtime) so
standardizing this would be counter-intuitive either way.

>
>
>> 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)
>
> You shot your leg off.
I certainly did. This is exactly why I do not mind if this particular
way to self-inflict harm on myself is not supported :-). smart pointers
were supposed to be safer than the raw ones, after all, and even raw
pointers do not support iteration.

>
> C++ allows that, in general.
Yes, that was one of the design goals. Blow up your whole leg.. Going on
tangent, I am still mad at them they broke this performance-over-safety
promise when they decided that most-derived-class's virtual function
cannot be called from a constructor or destructor of a base class.
"What's safe enough for Java should be safe enough for C++" says I :-).

>
> shared_ptr provides support for arrays,
I disagree. I think what you mean by "support for array" (indexing?) is
actually the support for the raw pointers to memory allocated by
operator new[]. The argument that we pass to the shared_ptr constructor in

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

(and that the shared_ptr likely stores underneath) is such a raw
pointer, not an array.

> including I believe restrictions
> on conversions, but not total type safety enforcement.
>
>
> - Alf
>

-Pavel

On 5/24/2023 6:40 PM, Pavel wrote:
> Alf P. Steinbach wrote:
>> On 2023-05-21 5:53 AM, Pavel wrote:
>>> 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[].
[...]
>> shared_ptr provides support for arrays,
> I disagree. I think what you mean by "support for array" (indexing?) is
> actually the support for the raw pointers to memory allocated by
> operator new[]. The argument that we pass to the shared_ptr constructor in
>
> shared_ptr<mystruct[3]> sp(new mystruct[3]);
>
> (and that the shared_ptr likely stores underneath) is such a raw
> pointer, not an array.
[...]

Almost has to be.

On Wed, 24 May 2023 09:48:05 -0700 (PDT)
"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> wrote:
>On Wednesday, May 24, 2023 at 4:51:07=E2=80=AFAM UTC-4, Mut...@dastardlyhq.=
>com wrote:
>> On Tue, 23 May 2023 21:39:46 -0700 (PDT)=20
>> "james...@alumni.caltech.edu" <james...@alumni.caltech.edu> wrote:=20
>> >On Thursday, May 18, 2023 at 5:10:57=3DE2=3D80=3DAFAM UTC-4, Mut...@dast=
>ardlyhq.c=3D
>> >om wrote:=20
>> >> I've tried other combinations too, nothing works.=20
>> >
>> >Would this be an acceptable alternative? It compiles and executes as I e=
>xpe=3D=20
>> >cted it to:=20
>>=20
>> Clang doesn't like it I'm afraid:=20
>>=20
>> fenris$ c++ -std=3Dc++17 t.cc=20
>> t.cc:16:32: error: no matching constructor for initialization of 'shared_=
>ptr<mys=20
>> truct[1][3]>'
>> shared_ptr<mystruct[1][3]> sp(new mystruct[1][3]);
>
>On my machine, it works:
>
>clang++-14 -std=3Dc++17 shared_pointer.cpp -o shared_pointer
>
>clang++-14 --version
>Ubuntu clang version 14.0.6
>Target: x86_64-pc-linux-gnu
>Thread model: posix
>InstalledDir: /usr/bin

Beats me. I'm using clang on a Mac and I tried it again in case I'd not
cut and pasted properly but it still failed.

However this wouldn't be the first time the Apple version of Clang differs
from versions on other platforms.

On Thursday, May 25, 2023 at 4:51:30 AM UTC-4, Mut...@dastardlyhq.com wrote:
> On Wed, 24 May 2023 09:48:05 -0700 (PDT)
> "james...@alumni.caltech.edu" <james...@alumni.caltech.edu> wrote:
> >On Wednesday, May 24, 2023 at 4:51:07=E2=80=AFAM UTC-4, Mut...@dastardlyhq.=
> >com wrote:
....
> >> Clang doesn't like it I'm afraid:=20
> >>=20
> >> fenris$ c++ -std=3Dc++17 t.cc=20
> >> t.cc:16:32: error: no matching constructor for initialization of 'shared_=
> >ptr<mys=20
> >> truct[1][3]>'
> >> shared_ptr<mystruct[1][3]> sp(new mystruct[1][3]);
> >
> >On my machine, it works:
> >
> >clang++-14 -std=3Dc++17 shared_pointer.cpp -o shared_pointer
> >
> >clang++-14 --version
> >Ubuntu clang version 14.0.6
> >Target: x86_64-pc-linux-gnu
> >Thread model: posix
> >InstalledDir: /usr/bin
> Beats me. I'm using clang on a Mac and I tried it again in case I'd not
> cut and pasted properly but it still failed.
>
> However this wouldn't be the first time the Apple version of Clang differs
> from versions on other platforms.

Something about that error message makes me suspicious that the
problem may be more fundamental. Does it still complain if you change it
to use a raw pointer, rather than a shared_pointer?:

mystruct(*sp)[3](new mystruct[1][3]);
....
for(auto &ms: sp[0]) ms.func();
....
delete[] sp;

On Fri, 26 May 2023 00:49:32 -0700 (PDT)
"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> wrote:
>On Thursday, May 25, 2023 at 4:51:30=E2=80=AFAM UTC-4, Mut...@dastardlyhq.c=
>om wrote:
>> Beats me. I'm using clang on a Mac and I tried it again in case I'd not=
>=20
>> cut and pasted properly but it still failed.=20
>>=20
>> However this wouldn't be the first time the Apple version of Clang differ=
>s=20
>> from versions on other platforms.
>
>Something about that error message makes me suspicious that the
>problem may be more fundamental. Does it still complain if you change it
>to use a raw pointer, rather than a shared_pointer?:
>
>mystruct(*sp)[3](new mystruct[1][3]);=20
>....
>for(auto &ms: sp[0]) ms.func();
>....
>delete[] sp;

No, that compiles fine. Looks like the current Mac version of Clang does
have a bug but given how infrequently Apple updates their compiler I won't
hold my breath on it being fixed anytime soon.

Am 26.05.2023 um 10:44 schrieb Muttley@dastardlyhq.com:

> No, that compiles fine. Looks like the current Mac version of Clang does
> have a bug but given how infrequently Apple updates their compiler I won't
> hold my breath on it being fixed anytime soon.

AFAIK you can replace Apple's clang with LLVM clang somhehow.

On Friday, 26 May 2023 at 14:16:10 UTC+3, Bonita Montero wrote:
> Am 26.05.2023 um 10:44 schrieb Mut...@dastardlyhq.com:
>
> > No, that compiles fine. Looks like the current Mac version of Clang does
> > have a bug but given how infrequently Apple updates their compiler I won't
> > hold my breath on it being fixed anytime soon.
> AFAIK you can replace Apple's clang with LLVM clang somhehow.

Yes, <https://releases.llvm.org/> can download distributions for Apple too.

On Fri, 26 May 2023 05:59:02 -0700 (PDT)
=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>On Friday, 26 May 2023 at 14:16:10 UTC+3, Bonita Montero wrote:
>> Am 26.05.2023 um 10:44 schrieb Mut...@dastardlyhq.com:
>>
>> > No, that compiles fine. Looks like the current Mac version of Clang does
>> > have a bug but given how infrequently Apple updates their compiler I won't
>
>> > hold my breath on it being fixed anytime soon.
>> AFAIK you can replace Apple's clang with LLVM clang somhehow.
>
>Yes, <https://releases.llvm.org/> can download distributions for Apple too.

Every new release of MacOS locks things down more and more. I'm a bit
paranoid about updating something as fundamental as the compiler and all
the libraries as I have a nasty feeling things might die halfway through with
some system integrity or unsigned code error or similar.

Am 26.05.2023 um 17:00 schrieb Muttley@dastardlyhq.com:
> On Fri, 26 May 2023 05:59:02 -0700 (PDT)
> =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>> On Friday, 26 May 2023 at 14:16:10 UTC+3, Bonita Montero wrote:
>>> Am 26.05.2023 um 10:44 schrieb Mut...@dastardlyhq.com:
>>>
>>>> No, that compiles fine. Looks like the current Mac version of Clang does
>>>> have a bug but given how infrequently Apple updates their compiler I won't
>>
>>>> hold my breath on it being fixed anytime soon.
>>> AFAIK you can replace Apple's clang with LLVM clang somhehow.
>>
>> Yes, <https://releases.llvm.org/> can download distributions for Apple too.
>
> Every new release of MacOS locks things down more and more. I'm a bit
> paranoid about updating something as fundamental as the compiler and
> all the libraries as I have a nasty feeling things might die halfway
> through with some system integrity or unsigned code error or similar.

I think a compiler is much more fundamental for Linux than for macOS.

On Fri, 26 May 2023 19:20:05 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 26.05.2023 um 17:00 schrieb Muttley@dastardlyhq.com:
>> On Fri, 26 May 2023 05:59:02 -0700 (PDT)
>> =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>>> On Friday, 26 May 2023 at 14:16:10 UTC+3, Bonita Montero wrote:
>>>> Am 26.05.2023 um 10:44 schrieb Mut...@dastardlyhq.com:
>>>>
>>>>> No, that compiles fine. Looks like the current Mac version of Clang does
>>>>> have a bug but given how infrequently Apple updates their compiler I won't
>
>>>
>>>>> hold my breath on it being fixed anytime soon.
>>>> AFAIK you can replace Apple's clang with LLVM clang somhehow.
>>>
>>> Yes, <https://releases.llvm.org/> can download distributions for Apple too.
>>
>> Every new release of MacOS locks things down more and more. I'm a bit
>> paranoid about updating something as fundamental as the compiler and
>> all the libraries as I have a nasty feeling things might die halfway
>> through with some system integrity or unsigned code error or similar.
>
>I think a compiler is much more fundamental for Linux than for macOS.

MacOS internals are somewhat opaque. I'd rather not take the risk as I use my
Mac for far more than just writing C++ and if it died I'd be screwed even
with data backups.