Casting the return value of malloc() ?

[Ian Collins]

CBFalconer said:


No, we don't. We want a clear delineation between the two languages.


At the cost of introducing a syntax error into the C code, protected by the
flimsiest of defences.

Tell that to just about every platform's standard library writers and
give then a good laugh.

 

[Ian Collins]

If the code is legal C and legal C++, it will either be bad C, bad C++, or
both. Daft idea. Silly to pander to daft ideas. Harumph, etc.

This is your blinkered view, not fact. Some of us have good technical
reasons to compile some of our C with a C++ compiler.

 

[Ian Collins]

But why should the C be uglified with a C++ construct?

Because library writers want their headers to be useful?

How often do you read system headers?

 

[Keith Thompson]

But why should the C be uglified with a C++ construct?

For the reasons I stated above.

Implementations of the standard C headers are already quite ugly on
most systems.

 

[CBFalconer]

CBFalconer said:

No, we don't. We want a clear delineation between the two languages.


At the cost of introducing a syntax error into the C code,
protected by the flimsiest of defences.

No. Protected by the fact that the C standard (the present one,
for C99) specifies that the implementation must not define
__cplusplus. I believe that that name was picked only after
considering as many C compilers as possible, and it was determined
that the requirement would not conflict in any known extant C90
compilers.

 

[CBFalconer]

For the reasons I stated above.

Implementations of the standard C headers are already quite ugly
on most systems.

I see no C++ construct in:

#ifdef __cplusplus
/* something */
#endif

 

[CBFalconer]

This is your blinkered view, not fact. Some of us have good
technical reasons to compile some of our C with a C++ compiler.

Why? A C compiler is smaller, and more accurate for compiling C
code. No C++ compiler is needed.

 

[Ian Collins]

Why? A C compiler is smaller, and more accurate for compiling C
code. No C++ compiler is needed.

As I've posted before; I use C++ simulations of hardware to test driver
code. I use typedefs to integer types for registers when compiling in C
for target hardware and C++ classes when compiling as C++ on my
development host. The C++ classes are used to simulate the hardware
behaviour and interface with the test harness when the registers are
read from or written to.

If there was a way to do this in C, I would use C, but there isn't. The
utility of the technique more than justifies the compromises in the C code.

 

[James Kuyper]

Richard Heathfield wrote:
....

Do you know that one won't be released tomorrow, with such fantastic
compensating advantages that everyone flocks to it despite its strident
approach to __cplusplus?

I'd expect such a "strident approach" to be anti-correlated with the
attitudes needed to produce a compiler with "fantastic compensating
advantages".

 

[Nick Keighley]

This is your blinkered view, not fact.  Some of us have good technical
reasons to compile some of our C with a C++ compiler.

hallelujah!
Richard is inhabiting a bizzare parallel universe on this one

 

[Ian Collins]

Ian Collins said:


NO, sir! It's my blinkered view, AND fact!


I've never heard a convincing reason for doing this - including P J
Plauger's reason. But of course I respect your choice. And so, it appears,
do implementers!

What isn't convincing about my main reason?

 

[Ian Collins]

Ian Collins said:


Well, I certainly wouldn't do it that way. If I have understood you
correctly, you're using one set of code for development, and a very
different set of code (and indeed a different language!) for testing.

Not different code, same code, different types for some bits of hardware
along the lines of:

#if defined __cplusplus

struct StatusRegister
{
/* Handle writes
*/
StatusRegister& operator=( uint8_t );

/* Handle reads
*/
operator uint8_t() const;
};

#else

typedef uint8_t StatusRegister;

#endif

Although in practice I'd split the header into C and C++ versions.

All the rest of the code is unchanged. I adopted this technique to
avoid having code littered with ugly #ifded TEST block I've seen
elsewhere. I believe the code under test should be the code used in
production and that the code should be as free of conditional compiles
as possible. I hate conditional compile blocks, they destroy the flow
when reeding code.

Okay, I'm not going to say it was a bad decision, but it does go against
what I would consider to be good test design principles.

There's more than one level of testing. My unit tests don't use C++ for
the target code. Hardware registers are just a block of memory shared
by the target code and the test harness. The C++ trickery is used for
simulations.

 

[Nick Keighley]

Ian Collins said:

<snip>

[using C++ to emulate hardware]

Well, I certainly wouldn't do it that way. If I have understood you
correctly, you're using one set of code for development, and a very
different set of code (and indeed a different language!) for testing.
Okay, I'm not going to say it was a bad decision, but it does go against
what I would consider to be good test design principles.

I believe he's talking about using C++ to emulate hardware.
This means a large chunk of the software can be tested
without specialist hardware. And with superior debugging
facilities.

With really specialised hardware the hardware may not exist
when the software development starts.

