which of these 3 casts would you prefer?

[BGB]

The problem with -Wold-style-cast, in my experience, is that
system/library headers are often chock-full of C-style casts,
resulting in huge quantities of warnings over which one has no
control...

well, as well as any code which is designed to work if compiled as
either C or C++ (potentially including static-inline functions in
headers, ...).

any such code would likely necessarily reflect the common subset of C
and C++, which would mean C-style casts.

 

[Juha Nieminen]

but, it is common practice, no different from a manual transmission, or
filling out and filing paperwork, ...

well, as noted, it is not C's job to be programmer friendly.

I think these summarize perfectly the kind of mentality that the
language produces, and the reason why I hate the language so much.

C++ might not be as "programmer friendly" as many other high-level
languages, but at least it offers significantly more tools to aid the
programmer *without* the compromises of those higher-level languages
(such as increased memory consumption or the requirement of a very
complex runtime environment and JIT compiler to make the program even
acceptably fast, and which often do not exist in most systems, especially
the embedded ones.)

If someone wants to create big projects in C, even if C++ or other
languages would be perfecly good for the job, that's fine. However,
when these same people start preaching how the defects of the language
are "normal" and "not a big deal", rather than "yeah, it's bad, but you
just have to live with it", that's rationalizing.

 

[BGB]

How does that change what I said? It doesn't matter if it's allocated
and freed directly or via function calls. (Heck, malloc() and free() *are*
function calls.)

My point is that this manual construction/destruction requirement is
"inherited" by anything that wants to use those types. For example, if
you create a new struct that has such a type as a member, this struct
will now also have to be constructed/destructed manually, and so on.
The language offers no means to automatize and hide this in any way.

well, when you create the new type / structs and functions, you wrap the
old ones.

so, no big deal, one creates/destroys objects in a similar way,
regardless of how many levels are involved.

alternatively, one can treat them all as the root type by using function
pointers to handle the case of the destruction of subtypes:

struct FOO_SomeType_s {
void *data; //member
void (*deinit)(FOO_SomeType *self);
....
};

then:
void FOO_FreeSomeType(FOO_SomeType *self)
{
if(self->deinit)
self->deinit(self);
free(self);
}

in practice, it is all "not really a big deal".

for added safety though, one can use a garbage collector in place of
malloc/free, and give the GC the ability to call destructors, creating a
mechanism vaguely similar to Java's finalizer system.

Containers being homogeneous has nothing to do with genericness. A container
being generic means that you can use it with any type, rather than it being
fixed to a single hard-coded type, even if the container is homogeneous.

Even if the container is hard-coded for one single type, if that type
requires construction and destruction, it makes the implementation of the
container more complicated and more error-prone.

this seems like hair-splitting IMO.

only one of 2 possibilities exist:
the container is responsible for destroying its contents, in which case
it will do so;
it will not be responsible for doing so, and it will be the
responsibility of the client to destroy all container contents and then
destroy the container.


IMO probably one of the most common "containers" in C is the internally
linked-list (every member points to the next one) in which in the common
case destroying the container and destroying its contents are equivalent.

cur=first;
while(cur)
{
nxt=cur->next;
FOO_FreeFoo(cur);
cur=nxt;
}

Having to implement the same algorithms over and over has never been a
good programming practice. That's why generic programming is such a great
aid in this.

but, it is common practice, no different from a manual transmission, or
filling out and filing paperwork, ...


like "just do it", "doesn't matter if it is clean or elegant, just make
it work", ...

You see, these coding conventions exist solely because of the deficiencies
of the language, rather than because they are good programming practices.
With RAII they become unneeded, and the resulting code becomes simpler,
more straightforward and easier to read.

well, as noted, it is not C's job to be programmer friendly.

usually, it is used for things like implementing back-end libraries,
often with the front-end application-development done in a different
language, for example: C++, Java, C#, Ruby, Python, Lua, or some other
custom-designed language.


but, one may develop their libraries in C, since it may not be known in
advance which language may need to interface with the library code, and
in most ways C is the least common denominator (and for many types of
library, using C++ will not bring so much benefit internally if the
external API has to be C-like anyways).

 

[Jorgen Grahn]

The problem with -Wold-style-cast, in my experience, is that
system/library headers are often chock-full of C-style casts,
resulting in huge quantities of warnings over which one has no
control...

Haven't seen that happen yet. Either the warning is suppressed when
generated by a system header, or the ones I use (on Linux) happen to
be clean.

If I end up in that situation, of course I'll have to disable the
warnings for the affected translation units.

/Jorgen

 

[Joshua Maurice]

Haven't seen that happen yet. Either the warning is suppressed when
generated by a system header, or the ones I use (on Linux) happen to
be clean.

If I end up in that situation, of course I'll have to disable the
warnings for the affected translation units.

I seem to recall some gcc command line option which is on by default
to disable warnings for system headers.

 

[gwowen]

I seem to recall some gcc command line option which is on by default
to disable warnings for system headers.

Unsuprisingly, its -Wno-system-headers, and as you say, the default is
to suppress them.

 

[Keith H Duggar]

because then I would have to port all that assembler between the various
targets platforms...

"however, it could be argued that *not* having to write duplicated
code in this case is what is nifty/convinient/..." C is just nifty
syntax sugar over assembly.

;-)

however, ASM can also be a little verbose at times.

Compared to MyFooLib_MyContainerStuff_IsHashEmpty?

yes, people so much commenting "well I don't have to do X
manually", but what really is the big deal?...

*sigh* How is it that you do you appreciate the basic value of
standardization and/or automation? Or are you just playing dumb
for the sake of tedium?

KHD

 

[Jorgen Grahn]

whether or not it is pretty is a much lesser concern though than whether
or not one is liable to have a name clash.

My reply is late, but I need to explain that IMO, readability (here
via short and in their context relevant names) is *not* about
prettiness. After correctness, it's the most important aspect of the
code.

/Jorgen