C/C++ guidelines
 

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

Re: C/C++ guidelines
 

Robbie Marshall wrote:
> 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.

--
Ian Collins.

Re: C/C++ guidelines
 

In article <5l34ctF5ius4U21@mid.individual.net>,
Ian Collins <ian-news@hotmail.com> wrote:

>> 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.

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

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

Re: C/C++ guidelines
 

On 2007-09-15, Robbie Marshall <killspam@invalid.com> wrote:
> 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.

Re: C/C++ guidelines
 

* 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

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Re: C/C++ guidelines
 

On Sun, 16 Sep 2007 00:59:47 +0200, "Alf P. Steinbach"
<alfps@start.no> wrote:

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


K. H.

--

E-mail: info<at>simple-line<Punkt>de

Re: C/C++ guidelines
 

"Karl Heinze" <nomail@invalid> wrote in message
news:a40pe391298djdguiif7knr65tvcqombee@4ax.com...
> On Sun, 16 Sep 2007 00:59:47 +0200, "Alf P. Steinbach"
> <alfps@start.no> wrote:
>> [...] 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

Re: C/C++ guidelines
 

On Sat, 15 Sep 2007 18:14:30 -0700, "Chris Thomasson"
<cristom@comcast.net> wrote:

>
> 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[s] 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.

--

E-mail: info<at>simple-line<Punkt>de

Re: C/C++ guidelines
 

Richard Tobin wrote:
> In article <5l34ctF5ius4U21@mid.individual.net>,
> Ian Collins <ian-news@hotmail.com> wrote:
>
>>> 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.
>
> That's not enough: for example you need to avoid C++ keywords
> ("namespace" is one I've run into).

Is it safe to code in C89/90/94 (corrigenda) and compile, or better yet
lint as C++ AND C?
Is it the same labo[u]r as to to write in a common subset of British and
American and other flavo[u]rs of English?
--
Ark

Re: C/C++ guidelines
 

Robbie Marshall wrote:

> 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
http://www.oreilly.com/catalog/9780596510657/
"Test Driven Ajax (on Rails)"
assert_xpath, assert_javascript, & assert_ajax