Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Marriage is the sole cause of divorce.


devel / comp.lang.c++ / Re: "Functional exception-less error handling with C++23

SubjectAuthor
* Re: "Functional exception-less error handling with C++23Muttley
+* Re: "Functional exception-less error handling with C++23David Brown
|`* Re: "Functional exception-less error handling with C++23Muttley
| `- Re: "Functional exception-less error handling with C++23David Brown
`* Re: "Functional exception-less error handling with C++23Mr Flibble
 +* Re: "Functional exception-less error handling with C++23Malcolm McLean
 |`* Re: "Functional exception-less error handling with C++23Mr Flibble
 | `* Re: "Functional exception-less error handling with C++23Malcolm McLean
 |  +- Re: "Functional exception-less error handling with C++23Mr Flibble
 |  `* Re: "Functional exception-less error handling with C++23Chris M. Thomasson
 |   `* Re: "Functional exception-less error handling with C++23Muttley
 |    `* Re: "Functional exception-less error handling with C++23Bonita Montero
 |     `* Re: "Functional exception-less error handling with C++23Muttley
 |      `* Re: "Functional exception-less error handling with C++23Bonita Montero
 |       `* Re: "Functional exception-less error handling with C++23Muttley
 |        +- Re: "Functional exception-less error handling with C++23Muttley
 |        `* Re: "Functional exception-less error handling with C++23Bonita Montero
 |         +- Re: "Functional exception-less error handling with C++23Bonita Montero
 |         `* Re: "Functional exception-less error handling with C++23Muttley
 |          +* Re: "Functional exception-less error handling with C++23Bonita Montero
 |          |`* Re: "Functional exception-less error handling with C++23Muttley
 |          | `* Re: "Functional exception-less error handling with C++23Bonita Montero
 |          |  `* Re: "Functional exception-less error handling with C++23Muttley
 |          |   +* Re: "Functional exception-less error handling with C++23Malcolm McLean
 |          |   |`- Re: "Functional exception-less error handling with C++23Chris M. Thomasson
 |          |   `* Re: "Functional exception-less error handling with C++23Bonita Montero
 |          |    `* Re: "Functional exception-less error handling with C++23Muttley
 |          |     `* Re: "Functional exception-less error handling with C++23Bonita Montero
 |          |      `* Re: "Functional exception-less error handling with C++23Muttley
 |          |       `* Re: "Functional exception-less error handling with C++23Bonita Montero
 |          |        `* Re: "Functional exception-less error handling with C++23Muttley
 |          |         `* Re: "Functional exception-less error handling with C++23Bonita Montero
 |          |          `* Re: "Functional exception-less error handling with C++23Muttley
 |          |           +* Re: "Functional exception-less error handling with C++23Scott Lurndal
 |          |           |`* Re: "Functional exception-less error handling with C++23Muttley
 |          |           | `- Re: "Functional exception-less error handling with C++23Bonita Montero
 |          |           `* Re: "Functional exception-less error handling with C++23Bonita Montero
 |          |            `* Re: "Functional exception-less error handling with C++23Scott Lurndal
 |          |             `* Re: "Functional exception-less error handling with C++23Bonita Montero
 |          |              `* Re: "Functional exception-less error handling with C++23Scott Lurndal
 |          |               +* Re: "Functional exception-less error handling with C++23Bonita Montero
 |          |               |`* Re: "Functional exception-less error handling with C++23Scott Lurndal
 |          |               | `* Re: "Functional exception-less error handling with C++23Bonita Montero
 |          |               |  `- Re: "Functional exception-less error handling with C++23Scott Lurndal
 |          |               `* Re: "Functional exception-less error handling with C++23Keith Thompson
 |          |                +- Re: "Functional exception-less error handling with C++23Scott Lurndal
 |          |                `* Re: "Functional exception-less error handling with C++23David Brown
 |          |                 `* Re: "Functional exception-less error handling with C++23Muttley
 |          |                  `* Re: "Functional exception-less error handling with C++23Bonita Montero
 |          |                   +* Re: "Functional exception-less error handling with C++23Muttley
 |          |                   |`* Re: "Functional exception-less error handling with C++23Bonita Montero
 |          |                   | `- Re: "Functional exception-less error handling with C++23Bonita Montero
 |          |                   `* Re: "Functional exception-less error handling with C++23David Brown
 |          |                    +* Re: "Functional exception-less error handling with C++23Bonita Montero
 |          |                    |`* Re: "Functional exception-less error handling with C++23David Brown
 |          |                    | `* Re: "Functional exception-less error handling with C++23Bonita Montero
 |          |                    |  `* Re: "Functional exception-less error handling with C++23Vir Campestris
 |          |                    |   +- Re: "Functional exception-less error handling with C++23Scott Lurndal
 |          |                    |   `* Re: "Functional exception-less error handling with C++23Bonita Montero
 |          |                    |    +* Re: "Functional exception-less error handling with C++23Chris M. Thomasson
 |          |                    |    |`* Re: "Functional exception-less error handling with C++23Bonita Montero
 |          |                    |    | `* Re: "Functional exception-less error handling with C++23Chris M. Thomasson
 |          |                    |    |  `- Re: "Functional exception-less error handling with C++23Chris M. Thomasson
 |          |                    |    `* Re: "Functional exception-less error handling with C++23Scott Lurndal
 |          |                    |     `* Re: "Functional exception-less error handling with C++23Bonita Montero
 |          |                    |      `* Re: "Functional exception-less error handling with C++23Scott Lurndal
 |          |                    |       `* Re: "Functional exception-less error handling with C++23Bonita Montero
 |          |                    |        `* Re: "Functional exception-less error handling with C++23Scott Lurndal
 |          |                    |         `* Re: "Functional exception-less error handling with C++23Bonita Montero
 |          |                    |          `* Re: "Functional exception-less error handling with C++23Vir Campestris
 |          |                    |           +- Re: "Functional exception-less error handling with C++23Richard Damon
 |          |                    |           +* Re: "Functional exception-less error handling with C++23Scott Lurndal
 |          |                    |           |+- Re: "Functional exception-less error handling with C++23Muttley
 |          |                    |           |`- Re: "Functional exception-less error handling with C++23Vir Campestris
 |          |                    |           `- Re: "Functional exception-less error handling with C++23Bonita Montero
 |          |                    `- Re: "Functional exception-less error handling with C++23Muttley
 |          `* Re: "Functional exception-less error handling with C++23Scott Lurndal
 |           +- Re: "Functional exception-less error handling with C++23Muttley
 |           `* Re: "Functional exception-less error handling with C++23Muttley
 |            `* Re: "Functional exception-less error handling with C++23Scott Lurndal
 |             `- Re: "Functional exception-less error handling with C++23Muttley
 `* Re: "Functional exception-less error handling with C++23Muttley
  +- Re: "Functional exception-less error handling with C++23Öö Tiib
  `- Re: "Functional exception-less error handling with C++23Mr Flibble

