Sujet : Re: valgrind leak I can't find
De : bluemanedhawk (at) *nospam* invalid.invalid (Blue-Maned_Hawk)
Groupes : comp.lang.cDate : 24. Aug 2024, 12:47:02
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <pan$8db48$12dfbf80$ce60889d$2a8f67fc@invalid.invalid>
References : 1 2 3 4
User-Agent : Pan/0.154 (Izium; 517acf4)
Annada Behera wrote:
On Thu, 2024-08-22 at 08:18 -0300, Thiago Adams wrote:
>
<snip/>
C++ made the usage of 'this->' optional when calling member functions.
As a result, when C++ programmers encounter 'i' in the middle of a
function, they might not know where it comes from.
If 'this->' were not optional, 'this->i' would clarify that.
To avoid confusion, many C++ programmers use prefixes like 'm_' that
can't be ignored.
Since many C programmers also work in C++, this pattern can sometimes
influence C code as well.
Although I think this is stupid thing to do when writing C, the same
convention also exits in Python PEP-8 [1]
_single_leading_underscore: weak “internal use” indicator. E.g. from
M import * does not import objects whose names start with an
underscore.
[1]: https://peps.python.org/pep-0008/#descriptive-naming-styles
That's an entirely different convention that is much more common cross-
linguistically. I've seen a good bit of C code that's used that for
various parts of interfaces that need to be given separate names, but
aren't meant to be used directly, such as identifiers constructed in the
expansion of a macro. I've personally taken to the habit of naming macros
used exclusively to get other macros to work with the name of the macro
they're making work prefixed by a number prefixed with an underscore.
-- Blue-Maned_Hawk│shortens to Hawk│/blu.mɛin.dʰak/│he/him/his/himself/Mr.blue-maned_hawk.srht.siteMade with inadequate loophole sealant!