Common problems with C
Bart v Ingen Schenau
At the moment I am updating the company's coding standard.
The intention of this document is to identify those areas of the C language
where problems most often occur, and to indicate means of avoiding those
problems.
In view of this, I have some questions
1. What features/constructs do you know of that are often differently
interpreted by programmers and/or compilers?
2. What major bugs, that influence the portability of programs, in many
and/or popular compilers do you know of and what is the usual work-aroud for
these bugs?
Bart v Ingen Schenau
--
comp.lang.c.moderated - moderation address: cl...@plethora.net
-hs-
news:clcm-2001...@plethora.net:
> Hello all,
>
> At the moment I am updating the company's coding standard.
Some good stuff here:
http://www.msu.edu/user/pfaffben/writings/blp-stds/blp-stds.html
> 1. What features/constructs do you know of that are often differently
> interpreted by programmers and/or compilers?
Endianness
Data type ranges
Structure padding
Negative integer representation
Floating point representation
--
-hs- emdel at noos.fr "support Afghans against Taleban"
"Car les bandits qui sont cause des guerres
N'en meurent jamais, on n'tue qu'les innocents."
Gaston Montéhus -- La Butte Rouge
Richard Norman
<Bart.van.In...@ict.nl.invalid> wrote:
>Hello all,
>
>At the moment I am updating the company's coding standard.
>The intention of this document is to identify those areas of the C language
>where problems most often occur, and to indicate means of avoiding those
>problems.
>In view of this, I have some questions
>
>1. What features/constructs do you know of that are often differently
>interpreted by programmers and/or compilers?
>
>2. What major bugs, that influence the portability of programs, in many
>and/or popular compilers do you know of and what is the usual work-aroud for
>these bugs?
>
>Bart v Ingen Schenau
Identifying problems is one thing. Trying to enforce standards to
eliminate them is another. Here are some common problems:
Wrong assumptions about operator precedence:
if (value&mask == 0x04) ...
Indenting doesn't agree with real scope of blocks
if (a==b)
do this;
and that; // always gets executed
if (a==b)
do this;
if (c==d)
do that;
else
do the other; // associated with wrong if
Redefining variables with the same name
int i = 4;
for (j=0; j<10; ++j) {
int i = 0; // I really didn't mean this
do a bunchof stuff;
if (i==j) // I really meant the i with value 4
stuff;
}
Confusing assignment and equality test
if (i=0)
do stuff;
Of course a BIG thing is overwriting arrays:
strcpy(dest, source); // source is really really big
gets(s); // user typed 5000 characters before "enter"
Portability issues often overlooked include assumptions
on sizeof(int) (or of other data types), packing of data
structures, incompatibility between "standard" data
types like time_t values, byte order in data structures.
A really serious problem is failure to allow for
internationalization: assuming all strings are ASCII,
hard coding English strings into code, not allowing
for different representations of numbers and dates.
CBFalconer
>
> Hello all,
>
> At the moment I am updating the company's coding standard.
> The intention of this document is to identify those areas of the C
> language where problems most often occur, and to indicate means of
> avoiding those problems.
> In view of this, I have some questions
>
> 1. What features/constructs do you know of that are often
> differently interpreted by programmers and/or compilers?
Off the top of my head I would say ban use of gets, strtok, and
fscanf and friends. Ban use of non-standard functions except in
carefully isolated areas. Insist on full parenthization of
expressions, only assuming (multiplicative > additive > logical)
relative precedences. Ban hungarian notation. Do insist that
pointer identifiers end in p or ptr. Treat all casts with great
suspicion, and ban casting the result of malloc. Insist that
lines do not exceed 72 chars. Insist that functional macros wrap
each use of their arguments in parentheses. Look closely at any
function that exceeds one screenful. Mark as many functions as
possible static in any given file.
For a start :-)
--
Chuck F (cbfal...@yahoo.com) (cbfal...@XXXXworldnet.att.net)
(Remove "XXXX" from reply address. yahoo works unmodified)
mailto:u...@ftc.gov (for spambots to harvest)
Mark Weaver
result?
"CBFalconer" <cbfal...@yahoo.com> wrote in message
news:clcm-2001...@plethora.net...
Kalle Olavi Niemitalo
> 1. What features/constructs do you know of that are often differently
> interpreted by programmers and/or compilers?
Some compilers allow enumerators and sizeof in #if expressions.
John Hascall
[several reasonable suggestions, then...[
>Do insist that pointer identifiers end in p or ptr.
Ick.
int main (int argc, char ** argPtrPtr) {...} ????
> Insist that lines do not exceed 72 chars.
What about column 6?!?
In addition:
1) No old-style function declarations.
2) Always:
if (cond) statement;
Or:
if (cond) {
statement;
:
}
Never:
if (cond)
statement;
3) Always protect include files with #ifndef FOO/#define FOO/.../#endif
4) Everytime you think "my what a clever boy am I" you owe us a comment
(if not a rewrite).
5) Put the debug code in from the start.
6) Check return codes!
(void)close(fd); /* this sucks! */
7) use a source-code-control system
8) all arrays are suspect
9) every bug gets a test
10) you can use a general solution specifically,
but not vice-versa
John
--
John Hascall (__) Shut up, be happy.
Software Engineer, ,------(oo) The conveniences you demanded
Acropolis Project Manager, / |Moo U|\/ are now mandatory.
ISU Academic IT * ||----|| -- Jello Biafra
Richard Heathfield
>
> I doubt malloc() is going to be a whole heap of use if you can't cast the
> result?
What on earth makes you think that? Casting the result of malloc is
unnecessary in C, and malloc itself is unnecessary in C++, so it is
never necessary to cast malloc.
<snip>
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
CBFalconer
Yes it is, because it returns a void*, which is compatible with
any other pointer type. If left to itself the compiler will do
the right thing. If you tell it to foul up it will foul up and
may will bite you.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@XXXXworldnet.att.net)
Available for consulting/temporary embedded and systems.
Robert O'Dowd
>
> I doubt malloc() is going to be a whole heap of use if you can't cast the
> result?
>
In C, void * (the return type from malloc) can be implicitly converted
to any other pointer type. i.e. an explicit typecast is not required.
In C++ code, an explicit cast is required. If you expect to compile
your C code with a C++ compiler, you need to cast the result of
malloc(). [Of course, in idiomatic C++ code, malloc would not be
used at all].
IIRC, in older (prestandard) versions of C, malloc() returned a char *,
which needed to be explicitly typecast.
Martin Ambuhl
>
> I doubt malloc() is going to be a whole heap of use if you can't cast the
> result?
There is hardly any part of this that stands up to scrutiny.
1) You _can_ cast the result, but
2) Casting it is completely unnecessary and unwise.
What the heck did you think you meant?
Mike Wahler
>I doubt malloc() is going to be a whole heap of use if you can't cast the
>result?
Quite useful. No need to cast. (And doing so is a bad idea).
#include <stdio.h>
#include <stdlib.h>
int main()
{
size_t i = 0;
int *p = malloc(5 * sizeof *p);
if(p == NULL)
{
printf("allocation failure\n");
return EXIT_FAILURE;
}
for(i = 0; i < 5; ++i)
p[i] = i;
for(i = 0; i < 5; ++i)
printf("p[%lu] = %d\n", i, p[i]);
printf("Look Ma, no casts!\n");
free(p);
return EXIT_SUCCESS;
}
'void*' implicitly converts to any other
pointer type with no problems, and well-defined
behavior.
-Mike
Dave Shawley
>
The one that I have been noticying a lot lately is that most programmers
don't understand signed/unsigned comparisons. I've been seeing a lot of
code like the following from new graduates.
unsigned long aNumber;
unsigned long anotherNumber;
if ((aNumber - anotherNumber) < 0)
{
/* blah */
}
It will usually work fine under a PC simulator and then fail on the
target platform (we do embedded systems work). Msot PC compilers will
(and can) extend the unsigned long (usually 32 bits) to a long long
(usually 64 bits) and perform the math in signed mode. However, our
little embedded targets rarely support 64 bit arithmetic so the result
is undefined...
--
------------------------------------------------------------------------
Dave Shawley Embedded Software Engineer
daves...@home.com Digital Video Arts, Ltd.
"More computing sins are committed in the name of efficiency (without
necessarily achieving it) that for any other single reason --
including blind stupidity." -- W.A. Wulf
------------------------------------------------------------------------
James Dennett
> I doubt malloc() is going to be a whole heap of use if you can't cast the
> result?
On the contrary; in C, you should never cast the result
of malloc. It's a (void*) which implicitly converts to
any pointer type you care to mention.
-- James Dennett
Kalle Olavi Niemitalo
> I doubt malloc() is going to be a whole heap of use if you can't cast the
> result?
int *p = malloc(sizeof *p);
Not all conversions need casts.
bliss
article <clcm-2001...@plethora.net>...
> I doubt malloc() is going to be a whole heap of use if you can't cast the
> result?
>
pointer type
without a cast. Adding the cast can cause errors. Maybe you were thinkng
of some language other than "C"? :-)
<snip>
>>and ban casting the result of malloc.
Roger...
Walter Mallory
>Bart v Ingen Schenau wrote:
>>
>Insist that lines do not exceed 72 chars.
Ick. Buy yourself a better editor, monitor, or printer (or all three).
Set the max characters on a line to the max you can live with on a
printed page. I happen to use 120 characters for US A size (8.5x11)
paper. This also allows for 100 lines per page which is convenient.
YMMV.
Anyone out there use B or even C size for printing listings? Just
curious.
--
Walter Mallory walter....@amsi-us.com
All opinions expressed are my own and not my employer's.
Kevin Lacquement
MW> I doubt malloc() is going to be a whole heap of use if you can't cast the
MW> result?
Why do you say that? If you remember to #include <stdlib.h>, malloc()
returns void *. A void * is automatically cast to the apropriate
pointer type, and casting it manually is an easy way to mask the fact
that you forgot to #include <stdlib.h>.
Cheers,
Kevin
--
He that breaks a thing to find out what it is has left the path of
wisdom -- Gandalf the Grey
Bart van Ingen Schenau
wrote:
>The one that I have been noticying a lot lately is that most programmers
>don't understand signed/unsigned comparisons. I've been seeing a lot of
>code like the following from new graduates.
>
>unsigned long aNumber;
>unsigned long anotherNumber;
>
>if ((aNumber - anotherNumber) < 0)
>{
> /* blah */
>}
>
>It will usually work fine under a PC simulator and then fail on the
>target platform (we do embedded systems work). Msot PC compilers will
>(and can) extend the unsigned long (usually 32 bits) to a long long
>(usually 64 bits) and perform the math in signed mode. However, our
>little embedded targets rarely support 64 bit arithmetic so the result
>is undefined...
In your example, the result is perfectly well defined. Both aNumber
and anotherNumber are unsigned long's, so the substraction is
performed with unsigned arithmatic, and the result is always a
positive number in the range of unsigned long.
The effect is that /* blah */ will never be executed.
>------------------------------------------------------------------------
> Dave Shawley Embedded Software Engineer
> daves...@home.com Digital Video Arts, Ltd.
Bart v Ingen Schenau
--
Remove NOSPAM to mail me directly
FAQ for clc: http://www.eskimo.com/~scs/C-faq/top.html
FAQ for acllc-c++: http://snurse-l.org/acllc-c++/faq
Thomas
news:clcm-2001...@plethora.net...
> Mark Weaver wrote:
[snip]
> IIRC, in older (prestandard) versions of C, malloc() returned a char *,
> which needed to be explicitly typecast.
> --
> comp.lang.c.moderated - moderation address: cl...@plethora.net
According to K&R2, void * replaced char * as the generic pointer type in
C89.
Just for the record ;)
Dan Pop
>In article <clcm-2001...@plethora.net>, cbfal...@worldnet.att.net wrote:
>>Bart v Ingen Schenau wrote:
>>>
>>Insist that lines do not exceed 72 chars.
>
>Ick. Buy yourself a better editor, monitor, or printer (or all three).
>Set the max characters on a line to the max you can live with on a
>printed page. I happen to use 120 characters for US A size (8.5x11)
>paper. This also allows for 100 lines per page which is convenient.
>YMMV.
The 72 chars limit was adopted precisely because YMMV. Text terminals
with 80 chars per line are still used and, if you restrict the length
of your lines to 72 chars, there is still some place for the '>'
quotation marks before the line overflows the hardware-imposed limit of
80.
Dan
--
Dan Pop
CERN, IT Division
Email: Dan...@cern.ch
Mail: CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
Mark McIntyre
Mallory) wrote:
>In article <clcm-2001...@plethora.net>, cbfal...@worldnet.att.net wrote:
>>Bart v Ingen Schenau wrote:
>>>
>>Insist that lines do not exceed 72 chars.
>
>Ick. Buy yourself a better editor, monitor, or printer (or all three).
I disagree. Lines longer than about 80 chars are inherently hard to
scan visually, even at 8 point (which is too small to sensibly read).
Why do you think that printed books are typically 6 inches wide or
less?
>Set the max characters on a line to the max you can live with on a
>printed page. I happen to use 120 characters for US A size (8.5x11)
>paper. This also allows for 100 lines per page which is convenient.
provided you don't mind going blind early...
>YMMV.
at least we both measure in miles....
>Anyone out there use B or even C size for printing listings? Just
>curious.
but whats B or C size? (rhetorical question). The only sizes that fit
my printers are A4 and A3. Or envelopes. Go on, print your listing on
envelopes, that will make the maintenance programmers adore you....
:->
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
Dan Pop
>The one that I have been noticying a lot lately is that most programmers
>don't understand signed/unsigned comparisons.
You are one of them, BTW :-)
>I've been seeing a lot of
>code like the following from new graduates.
>
>unsigned long aNumber;
>unsigned long anotherNumber;
>
>if ((aNumber - anotherNumber) < 0)
>{
> /* blah */
>}
>
>It will usually work fine under a PC simulator and then fail on the
>target platform (we do embedded systems work). Msot PC compilers will
>(and can) extend the unsigned long (usually 32 bits) to a long long
>(usually 64 bits) and perform the math in signed mode.
If they do that, they're hopelessly broken. When both operands are
unsigned long, the math is ALWAYS performed in unsigned mode.
The code you posted will NEVER work (i.e. execute /* blah */) on any
conforming implementation, regardless of the values of the two operands.
>However, our
>little embedded targets rarely support 64 bit arithmetic so the result
>is undefined...
Wrong again. The result is *always* defined. Unsigned arithmetic is
performed modulo the width of the operands, so 0ul - 1ul will give
ULONG_MAX.
Dan
--
Dan Pop
CERN, IT Division
Email: Dan...@cern.ch
Mail: CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
Igor Bukanov
> Mark Weaver wrote in message ...
>
>>I doubt malloc() is going to be a whole heap of use if you can't cast the
>>result?
>>
>
> Quite useful. No need to cast. (And doing so is a bad idea).
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main()
> {
> size_t i = 0;
> int *p = malloc(5 * sizeof *p);
>
> if(p == NULL)
> {
> printf("allocation failure\n");
> return EXIT_FAILURE;
> }
>
> for(i = 0; i < 5; ++i)
> p[i] = i;
>
> for(i = 0; i < 5; ++i)
> printf("p[%lu] = %d\n", i, p[i]);
that should be
printf("p[%lu] = %d\n", (unsigned long)i, p[i]);
because there is no garanty that size_t is the same as unsigned long...
Regards, Igor
Kalle Olavi Niemitalo
[ unsigned long - unsigned long ]
> Msot PC compilers will (and can) extend the unsigned long
> (usually 32 bits) to a long long (usually 64 bits) and perform
> the math in signed mode.
Uh... isn't that against the Standard?
Stuart L. Anderson
>>Set the max characters on a line to the max you can live with on a
>>printed page. I happen to use 120 characters for US A size (8.5x11)
>>paper. This also allows for 100 lines per page which is convenient.
> provided you don't mind going blind early...
I am 66 years old. So are my eyes. I avoid small fonts since I don't
want to go blind late!
--Stu
___________________________________________________________________
Stu Anderson stua...@drizzle.com Renton, Washington, USA
CBFalconer
>
> walter....@amsi-us.com (Walter Mallory) writes:
>
> >cbfal...@worldnet.att.net wrote:
> >
> >>Insist that lines do not exceed 72 chars.
> >
> >Ick. Buy yourself a better editor, monitor, or printer (or all three).
> >Set the max characters on a line to the max you can live with on a
> >printed page. I happen to use 120 characters for US A size (8.5x11)
> >paper. This also allows for 100 lines per page which is convenient.
> >YMMV.
>
> The 72 chars limit was adopted precisely because YMMV. Text terminals
> with 80 chars per line are still used and, if you restrict the length
> of your lines to 72 chars, there is still some place for the '>'
> quotation marks before the line overflows the hardware-imposed limit of
> 80.
I make printouts in booklet or 2-up form, so that one side of an A
size (US) sheet can hold something like 160 to 180 lines. If line
numbers are added those lines are often 80 chars wide. Save the
trees for oxygen generation.
At the same time handy utilities like Buerg's list can function
quite nicely on 72 char lines. Long lines have to either be
wrapped or scrolled over. A big fat pain.
Most C lines tend to be short anyhow. Those that are naturally
long are usually much clearer when broken up, say 1 line per
parameter in a call, or similar.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@XXXXworldnet.att.net)
Available for consulting/temporary embedded and systems.
(Remove "XXXX" from reply address. yahoo works unmodified)
mailto:u...@ftc.gov (for spambots to harvest)
CBFalconer
>
> On 15 Oct 2001 16:05:12 GMT, walter....@amsi-us.com (Walter
> Mallory) wrote:
>
> >In article <clcm-2001...@plethora.net>, cbfal...@worldnet.att.net wrote:
> >>Bart v Ingen Schenau wrote:
> >>>
> >>Insist that lines do not exceed 72 chars.
> >
> >Ick. Buy yourself a better editor, monitor, or printer (or all three).
>
> I disagree. Lines longer than about 80 chars are inherently hard to
> scan visually, even at 8 point (which is too small to sensibly read).
> Why do you think that printed books are typically 6 inches wide or
> less?
>
> >Set the max characters on a line to the max you can live with on a
> >printed page. I happen to use 120 characters for US A size (8.5x11)
> >paper. This also allows for 100 lines per page which is convenient.
>
> provided you don't mind going blind early...
>
> >YMMV.
>
> at least we both measure in miles....
>
> >Anyone out there use B or even C size for printing listings? Just
> >curious.
>
> but whats B or C size? (rhetorical question). The only sizes that fit
> my printers are A4 and A3. Or envelopes. Go on, print your listing on
> envelopes, that will make the maintenance programmers adore you....
I do. They just get remapped for final printing to fit on an A
sheet. This tends to make the individual characters fairly small.
:-)
http://www.fineprint.com does all this under W9x.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@XXXXworldnet.att.net)
Available for consulting/temporary embedded and systems.
(Remove "XXXX" from reply address. yahoo works unmodified)
mailto:u...@ftc.gov (for spambots to harvest)
Lawrence Kirby
...
>The 72 chars limit was adopted precisely because YMMV. Text terminals
>with 80 chars per line are still used and, if you restrict the length
>of your lines to 72 chars, there is still some place for the '>'
>quotation marks before the line overflows the hardware-imposed limit of
>80.
Most C code isn't written to be quoted in Usenet articles so quoting is
not relevant for that. It is perfectly reasonable to use up to 80
character lines for source code, maybe 79 if you are worried about how
80 character lines wrap.
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
Lawrence Kirby
ma...@garthorn.demon.co.uk "Mark McIntyre" writes:
...
>>Set the max characters on a line to the max you can live with on a
>>printed page. I happen to use 120 characters for US A size (8.5x11)
>>paper. This also allows for 100 lines per page which is convenient.
And when you use a large line length then you tend to en up with a lot
of wasted space/paper to the right. Using 120 characters to write i = j;
is not a good use of resources, nor does it help readability. Maybe having
more lines per page helps within reason, I might accept 90 or perhaps 100
columns at a stretch but anything beyond that isn't sensible.
>provided you don't mind going blind early...
Right. :-)
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
Lawrence Kirby
k...@iki.fi "Kalle Olavi Niemitalo" writes:
>"Bart v Ingen Schenau" <Bart.van.In...@ict.nl.invalid> writes:
>
>> 1. What features/constructs do you know of that are often differently
>> interpreted by programmers and/or compilers?
>
>Some compilers allow enumerators and sizeof in #if expressions.
Many compilers have extensions, these examples make no sense in standard C
because type doesn't exist in preprocessing stages. It is certainly true
that compilers that support extensions will treat those differently to
compilers that don't support them. The only thing to note here is to stick
to the language features defined by the standard. While it is often necessary
to use non-strandard library functions, "language" extensions can usually
be avoided.
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
John L
message news:clcm-2001...@plethora.net...
> Hello all,
>
> At the moment I am updating the company's coding standard.
> The intention of this document is to identify those areas of the C
language
> where problems most often occur, and to indicate means of avoiding those
> problems.
Try the book "Safer C" by Les Hatton.
And "Guidelines for the Use of the C Language in Vehicle Based Software"
from http://www.misra.org.uk
John.
Chris Torek
Dave Shawley <daves...@home.com> writes:
>The one that I have been noticying a lot lately is that most programmers
>don't understand signed/unsigned comparisons. I've been seeing a lot of
>code like the following from new graduates.
>
>unsigned long aNumber;
>unsigned long anotherNumber;
>
>if ((aNumber - anotherNumber) < 0)
>{
> /* blah */
>}
>
>It will usually work fine under a PC simulator and then fail on the
>target platform (we do embedded systems work). Msot PC compilers will
>(and can) extend the unsigned long (usually 32 bits) to a long long
>(usually 64 bits) and perform the math in signed mode. However, our
>little embedded targets rarely support 64 bit arithmetic so the result
>is undefined...
As others noted, this is contrary to the C standards (both C89,
which lacks "long long", and C99, in which "unsigned long" remains
"unsigned long" after promotion).
Perhaps you mean:
unsigned short a, b;
... /* set a and b to some values */
if ((a - b) < 0) something();
This code runs afoul of the horrible ANSI "value preserving"
arithmetic rules. In expressions like the above, the "values" of
the two unsigned numbers are preserved under arithmetic promotion,
but the *types* are not. To achieve this, ANSI C (both C89 and
C99) requires that the result have type "signed int" if and only
if USHRT_MAX <= INT_MAX, i.e., no matter what values a and b might
have, the same value can be expressed as a (non-negative) signed
"int".
Since the result of subtracting two signed "int"s is signed, the
conditional code ("something()" above) executes whenever a < b.
Of course, on some systems, USHRT_MAX > INT_MAX. In particular,
if "int" is only 16 bits, INT_MAX will be no greater than 32767,
while USHRT_MAX is always at least 65535. That means there are
values that can be stored in variables a and b that cannot be
represented as an "int". In this case, the "value preserving"
rules require that the promoted types used before the subtraction
occurs be "unsigned int".
Since the result of subtracting two "unsigned int"s is invariably
another "unsigned int" that is by definition nonnegative, the
conditional code never executes.
Before the 1989 C standard, all sensible compilers used a different
promotion rule, called "sign preserving" or "unsigned preserving":
any unsigned short would always promote to an unsigned int. Some
on the X3J11 committee thought this rule was "too surprising",
because it meant that something() above would never execute, even
on a 32-bit-int machine. Thus, they adopted instead a set of rules
that makes something() execute *sometimes*, on *some* machines,
claiming that this was somehow *less* confusing and surprising than
having it consistently never execute. (The latter surprises exactly
once; having been surprised, one learns the "unsigned preserving"
rule and is never surprised again.)
I am not sure why this was not fixed in C99, given how obviously
horrible the "value preserving" rules are, but we are stuck with
it.
--
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
El Cerrito, CA, USA Domain: to...@bsdi.com +1 510 234 3167
http://claw.eng.bsdi.com/torek/ (not always up) I report spam to abuse@.
Dan Pop
>In article <clcm-2001...@plethora.net> Dan...@cern.ch "Dan Pop" writes:
>
>...
>
>>The 72 chars limit was adopted precisely because YMMV. Text terminals
>>with 80 chars per line are still used and, if you restrict the length
>>of your lines to 72 chars, there is still some place for the '>'
>>quotation marks before the line overflows the hardware-imposed limit of
>>80.
>
>Most C code isn't written to be quoted in Usenet articles so quoting is
>not relevant for that.
Nevertheless, you can't tell in advance which piece of C code will be
quoted in Usenet articles or email messages. So, quoting is relevant :-)
Dan
--
Dan Pop
CERN, IT Division
Email: Dan...@cern.ch
Mail: CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
Kalle Olavi Niemitalo
> Many compilers have extensions, these examples make no sense in standard C
> because type doesn't exist in preprocessing stages. It is certainly true
> that compilers that support extensions will treat those differently to
> compilers that don't support them. The only thing to note here is to stick
> to the language features defined by the standard.
There are two problems here:
1. Some programmers don't read the standard and don't know what
is an extension and what is not.
2. The particular extension of allowing enumerators in #if
expressions is *against* the standard, because it changes the
meaning of conforming programs.
#undef notdefined
enum { notdefined = 1 };
#if notdefined
#error broken compiler
#else
int main(void) { return 0; }
#endif
This is a silly example, but nevertheless I think compilers
should not have such extensions, or should at least have a way
to turn them off.
Lawrence Kirby
>fr...@genesis.demon.co.uk (Lawrence Kirby) writes:
>
>> Many compilers have extensions, these examples make no sense in standard C
>> because type doesn't exist in preprocessing stages. It is certainly true
>> that compilers that support extensions will treat those differently to
>> compilers that don't support them. The only thing to note here is to stick
>> to the language features defined by the standard.
>
>There are two problems here:
>
>1. Some programmers don't read the standard and don't know what
> is an extension and what is not.
And they use things like void main(). The only solution to this problem
is to educate people about standard C. If saying "stick to the language
features defined by the standard" makes people ask what that means then
that is a good thing.
>2. The particular extension of allowing enumerators in #if
> expressions is *against* the standard, because it changes the
> meaning of conforming programs.
>
> #undef notdefined
> enum { notdefined = 1 };
> #if notdefined
> #error broken compiler
> #else
> int main(void) { return 0; }
> #endif
>
> This is a silly example, but nevertheless I think compilers
> should not have such extensions, or should at least have a way
> to turn them off.
That is typically hoiw they do things (an option to turn off extensions).
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
Lawrence Kirby
...
>Nevertheless, you can't tell in advance which piece of C code will be
>quoted in Usenet articles or email messages. So, quoting is relevant :-)
I see, indirect relevance. Next you'll be saying that getch() is a
relevant topic of discussion in c.l.c/c.l.c.m. :-)
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
Dan Pop
>In article <clcm-2001...@plethora.net> Dan...@cern.ch "Dan Pop" writes:
>
>...
>
>>Nevertheless, you can't tell in advance which piece of C code will be
>>quoted in Usenet articles or email messages. So, quoting is relevant :-)
>
>I see, indirect relevance. Next you'll be saying that getch() is a
>relevant topic of discussion in c.l.c/c.l.c.m. :-)
Since getch() is in the program's namespace, I can't see why discussing
such a function would be irrelevant, provided it is implemented in
standard C :-)
Dan
--
Dan Pop
CERN, IT Division
Email: Dan...@cern.ch
Mail: CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
od Dejan
Joona I Palaste
on comp.lang.c:
> Think about the future and avoid C++ keywords as identifier names.
Why? Will C eventually evolve into C++?
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
Richard Heathfield
>
> Think about the future and avoid C++ keywords as identifier names.
Or use them whenever you can, as an indicator to a future maintainer of
your code that you wrote the code for C, not for C++, and that anyone
porting it to C++ had better watch out.
Admittedly, this intention could be more clearly indicated by a comment,
but comments are for wimps, right? ;-)
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Mark McIntyre
>In <clcm-2001...@plethora.net> fr...@genesis.demon.co.uk (Lawrence Kirby) writes:
>
>>In article <clcm-2001...@plethora.net> Dan...@cern.ch "Dan Pop" writes:
>>
>>...
>>
>>>Nevertheless, you can't tell in advance which piece of C code will be
>>>quoted in Usenet articles or email messages. So, quoting is relevant :-)
>>
>>I see, indirect relevance. Next you'll be saying that getch() is a
>>relevant topic of discussion in c.l.c/c.l.c.m. :-)
>
>Since getch() is in the program's namespace, I can't see why discussing
>such a function would be irrelevant, provided it is implemented in
>standard C :-)
Just to note, Dan is of course making a small joke. If someone posted
the code to a function called getch() that would be topical. Asking
about the behaviour of the function getch() provided by some
compilers, that would not be topical.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
osmium
news:clcm-2001...@plethora.net...
> od Dejan <Dejan...@hotmail.com> scribbled the following
> on comp.lang.c:
> > Think about the future and avoid C++ keywords as identifier names.
>
> Why? Will C eventually evolve into C++?
I would guess that the point was that the coder might eventually see the
light. I view C coders as the modern equivalent of Fortran coders who
refused to learn Algol. Although C++ has a googol more warts than Algol.
Wonders from Redmond number 1,635,072.
When one types in Algol and gives it to the IE spell checker it says, in
essence. Incorrect. spell it Algol. Do that. Check spelling. Says
"Incorrect. Spell it Algol".
Mark McIntyre
wrote:
>od Dejan <Dejan...@hotmail.com> scribbled the following
>on comp.lang.c:
>> Think about the future and avoid C++ keywords as identifier names.
>
>Why? Will C eventually evolve into C++?
1) Someday someone may decide to re-use your code in a C++
environment. The less porting work to do, the better.
2) Someday C may add a new keyword and if C were to take up the idea
of say new/delete, those might become keywords. Mind you, so might
foobar, but new probably has a higher chance of that happening.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
Dan Pop
>od Dejan <Dejan...@hotmail.com> scribbled the following
>on comp.lang.c:
>> Think about the future and avoid C++ keywords as identifier names.
>
>Why? Will C eventually evolve into C++?
It doesn't have to.
C89 has stolen "void" and "const" from C++.
C99 has stolen "inline" from C++.
Who knows that the next C standard will steal from C++?
So, the advice is sound.
Dan
--
Dan Pop
CERN, IT Division
Email: Dan...@cern.ch
Mail: CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
Chris Hills
Joona I Palaste <pal...@cc.helsinki.fi> writes
>od Dejan <Dejan...@hotmail.com> scribbled the following
>on comp.lang.c:
>> Think about the future and avoid C++ keywords as identifier names.
>
>Why? Will C eventually evolve into C++?
>
>--
>/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
>| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA
>N+++|
>| http://www.helsinki.fi/~palaste W++ B OP+ |
>\----------------------------------------- Finland rules! ------------/
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Bart van Ingen Schenau
wrote:
>od Dejan <Dejan...@hotmail.com> scribbled the following
>on comp.lang.c:
>> Think about the future and avoid C++ keywords as identifier names.
>
>Why? Will C eventually evolve into C++?
I don't think that C will evolve into C++, but I think that an
increasing amount of C code will be (re-)used in combination with C++
code.
In that situation it is important that the header-files are free from
C++ keywords used as identifiers, and if you are banning them from the
header-files, it is just as easy to ban them altogether.
>--
>/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
Bart v Ingen Schenau
--
Remove NOSPAM to mail me directly
FAQ for clc: http://www.eskimo.com/~scs/C-faq/top.html
FAQ for acllc-c++: http://snurse-l.org/acllc-c++/faq
Just Jekke
wrote:
>od Dejan <Dejan...@hotmail.com> scribbled the following
>on comp.lang.c:
>> Think about the future and avoid C++ keywords as identifier names.
>
>Why? Will C eventually evolve into C++?
No, but it's a short-sighted programmer who doesn't write his code for
maximum portability.
--Jekke
===
I promised CI Host that I would tell at least one
thousand people about their awful service. So far,
over nine hundred have read my review. See it at:
http://www.optionstrict.net/cihost.asp
James Dennett
> od Dejan <Dejan...@hotmail.com> scribbled the following
> on comp.lang.c:
>
>>Think about the future and avoid C++ keywords as identifier names.
>>
>
> Why? Will C eventually evolve into C++?
>
>
Some C code will eventually be compiled as C++, yes.
(And as for the languages: one direction in the evolution
of C lead to C++98. Another lead to C99.)
-- James Dennett
Dave Hansen
wrote:
>On 24 Oct 2001 15:54:36 GMT, Joona I Palaste <pal...@cc.helsinki.fi>
>wrote:
[...]
>>Why? Will C eventually evolve into C++?
>
>1) Someday someone may decide to re-use your code in a C++
>environment. The less porting work to do, the better.
extern "C"
>
>2) Someday C may add a new keyword and if C were to take up the idea
>of say new/delete, those might become keywords. Mind you, so might
>foobar, but new probably has a higher chance of that happening.
If a future C standard specifies new keywords, they'll come from the
reserved namespace. Ref. _Bool in C99.
Regards,
-=Dave
--
Change is inevitable, progress is not.
Chris Hills
>On 24 Oct 2001 15:54:36 GMT, Joona I Palaste <pal...@cc.helsinki.fi>
>wrote:
>
>>od Dejan <Dejan...@hotmail.com> scribbled the following
>>on comp.lang.c:
>>> Think about the future and avoid C++ keywords as identifier names.
>>
>>Why? Will C eventually evolve into C++?
>
>No, but it's a short-sighted programmer who doesn't write his code for
>maximum portability.
No, probably an embedded programmer.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
jgut...@brokersys.com
> On 24 Oct 2001 15:54:36 GMT, Joona I Palaste <pal...@cc.helsinki.fi>
> wrote:
>>od Dejan <Dejan...@hotmail.com> scribbled the following
>>on comp.lang.c:
>>> Think about the future and avoid C++ keywords as identifier names.
>>
>>Why? Will C eventually evolve into C++?
> No, but it's a short-sighted programmer who doesn't write his code for
> maximum portability.
If that's the case, then why are you not worried about not using
keywords from Modula-3 or Ada? C++ is a different language from C, so
why shouldn't it be treated the same way as other languages that aren't
C?
Look, I can see not trying to conflict with C++ because many people
who work on C want to borrow ideas from C++ for inclusion into C, but
"portability" doesn't enter into it.
For my own part, I can't predict what the C compiler mavens are going to
do, and I'm not willing to bet that they are going to restrict their
pool of potential new keywords to just those thare are currently in C++.
So it seems, to me, to be silly to give C++ keywords preferential
treatment because there is the possibility they might be made into C
keywords at some point. You can say that about any keyword used by any
other language, or, indeed, any sequence of characters in the C locale
and the C locale itself is subject to change.
The "we may, at some point, want to compile the C source with a C++
compiler" argument is valid in many situation, but not in mine. When I
move away from C, I sure as heck can find better languages than C++.
In fact, I already have.
I guess what I'm trying to say is that mileage varies and, if you choose
this restriction, you should do it for different reasons than simply
because some posts to comp.lang.c said to.
--
Jonathan Guthrie (jgut...@brokersys.com)
Sto pro veritate
Peter Nilsson
> od Dejan <Dejan...@hotmail.com> scribbled the following
> on comp.lang.c:
> > Think about the future and avoid C++ keywords as identifier names.
>
> Why? Will C eventually evolve into C++?
I think it was the Greek philosopher Zeno who etched: "By the time C
catches up to C++, C++ will already have moved on." ;)
--
Peter
Mark McIntyre
>On 25 Oct 2001 15:04:35 GMT, Mark McIntyre <ma...@garthorn.demon.co.uk>
>wrote:
>
>>On 24 Oct 2001 15:54:36 GMT, Joona I Palaste <pal...@cc.helsinki.fi>
>>wrote:
>[...]
>>>Why? Will C eventually evolve into C++?
>>
>>1) Someday someone may decide to re-use your code in a C++
>>environment. The less porting work to do, the better.
>
>extern "C"
not sure that helps if you have
int new, delete;
char std;
>>2) Someday C may add a new keyword and if C were to take up the idea
>>of say new/delete, those might become keywords. Mind you, so might
>>foobar, but new probably has a higher chance of that happening.
>
>If a future C standard specifies new keywords, they'll come from the
>reserved namespace. Ref. _Bool in C99.
which is curiously aliased to bool.....
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
od Dejan
news:clcm-2001...@plethora.net...
> od Dejan <Dejan...@hotmail.com> scribbled the following
> on comp.lang.c:
> > Think about the future and avoid C++ keywords as identifier names.
>
> Why? Will C eventually evolve into C++?
Do you think that C will be less efective if J do not use
new,class,friend,cout..... as identifier names????
Chris Torek
>>on comp.lang.c:
>>> Think about the future and avoid C++ keywords as identifier names.
>In <clcm-2001...@plethora.net> Joona I Palaste <pal...@cc.helsinki.fi> writes:
>>Why? Will C eventually evolve into C++?
In article <clcm-2001...@plethora.net> Dan Pop <Dan...@cern.ch> wrote:
>It doesn't have to.
>
>C89 has stolen "void" and "const" from C++.
>C99 has stolen "inline" from C++.
>Who knows that the next C standard will steal from C++?
>
>So, the advice is sound.
I am not sure about the soundness of the advice, but I would
point out that C99 got "void" from C, not C++. Shortly after
the White Book came out, a new version of C, with "enum",
"void", structures as arguments and return values, and so on,
became relatively commonly available.
The "const" keyword may or may not have come from C++. Some form
of "const", usually spelled just that way, wwas present (as an
sc-specifier, not a type-qualifier) in a number of embedded system
ROM-able-code C compilers in the 1980s. The "volatile" keyword
was also already in use in compilers like that from MIPS, for
the R2000 CPU.
The "inline" keyword is also debatable, like "const". One problem
with arguing that "const" and "inline" came from C++ is that their
C versions have different semantics than their C++ versions.
C99 adds a "restrict" keyword, too, which certainly does not come
from C++; and C99's boolean keyword is spelled _Bool, with a macro
from <stdbool.h> to rename it for convenience. Standards Committees
are not very consistent about this sort of thing, and my suggestion
is not even to *attempt* to anticipate their actions. :-)
Ben Pfaff
> Do you think that C will be less efective if J do not use
> new,class,friend,cout..... as identifier names????
There you go again using `J' as a personal pronoun. It's not.
`I' is the personal pronoun in English. The first time I assumed
it was a typo, but now I'm starting to get annoyed.
osmium
news:87lmhz2...@pfaff.stanford.edu...
You should listen to Frenchman delivering a paper with indexes i and j.
You soon discover that it it not one world.
Richard Norman
As all good programmers know, the letter 'I' is much too easily
confused with the number '1'. So this is a sign of modesty.
Americans, like all other English speakers, are constantly
running around arrogantly proclaiming that I am number 1!
Mark McIntyre
wrote:
Nevertheless this is an english language group, and how french
pronounce i, j or h for that matter, is non-germane !
osmium
news:b2qitt09a115rv74l...@4ax.com...
I apologize for trying to bring a little lightness to your dreary world.
That was very rude of me.
Richard Heathfield
>
> Joona I Palaste <pal...@cc.helsinki.fi> wrote in message news:<clcm-2001...@plethora.net>...
> > od Dejan <Dejan...@hotmail.com> scribbled the following
> > on comp.lang.c:
> > > Think about the future and avoid C++ keywords as identifier names.
> >
> > Why? Will C eventually evolve into C++?
>
> I think it was the Greek philosopher Zeno who etched: "By the time C
> catches up to C++, C++ will already have moved on." ;)
That is a paradox indeed, since C started ahead of C++, and remains
ahead by a substantial and increasing margin.
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Richard Heathfield
>
> In article <clcm-2001...@plethora.net> Dan Pop <Dan...@cern.ch> wrote:
> >
> >C89 has stolen "void" and "const" from C++.
> >C99 has stolen "inline" from C++.
> >Who knows that the next C standard will steal from C++?
> >
> >So, the advice is sound.
>
> I am not sure about the soundness of the advice,
Nor I...
> but I would
> point out that C99 got "void" from C, not C++.
....but I would point out that Dan said C89, not C99.
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Dave Hansen
wrote:
>On 25 Oct 2001 19:48:13 GMT, id...@hotmail.com (Dave Hansen) wrote:
>
>>On 25 Oct 2001 15:04:35 GMT, Mark McIntyre <ma...@garthorn.demon.co.uk>
>>wrote:
[...]
>>>1) Someday someone may decide to re-use your code in a C++
>>>environment. The less porting work to do, the better.
>>
>>extern "C"
>
>not sure that helps if you have
> int new, delete;
> char std;
It doesn't help if you're trying to import global symbols (variables
or functions) or structure members that have such names:
delete(std.new) -- oops.
But it's effective for hiding anything that can be contained within
the "C" universe. E.g., if you have a C function to accumulate a
checksum that looks something like
unsigned accum(unsigned sum, unsigned char new)
{
/* perform calculations and return new sum */
}
This could be called directly from a C++ program given the appropriate
prototype:
extern "C" unsigned accum(unsigned, unsigned char);
But you knew that. ;-)
I wasn't advocating using C++ keywords for C program symbols, I was
merely suggesting a possible solution for the situation described.
But I'm not certain it's reasonable to preclude the use of C++
keywords in programs written in C, just on the basis that someone,
someday might want to port the code to C++. Why not include Java on
that list. Or Perl? AWK? Python? And the differences between C and
C++ are large enough that keywords aren't going to be your biggest
problem anyway.
>
>>>2) Someday C may add a new keyword and if C were to take up the idea
>>>of say new/delete, those might become keywords. Mind you, so might
>>>foobar, but new probably has a higher chance of that happening.
>>
>>If a future C standard specifies new keywords, they'll come from the
>>reserved namespace. Ref. _Bool in C99.
>
>which is curiously aliased to bool.....
Only if stdbool.h is included, which also defines true, false, and
(curiously) __bool_true_false_are_defined. Even then, these are all
macros, and can be #undef'ed and redefined if desired.
Regards,
-=Dave
--
Change is inevitable, progress is not.
CBFalconer
>
> On 25 Oct 2001 19:48:13 GMT, id...@hotmail.com (Dave Hansen) wrote:
>
> >On 25 Oct 2001 15:04:35 GMT, Mark McIntyre <ma...@garthorn.demon.co.uk>
> >wrote:
> >
> >>On 24 Oct 2001 15:54:36 GMT, Joona I Palaste <pal...@cc.helsinki.fi>
> >>wrote:
> >[...]
> >>>Why? Will C eventually evolve into C++?
> >>
> >>1) Someday someone may decide to re-use your code in a C++
> >>environment. The less porting work to do, the better.
> >
> >extern "C"
>
> not sure that helps if you have
> int new, delete;
> char std;
>
> >>2) Someday C may add a new keyword and if C were to take up the idea
> >>of say new/delete, those might become keywords. Mind you, so might
> >>foobar, but new probably has a higher chance of that happening.
> >
> >If a future C standard specifies new keywords, they'll come from the
> >reserved namespace. Ref. _Bool in C99.
>
> which is curiously aliased to bool.....
Which alias does not appear unless you #include <stdbool.h>, thus
giving the user a choice and avoiding breaking any older source.
This was not consistent. Older source that uses round and
#includes <math.h> is very likely to be broken under C99, for
example. Of course, that is not a keyword, so things are not
quite so serious.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@XXXXworldnet.att.net)
Available for consulting/temporary embedded and systems.
(Remove "XXXX" from reply address. yahoo works unmodified)
mailto:u...@ftc.gov (for spambots to harvest)
CBFalconer
>
> On 25 Oct 2001 19:48:13 GMT, id...@hotmail.com (Dave Hansen) wrote:
>
> >On 25 Oct 2001 15:04:35 GMT, Mark McIntyre <ma...@garthorn.demon.co.uk>
> >wrote:
> >
> >>On 24 Oct 2001 15:54:36 GMT, Joona I Palaste <pal...@cc.helsinki.fi>
> >>wrote:
> >[...]
> >>>Why? Will C eventually evolve into C++?
> >>
> >>1) Someday someone may decide to re-use your code in a C++
> >>environment. The less porting work to do, the better.
> >
> >extern "C"
>
> not sure that helps if you have
> int new, delete;
> char std;
>
> >>2) Someday C may add a new keyword and if C were to take up the idea
> >>of say new/delete, those might become keywords. Mind you, so might
> >>foobar, but new probably has a higher chance of that happening.
> >
> >If a future C standard specifies new keywords, they'll come from the
> >reserved namespace. Ref. _Bool in C99.
>
> which is curiously aliased to bool.....
Which alias does not appear unless you #include <stdbool.h>, thus
giving the user a choice and avoiding breaking any older source.
This was not consistent. Older source that uses round and
#includes <math.h> is very likely to be broken under C99, for
example. Of course, that is not a keyword, so things are not
quite so serious.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@XXXXworldnet.att.net)
Available for consulting/temporary embedded and systems.
(Remove "XXXX" from reply address. yahoo works unmodified)
mailto:u...@ftc.gov (for spambots to harvest)
Ben Pfaff
> Nevertheless this is an english language group, and how french
> pronounce i, j or h for that matter, is non-germane !
Who said anything about German?
<g,d&r>
Mark McIntyre
wrote:
You need a smiley to indicate humour. Since I work for a french bank,
listening to my colleagues torturing English has long ago passed
beyond humour... :-)
>That was very rude of me.
Not at all.
Mark McIntyre
Sorry, I meant non-geranium.
Oh no, not again...
Erik Max Francis
> ....but I would point out that Dan said C89, not C99.
Point being, the introduction of void to C predates C++.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ There is no fate that cannot be surmounted by scorn.
\__/ Albert Camus
Erik Max Francis' bookmarks / http://www.alcyone.com/max/links/
A highly categorized list of Web links.
Kaz Kylheku
>Joona I Palaste <pal...@cc.helsinki.fi> wrote in message
>news:clcm-2001...@plethora.net...
>> od Dejan <Dejan...@hotmail.com> scribbled the following
>> on comp.lang.c:
>> > Think about the future and avoid C++ keywords as identifier names.
>>
>> Why? Will C eventually evolve into C++?
>
> Do you think that C will be less efective if J do not use
>new,class,friend,cout..... as identifier names????
A C *programmer* will be less effective if he or she wastes
time researching what keywords are reserved in other programming
languages, and then exerts the extra discipline (quite likely without
the help of the C implementation) to avoid these keywords.
These extra steps must be justified by an actual need, such as an
externally imposed requirement to write code that compiles as C++.
Otherwise they are a waste of time. Such a requirement is frequently
imposed on C library writers, who these days have to ensure that their
header files support C as well as C++ users.
Lew Pitcher
>
> On 24 Oct 2001 15:54:36 GMT, Joona I Palaste <pal...@cc.helsinki.fi>
> wrote:
>
> >od Dejan <Dejan...@hotmail.com> scribbled the following
> >on comp.lang.c:
> >> Think about the future and avoid C++ keywords as identifier names.
> >
> >Why? Will C eventually evolve into C++?
>
> No, but it's a short-sighted programmer who doesn't write his code for
> maximum portability.
I must be very shortsighted then, because when I write my C code, I
_don't_ write it assuming that it will someday be compiled with a COBOL,
Fortran, PL/I, or Algol compiler. In fact, I assume that my C code will
be compiled with _only_ a C compiler. Anything else would be foolish.
--
Lew Pitcher
Master Codewright and JOAT-in-training
Registered Linux User #112576 (http://counter.li.org/)
Chris Torek
>>>C89 has stolen "void" and "const" from C++.
>Chris Torek wrote:
>>... I would point out that C99 got "void" from C, not C++.
In article <clcm-2001...@plethora.net>
Richard Heathfield <bin...@eton.powernet.co.uk> writes:
>.... I would point out that Dan said C89, not C99.
Sorry, typo -- I meant `C89 got "void" from C'. It also got enum,
structure-valued arguments, and structure-valued fucntions from C.
They were all in C before C++ even existed -- they were just missing
from the 1978 White Book.
--
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
El Cerrito, CA, USA Domain: to...@bsdi.com +1 510 234 3167
http://claw.eng.bsdi.com/torek/ (not always up) I report spam to abuse@.
James Dennett
> Peter Nilsson wrote:
>
>>Joona I Palaste <pal...@cc.helsinki.fi> wrote in message news:<clcm-2001...@plethora.net>...
>>
>>>od Dejan <Dejan...@hotmail.com> scribbled the following
>>>on comp.lang.c:
>>>
>>>>Think about the future and avoid C++ keywords as identifier names.
>>>>
>>>Why? Will C eventually evolve into C++?
>>>
>>I think it was the Greek philosopher Zeno who etched: "By the time C
>>catches up to C++, C++ will already have moved on." ;)
>>
>
> That is a paradox indeed, since C started ahead of C++, and remains
> ahead by a substantial and increasing margin.
C99 has some things C++98 does not. And vice versa.
Neither is "ahead" of the other in terms of language
features.
C compilers are more mature than C++ compilers, so
in that sense C is ahead. C code currently has better
chances of portability than C++ code, because of the
wider availability of implementations (of C90, at
least -- C99 is taking a while to be implemented, just
as for C++98).
In terms of support for OO and generic programming,
and a slew of other things, C++ is ahead. This is
not contentious. C99 has better support for various
things including (optional) fixed size integral
types. C++ will learn from this.
In terms of people who believe that one of the two is
*always* better than the other, both languages have
sadly collected large numbers. Pick the right tool
for the job, based on all relevant factors -- including
tools (and their support), the availability of developers,
and language features matched against the problem domain.
Don't pick one or the other on religious grounds.
Probably I should not have responded to the previous
poster, who made a vague and unsubstantiated claim,
but if he would care to attempt to justify it then I
*would* be interested to hear how.
-- James Dennett
Richard Heathfield
>
> Richard Heathfield wrote:
>
> > Peter Nilsson wrote:
> >
<snip>
> >>I think it was the Greek philosopher Zeno who etched: "By the time C
> >>catches up to C++, C++ will already have moved on." ;)
> >>
> >
> > That is a paradox indeed, since C started ahead of C++, and remains
> > ahead by a substantial and increasing margin.
>
<snip>
>
> In terms of people who believe that one of the two is
> *always* better than the other, both languages have
> sadly collected large numbers. Pick the right tool
> for the job, based on all relevant factors -- including
> tools (and their support), the availability of developers,
> and language features matched against the problem domain.
> Don't pick one or the other on religious grounds.
My own response was of course HHOS. I am very fond of C++, although
admittedly not as fond of it as I am of C, but it grates a little when
people think C is playing catch-up all the time. It is not. It is, in
fact, running a completely different race which happens to be held in
the same stadium.
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Brian Inglis
Kylheku) wrote:
With the new c-prefixed .h-less header names in C++, C library
header files should be cleansed of all non-C abominations!
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
--
Brian....@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
fake address use address above to reply
tos...@aol.com ab...@aol.com ab...@yahoo.com ab...@hotmail.com ab...@msn.com ab...@sprint.com ab...@earthlink.com ab...@cadvision.com ab...@ibsystems.com u...@ftc.gov
spam traps
Greg Comeau
CBFalconer <cbfal...@worldnet.att.net> wrote:
>Mark McIntyre wrote:
>> On 25 Oct 2001 19:48:13 GMT, id...@hotmail.com (Dave Hansen) wrote:
>> which is curiously aliased to bool.....
>
>Which alias does not appear unless you #include <stdbool.h>, thus
>giving the user a choice and avoiding breaking any older source.
Not quite sure what you're asking, but C99's stdbool.h
brings in bool, true and false (and __bool_true_false_are_defined)
as macros (alias is probably not the right word for macro).
Otherwise, C99 itself doesn't bring them in.
Hmm, I now see you're making a statement not a question.
Anyway, I'll send this off anyway for folks who don't know.
W.r.t what you did say: Not if the older source uses _Bool,
which may have already been in the vendors namespace (I'm not
aware of any vendor who did this though).
>This was not consistent. Older source that uses round and
>#includes <math.h> is very likely to be broken under C99, for
>example. Of course, that is not a keyword, so things are not
>quite so serious.
Yup.
--
Greg Comeau export ETA: December See our Oct 31st special
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Greg Comeau
Chris Torek <to...@BSDI.COM> wrote:
>>>od Dejan <Dejan...@hotmail.com> scribbled the following
>>>on comp.lang.c:
>>>> Think about the future and avoid C++ keywords as identifier names.
>
>>In <clcm-2001...@plethora.net> Joona I Palaste <pal...@cc.helsinki.fi> writes:
>>>Why? Will C eventually evolve into C++?
>
>In article <clcm-2001...@plethora.net> Dan Pop <Dan...@cern.ch> wrote:
>>It doesn't have to.
>>
>>C89 has stolen "void" and "const" from C++.
>>C99 has stolen "inline" from C++.
>>Who knows that the next C standard will steal from C++?
>>
>>So, the advice is sound.
>
>I am not sure about the soundness of the advice, but I would
>point out that C99 got "void" from C, not C++. Shortly after
>the White Book came out, a new version of C, with "enum",
>"void", structures as arguments and return values, and so on,
>became relatively commonly available.
>
>The "const" keyword may or may not have come from C++. Some form
>of "const", usually spelled just that way, wwas present (as an
>sc-specifier, not a type-qualifier) in a number of embedded system
>ROM-able-code C compilers in the 1980s. The "volatile" keyword
>was also already in use in compilers like that from MIPS, for
>the R2000 CPU.
Certainly keywords similar were available, and as you say,
in some cases the same ones.
>The "inline" keyword is also debatable, like "const". One problem
>with arguing that "const" and "inline" came from C++ is that their
>C versions have different semantics than their C++ versions.
Nonetheless, the motivation came from C++, even though the C
committe both purposely and unporposely made differences for
C90 and C99 in their meaning.
>C99 adds a "restrict" keyword, too, which certainly does not come
>from C++;
Right, actually at the time the C++ committee considered it,
but with differences didn't know what it would mean for C++.
This is still something on the side of the C++ committees table.
>and C99's boolean keyword is spelled _Bool, with a macro
>from <stdbool.h> to rename it for convenience. Standards Committees
>are not very consistent about this sort of thing, and my suggestion
>is not even to *attempt* to anticipate their actions. :-)
I didn't take the spirit of the discussion as that, but yes,
you're quite right otherwise.
--
Greg Comeau export ETA: December See our Oct 31st special
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Greg Comeau
Dave Hansen <id...@hotmail.com> wrote:
>If a future C standard specifies new keywords, they'll come from the
>reserved namespace. Ref. _Bool in C99.
Then how does that explain long long, restrict, etc.?
Greg Comeau
>In <clcm-2001...@plethora.net> Joona I Palaste <pal...@cc.helsinki.fi> writes:
>
>>od Dejan <Dejan...@hotmail.com> scribbled the following
>>on comp.lang.c:
>>> Think about the future and avoid C++ keywords as identifier names.
>>
>>Why? Will C eventually evolve into C++?
>
>
>C89 has stolen "void" and "const" from C++.
>C99 has stolen "inline" from C++.
>Who knows that the next C standard will steal from C++?
>
>So, the advice is sound.
Well, C++ needs to steal from C99 first :)
On a more serious note, these, they are interesting times,
and it'll be interesting to see if the committees are
capable of co-creating features from hereon in.
Ben Pfaff
> In article <clcm-2001...@plethora.net>,
> Dave Hansen <id...@hotmail.com> wrote:
> >If a future C standard specifies new keywords, they'll come from the
> >reserved namespace. Ref. _Bool in C99.
>
> Then how does that explain long long, restrict, etc.?
I can understand a gripe on `restrict', but why do you imply that
`long long' is a new keyword not from the reserved namespace?
`long' was certainly reserved, being already a keyword.
Kaz Kylheku
>On 27 Oct 2001 01:06:35 GMT, k...@ashi.footprints.net (Kaz
>Kylheku) wrote:
>
>>In article <clcm-2001...@plethora.net>, od Dejan wrote:
>>>Joona I Palaste <pal...@cc.helsinki.fi> wrote in message
>>>news:clcm-2001...@plethora.net...
>>>> od Dejan <Dejan...@hotmail.com> scribbled the following
>>>> on comp.lang.c:
>>>> > Think about the future and avoid C++ keywords as identifier names.
>>>>
>>>> Why? Will C eventually evolve into C++?
>>>
>>> Do you think that C will be less efective if J do not use
>>>new,class,friend,cout..... as identifier names????
>>
>>A C *programmer* will be less effective if he or she wastes
>>time researching what keywords are reserved in other programming
>>languages, and then exerts the extra discipline (quite likely without
>>the help of the C implementation) to avoid these keywords.
>>
>>These extra steps must be justified by an actual need, such as an
>>externally imposed requirement to write code that compiles as C++.
>>Otherwise they are a waste of time. Such a requirement is frequently
>>imposed on C library writers, who these days have to ensure that their
>>header files support C as well as C++ users.
>
>With the new c-prefixed .h-less header names in C++, C library
>header files should be cleansed of all non-C abominations!
This is completely irrelevant to the discussion, which is about headers
in general, not merely standard library headers.
Note that even if you separate the headers into suffix-free ones
for C++ programmers that wrap the .h headers used by C programmers,
the .h headers still have to be carefully written to support C++;
they must avoid using C++ keywords as identifiers and so forth.
Richard Heathfield
>
> In article <clcm-2001...@plethora.net>, Dan Pop <Dan...@cern.ch> wrote:
> >In <clcm-2001...@plethora.net> Joona I Palaste <pal...@cc.helsinki.fi> writes:
> >
> >>od Dejan <Dejan...@hotmail.com> scribbled the following
> >>on comp.lang.c:
> >>> Think about the future and avoid C++ keywords as identifier names.
> >>
> >>Why? Will C eventually evolve into C++?
> >
> >It doesn't have to.
> >
> >C89 has stolen "void" and "const" from C++.
> >C99 has stolen "inline" from C++.
> >Who knows that the next C standard will steal from C++?
> >
> >So, the advice is sound.
>
> Well, C++ needs to steal from C99 first :)
Actually, I don't think it does. The time when C++ *needed* C
compatibility is past. Perhaps it's time to cut the cord.
> On a more serious note, these, they are interesting times,
> and it'll be interesting to see if the committees are
> capable of co-creating features from hereon in.
It'll be even more interesting to see whether they have the will-power
/not/ to; C and C++ are now different languages, and there is little
point in maintaining the ties between them. C++ has left for college.
It'll still be welcome at weekends, and its room will be left just the
way it always was, but that's as far as it goes.
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Francis Glassborow
<bin...@eton.powernet.co.uk> writes
>It'll be even more interesting to see whether they have the will-power
>/not/ to; C and C++ are now different languages, and there is little
>point in maintaining the ties between them. C++ has left for college.
>It'll still be welcome at weekends, and its room will be left just the
>way it always was, but that's as far as it goes.
That may be true for you but it is not true for many programmers who
willingly or otherwise have to program in both languages. I am not a
supporter of 'compatibility at all costs' but I am a supporter of
'incompatibility is not cost free'. Fortunately most, if not all, my
fellow WG14 and WG21 colleagues have a similar perspective. Into the
foreseeable future both committees will consider the needs of those who
use both languages and will seek to provide as much compatibility as
possible without distorting their separate objectives.
Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.
Richard Heathfield
>
> In article <clcm-2001...@plethora.net>, Richard Heathfield
> <bin...@eton.powernet.co.uk> writes
> >It'll be even more interesting to see whether they have the will-power
> >/not/ to; C and C++ are now different languages, and there is little
> >point in maintaining the ties between them. C++ has left for college.
> >It'll still be welcome at weekends, and its room will be left just the
> >way it always was, but that's as far as it goes.
>
> That may be true for you but it is not true for many programmers who
> willingly or otherwise have to program in both languages.
As a matter of fact, I /do/ program in C++, and indeed it is my
second-favourite language. But I don't see any need to change the C
language to make it more C++-like. I like having a choice between many
languages. C and C++ are my two favourites, but I see no value in trying
to merge them into one.
Many programmers, willingly or otherwise, have to program in VB and C++.
Do you advocate moving C++ closer to VB? :-)
> I am not a
> supporter of 'compatibility at all costs' but I am a supporter of
> 'incompatibility is not cost free'.
But the languages are /already/ incompatible to some extent, and that
situation has been exacerbated by C99.
> Fortunately most, if not all, my
> fellow WG14 and WG21 colleagues have a similar perspective. Into the
> foreseeable future both committees will consider the needs of those who
> use both languages and will seek to provide as much compatibility as
> possible without distorting their separate objectives.
Those last five words are of key importance. I don't think we have a
quarrel here.
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Greg Comeau
Ben Pfaff <b...@cs.stanford.edu> wrote:
>com...@panix.com (Greg Comeau) writes:
>
>> In article <clcm-2001...@plethora.net>,
>> Dave Hansen <id...@hotmail.com> wrote:
>> >If a future C standard specifies new keywords, they'll come from the
>> >reserved namespace. Ref. _Bool in C99.
>>
>> Then how does that explain long long, restrict, etc.?
>
>I can understand a gripe on `restrict', but why do you imply that
>`long long' is a new keyword not from the reserved namespace?
>`long' was certainly reserved, being already a keyword.
The idea being that it could have been _Longlong
(I'm not recommending this, just saying it :)
--
Greg Comeau export ETA: December See our Oct 31st special
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Greg Comeau
Richard Heathfield <bin...@eton.powernet.co.uk> wrote:
>Greg Comeau wrote:
>> In article <clcm-2001...@plethora.net>, Dan Pop <Dan...@cern.ch> wrote:
>> >In <clcm-2001...@plethora.net> Joona I Palaste <pal...@cc.helsinki.fi> writes:
>> >
>> >>od Dejan <Dejan...@hotmail.com> scribbled the following
>> >>on comp.lang.c:
>> >>> Think about the future and avoid C++ keywords as identifier names.
>> >>Why? Will C eventually evolve into C++?
>> >It doesn't have to.
>> >C89 has stolen "void" and "const" from C++.
>> >C99 has stolen "inline" from C++.
>> >Who knows that the next C standard will steal from C++?
>> >So, the advice is sound.
>> Well, C++ needs to steal from C99 first :)
>
>Actually, I don't think it does. The time when C++ *needed* C
>compatibility is past. Perhaps it's time to cut the cord.
Well, many people disagree with you.
>> On a more serious note, these, they are interesting times,
>> and it'll be interesting to see if the committees are
>> capable of co-creating features from hereon in.
>
>It'll be even more interesting to see whether they have the will-power
>/not/ to; C and C++ are now different languages, and there is little
>point in maintaining the ties between them.
Again, many people disagree with you.
>C++ has left for college.
>It'll still be welcome at weekends, and its room will be left just the
>way it always was, but that's as far as it goes.
Still, many people disagree with you :)
--
Greg Comeau export ETA: December See our Oct 31st special
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Dan Pop
>Francis Glassborow wrote:
>>
>> In article <clcm-2001...@plethora.net>, Richard Heathfield
>> <bin...@eton.powernet.co.uk> writes
>> >It'll be even more interesting to see whether they have the will-power
>> >/not/ to; C and C++ are now different languages, and there is little
>> >point in maintaining the ties between them. C++ has left for college.
>> >It'll still be welcome at weekends, and its room will be left just the
>> >way it always was, but that's as far as it goes.
>>
>> That may be true for you but it is not true for many programmers who
>> willingly or otherwise have to program in both languages.
>
>As a matter of fact, I /do/ program in C++, and indeed it is my
>second-favourite language. But I don't see any need to change the C
>language to make it more C++-like.
Nobody argued for that. However, if C acquires a feature already
existing in C++, or if both languages acquire the same new feature,
incompatibilities between the two languages are better avoided, to make
the programmers' lives easier. This is true especially for the
programmers who have considerably more experience with one of the
languages than with the other.
The point is to avoid gratuitous divergences, not to make one of the
languages more like the other.
Dan
--
Dan Pop
CERN, IT Division
Email: Dan...@cern.ch
Mail: CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
Dan Pop
>Richard Heathfield wrote:
>
>> ....but I would point out that Dan said C89, not C99.
>
>Point being, the introduction of void to C predates C++.
The base document for the language part of the C89 standard is K&R1.
There is no mention of void in that document.
Dan
--
Dan Pop
CERN, IT Division
Email: Dan...@cern.ch
Mail: CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
Francis Glassborow
>second-favourite language. But I don't see any need to change the C
>language to make it more C++-like. I like having a choice between many
>languages. C and C++ are my two favourites, but I see no value in trying
>to merge them into one.
>
>Many programmers, willingly or otherwise, have to program in VB and C++.
>Do you advocate moving C++ closer to VB? :-)
No, but then a C++ compiler will not compile VB, but it will almost
always compile C (certainly in so far as C90 is concerned) and that is
an important distinction.
In general I cannot look at a piece of source code and immediately
determine if it is C or C++.
Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.
Richard Heathfield
> >> >>> Think about the future and avoid C++ keywords as identifier names.
> >> >>Why? Will C eventually evolve into C++?
> >> >It doesn't have to.
> >> >C89 has stolen "void" and "const" from C++.
> >> >C99 has stolen "inline" from C++.
> >> >Who knows that the next C standard will steal from C++?
> >> >So, the advice is sound.
> >> Well, C++ needs to steal from C99 first :)
> >
> >Actually, I don't think it does. The time when C++ *needed* C
> >compatibility is past. Perhaps it's time to cut the cord.
>
> Well, many people disagree with you.
Sure, and that's their privilege. But IMHO C++ has been a tremendous
success and will no doubt continue to be so. The only reason it /needs/
compatibility with C nowadays is to ease the porting of old code. People
writing programs today can already choose between C and C++, and if they
choose C then there's probably a good reason for that.
>
> >> On a more serious note, these, they are interesting times,
> >> and it'll be interesting to see if the committees are
> >> capable of co-creating features from hereon in.
> >
> >It'll be even more interesting to see whether they have the will-power
> >/not/ to; C and C++ are now different languages, and there is little
> >point in maintaining the ties between them.
>
> Again, many people disagree with you.
Again, my reaction is that that's fine but I didn't get where I am today
by agreeing with people. In fact, had I agreed with more people earlier,
(a) I'd now be in Marketing (b) I'd be worth a fortune. :-)
I don't see anyone saying C++ should be made more C-like, or that BCPL
should be dragged kicking and screaming into the 21st century. [ Hey
everyone, why don't we give BCPL those funky C++-style // comments! :-)
]
> >C++ has left for college.
> >It'll still be welcome at weekends, and its room will be left just the
> >way it always was, but that's as far as it goes.
>
> Still, many people disagree with you :)
Yes, I've already had evidence of that. But it was a wonderful metaphor,
and I couldn't resist using it. After all, I /really/ don't want C++'s
noisy friends lounging around the house watching TV and sending out for
pizzas.
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Chris Hills
>In article <clcm-2001...@plethora.net>,
>>Actually, I don't think it does. The time when C++ *needed* C
>>compatibility is past. Perhaps it's time to cut the cord.
>
>Well, many people disagree with you.
own..
>>It'll be even more interesting to see whether they have the will-power
>>/not/ to; C and C++ are now different languages, and there is little
>>point in maintaining the ties between them.
>
>Again, many people disagree with you.
and a lot of us agree but I would not add gratuitous differences..
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Mark McIntyre
<bin...@eton.powernet.co.uk> wrote:
>
>Many programmers, willingly or otherwise, have to program in VB and C++.
>Do you advocate moving C++ closer to VB? :-)
I on the other hand would be a strong advocate of moving C closer to
bullsh*t. It would make it _so_ much easier to explain to the trading
and sales force, who all understand that language perfectly..... :->
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
Morris Dovey
> On 30 Oct 2001 04:37:32 GMT, Richard Heathfield
> <bin...@eton.powernet.co.uk> wrote:
>
> >
> >Many programmers, willingly or otherwise, have to program in VB and C++.
> >Do you advocate moving C++ closer to VB? :-)
>
> I on the other hand would be a strong advocate of moving C closer to
> bullsh*t. It would make it _so_ much easier to explain to the trading
> and sales force, who all understand that language perfectly..... :->
C# is off-topic in comp.lang.c
8^)
--
Morris Dovey
West Des Moines, Iowa USA
Ben Pfaff
> On 30 Oct 2001 04:37:32 GMT, Richard Heathfield
> <bin...@eton.powernet.co.uk> wrote:
>
> >Many programmers, willingly or otherwise, have to program in VB and C++.
> >Do you advocate moving C++ closer to VB? :-)
>
> I on the other hand would be a strong advocate of moving C closer to
> bullsh*t.
I bet a certain notorious book author would be willing to help
out.
--
"I hope, some day, to learn to read.
It seems to be even harder than writing."
--Richard Heathfield
Richard Heathfield
>
> In <clcm-2001...@plethora.net> Richard Heathfield <bin...@eton.powernet.co.uk> writes:
>
> >
> >As a matter of fact, I /do/ program in C++, and indeed it is my
> >second-favourite language. But I don't see any need to change the C
> >language to make it more C++-like.
>
>
> The point is to avoid gratuitous divergences, not to make one of the
> languages more like the other.
That's All Right Then (tm). I have no problem with that.
[ Mind you, gratuitous divergences have their uses. :-) ]
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Dennis Ritchie
> >
> >Point being, the introduction of void to C predates C++.
>
> The base document for the language part of the C89 standard is K&R1.
> There is no mention of void in that document.
>
True. However, several changes were made to
our compilers in the beginning of the 80s,
including void, first-class structures,
structure members associated with the structure
itself. E.g. I have a version of my PDP-11
compiler with them. This might have been
before C with Classes (C++ predecessor), or
perhaps approximately contemporaneous.
Remember, also, that Bjarne was around here
and in the same group. There was definitely
information transfer.
As an aside, Bjarne is working on a paper
that urges that C and C++ remain compatible
to the extent possible. It's only a draft
so I won't quote or further summarize.
Dennis
Francis Glassborow
<ch...@phaedsys.org> writes
>and a hell of a lot agree that it is time to let C++ wander off on it's own..
Yet no voices were raised at the recent WG14 meeting against a proposal
to very substantially increase the liaison with WG21. Most were actively
in favour and exhibit a higher tolerance for the needs of those that
implement tools and write source code that works in both languages
>
>>>It'll be even more interesting to see whether they have the will-power
>>>/not/ to; C and C++ are now different languages, and there is little
>>>point in maintaining the ties between them.
>>
>>Again, many people disagree with you.
>and a lot of us agree but I would not add gratuitous differences..
As well as gratuitous incompatibilities there are accidental ones and
many of us want to reduce those.
Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.
Peter Seebach
Francis Glassborow <fran...@robinton.demon.co.uk> wrote:
>In article <clcm-2001...@plethora.net>, Chris Hills
><ch...@phaedsys.org> writes
>>and a hell of a lot agree that it is time to let C++ wander off on it's own..
>Yet no voices were raised at the recent WG14 meeting against a proposal
>to very substantially increase the liaison with WG21. Most were actively
>in favour and exhibit a higher tolerance for the needs of those that
>implement tools and write source code that works in both languages
As one of the people not objecting, I am all for liason work - as long as it
stays *WELL* clear of any kind of normative power. I would like very much to
be clear on whether a change is compatible with C++ - but I don't want to be
told I can't make an incompatible change, and I think many of us feel that
way.
I would be happier if, eventually, C++ wandered off on its own. I don't think
C++ is a good influence on C.
-s
--
Copyright 2001, all wrongs reversed. Peter Seebach / se...@plethora.net
$ chmod a+x /bin/laden Please do not feed or harbor the terrorists.
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Consulting, computers, web hosting, and shell access: http://www.plethora.net/
Francis Glassborow
<se...@plethora.net> writes
>As one of the people not objecting, I am all for liason work - as long as it
>stays *WELL* clear of any kind of normative power. I would like very much to
>be clear on whether a change is compatible with C++ - but I don't want to be
>told I can't make an incompatible change, and I think many of us feel that
>way.
And I fully support that view.
>
>I would be happier if, eventually, C++ wandered off on its own. I don't think
>C++ is a good influence on C.
Well there are quite a few who think C has a bad influence on C++ :) So
obviously we need some device to guarantee that C code will not compile
as C++ and vice-versa :)
Actually I think we should campaign against the use of 'C/C++' as it
perpetuates the view among the masses that there is such a beast. Could
CUJ be persuaded to change its title to 'The C & C++ Users Journal'?
Such a change may seem trivial but the current title gives the wrong
message.
Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.