Pages:1234
Re: "Functional exception-less error handling with C++23

<u3b5m1$3tr4o$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=53&group=comp.lang.c%2B%2B#53

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Mutt...@dastardlyhq.com
Newsgroups: comp.lang.c++
Subject: Re: "Functional exception-less error handling with C++23
Date: Mon, 8 May 2023 15:49:21 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 26
Message-ID: <u3b5m1$3tr4o$1@dont-email.me>
References: <u1pli1$6mq8$1@dont-email.me> <u1qt0r$h625$1@dont-email.me> <u1rk1f$l0f7$1@dont-email.me>
Injection-Date: Mon, 8 May 2023 15:49:21 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="345b0689b1020e4dbc19378596b39e48";
logging-data="4123800"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+Wlv5NM4qNrPmz9WA0A2Od"
Cancel-Lock: sha1:OrT/8gmrQgSYnPBO3O5G84rEIQU=
 by: Mutt...@dastardlyhq.com - Mon, 8 May 2023 15:49 UTC

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.

Re: "Functional exception-less error handling with C++23

<u3bai4$3ud31$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=58&group=comp.lang.c%2B%2B#58

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.lang.c++
Subject: Re: "Functional exception-less error handling with C++23
Date: Mon, 8 May 2023 19:12:35 +0200
Organization: A noiseless patient Spider
Lines: 52
Message-ID: <u3bai4$3ud31$1@dont-email.me>
References: <u1pli1$6mq8$1@dont-email.me> <u1qt0r$h625$1@dont-email.me>
<u1rk1f$l0f7$1@dont-email.me> <u3b5m1$3tr4o$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 8 May 2023 17:12:36 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="106ba499bea53c129f1e1bed42408e99";
logging-data="4142177"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1875VpmGmjmN1jbve7eFnxVYJA+URchNNc="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.7.1
Cancel-Lock: sha1:b3b8AbO04d4rTmioj8e8gqGJiHA=
Content-Language: en-GB
In-Reply-To: <u3b5m1$3tr4o$1@dont-email.me>
 by: David Brown - Mon, 8 May 2023 17:12 UTC

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++.

Re: "Functional exception-less error handling with C++23

<175d3b105d57808b$80$2186$faa1aca7@news.newsdemon.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=59&group=comp.lang.c%2B%2B#59

  copy link   Newsgroups: comp.lang.c++
Date: Mon, 8 May 2023 18:26:16 +0100
Mime-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0
Subject: Re: "Functional exception-less error handling with C++23
Newsgroups: comp.lang.c++
References: <u1pli1$6mq8$1@dont-email.me> <u1qt0r$h625$1@dont-email.me> <u1rk1f$l0f7$1@dont-email.me> <u3b5m1$3tr4o$1@dont-email.me>
Content-Language: en-US
From: flibb...@reddwarf.jmc.corp (Mr Flibble)
In-Reply-To: <u3b5m1$3tr4o$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 14
Path: i2pn2.org!i2pn.org!news.neodome.net!feeder1.feed.usenet.farm!feed.usenet.farm!peer02.ams4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!news.newsdemon.com!not-for-mail
Nntp-Posting-Date: Mon, 08 May 2023 17:26:17 +0000
Organization: NewsDemon - www.newsdemon.com
X-Complaints-To: abuse@newsdemon.com
Message-Id: <175d3b105d57808b$80$2186$faa1aca7@news.newsdemon.com>
X-Received-Bytes: 1530
 by: Mr Flibble - Mon, 8 May 2023 17:26 UTC

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

Re: "Functional exception-less error handling with C++23

<ea067fd1-e6df-4e6b-a5ff-3be2b0984500n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=62&group=comp.lang.c%2B%2B#62

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:ad4:4b24:0:b0:5ef:52a8:bb8d with SMTP id s4-20020ad44b24000000b005ef52a8bb8dmr2297663qvw.0.1683567692012;
Mon, 08 May 2023 10:41:32 -0700 (PDT)
X-Received: by 2002:ad4:4b24:0:b0:5ef:52a8:bb8d with SMTP id
s4-20020ad44b24000000b005ef52a8bb8dmr2297660qvw.0.1683567691782; Mon, 08 May
2023 10:41:31 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!peer01.ams4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Mon, 8 May 2023 10:41:31 -0700 (PDT)
In-Reply-To: <175d3b105d57808b$80$2186$faa1aca7@news.newsdemon.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2a00:23a8:400a:5601:649c:c98c:649e:40ee;
posting-account=Dz2zqgkAAADlK5MFu78bw3ab-BRFV4Qn
NNTP-Posting-Host: 2a00:23a8:400a:5601:649c:c98c:649e:40ee
References: <u1pli1$6mq8$1@dont-email.me> <u1qt0r$h625$1@dont-email.me>
<u1rk1f$l0f7$1@dont-email.me> <u3b5m1$3tr4o$1@dont-email.me> <175d3b105d57808b$80$2186$faa1aca7@news.newsdemon.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <ea067fd1-e6df-4e6b-a5ff-3be2b0984500n@googlegroups.com>
Subject: Re: "Functional exception-less error handling with C++23
From: malcolm....@gmail.com (Malcolm McLean)
Injection-Date: Mon, 08 May 2023 17:41:31 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 2356
 by: Malcolm McLean - Mon, 8 May 2023 17:41 UTC

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.

