Sujet : Re: question about nullptr
De : janis_papanagnou+ng (at) *nospam* hotmail.com (Janis Papanagnou)
Groupes : comp.lang.cDate : 08. Jul 2024, 19:07:26
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <v6h9su$vkip$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14
User-Agent : Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
On 08.07.2024 18:23, Ben Bacarisse wrote:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
On 08.07.2024 12:18, Ben Bacarisse wrote:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>
What's superfluous to one is useful for others (e.g. for grep'ing
occurrences of a null-pointer value in source codes);
>
This is been suggested twice now but I'm struggling to see why that is
useful. I can see management wanting one to find all uses of a null
pointer constant to check that they have all been replaced by the
"safer" nullptr, but what's the value in searching for nullptr?
>
Bug-tracking.
Can you say more?
Frankly, no. Not more than has been already written (not only by me
but also by others) in a couple posts of this thread. It's so clear to
me that if it's not obvious I don't know what would help to explain
(i.e. without going into micro-management explanations). - If yet you
haven't experienced a necessity for an alpha pattern for the value 0,
and since you're an experienced IT expert, I suppose it's okay for you
as it was. - When it had been introduced in our development standards
there was no second opinion. With C's primitive pointer concept we had
so often issues that it was helpful to quickly find them. The 'null'
we used was not the only convention, also suffixing pointer variables
with '_ptr' (or camel-case as 'Ptr' in C++) helped to quickly gain
insights, especially in (but not restricted to) code of others. Besides
bug-tracking we had also other QA measures like code inspections that
took advantage of more explicit naming supported by 'null' or '_ptr'.
We tried to express as much as possible ("as C allows") by conventions
and additions to a class library we were using. (Also things like the
elsethread disrespectfully mentioned 'true' and 'false' literals; but
since there was no first class boolean type as in more sophisticated
HLL of that time this could not address all issues; but at least make
the programmers' intention clearer - cf. false positives/negatives -
and bugs easier to find.)
Janis