On Thu, 20 Apr 2023 16:59:59 +0200
David Brown <david.brown@hesbynett.no> wrote:
>Perhaps you got that idea from working with old C compilers and old C
>code, where programmers were allergic to creating structs and would
>rather use an ugly and error-prone mix of pointer parameters instead of
>returning the function's results in the natural way - as the return value.
>
>When a function (C or C++) returns a struct that is too big to fit in
>registers, it is implemented by the calling function passing a hidden
>pointer parameter for the return value - there's no need to do it
>manually. C++ RVO guarantees you avoid extra coping in many cases.

In many cases is not every case so you could end up with performance in the
toilet on certain architectures all because you want to be "pure" and not use
pointers/references.

Also C++ can't change the hardware and if a C++ compiler can optimise returns
so can a C compiler.

>If the data is big enough that you don't want it in your local frame,
>you'll likely be using some kind of ownership class to handle the
>resource and heap management in a clean RAII manner.

ie globals in disguise. Which is fine, but don't pretend its some profoundly
new paradigm.

On 08/05/2023 17:49, Muttley@dastardlyhq.com wrote:
> On Thu, 20 Apr 2023 16:59:59 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>> Perhaps you got that idea from working with old C compilers and old C
>> code, where programmers were allergic to creating structs and would
>> rather use an ugly and error-prone mix of pointer parameters instead of
>> returning the function's results in the natural way - as the return value.
>>
>> When a function (C or C++) returns a struct that is too big to fit in
>> registers, it is implemented by the calling function passing a hidden
>> pointer parameter for the return value - there's no need to do it
>> manually. C++ RVO guarantees you avoid extra coping in many cases.
>
> In many cases is not every case so you could end up with performance in the
> toilet on certain architectures all because you want to be "pure" and not use
> pointers/references.

Again - when you have a function (C or C++) that returns a struct that
is too big to fit in registers, it is handled as though the caller had
passed a pointer to a struct to fill up. There will be, at most, minor
differences in the generated code. But if the struct is small enough to
fit in registers (and the ABI supports that), returning a struct will be
more efficient.

I agree that "many cases" is not "every case" - that's why I wrote "many
cases", and not "every case".

>
> Also C++ can't change the hardware and if a C++ compiler can optimise returns
> so can a C compiler.
>

Yes, so you get the same effects with C and C++, as I said. RVO and
copy elision guarantee (C++17) or allow (earlier C++) skipping of
unnecessary copy or move constructors and destructors when returning a
struct or class.

<https://en.cppreference.com/w/cpp/language/copy_elision>

>> If the data is big enough that you don't want it in your local frame,
>> you'll likely be using some kind of ownership class to handle the
>> resource and heap management in a clean RAII manner.
>
> ie globals in disguise. Which is fine, but don't pretend its some profoundly
> new paradigm.
>

No, that is not "globals in disguise". And of course it is not a new
idea - RAII for tracking memory is one of the main reasons for the
existence of C++.

On 08/05/2023 4:49 pm, Muttley@dastardlyhq.com wrote:
> On Thu, 20 Apr 2023 16:59:59 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>> If the data is big enough that you don't want it in your local frame,
>> you'll likely be using some kind of ownership class to handle the
>> resource and heap management in a clean RAII manner.
>
> ie globals in disguise. Which is fine, but don't pretend its some profoundly
> new paradigm.

Globals in disguise? You really are a clueless idiot, nearly as bad as
Bonita.

/Flibble

On Monday, 8 May 2023 at 18:27:57 UTC+1, Mr Flibble wrote:
> On 08/05/2023 4:49 pm, Mut...@dastardlyhq.com wrote:
> > On Thu, 20 Apr 2023 16:59:59 +0200
> > David Brown <david...@hesbynett.no> wrote:
> >> If the data is big enough that you don't want it in your local frame,
> >> you'll likely be using some kind of ownership class to handle the
> >> resource and heap management in a clean RAII manner.
> >
> > ie globals in disguise. Which is fine, but don't pretend its some profoundly
> > new paradigm.
> Globals in disguise? You really are a clueless idiot, nearly as bad as
> Bonita.
>
Resources are inherently global. You only have one physical port. Almost
always the system will need some global memory to manage it and
prevent two data sources from connecting to the same port at once.
RAII gives you the illusion that the port is a local object on the stack.
That's not necessarily a bad thing, however.