Re: "Functional exception-less error handling with C++23

<175d3cd00dbb8d6e$1$2480680$baa1eca3@news.newsdemon.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=63&group=comp.lang.c%2B%2B#63

  copy link   Newsgroups: comp.lang.c++
Date: Mon, 8 May 2023 18:58:19 +0100
Mime-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0
Subject: Re: "Functional exception-less error handling with C++23
Newsgroups: comp.lang.c++
References: <u1pli1$6mq8$1@dont-email.me> <u1qt0r$h625$1@dont-email.me> <u1rk1f$l0f7$1@dont-email.me> <u3b5m1$3tr4o$1@dont-email.me> <175d3b105d57808b$80$2186$faa1aca7@news.newsdemon.com> <ea067fd1-e6df-4e6b-a5ff-3be2b0984500n@googlegroups.com>
Content-Language: en-US
From: flibb...@reddwarf.jmc.corp (Mr Flibble)
In-Reply-To: <ea067fd1-e6df-4e6b-a5ff-3be2b0984500n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 26
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!2.eu.feeder.erje.net!feeder.erje.net!news-2.dfn.de!news.dfn.de!npeer.as286.net!npeer-ng0.as286.net!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!news.newsdemon.com!not-for-mail
Nntp-Posting-Date: Mon, 08 May 2023 17:58:19 +0000
X-Complaints-To: abuse@newsdemon.com
Organization: NewsDemon - www.newsdemon.com
Message-Id: <175d3cd00dbb8d6e$1$2480680$baa1eca3@news.newsdemon.com>
X-Received-Bytes: 2403
 by: Mr Flibble - Mon, 8 May 2023 17:58 UTC

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

Re: "Functional exception-less error handling with C++23

<2c26c134-809f-49ed-a5fd-839c2d775579n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=64&group=comp.lang.c%2B%2B#64

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:ac8:58cf:0:b0:3f3:9062:4a72 with SMTP id u15-20020ac858cf000000b003f390624a72mr1461603qta.4.1683572663276;
Mon, 08 May 2023 12:04:23 -0700 (PDT)
X-Received: by 2002:a05:6214:b2e:b0:61a:23ac:b0de with SMTP id
w14-20020a0562140b2e00b0061a23acb0demr2329447qvj.6.1683572662352; Mon, 08 May
2023 12:04:22 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border-2.nntp.ord.giganews.com!border-1.nntp.ord.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Mon, 8 May 2023 12:04:22 -0700 (PDT)
In-Reply-To: <175d3cd00dbb8d6e$1$2480680$baa1eca3@news.newsdemon.com>
Injection-Info: google-groups.googlegroups.com; posting-host=81.143.231.9; posting-account=Dz2zqgkAAADlK5MFu78bw3ab-BRFV4Qn
NNTP-Posting-Host: 81.143.231.9
References: <u1pli1$6mq8$1@dont-email.me> <u1qt0r$h625$1@dont-email.me>
<u1rk1f$l0f7$1@dont-email.me> <u3b5m1$3tr4o$1@dont-email.me>
<175d3b105d57808b$80$2186$faa1aca7@news.newsdemon.com> <ea067fd1-e6df-4e6b-a5ff-3be2b0984500n@googlegroups.com>
<175d3cd00dbb8d6e$1$2480680$baa1eca3@news.newsdemon.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <2c26c134-809f-49ed-a5fd-839c2d775579n@googlegroups.com>
Subject: Re: "Functional exception-less error handling with C++23
From: malcolm....@gmail.com (Malcolm McLean)
Injection-Date: Mon, 08 May 2023 19:04:23 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 26
 by: Malcolm McLean - Mon, 8 May 2023 19:04 UTC

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.

Re: "Functional exception-less error handling with C++23

<175d44ea7f43274f$63$565070$7aa12caf@news.newsdemon.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=65&group=comp.lang.c%2B%2B#65

  copy link   Newsgroups: comp.lang.c++
Date: Mon, 8 May 2023 21:26:49 +0100
Mime-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0
Subject: Re: "Functional exception-less error handling with C++23
Content-Language: en-US
Newsgroups: comp.lang.c++
References: <u1pli1$6mq8$1@dont-email.me> <u1qt0r$h625$1@dont-email.me> <u1rk1f$l0f7$1@dont-email.me> <u3b5m1$3tr4o$1@dont-email.me> <175d3b105d57808b$80$2186$faa1aca7@news.newsdemon.com> <ea067fd1-e6df-4e6b-a5ff-3be2b0984500n@googlegroups.com> <175d3cd00dbb8d6e$1$2480680$baa1eca3@news.newsdemon.com> <2c26c134-809f-49ed-a5fd-839c2d775579n@googlegroups.com>
From: flibb...@reddwarf.jmc.corp (Mr Flibble)
In-Reply-To: <2c26c134-809f-49ed-a5fd-839c2d775579n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 32
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!2.eu.feeder.erje.net!feeder.erje.net!feeder1.feed.usenet.farm!feed.usenet.farm!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!news.newsdemon.com!not-for-mail
Nntp-Posting-Date: Mon, 08 May 2023 20:26:49 +0000
X-Received-Bytes: 2570
Organization: NewsDemon - www.newsdemon.com
X-Complaints-To: abuse@newsdemon.com
Message-Id: <175d44ea7f43274f$63$565070$7aa12caf@news.newsdemon.com>
 by: Mr Flibble - Mon, 8 May 2023 20:26 UTC

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