Some peripherals may be expensive, power hungry physically large
or massive (I've worked with power amplifiers that filled a room).

 

[Ian Collins]

Ian Collins said:

<snip>

[using C++ to emulate hardware]

Well, I certainly wouldn't do it that way. If I have understood you
correctly, you're using one set of code for development, and a very
different set of code (and indeed a different language!) for testing.
Okay, I'm not going to say it was a bad decision, but it does go against
what I would consider to be good test design principles.

I believe he's talking about using C++ to emulate hardware.
This means a large chunk of the software can be tested
without specialist hardware. And with superior debugging
facilities.

With really specialised hardware the hardware may not exist
when the software development starts.

Some peripherals may be expensive, power hungry physically large
or massive (I've worked with power amplifiers that filled a room).

In my case it was power supplies that can fill a room - with smoke if
you drive them incorrectly!

 

[David Thompson]

On Sat, 4 Oct 2008 19:13:48 +0100, "Malcolm McLean"

Now one good question is why use C at all when C++ is a near as makes no
difference a superset of it? However let's say that we decide that we want
to discourage people from using object-orientation, because of certain
drawbacks we see in the methodogy. A politically effective way of doing this
is to ban C++.

OK, so here's a fragment of our C program

void encrypt(unsigned char *data, size_t len)
{
int i;

May be unsafe/wrong depending on range of size_t.

for(i=0;i<len;i++)
data ^= 0xCC;

Constraint violation. Presumably you meant data.

}

A few weeks later, the terrible news come through. Our encryption has been
compromised. We need a beter method, and fast.

weeks? sci.crypt can do that for you in barely a minute or two.

So we dust off our Sedgewick and realise that there is somethign called the
RSA cryptosystem. This is very much better, and it is not too difficult to
implment, as long as you have a huge integer library. Well we've got one,
but it's in C++.

No problem. Change the file extension to .cpp, and drop in

void encrypt(unsigned char *data, size_t len)
{
bignum prime1(13);
bignum prime2(17);
bignum unfactorisable = prime1 * prime2;

Those numbers aren't nearly big enough to be secure. More to the
point, no numbers representable as integer literals (even long long)
on any likely implementation will be. Plus the 'naive' RSA encryption
primitive often shown in textbooks, just data up pubexpt mod modulus,
can be insecure in other ways. And even after you get a good design,
_coding_ secure crypto code in most environments requires techniques
not commonly used, or known, for ordinary code. So you are almost
always better off using an established crypto library, which are
available for both C and C++ among others, than writing your own.

/* (etc) */
}

Now we're back in business. Nothing else needs to be changed. We've dropped
in an emergency C++ bignum library and the code is now C++ and won't compile
under C, but that is small price for turning out our improved encryption on
time.

See above.
- formerly david.thompson1 || achar(64) || worldnet.att.net

 

[Old Wolf]

This is your blinkered view, not fact.  Some of us have good technical
reasons to compile some of our C with a C++ compiler.

And those reasons are?

 

[Ian Collins]

And those reasons are?

If you read my responses elsewhere (my last couple of responses to
Richard H.) in this thread, you'll see.

 

[Old Wolf]

If you read my responses elsewhere (my last couple of responses to
Richard H.) in this thread, you'll see.

I guess you are referring to the following:

The first C code I ever built C as C++ as a device driver. In C,
hardware registers were typedefs to an integer type. In C++ the
register types were classes that simulated the hardware behaviour when
read a written. I still use this technique today for testing drivers.

Well: the first sentence doesn't even make sense,
so I don't know what you're talking about there.
From the rest of the paragraph it sounds like you
are taking the idea of a macro kludge to the extreme.
Instead of a
#define something some_debug_thing

you compile the source in a different language
where 'something' means 'some_debug_thing' !

I have a pretty dim view of a test environment
where you aren't even using the same language
as the live environment. Certainly qualifies
as 'stupid' in my book (Your mileage varies, obviously).

We also compiled application code as C++ to get stricter type checking,
but C compilers and lint have improved considerably in this area.

Also stupid. C has type checking rules. You should
conform to C type checking rules when writing C.
I suspect people who make this claim are just writing
dreadful code in the first place.

 

[Ian Collins]

I guess you are referring to the following:


Well: the first sentence doesn't even make sense,
so I don't know what you're talking about there.
From the rest of the paragraph it sounds like you
are taking the idea of a macro kludge to the extreme.
Instead of a
#define something some_debug_thing

you compile the source in a different language
where 'something' means 'some_debug_thing' !

Well it's pretty clear you either you don't understand the concept of a
simulation.

I have a pretty dim view of a test environment
where you aren't even using the same language
as the live environment. Certainly qualifies
as 'stupid' in my book (Your mileage varies, obviously).

You obviously don't understand testing. If you'd read the part you
snipped you'd have seen how we did our testing.

Also stupid. C has type checking rules. You should
conform to C type checking rules when writing C.
I suspect people who make this claim are just writing
dreadful code in the first place.

Your English comprehension is either lacking of you are being
deliberately obtuse. Note the past tense.

 

[Nick Keighley]

Old Wolf wrote:
Richard Heathfield wrote:
If the code is legal C and legal C++, it will either be bad C, bad C++, > >>>>> or both. Daft idea. Silly to pander to daft ideas. Harumph, etc.

[...] you are taking the idea of a macro kludge to the extreme.

[...] Certainly qualifies
as 'stupid' in my book (Your mileage varies, obviously).
Also stupid.

[...]

I suspect people who make this claim are just writing
dreadful code in the first place.

it's the attitude that "someone who doesn't do it the same way as me
is stupid" that gets up my nose. Unless he's trolling.