On 08/05/2023 6:41 pm, Malcolm McLean wrote:
> On Monday, 8 May 2023 at 18:27:57 UTC+1, Mr Flibble wrote:
>> On 08/05/2023 4:49 pm, Mut...@dastardlyhq.com wrote:
>>> On Thu, 20 Apr 2023 16:59:59 +0200
>>> David Brown <david...@hesbynett.no> wrote:
>>>> If the data is big enough that you don't want it in your local frame,
>>>> you'll likely be using some kind of ownership class to handle the
>>>> resource and heap management in a clean RAII manner.
>>>
>>> ie globals in disguise. Which is fine, but don't pretend its some profoundly
>>> new paradigm.
>> Globals in disguise? You really are a clueless idiot, nearly as bad as
>> Bonita.
>>
> Resources are inherently global. You only have one physical port. Almost
> always the system will need some global memory to manage it and
> prevent two data sources from connecting to the same port at once.
> RAII gives you the illusion that the port is a local object on the stack.
> That's not necessarily a bad thing, however.

Within the context of C++ (i.e., this newsgroup's topic) "globals" have
a distinct and specific meaning: global variables. Resources allocated
using some operating system service with a dynamic rather than fixed
lifetime are nothing like global variables.

/Flibble

On Monday, 8 May 2023 at 19:00:25 UTC+1, Mr Flibble wrote:
> On 08/05/2023 6:41 pm, Malcolm McLean wrote:
> > On Monday, 8 May 2023 at 18:27:57 UTC+1, Mr Flibble wrote:
> >> On 08/05/2023 4:49 pm, Mut...@dastardlyhq.com wrote:
> >>> On Thu, 20 Apr 2023 16:59:59 +0200
> >>> David Brown <david...@hesbynett.no> wrote:
> >>>> If the data is big enough that you don't want it in your local frame,
> >>>> you'll likely be using some kind of ownership class to handle the
> >>>> resource and heap management in a clean RAII manner.
> >>>
> >>> ie globals in disguise. Which is fine, but don't pretend its some profoundly
> >>> new paradigm.
> >> Globals in disguise? You really are a clueless idiot, nearly as bad as
> >> Bonita.
> >>
> > Resources are inherently global. You only have one physical port. Almost
> > always the system will need some global memory to manage it and
> > prevent two data sources from connecting to the same port at once.
> > RAII gives you the illusion that the port is a local object on the stack.
> > That's not necessarily a bad thing, however.
> Within the context of C++ (i.e., this newsgroup's topic) "globals" have
> a distinct and specific meaning: global variables. Resources allocated
> using some operating system service with a dynamic rather than fixed
> lifetime are nothing like global variables.
>
Of course they are. Think about how you would write malloc() in pure C++
for a small system wth a small, flat memory.

On 08/05/2023 8:04 pm, Malcolm McLean wrote:
> On Monday, 8 May 2023 at 19:00:25 UTC+1, Mr Flibble wrote:
>> On 08/05/2023 6:41 pm, Malcolm McLean wrote:
>>> On Monday, 8 May 2023 at 18:27:57 UTC+1, Mr Flibble wrote:
>>>> On 08/05/2023 4:49 pm, Mut...@dastardlyhq.com wrote:
>>>>> On Thu, 20 Apr 2023 16:59:59 +0200
>>>>> David Brown <david...@hesbynett.no> wrote:
>>>>>> If the data is big enough that you don't want it in your local frame,
>>>>>> you'll likely be using some kind of ownership class to handle the
>>>>>> resource and heap management in a clean RAII manner.
>>>>>
>>>>> ie globals in disguise. Which is fine, but don't pretend its some profoundly
>>>>> new paradigm.
>>>> Globals in disguise? You really are a clueless idiot, nearly as bad as
>>>> Bonita.
>>>>
>>> Resources are inherently global. You only have one physical port. Almost
>>> always the system will need some global memory to manage it and
>>> prevent two data sources from connecting to the same port at once.
>>> RAII gives you the illusion that the port is a local object on the stack.
>>> That's not necessarily a bad thing, however.
>> Within the context of C++ (i.e., this newsgroup's topic) "globals" have
>> a distinct and specific meaning: global variables. Resources allocated
>> using some operating system service with a dynamic rather than fixed
>> lifetime are nothing like global variables.
>>
> Of course they are. Think about how you would write malloc() in pure C++
> for a small system wth a small, flat memory.

Yep, thought about it, and my point still stands: you are wrong.

/Flibble

On 5/8/2023 12:04 PM, Malcolm McLean wrote:
> On Monday, 8 May 2023 at 19:00:25 UTC+1, Mr Flibble wrote:
>> On 08/05/2023 6:41 pm, Malcolm McLean wrote:
>>> On Monday, 8 May 2023 at 18:27:57 UTC+1, Mr Flibble wrote:
>>>> On 08/05/2023 4:49 pm, Mut...@dastardlyhq.com wrote:
>>>>> On Thu, 20 Apr 2023 16:59:59 +0200
>>>>> David Brown <david...@hesbynett.no> wrote:
>>>>>> If the data is big enough that you don't want it in your local frame,
>>>>>> you'll likely be using some kind of ownership class to handle the
>>>>>> resource and heap management in a clean RAII manner.
>>>>>
>>>>> ie globals in disguise. Which is fine, but don't pretend its some profoundly
>>>>> new paradigm.
>>>> Globals in disguise? You really are a clueless idiot, nearly as bad as
>>>> Bonita.
>>>>
>>> Resources are inherently global. You only have one physical port. Almost
>>> always the system will need some global memory to manage it and
>>> prevent two data sources from connecting to the same port at once.
>>> RAII gives you the illusion that the port is a local object on the stack.
>>> That's not necessarily a bad thing, however.
>> Within the context of C++ (i.e., this newsgroup's topic) "globals" have
>> a distinct and specific meaning: global variables. Resources allocated
>> using some operating system service with a dynamic rather than fixed
>> lifetime are nothing like global variables.
>>
> Of course they are. Think about how you would write malloc() in pure C++
> for a small system wth a small, flat memory.

I can write a thread local memory based malloc that still allows for
malloc and free even on different threads. realloc is a little bastard
to impl in this setup, but it can be done.

On Mon, 8 May 2023 19:12:35 +0200
David Brown <david.brown@hesbynett.no> wrote:
>On 08/05/2023 17:49, Muttley@dastardlyhq.com wrote:
>> Also C++ can't change the hardware and if a C++ compiler can optimise returns
>
>> so can a C compiler.
>>
>
>Yes, so you get the same effects with C and C++, as I said. RVO and
>copy elision guarantee (C++17) or allow (earlier C++) skipping of
>unnecessary copy or move constructors and destructors when returning a
>struct or class.

To be fair gcc has been doing that for decades anyway and I assume clang
and VC++ too.

On Mon, 8 May 2023 18:26:16 +0100
Mr Flibble <flibble2@reddwarf.jmc.corp> wrote:
>On 08/05/2023 4:49 pm, Muttley@dastardlyhq.com wrote:
>> On Thu, 20 Apr 2023 16:59:59 +0200
>> David Brown <david.brown@hesbynett.no> wrote:
>>> If the data is big enough that you don't want it in your local frame,
>>> you'll likely be using some kind of ownership class to handle the
>>> resource and heap management in a clean RAII manner.
>>
>> ie globals in disguise. Which is fine, but don't pretend its some profoundly
>> new paradigm.
>
>Globals in disguise? You really are a clueless idiot, nearly as bad as
>Bonita.

If the ownership object/singleton is available to the rest of the program and
not just the function/object in question then its a global. I'm not sure what
the issue is.

On Mon, 8 May 2023 14:22:13 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
>On 5/8/2023 12:04 PM, Malcolm McLean wrote:
>> Of course they are. Think about how you would write malloc() in pure C++
>> for a small system wth a small, flat memory.
>
>I can write a thread local memory based malloc that still allows for
>malloc and free even on different threads. realloc is a little bastard
>to impl in this setup, but it can be done.

A realloc equivalent is something that would be a nice to have in the C++
toolbox. Yes you can role your own allocators but it would be great if it was a
built in variant of "new".

On Tuesday, 9 May 2023 at 11:22:50 UTC+3, Mut...@dastardlyhq.com wrote:
> On Mon, 8 May 2023 18:26:16 +0100
> Mr Flibble <flib...@reddwarf.jmc.corp> wrote:
> >On 08/05/2023 4:49 pm, Mut...@dastardlyhq.com wrote:
> >> On Thu, 20 Apr 2023 16:59:59 +0200
> >> David Brown <david...@hesbynett.no> wrote:
> >>> If the data is big enough that you don't want it in your local frame,
> >>> you'll likely be using some kind of ownership class to handle the
> >>> resource and heap management in a clean RAII manner.
> >>
> >> ie globals in disguise. Which is fine, but don't pretend its some profoundly
> >> new paradigm.
> >
> >Globals in disguise? You really are a clueless idiot, nearly as bad as
> >Bonita.
> If the ownership object/singleton is available to the rest of the program and
> not just the function/object in question then its a global. I'm not sure what
> the issue is.
>
But it was about resource management/managing object in context of RAII
not about singleton. Object like std::unique_ptr, std::vector or std::thread.

It happens that sometimes we can gain lot of performance benefits
in C++ by dumping all that back and forth dynamic monkey-management
of copies and instead keeping data in some common place (like singleton).
However keeping accesses of that common place ordered and transactional
(so one can roll-back half-made changes because of exception) is trick of
its own. That kind of designs weren't under discussion.

On 09/05/2023 10:20, Muttley@dastardlyhq.com wrote:
> On Mon, 8 May 2023 19:12:35 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>> On 08/05/2023 17:49, Muttley@dastardlyhq.com wrote:
>>> Also C++ can't change the hardware and if a C++ compiler can optimise returns
>>
>>> so can a C compiler.
>>>
>>
>> Yes, so you get the same effects with C and C++, as I said. RVO and
>> copy elision guarantee (C++17) or allow (earlier C++) skipping of
>> unnecessary copy or move constructors and destructors when returning a
>> struct or class.
>
> To be fair gcc has been doing that for decades anyway and I assume clang
> and VC++ too.
>

They've been doing a lot of it, yes, but until RVO and copy elision
rules were added to C++, they could not simplify copy-constructor then
destructor sequences if they had observable side effects - or if the
compiler couldn't be sure that they had no observable side effects. As
long as the compiler knows a transformation does not have observable
behaviour, any optimisation is allowed. RVO rules let it do more than
that. And in particular, they allow more efficient return of struct or
class objects even if the compiler cannot see the definitions of the
constructors and destructors at the time.

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

> A realloc equivalent is something that would be a nice to have in the C++
> toolbox. Yes you can role your own allocators but it would be great if it
> was a built in variant of "new".

There are containers that do this for free with ::resize( n ).

On Tue, 9 May 2023 15:36:39 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 09.05.2023 um 10:24 schrieb Muttley@dastardlyhq.com:
>
>> A realloc equivalent is something that would be a nice to have in the C++
>> toolbox. Yes you can role your own allocators but it would be great if it
>> was a built in variant of "new".
>
>There are containers that do this for free with ::resize( n ).
>

Thats a limited use case. It would be nice if there was a generic way to do it.

Am 09.05.2023 um 17:48 schrieb Muttley@dastardlyhq.com:

> Thats a limited use case. It would be nice if there was a generic way to do it.

You can do anything with a vector<sth> you can do
with manual memory through malloc() / realloc():

On Tue, 9 May 2023 17:51:29 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 09.05.2023 um 17:48 schrieb Muttley@dastardlyhq.com:
>
>> Thats a limited use case. It would be nice if there was a generic way to do
>it.
>
>You can do anything with a vector<sth> you can do
>with manual memory through malloc() / realloc():

You'd still need to write your own allocator (which in turn would need realloc
internally so defeating the point) because the STL doesn't do reallocation, it
does new allocation + copy which is not what realloc is about most of the time.
The point of it is to extend the current allocated memory which is much more
efficient.

On Tue, 9 May 2023 16:14:29 -0000 (UTC)
Muttley@dastardlyhq.com wrote:
>On Tue, 9 May 2023 17:51:29 +0200
>Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>Am 09.05.2023 um 17:48 schrieb Muttley@dastardlyhq.com:
>>
>>> Thats a limited use case. It would be nice if there was a generic way to do
>>it.
>>
>>You can do anything with a vector<sth> you can do
>>with manual memory through malloc() / realloc():
>
>You'd still need to write your own allocator (which in turn would need realloc
>internally so defeating the point) because the STL doesn't do reallocation, it
>
>does new allocation + copy which is not what realloc is about most of the time.

Ok, allocation + move now but point still stands.

Am 09.05.2023 um 18:14 schrieb Muttley@dastardlyhq.com:

> You'd still need to write your own allocator (which in turn would need realloc
> internally so defeating the point) because the STL doesn't do reallocation, ...

A realloc() is the same as a further malloc(), copy and then free()
of the old block. There's no difference if the container does that
manually.

Am 09.05.2023 um 18:17 schrieb Bonita Montero:

> A realloc() is the same as a further malloc(), copy and then free()
> of the old block. There's no difference if the container does that
> manually.

And a realloc() does a plain memcpy()-like copy. That doesn't fit with
most types inside a vector. And for trivial data types or PODs there's
no performance-advantage if you'd have a realloc with your allocator.

On Tue, 9 May 2023 18:17:57 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 09.05.2023 um 18:14 schrieb Muttley@dastardlyhq.com:
>
>> You'd still need to write your own allocator (which in turn would need
>realloc
>> internally so defeating the point) because the STL doesn't do reallocation,
>...
>
>A realloc() is the same as a further malloc(), copy and then free()
>of the old block. There's no difference if the container does that
>manually.