Re: "Functional exception-less error handling with C++23

<u3bp66$3vrge$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=67&group=comp.lang.c%2B%2B#67

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: chris.m....@gmail.com (Chris M. Thomasson)
Newsgroups: comp.lang.c++
Subject: Re: "Functional exception-less error handling with C++23
Date: Mon, 8 May 2023 14:22:13 -0700
Organization: A noiseless patient Spider
Lines: 32
Message-ID: <u3bp66$3vrge$1@dont-email.me>
References: <u1pli1$6mq8$1@dont-email.me> <u1qt0r$h625$1@dont-email.me>
<u1rk1f$l0f7$1@dont-email.me> <u3b5m1$3tr4o$1@dont-email.me>
<175d3b105d57808b$80$2186$faa1aca7@news.newsdemon.com>
<ea067fd1-e6df-4e6b-a5ff-3be2b0984500n@googlegroups.com>
<175d3cd00dbb8d6e$1$2480680$baa1eca3@news.newsdemon.com>
<2c26c134-809f-49ed-a5fd-839c2d775579n@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 8 May 2023 21:22:14 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="d2c7a55820c79dd175750f71e6ffdaa7";
logging-data="4189710"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18VnXSXMPEs+4lDPXdVt1AgNUth/KHiz2A="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.10.1
Cancel-Lock: sha1:TgBMwHy190B2dfrZl4qa096hwJQ=
Content-Language: en-US
In-Reply-To: <2c26c134-809f-49ed-a5fd-839c2d775579n@googlegroups.com>
 by: Chris M. Thomasson - Mon, 8 May 2023 21:22 UTC

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.

Re: "Functional exception-less error handling with C++23

<u3cvo1$7641$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=69&group=comp.lang.c%2B%2B#69

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Mutt...@dastardlyhq.com
Newsgroups: comp.lang.c++
Subject: Re: "Functional exception-less error handling with C++23
Date: Tue, 9 May 2023 08:20:17 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 16
Message-ID: <u3cvo1$7641$1@dont-email.me>
References: <u1pli1$6mq8$1@dont-email.me> <u1qt0r$h625$1@dont-email.me>
<u1rk1f$l0f7$1@dont-email.me> <u3b5m1$3tr4o$1@dont-email.me>
<u3bai4$3ud31$1@dont-email.me>
Injection-Date: Tue, 9 May 2023 08:20:17 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="f4abde31a142c822785904edf044297a";
logging-data="235649"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19M8OnZuCiHRu6yaeUoniUH"
Cancel-Lock: sha1:CHHQVkANUFHoe2XYbHxje3jRP9Q=
 by: Mutt...@dastardlyhq.com - Tue, 9 May 2023 08:20 UTC

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.

Re: "Functional exception-less error handling with C++23

<u3cvq9$76a6$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=70&group=comp.lang.c%2B%2B#70

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Mutt...@dastardlyhq.com
Newsgroups: comp.lang.c++
Subject: Re: "Functional exception-less error handling with C++23
Date: Tue, 9 May 2023 08:21:29 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 19
Message-ID: <u3cvq9$76a6$1@dont-email.me>
References: <u1pli1$6mq8$1@dont-email.me> <u1qt0r$h625$1@dont-email.me> <u1rk1f$l0f7$1@dont-email.me> <u3b5m1$3tr4o$1@dont-email.me> <175d3b105d57808b$80$2186$faa1aca7@news.newsdemon.com>
Injection-Date: Tue, 9 May 2023 08:21:29 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="f4abde31a142c822785904edf044297a";
logging-data="235846"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+q31vb70rQJxqOn7CqkzNz"
Cancel-Lock: sha1:w0OE44o1pK77kBb+o2todpMPfzI=
 by: Mutt...@dastardlyhq.com - Tue, 9 May 2023 08:21 UTC

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.

Re: "Functional exception-less error handling with C++23

<u3cvvk$76qa$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=71&group=comp.lang.c%2B%2B#71

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Mutt...@dastardlyhq.com
Newsgroups: comp.lang.c++
Subject: Re: "Functional exception-less error handling with C++23
Date: Tue, 9 May 2023 08:24:20 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 14
Message-ID: <u3cvvk$76qa$1@dont-email.me>
References: <u1pli1$6mq8$1@dont-email.me> <u1qt0r$h625$1@dont-email.me>
<u1rk1f$l0f7$1@dont-email.me> <u3b5m1$3tr4o$1@dont-email.me>
<175d3b105d57808b$80$2186$faa1aca7@news.newsdemon.com>
<ea067fd1-e6df-4e6b-a5ff-3be2b0984500n@googlegroups.com>
<175d3cd00dbb8d6e$1$2480680$baa1eca3@news.newsdemon.com>
<2c26c134-809f-49ed-a5fd-839c2d775579n@googlegroups.com>
<u3bp66$3vrge$1@dont-email.me>
Injection-Date: Tue, 9 May 2023 08:24:20 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="f4abde31a142c822785904edf044297a";
logging-data="236362"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19DVg38ILY3zR8TF9Im+KiR"
Cancel-Lock: sha1:rt1HVpWDWKdIUetVas86Rn4GHwc=
 by: Mutt...@dastardlyhq.com - Tue, 9 May 2023 08:24 UTC

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".

Re: "Functional exception-less error handling with C++23

