Sujet : Re: Naming conventions (was Re: valgrind leak I can't find)
De : janis_papanagnou+ng (at) *nospam* hotmail.com (Janis Papanagnou)
Groupes : comp.lang.cDate : 23. Aug 2024, 16:10:12
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vaa8ol$v263$1@dont-email.me>
References : 1 2 3 4 5 6
User-Agent : Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
On 22.08.2024 16:01, Thiago Adams wrote:
C++ also made the use of "struct/union/enum" before tags optional.
For example:
struct X x;
In C++, we can write:
X x;
Yes, because it's the "natural" form of a 'Type entity;' declaration.
With a 'class Player;' we write 'Player p;' as we do with an 'int i;'
I don't think it would be a good idea to have to write 'class Player p;'
or 'struct Player p;'. (Mileages may vary.)
In C++ the C's special type 'struct' has been merged in a generalized
form of type, a 'class'.
It may be different for the inherited unions or enums, but anyway...
If I declare a type and give it a name I want to refer to it by that
name in object declarations and not repeat (unnecessary) keywords.
(That's what I'm used to also from other programming languages.)
Consequence?
(C has to struggle with its own inconsistencies since ever. Whether
some C++ language design conventions backfire to C... - well, hard to
tell. I don't think we can clearly deduce or prove any such (social)
effects; at least I cannot.)
Programmers started using a suffix "C" for classes and "E" for enums.
For example:
CArray array;
EType type;
Yes, I'm well aware of some folks doing so. (That's one point I have
expressed in my previous post. Yet I don't see any advantage in doing
so and haven't heard any substantial rationale for that.)
In C, we have a similar situation where it's sometimes unclear where a
variable comes from.
Consider this code:
void f(int arg1){
i = 2;
}
This can happen with external variables.
For instance:
int i;
void f(int arg1){
i = 2;
}
In this situation, I use a prefix "s_" for the variable, like this:
int s_i;
I'd most likely pass the value through a well defined interface
in such cases; either use (here) the unused function return value,
or add a function argument and pass '&i' to set '*iptr=2' instead
of relying on side-effects accessing global variables, or in more
complex application data cases add a function parameter-object.
Preferences vary, of course, also depending on context.
Janis