C/C++ guidelines

[Robbie Marshall]

Hi groups,

I'm about to embark on a new project and for maximum portability we've
been asked to code it in the common subset of C and C++.

Can anyone suggest any good documents that might help us? Lists of
gotchas to avoid, that sort of thing?

TIA!

Robbie

 

[Ian Collins]

Hi groups,

I'm about to embark on a new project and for maximum portability we've
been asked to code it in the common subset of C and C++.

For maximum portability, code in C89.

If you aren't aware of the (sometimes subtle) differences between C and
C++ (even within the common subset), don't risk running into them! Even
when using the common subset, there are idiomatic differences between
the two.

 

[Richard Tobin]

I'm about to embark on a new project and for maximum portability we've
been asked to code it in the common subset of C and C++.

[/QUOTE]

For maximum portability, code in C89.

That's not enough: for example you need to avoid C++ keywords
("namespace" is one I've run into).

-- Richard

 

[rafaelc]

Hi groups,

I'm about to embark on a new project and for maximum portability we've
been asked to code it in the common subset of C and C++.

Can anyone suggest any good documents that might help us? Lists of
gotchas to avoid, that sort of thing?

Could you give us a little more context? Why do you want to program in the
subset of both languages? It seems to me that's a bit of a waste. You're trying
to write code in a language that's not really standard, if you want long term
comaptibility you should take a standardized language and go for it. If you're
willing to take a subset of C++ and C, you might as well just program in plain
C. If you need to you can easily import your C functions in C++ using extern
"C".

I don't really know how to answer your questions, i.e. I don't know any
documentation on writting code in a subset of C and C++. But I really feel you
should rethink what you want to do, and if you don't feel the same way I'm
really curious to know why you don't agree with me.

 

[Alf P. Steinbach]

* Robbie Marshall:

I'm about to embark on a new project and for maximum portability we've
been asked to code it in the common subset of C and C++.

Can anyone suggest any good documents that might help us? Lists of
gotchas to avoid, that sort of thing?

Coding in a common subset of C and C++ is a gotcha.

C and C++ are two different languages, where some constructs that are
valid in both mean different things. Recommended coding style therefore
differs. E.g, in C you should not cast the result of malloc, because
doing that might introduce subtle errors, while in C++ you must.

Inform your manager.

Cheers, & hth.,

- Alf

 

[Karl Heinze]

[...] in C you should not cast the result of malloc, because
doing that might introduce subtle errors [...]

For example?


K. H.

 

[Chris Thomasson]

[...] in C you should not cast the result of malloc, because
doing that might introduce subtle errors [...]

For example?

http://c-faq.com/malloc/mallocnocast.html

 

[Karl Heinze]

http://c-faq.com/malloc/mallocnocast.html

Thanx. Though I don't buy in that "argument".

Consider:

#include <stdio.h>

int main(void)
{
char *p = (char *) malloc(10);

return 0;
}

At least lcc-win32 DOES warn you: "Missing prototype for 'malloc'.

Same with Pelles C: "Missing prototype for 'malloc'".

Same with gcc: "implicit declaration of function 'malloc'".


So _my_ "A:" is: There's NOTHING wrong with casting malloc's return
value. (But don't forget to include <stdlib.h>, man!)

Moreover: From the answer in the FAQ I deduce that the claim

"... in C you should not cast the result of malloc,
because doing that might introduce subtle errors [...]"

is simply wrong: It's not the usage of the cast (as such) which "might
introduce subtle errors. Not including <stdlib.h> is what actually
might introduce subtle errors - but (as it seems) most modern
compilers would catch that lapse (and produce a warning).


K. H.

 

[Ark Khasin]

For maximum portability, code in C89.

That's not enough: for example you need to avoid C++ keywords
("namespace" is one I've run into).[/QUOTE]

Is it safe to code in C89/90/94 (corrigenda) and compile, or better yet
lint as C++ AND C?
Is it the same labor as to to write in a common subset of British and
American and other flavors of English?

 

[Phlip]

I'm about to embark on a new project and for maximum portability we've
been asked to code it in the common subset of C and C++.

For maximum portability, write unit tests for all your code. Then you can
run the tests on each target platform.

For _real_ portability (not just "tell our boss we are portable"
portability), you could configure a test server on each target platform. Run
the test suite each time you integrate, automatically on each platform.
Configure them to e-mail all the developers if the tests break on any
platform.

Yes, I've done this before...

 

[Phlip]

I think the common subset of c and c++ is empty, because if you do malloc
then yikes and if you don't malloc, well that's not much of a program is
it.

Actually I haven't done the Common Subset thing.

But (char*)malloc(..) is well-formed C++ (with appropriate substitution for
....). Don't sweat the details; portability is up to your compiler(s).

 

[CBFalconer]

[...] in C you should not cast the result of malloc, because
doing that might introduce subtle errors [...]

For example?

Failure to #include <stdlib.h> going undetected.

 

[CBFalconer]

Actually I haven't done the Common Subset thing.

But (char*)malloc(..) is well-formed C++ (with appropriate
substitution for ...). Don't sweat the details; portability is up
to your compiler(s).

And it is execreble dangerous coding in C. The languages are
different. This is c.l.c, and c.l.c++ is a separate newsgroup
dealing with a separate language. F'ups set.

 

[Wade Ward]

For maximum portability, write unit tests for all your code. Then you can
run the tests on each target platform.

For _real_ portability (not just "tell our boss we are portable"
portability), you could configure a test server on each target platform.
Run the test suite each time you integrate, automatically on each
platform. Configure them to e-mail all the developers if the tests break
on any platform.

Yes, I've done this before...

I think the common subset of c and c++ is empty, because if you do malloc
then yikes and if you don't malloc, well that's not much of a program is it.

 

[Flash Gordon]

Ark Khasin wrote, On 16/09/07 02:40:

Is it safe to code in C89/90/94 (corrigenda) and compile, or better yet
lint as C++ AND C?

No. Since some code which is well formed in both languages will do
different things in the two languages. We have has some such examples
posted in comp.lang.c in the past week.

Is it the same labor as to to write in a common subset of British and
American and other flavors of English?

The common subset changes.

 

[Keith Thompson]

I'm about to embark on a new project and for maximum portability we've
been asked to code it in the common subset of C and C++.

Can anyone suggest any good documents that might help us? Lists of
gotchas to avoid, that sort of thing?

Consider programming in C90 and making sure not to accidentally use a
C++ compiler. You can enforce this with:

#ifdef __cplusplus
#error "Use a C compiler, not a C++ compiler"
#endif

 

[Peter J. Holzer]

And it is execreble dangerous coding in C.

Whether that's "execreble dangerous" depends on your compiler. If
malloc has been declared, it's not dangerous, merely superfluous and
ugly. If malloc hasn't been declared, a good compiler should complain
with or without the cast.

hp

 

[Peter J. Holzer]

Thanx. Though I don't buy in that "argument".

Consider:

#include <stdio.h>

int main(void)
{
char *p = (char *) malloc(10);

return 0;
}

At least lcc-win32 DOES warn you: "Missing prototype for 'malloc'.

Same with Pelles C: "Missing prototype for 'malloc'".

Same with gcc: "implicit declaration of function 'malloc'".

Once upon a time most compilers didn't warn about missing prototypes but
they did warn about conversions from int to a pointer. In these days not
casting malloc was the most reliable way to catch a missing declaration
of malloc.

Today I would advise anybody who's using such a compiler to get a
better one.

So _my_ "A:" is: There's NOTHING wrong with casting malloc's return
value. (But don't forget to include <stdlib.h>, man!)

There is STILL something wrong with casting malloc's return value: It is
unnecessary and clutters up the code. Also it gets you into the bad
habit of inserting unnecessary casts which *will* hide subtle errors.

hp

 

[Joachim Schmitz]

Whether that's "execreble dangerous" depends on your compiler. If
malloc has been declared, it's not dangerous, merely superfluous and
ugly. If malloc hasn't been declared, a good compiler should complain
with or without the cast.

a diagnostic is not required by the standared for an implicit declared
function
without the cast and in absence of a prototype the compiler has to assume
int. Assiging an int to a pointer ist a constraint violation (6.5.16.1-1)
and as such requires a diagnostic (5.1.1.3-1)

While indeed a good compiler might warn about the missing prototype, even a
not so good one has to warn about the incompatible types in assignement (if
not it's a bad and non-conforming one). The latter doesn't happen if there's
a cast, hence not using the cast is the safer bet.

Bye, Jojo

 

[Joachim Schmitz]

Once upon a time most compilers didn't warn about missing prototypes but
they did warn about conversions from int to a pointer. In these days not
casting malloc was the most reliable way to catch a missing declaration
of malloc.

Because they are required to do diagnose the conversionm and free to do do
the same with the missing prototype

Bye, Jojo