<f6cf8bde-1866-40c7-9ff8-cf0eb3047569n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=72&group=comp.lang.c%2B%2B#72

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:a05:622a:1a1a:b0:3e9:aa91:3600 with SMTP id f26-20020a05622a1a1a00b003e9aa913600mr5451794qtb.9.1683628397926;
Tue, 09 May 2023 03:33:17 -0700 (PDT)
X-Received: by 2002:a05:620a:2588:b0:757:7627:d06a with SMTP id
x8-20020a05620a258800b007577627d06amr2709520qko.15.1683628397774; Tue, 09 May
2023 03:33:17 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Tue, 9 May 2023 03:33:17 -0700 (PDT)
In-Reply-To: <u3cvq9$76a6$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=84.50.190.130; posting-account=pysjKgkAAACLegAdYDFznkqjgx_7vlUK
NNTP-Posting-Host: 84.50.190.130
References: <u1pli1$6mq8$1@dont-email.me> <u1qt0r$h625$1@dont-email.me>
<u1rk1f$l0f7$1@dont-email.me> <u3b5m1$3tr4o$1@dont-email.me>
<175d3b105d57808b$80$2186$faa1aca7@news.newsdemon.com> <u3cvq9$76a6$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <f6cf8bde-1866-40c7-9ff8-cf0eb3047569n@googlegroups.com>
Subject: Re: "Functional exception-less error handling with C++23
From: oot...@hot.ee (Öö Tiib)
Injection-Date: Tue, 09 May 2023 10:33:17 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 2850
 by: Öö Tiib - Tue, 9 May 2023 10:33 UTC

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.

Re: "Functional exception-less error handling with C++23

<u3dgkr$9301$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=73&group=comp.lang.c%2B%2B#73

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.lang.c++
Subject: Re: "Functional exception-less error handling with C++23
Date: Tue, 9 May 2023 15:08:43 +0200
Organization: A noiseless patient Spider
Lines: 29
Message-ID: <u3dgkr$9301$1@dont-email.me>
References: <u1pli1$6mq8$1@dont-email.me> <u1qt0r$h625$1@dont-email.me>
<u1rk1f$l0f7$1@dont-email.me> <u3b5m1$3tr4o$1@dont-email.me>
<u3bai4$3ud31$1@dont-email.me> <u3cvo1$7641$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 9 May 2023 13:08:43 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="9a2c42ad1c5d45be80252e8447a1dbc2";
logging-data="297985"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+9mruZorDJO4OzT7gpICURPZzKZDuSkuE="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.9.0
Cancel-Lock: sha1:X1u5SNhLeFfSaQ9kx5REQze+rwY=
In-Reply-To: <u3cvo1$7641$1@dont-email.me>
Content-Language: en-GB
 by: David Brown - Tue, 9 May 2023 13:08 UTC

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.

Re: "Functional exception-less error handling with C++23

<u3di97$99q0$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=74&group=comp.lang.c%2B%2B#74

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Bonita.M...@gmail.com (Bonita Montero)
Newsgroups: comp.lang.c++
Subject: Re: "Functional exception-less error handling with C++23
Date: Tue, 9 May 2023 15:36:39 +0200
Organization: A noiseless patient Spider
Lines: 9
Message-ID: <u3di97$99q0$1@dont-email.me>
References: <u1pli1$6mq8$1@dont-email.me> <u1qt0r$h625$1@dont-email.me>
<u1rk1f$l0f7$1@dont-email.me> <u3b5m1$3tr4o$1@dont-email.me>
<175d3b105d57808b$80$2186$faa1aca7@news.newsdemon.com>
<ea067fd1-e6df-4e6b-a5ff-3be2b0984500n@googlegroups.com>
<175d3cd00dbb8d6e$1$2480680$baa1eca3@news.newsdemon.com>
<2c26c134-809f-49ed-a5fd-839c2d775579n@googlegroups.com>
<u3bp66$3vrge$1@dont-email.me> <u3cvvk$76qa$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 9 May 2023 13:36:39 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="78575890c9ca26ab31e96e404032bd83";
logging-data="304960"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/dYSmNkNPg4ADa7u388b86or8Cl3/XFhw="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.10.1
Cancel-Lock: sha1:1sTCNRB0gREhEmjePaGonPNVhwM=
Content-Language: de-DE
In-Reply-To: <u3cvvk$76qa$1@dont-email.me>
 by: Bonita Montero - Tue, 9 May 2023 13:36 UTC

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

Re: "Functional exception-less error handling with C++23

<u3dq0m$a8cj$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=75&group=comp.lang.c%2B%2B#75

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Mutt...@dastardlyhq.com
Newsgroups: comp.lang.c++
Subject: Re: "Functional exception-less error handling with C++23
Date: Tue, 9 May 2023 15:48:38 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 13
Message-ID: <u3dq0m$a8cj$1@dont-email.me>
References: <u1pli1$6mq8$1@dont-email.me> <u1qt0r$h625$1@dont-email.me>
<u1rk1f$l0f7$1@dont-email.me> <u3b5m1$3tr4o$1@dont-email.me>
<175d3b105d57808b$80$2186$faa1aca7@news.newsdemon.com>
<ea067fd1-e6df-4e6b-a5ff-3be2b0984500n@googlegroups.com>
<175d3cd00dbb8d6e$1$2480680$baa1eca3@news.newsdemon.com>
<2c26c134-809f-49ed-a5fd-839c2d775579n@googlegroups.com>
<u3bp66$3vrge$1@dont-email.me> <u3cvvk$76qa$1@dont-email.me>
<u3di97$99q0$1@dont-email.me>
Injection-Date: Tue, 9 May 2023 15:48:38 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="f4abde31a142c822785904edf044297a";
logging-data="336275"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18szeNCp9a37TCS4gjeJNQ9"
Cancel-Lock: sha1:lK63dfxi9bgWnG+sYLuW83rqsHQ=
 by: Mutt...@dastardlyhq.com - Tue, 9 May 2023 15:48 UTC

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.

Re: "Functional exception-less error handling with C++23

