Re: why still use C?

From: Sidney Cadot (sidney_at_jigsaw.nl)
Date: 10/18/03 

Date: Sat, 18 Oct 2003 23:04:51 +0200

CBFalconer wrote:

> Sidney Cadot wrote:
>
>>CBFalconer wrote:
>>
>> > [[ casting malloc() results ]]
>>
>>
>>>>Why is it considered "bad practice"? I know it is frowned upon
>>>>sometimes, but I fail to see the rationale for that.
>>>>
>>>>One advantage of casting malloc() results is that, like you say,
>>>>one has a fighting chance of getting a clean (error/warning-less)
>>>>compile using C++ in addition to getting a clean compile in C.
>>
>>>It can hide errors that the compiler could otherwise pick up. It
>>>prevents controlling the type of that object in only one place,
>>>and having all other code slaved to that.
>>
>>Could you provide examples? I'm sure there are, but it's a lot easier to
>>discuss this over an example for me.
>
>
> typedef struct foo {
> ....
> } foo, *foop;
> ....
> foop barp;
> ....
> barp = malloc(count * sizeof *barp)
>
> (which you can handle slighly differently if you don't approve of
> typedefing structures.) At any rate, I can control what a foo (and
> a foop) is in just one place, without needing to alter any other
> code. I can also hide that definition in one module and export
> only the foop type by slight changes in the declaration method.
> Again, the rest of the code does not change.

How does all this keep you from writing this:

{
   foop barp;
   barp = (foop)malloc(count * sizeof *barp);
}

Only a name change of foop would be a slight hassle I think? I don't
quite see what changing the definition of the foo struct has to do with
casting the malloc result.

>>>Casts are fundamentally evil things, and very often serve only to
>>>conceal errors.
>>
>>'fundamentally evil things' ... that's a bit harsh isn't it?
>>
>>It would make an interesting exercise to write low-level C code (e.g.,
>>kernels or device drivers), without casts. Are you suggesting this is
>>practical?
>
>
> Certainly there are places where casts are needed. But they
> should never be used without a clear understanding of their
> purpose. "shutting up compiler complaints" is not a valid
> reason.

I agree insofar as that a compiler warning is an indication (symptom) of
an actual or potential problem, and that you should take care to solve
the problem instead of just curing the symptom.

As to whether "shutting up compiler complaints" is not a valid reason,
ever, I would hesitate to make this a dogma.

> Code written without casts is much more likely to be bugfree.

Sure, but that's also in large part because the type of code that really
*needs* casts tends to solve complicated problems.

>>>I have yet to see a C++ compiler that does not have a C mode, and
>>>there is no problem linking C++ code with C code when the headers
>>>are properly designed.
>>
>>Sure, but I want to write C code, but sometimes compile the program with
>>a C++ compiler to use the extra checks as required by a C++ compiler,
>>for flagging potential problems - is that so strange?
>
> That is what lint, pclint, splint (nee lclint) are for. splint is
> also free. They are all much more picky than some nebulous C++
> compiler, which is written for a different standard.

What's so nebulous about a C++ compiler? These pick up some of my
mistakes that a C compiler misses, it works for me. I'm sure the *lints
are nice tools as well. Have heard some good and bad things about them,
must try for myself one of these days.

As long as they have a flag for not complaining about malloc result
casts ... ;-)

> Please do not strip attributions for quoted material. I think you
> stripped yourself in this case, but am not sure.

Sorry about that.

Best regards,

  Sidney Cadot

Relevant Pages

  • Re: Why wont the compiler tell??
    ... >} foo; ... > Why can I not execute a statement like: ... > the compiler knows quite well what the answer to what I am asking. ...
    (comp.lang.cpp)
  • Why wont the compiler tell??
    ... Why can I not execute a statement like: ... the compiler knows quite well what the answer to what I am asking. ...
    (comp.lang.cpp)
  • Re: Why wont the compiler tell??
    ... > Why can I not execute a statement like: ... > the compiler knows quite well what the answer to what I am asking. ... size_t x = sizeof foo.b; ...
    (comp.lang.cpp)
  • Re: a case for multiple inheritance
    ... and overrides the write functions to change ... the compiler would optimize it so that the double function call would be ... private new void Foo ... The cast not much ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: a case for multiple inheritance
    ... the compiler would optimize it so that the double function call would be ... private new void Foo ... The cast not much ... This means that if method A1 overrides ...
    (microsoft.public.dotnet.languages.csharp)