Deutsch   English   Français   Italiano  
<vm8b9d$2uq20$5@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Julio Di Egidio <julio@diegidio.name>
Newsgroups: comp.lang.c
Subject: Re: So You Think You Can Const?
Date: Wed, 15 Jan 2025 13:56:12 +0100
Organization: A noiseless patient Spider
Lines: 106
Message-ID: <vm8b9d$2uq20$5@dont-email.me>
References: <vljvh3$27msl$1@dont-email.me> <20250107130809.661@kylheku.com>
 <vlm0hf$2dkpd$1@dont-email.me> <87a5c15ob0.fsf@bsb.me.uk>
 <vlm7o4$2dkpd$4@dont-email.me> <vlm8r6$2dkpd$5@dont-email.me>
 <87ldvk4wu7.fsf@bsb.me.uk> <20250108200758.563@kylheku.com>
 <vlo59o$39tcu$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 15 Jan 2025 13:56:14 +0100 (CET)
Injection-Info: dont-email.me; posting-host="2563c1350cfe2ddd1cd2f0f3cf044725";
	logging-data="3106880"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+54PG4kOLQWBxMGvUYCK9QAOphFPiVBrw="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:z7LufSL+B9TXCd/JYcPpyZaD92w=
Content-Language: en-GB
In-Reply-To: <vlo59o$39tcu$1@dont-email.me>
Bytes: 4786

On 09/01/2025 10:35, David Brown wrote:
> On 09/01/2025 05:24, Kaz Kylheku wrote:
>> On 2025-01-09, Ben Bacarisse <ben@bsb.me.uk> wrote:
>>> Julio Di Egidio <julio@diegidio.name> writes:
>>>
>>>> static AvlTree_t const *AvlTree_node(
>>>>      void const *pk, AvlTree_t const *pL, AvlTree_t const *pR
>>>> ) {
>>>>      AvlTree_t *pT;
>>>>
>>>>      pT = malloc(sizeof(AvlTree_t));
>>>>
>>>>      if (!pT) {
>>>>          return NULL;
>>>>      }
>>>>
>>>>      pT->pk = pk;
>>>>      pT->pL = pL;
>>>>      pT->pR = pR;
>>>>
>>>>      return pT;
>>>> }
>>>
>>> Just on a side issue, I prefer to make tests like this positive so I'd
>>> write:
>>>
>>>   static AvlTree_t const *AvlTree_node(
>>>       void const *pk, AvlTree_t const *pL, AvlTree_t const *pR
>>>   ) {
>>>       AvlTree_t *pT = malloc(*pT);
>>>       if (pT) {
>>>           pT->pk = pk;
>>>           pT->pL = pL;
>>>           pT->pR = pR;
>>>       }
>>>       return pT;
>>>   }
>>
>> More generally:
>>
>>     foo_handle *foo = foo_create();
>>     bar_handle *bar = foo ? bar_create(foo) : 0; // doesn't like null
>>     xyzzy_handle *xyz = xyzzy_create(42, bar, arg);
>>     container *con = malloc(sizeof *con);
>>
>>     if (foo && bar && xyz && con) {
>>       // happy case: we have all three resources
>>
>>       con->foo = foo;
>>       con->bar = bar;
>>       con->xyz = xyz;
>>
>>       return con;
>>     }
>>
>>     xyzzy_destroy(xyz);
>>     xyzzy_destroy(bar);
>>     if (foo)
>>        xyzzy_destroy(foo); // stupidly doesn't like null
>>
>>     return 0;
>>
>>> I'm not going to "make a case" for this (though I will if you want!) --
>>> I just think it helps to see lots of different styles.
>>
>> I might just have made the case. When more resources need to be
>> acquired that might fail, it consolidates the happy case under one
>> conjunctive test, and consolidates the cleanup in the unhappy case.
>> Effectively it's almost if we have only two cases.
>>
>> A minor disadvantage is that in the unhappy flow, we may allocate
>> resources past the point where it is obvious they are not going to be
>> needed: if foo_create() failed, we are pointlessly calling
>> xyzzy_create() and malloc for the container. It's possible that these
>> succeed, and we are just going to turn around and free them.
>>
> 
> How about taking the idea slightly further and making the later 
> allocations conditional too?
> 
>     foo_handle *foo = foo_create();
>     bar_handle *bar = foo ? bar_create(foo) : 0; // doesn't like null
>     xyzzy_handle *xyz = bar ? xyzzy_create(42, bar, arg) : 0;
>     container *con = xyz ? malloc(sizeof *con) : 0;
> 
>     if (con) {
>       // happy case: we have all three resources
> 
>     ...
> 
> If you are going to use that style (and I not arguing for or against 
> it), go all in!
> 
> 
>> It's a form of consolidated error checking, like when we make
>> several system calls and check them for errors as a batch;
>> e.g. call fprintf several times and check for disk full (etc)
>> just once.

HOW about you and that piece of nazi-retarded shit rather go fuck 
yourself somewhere else?  Eh??  Yeah, that would be it: I am having a 
great idea: YOU GO fuck yourself out of cpomp.lang.cv !! I am a fucking 
genius...

-Julio