<u3dq61$a8t0$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=76&group=comp.lang.c%2B%2B#76

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Bonita.M...@gmail.com (Bonita Montero)
Newsgroups: comp.lang.c++
Subject: Re: "Functional exception-less error handling with C++23
Date: Tue, 9 May 2023 17:51:29 +0200
Organization: A noiseless patient Spider
Lines: 7
Message-ID: <u3dq61$a8t0$1@dont-email.me>
References: <u1pli1$6mq8$1@dont-email.me> <u1qt0r$h625$1@dont-email.me>
<u1rk1f$l0f7$1@dont-email.me> <u3b5m1$3tr4o$1@dont-email.me>
<175d3b105d57808b$80$2186$faa1aca7@news.newsdemon.com>
<ea067fd1-e6df-4e6b-a5ff-3be2b0984500n@googlegroups.com>
<175d3cd00dbb8d6e$1$2480680$baa1eca3@news.newsdemon.com>
<2c26c134-809f-49ed-a5fd-839c2d775579n@googlegroups.com>
<u3bp66$3vrge$1@dont-email.me> <u3cvvk$76qa$1@dont-email.me>
<u3di97$99q0$1@dont-email.me> <u3dq0m$a8cj$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 9 May 2023 15:51:29 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="78575890c9ca26ab31e96e404032bd83";
logging-data="336800"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX185NSn7g9blGexPDCj2l24K5+O7HgBR0xY="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.10.1
Cancel-Lock: sha1:FWUySMwrg6a1l+S2llGjExusAgg=
In-Reply-To: <u3dq0m$a8cj$1@dont-email.me>
Content-Language: de-DE
 by: Bonita Montero - Tue, 9 May 2023 15:51 UTC

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

Re: "Functional exception-less error handling with C++23

<u3drh5$ael1$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=77&group=comp.lang.c%2B%2B#77

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Mutt...@dastardlyhq.com
Newsgroups: comp.lang.c++
Subject: Re: "Functional exception-less error handling with C++23
Date: Tue, 9 May 2023 16:14:29 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 16
Message-ID: <u3drh5$ael1$1@dont-email.me>
References: <u1pli1$6mq8$1@dont-email.me> <u1qt0r$h625$1@dont-email.me>
<u1rk1f$l0f7$1@dont-email.me> <u3b5m1$3tr4o$1@dont-email.me>
<175d3b105d57808b$80$2186$faa1aca7@news.newsdemon.com>
<ea067fd1-e6df-4e6b-a5ff-3be2b0984500n@googlegroups.com>
<175d3cd00dbb8d6e$1$2480680$baa1eca3@news.newsdemon.com>
<2c26c134-809f-49ed-a5fd-839c2d775579n@googlegroups.com>
<u3bp66$3vrge$1@dont-email.me> <u3cvvk$76qa$1@dont-email.me>
<u3di97$99q0$1@dont-email.me> <u3dq0m$a8cj$1@dont-email.me>
<u3dq61$a8t0$1@dont-email.me>
Injection-Date: Tue, 9 May 2023 16:14:29 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="f4abde31a142c822785904edf044297a";
logging-data="342689"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/eCvZ8qPN3RZTw1g2WEjJA"
Cancel-Lock: sha1:3aavoolhBoOgPTLypinUHA5ZIEI=
 by: Mutt...@dastardlyhq.com - Tue, 9 May 2023 16:14 UTC

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.

Re: "Functional exception-less error handling with C++23

<u3drk7$af3a$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=78&group=comp.lang.c%2B%2B#78

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Mutt...@dastardlyhq.com
Newsgroups: comp.lang.c++
Subject: Re: "Functional exception-less error handling with C++23
Date: Tue, 9 May 2023 16:16:08 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 19
Message-ID: <u3drk7$af3a$1@dont-email.me>
References: <u1pli1$6mq8$1@dont-email.me> <u1qt0r$h625$1@dont-email.me>
<u1rk1f$l0f7$1@dont-email.me> <u3b5m1$3tr4o$1@dont-email.me>
<175d3b105d57808b$80$2186$faa1aca7@news.newsdemon.com>
<ea067fd1-e6df-4e6b-a5ff-3be2b0984500n@googlegroups.com>
<175d3cd00dbb8d6e$1$2480680$baa1eca3@news.newsdemon.com>
<2c26c134-809f-49ed-a5fd-839c2d775579n@googlegroups.com>
<u3bp66$3vrge$1@dont-email.me> <u3cvvk$76qa$1@dont-email.me>
<u3di97$99q0$1@dont-email.me> <u3dq0m$a8cj$1@dont-email.me>
<u3dq61$a8t0$1@dont-email.me>
<u3drh5$ael1$1@dont-email.me>
Injection-Date: Tue, 9 May 2023 16:16:08 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="f4abde31a142c822785904edf044297a";
logging-data="343146"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+tac6fUvmad2jAEVy9xSBn"
Cancel-Lock: sha1:uxfClX7g6cbV/tZpxunpU/I0YPg=
 by: Mutt...@dastardlyhq.com - Tue, 9 May 2023 16:16 UTC

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.

Re: "Functional exception-less error handling with C++23

<u3drnl$af76$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=79&group=comp.lang.c%2B%2B#79

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Bonita.M...@gmail.com (Bonita Montero)
Newsgroups: comp.lang.c++
Subject: Re: "Functional exception-less error handling with C++23
Date: Tue, 9 May 2023 18:17:57 +0200
Organization: A noiseless patient Spider
Lines: 9
Message-ID: <u3drnl$af76$1@dont-email.me>
References: <u1pli1$6mq8$1@dont-email.me> <u1qt0r$h625$1@dont-email.me>
<u1rk1f$l0f7$1@dont-email.me> <u3b5m1$3tr4o$1@dont-email.me>
<175d3b105d57808b$80$2186$faa1aca7@news.newsdemon.com>
<ea067fd1-e6df-4e6b-a5ff-3be2b0984500n@googlegroups.com>
<175d3cd00dbb8d6e$1$2480680$baa1eca3@news.newsdemon.com>
<2c26c134-809f-49ed-a5fd-839c2d775579n@googlegroups.com>
<u3bp66$3vrge$1@dont-email.me> <u3cvvk$76qa$1@dont-email.me>
<u3di97$99q0$1@dont-email.me> <u3dq0m$a8cj$1@dont-email.me>
<u3dq61$a8t0$1@dont-email.me> <u3drh5$ael1$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 9 May 2023 16:17:58 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="78575890c9ca26ab31e96e404032bd83";
logging-data="343270"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX199HKzT91/P3aEZ8+jtSQepiFOMdNvaz34="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.10.1
Cancel-Lock: sha1:MW9sfaL0zJtMb7qTcVoebudAmBA=
In-Reply-To: <u3drh5$ael1$1@dont-email.me>
Content-Language: de-DE
 by: Bonita Montero - Tue, 9 May 2023 16:17 UTC

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.