No, it absolutely is not the same as that. It first inspects the current memory
block to see if it can be extended. If it can be then it is. Only if it can't
be extended does it do a malloc then copy.

> No, it absolutely is not the same as that. It first inspects the current memory
> block to see if it can be extended. ...

There's actually no memory allocator that can do in-place reallocation.

Muttley@dastardlyhq.com writes:
>On Tue, 9 May 2023 18:17:57 +0200
>Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>Am 09.05.2023 um 18:14 schrieb Muttley@dastardlyhq.com:
>>
>>> You'd still need to write your own allocator (which in turn would need
>>realloc
>>> internally so defeating the point) because the STL doesn't do reallocation,
>>...
>>
>>A realloc() is the same as a further malloc(), copy and then free()
>>of the old block. There's no difference if the container does that
>>manually.
>
>No, it absolutely is not the same as that. It first inspects the current memory
>block to see if it can be extended.

Which is almost _never_ in the real world unless you're using
a buddy allocator, which is wasteful of virtual address space
(and if not paged, memory as well).

On Tue, 9 May 2023 18:56:21 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> No, it absolutely is not the same as that. It first inspects the current
>memory
>> block to see if it can be extended. ...
>
>There's actually no memory allocator that can do in-place reallocation.
>

FFS, do try and keep up. Thats why I said you'd have to write your own.

On Tue, 09 May 2023 17:03:18 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>Muttley@dastardlyhq.com writes:
>>On Tue, 9 May 2023 18:17:57 +0200
>>Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>Am 09.05.2023 um 18:14 schrieb Muttley@dastardlyhq.com:
>>>
>>>> You'd still need to write your own allocator (which in turn would need
>>>realloc
>>>> internally so defeating the point) because the STL doesn't do reallocation,
>
>>>...
>>>
>>>A realloc() is the same as a further malloc(), copy and then free()
>>>of the old block. There's no difference if the container does that
>>>manually.
>>
>>No, it absolutely is not the same as that. It first inspects the current
>memory
>>block to see if it can be extended.
>
>Which is almost _never_ in the real world unless you're using

You'll have some proof of that then.