Re: "Functional exception-less error handling with C++23

<u3drs1$af76$2@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=80&group=comp.lang.c%2B%2B#80

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Bonita.M...@gmail.com (Bonita Montero)
Newsgroups: comp.lang.c++
Subject: Re: "Functional exception-less error handling with C++23
Date: Tue, 9 May 2023 18:20:17 +0200
Organization: A noiseless patient Spider
Lines: 10
Message-ID: <u3drs1$af76$2@dont-email.me>
References: <u1pli1$6mq8$1@dont-email.me> <u1qt0r$h625$1@dont-email.me>
<u1rk1f$l0f7$1@dont-email.me> <u3b5m1$3tr4o$1@dont-email.me>
<175d3b105d57808b$80$2186$faa1aca7@news.newsdemon.com>
<ea067fd1-e6df-4e6b-a5ff-3be2b0984500n@googlegroups.com>
<175d3cd00dbb8d6e$1$2480680$baa1eca3@news.newsdemon.com>
<2c26c134-809f-49ed-a5fd-839c2d775579n@googlegroups.com>
<u3bp66$3vrge$1@dont-email.me> <u3cvvk$76qa$1@dont-email.me>
<u3di97$99q0$1@dont-email.me> <u3dq0m$a8cj$1@dont-email.me>
<u3dq61$a8t0$1@dont-email.me> <u3drh5$ael1$1@dont-email.me>
<u3drnl$af76$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 9 May 2023 16:20:17 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="78575890c9ca26ab31e96e404032bd83";
logging-data="343270"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+jtQ2ynQlPo8nI9xUOu1xOqnFd5t0M8FU="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.10.1
Cancel-Lock: sha1:gv3kpvNEhTBpx313LszBhnE3/H0=
In-Reply-To: <u3drnl$af76$1@dont-email.me>
Content-Language: de-DE
 by: Bonita Montero - Tue, 9 May 2023 16:20 UTC

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.

Re: "Functional exception-less error handling with C++23

<u3drsd$afvs$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=81&group=comp.lang.c%2B%2B#81

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Mutt...@dastardlyhq.com
Newsgroups: comp.lang.c++
Subject: Re: "Functional exception-less error handling with C++23
Date: Tue, 9 May 2023 16:20:29 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 17
Message-ID: <u3drsd$afvs$1@dont-email.me>
References: <u1pli1$6mq8$1@dont-email.me> <u1qt0r$h625$1@dont-email.me>
<u1rk1f$l0f7$1@dont-email.me> <u3b5m1$3tr4o$1@dont-email.me>
<175d3b105d57808b$80$2186$faa1aca7@news.newsdemon.com>
<ea067fd1-e6df-4e6b-a5ff-3be2b0984500n@googlegroups.com>
<175d3cd00dbb8d6e$1$2480680$baa1eca3@news.newsdemon.com>
<2c26c134-809f-49ed-a5fd-839c2d775579n@googlegroups.com>
<u3bp66$3vrge$1@dont-email.me> <u3cvvk$76qa$1@dont-email.me>
<u3di97$99q0$1@dont-email.me> <u3dq0m$a8cj$1@dont-email.me>
<u3dq61$a8t0$1@dont-email.me> <u3drh5$ael1$1@dont-email.me>
<u3drnl$af76$1@dont-email.me>
Injection-Date: Tue, 9 May 2023 16:20:29 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="f4abde31a142c822785904edf044297a";
logging-data="344060"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+CTpCh/jmUNxLkvJG6ul27"
Cancel-Lock: sha1:Y7DjV09frDemoPf023STROb8NPU=
 by: Mutt...@dastardlyhq.com - Tue, 9 May 2023 16:20 UTC

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.

Re: "Functional exception-less error handling with C++23

<u3dtvl$anm0$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=82&group=comp.lang.c%2B%2B#82

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Bonita.M...@gmail.com (Bonita Montero)
Newsgroups: comp.lang.c++
Subject: Re: "Functional exception-less error handling with C++23
Date: Tue, 9 May 2023 18:56:21 +0200
Organization: A noiseless patient Spider
Lines: 6
Message-ID: <u3dtvl$anm0$1@dont-email.me>
References: <u1pli1$6mq8$1@dont-email.me> <u1qt0r$h625$1@dont-email.me>
<u1rk1f$l0f7$1@dont-email.me> <u3b5m1$3tr4o$1@dont-email.me>
<175d3b105d57808b$80$2186$faa1aca7@news.newsdemon.com>
<ea067fd1-e6df-4e6b-a5ff-3be2b0984500n@googlegroups.com>
<175d3cd00dbb8d6e$1$2480680$baa1eca3@news.newsdemon.com>
<2c26c134-809f-49ed-a5fd-839c2d775579n@googlegroups.com>
<u3bp66$3vrge$1@dont-email.me> <u3cvvk$76qa$1@dont-email.me>
<u3di97$99q0$1@dont-email.me> <u3dq0m$a8cj$1@dont-email.me>
<u3dq61$a8t0$1@dont-email.me> <u3drh5$ael1$1@dont-email.me>
<u3drnl$af76$1@dont-email.me> <u3drsd$afvs$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 9 May 2023 16:56:21 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="78575890c9ca26ab31e96e404032bd83";
logging-data="351936"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18qvFwvQXyNqNruu1K2dAMVp9Ke2T3Ysyo="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.10.1
Cancel-Lock: sha1:vp58p3HJkC6z/GuQiY89RVFuz94=
In-Reply-To: <u3drsd$afvs$1@dont-email.me>
Content-Language: de-DE
 by: Bonita Montero - Tue, 9 May 2023 16:56 UTC

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

Re: "Functional exception-less error handling with C++23

<q1v6M.539027$Olad.29733@fx35.iad>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=83&group=comp.lang.c%2B%2B#83

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!feeder1.feed.usenet.farm!feed.usenet.farm!peer03.ams4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx35.iad.POSTED!not-for-mail
X-newsreader: xrn 9.03-beta-14-64bit
Sender: scott@dragon.sl.home (Scott Lurndal)
From: sco...@slp53.sl.home (Scott Lurndal)
Reply-To: slp53@pacbell.net
Subject: Re: "Functional exception-less error handling with C++23
Newsgroups: comp.lang.c++
References: <u1pli1$6mq8$1@dont-email.me> <175d3b105d57808b$80$2186$faa1aca7@news.newsdemon.com> <ea067fd1-e6df-4e6b-a5ff-3be2b0984500n@googlegroups.com> <175d3cd00dbb8d6e$1$2480680$baa1eca3@news.newsdemon.com> <2c26c134-809f-49ed-a5fd-839c2d775579n@googlegroups.com> <u3bp66$3vrge$1@dont-email.me> <u3cvvk$76qa$1@dont-email.me> <u3di97$99q0$1@dont-email.me> <u3dq0m$a8cj$1@dont-email.me> <u3dq61$a8t0$1@dont-email.me> <u3drh5$ael1$1@dont-email.me> <u3drnl$af76$1@dont-email.me> <u3drsd$afvs$1@dont-email.me>
Lines: 21
Message-ID: <q1v6M.539027$Olad.29733@fx35.iad>
X-Complaints-To: abuse@usenetserver.com
NNTP-Posting-Date: Tue, 09 May 2023 17:03:18 UTC
Organization: UsenetServer - www.usenetserver.com
Date: Tue, 09 May 2023 17:03:18 GMT
X-Received-Bytes: 1947
 by: Scott Lurndal - Tue, 9 May 2023 17:03 UTC

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

Re: "Functional exception-less error handling with C++23

<u3dupo$arh5$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=84&group=comp.lang.c%2B%2B#84

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Mutt...@dastardlyhq.com
Newsgroups: comp.lang.c++
Subject: Re: "Functional exception-less error handling with C++23
Date: Tue, 9 May 2023 17:10:16 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 11
Message-ID: <u3dupo$arh5$1@dont-email.me>
References: <u1pli1$6mq8$1@dont-email.me> <u1qt0r$h625$1@dont-email.me>
<u1rk1f$l0f7$1@dont-email.me> <u3b5m1$3tr4o$1@dont-email.me>
<175d3b105d57808b$80$2186$faa1aca7@news.newsdemon.com>
<ea067fd1-e6df-4e6b-a5ff-3be2b0984500n@googlegroups.com>
<175d3cd00dbb8d6e$1$2480680$baa1eca3@news.newsdemon.com>
<2c26c134-809f-49ed-a5fd-839c2d775579n@googlegroups.com>
<u3bp66$3vrge$1@dont-email.me> <u3cvvk$76qa$1@dont-email.me>
<u3di97$99q0$1@dont-email.me> <u3dq0m$a8cj$1@dont-email.me>
<u3dq61$a8t0$1@dont-email.me> <u3drh5$ael1$1@dont-email.me>
<u3drnl$af76$1@dont-email.me> <u3drsd$afvs$1@dont-email.me>
<u3dtvl$anm0$1@dont-email.me>
Injection-Date: Tue, 9 May 2023 17:10:16 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="f4abde31a142c822785904edf044297a";
logging-data="355877"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19uLuOTLzexIEdkzvmKeLq7"
Cancel-Lock: sha1:dzqu9wDOmaZeXpQ42EXY+ICk4A0=
 by: Mutt...@dastardlyhq.com - Tue, 9 May 2023 17:10 UTC

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.

Re: "Functional exception-less error handling with C++23

<u3duu5$as1q$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=85&group=comp.lang.c%2B%2B#85

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Mutt...@dastardlyhq.com
Newsgroups: comp.lang.c++
Subject: Re: "Functional exception-less error handling with C++23
Date: Tue, 9 May 2023 17:12:37 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 25
Message-ID: <u3duu5$as1q$1@dont-email.me>
References: <u1pli1$6mq8$1@dont-email.me> <175d3b105d57808b$80$2186$faa1aca7@news.newsdemon.com> <ea067fd1-e6df-4e6b-a5ff-3be2b0984500n@googlegroups.com> <175d3cd00dbb8d6e$1$2480680$baa1eca3@news.newsdemon.com> <2c26c134-809f-49ed-a5fd-839c2d775579n@googlegroups.com> <u3bp66$3vrge$1@dont-email.me> <u3cvvk$76qa$1@dont-email.me> <u3di97$99q0$1@dont-email.me> <u3dq0m$a8cj$1@dont-email.me> <u3dq61$a8t0$1@dont-email.me> <u3drh5$ael1$1@dont-email.me> <u3drnl$af76$1@dont-email.me> <u3drsd$afvs$1@dont-email.me>
<q1v6M.539027$Olad.29733@fx35.iad>
Injection-Date: Tue, 9 May 2023 17:12:37 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="f4abde31a142c822785904edf044297a";
logging-data="356410"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19gdUVoGXsHfQYUG0oGGavk"
Cancel-Lock: sha1:JXyk68+iam/cEWjeqXQAmKYt3mY=
 by: Mutt...@dastardlyhq.com - Tue, 9 May 2023 17:12 UTC

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.


devel / comp.lang.c++ / Re: "Functional exception-less error handling with C++23

Pages:1234
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor