sscanf and int64 in Win32 and Unix - different results?

[zardoz]

I've got this problem:
unsigned long long lTemp;
char cLargeNum[]="1324567890";
sscanf(clargeNum,"%llu",&lTemp);

which under Win32 isn't working*. My program needs to compile under
posix so no Win32 specials allowed....

* lTemp = -368934881...
* if I mess around with signing I can get huge but incorrect poitive
numbers.
* I'm pretty sure it works in unix (but without a debugger I can only
sprintf with %lld as an argument .. this could hide the conversion
error I spose?)

[Richard Bos]

"zardoz" <si*******@hotmail.com> wrote:

I've got this problem:

unsigned long long lTemp;
char cLargeNum[]="1324567890";
sscanf(clargeNum,"%llu",&lTemp);

which under Win32 isn't working*. My program needs to compile under
posix so no Win32 specials allowed....

* lTemp = -368934881...
This is impossible. lTemp is unsigned, so it cannot be negative. Where
did you get this value?
* if I mess around with signing I can get huge but incorrect poitive
numbers.
* I'm pretty sure it works in unix (but without a debugger I can only
sprintf with %lld as an argument .. this could hide the conversion
error I spose?)

If your sscanf() understands %llu, so should your printf(). But yes,
using the wrong specifier for your object could hide other errors.

I suspect that the above is not your actual code (if only because it
contains a typo), and that the error is elsewhere in your code. Dev-C++
has no problem with this:

#include <stdio.h>

int main(void)
{
unsigned long long temp;
char largenum[]="1324567890";
sscanf(largenum, "%llu", &temp);
printf("%llu", temp);
getchar();
}

The output is as expected. What is your exact code? Reduce to the
smallest part that still shows the error, then copy, don't retype, into
your news client, please - this avoids typos.

Richard

[websnarf]

zardoz wrote:

I've got this problem:

unsigned long long lTemp;
char cLargeNum[]="1324567890";
sscanf(clargeNum,"%llu",&lTemp);

which under Win32 isn't working*. My program needs to compile under
posix so no Win32 specials allowed....

* lTemp = -368934881...
* if I mess around with signing I can get huge but incorrect poitive
numbers.
* I'm pretty sure it works in unix (but without a debugger I can only
sprintf with %lld as an argument .. this could hide the conversion
error I spose?)

1. Older Windows compilers do not support "%llu" but instead use
"%I64u". I have written up a file named "stdint.h" that you can find
here:

http://www.pobox.com/~qed/stdint.h

which solves the problem for most platforms. Instead of the platform
dependent "%llu" or "%I64u" you would write:

"%" PRINTF_INT64_MODIFIER "u"

After including the stdint.h file.

2. If you neglect to #include <stdio.h> at the beginning its possible
that the parameters are not passed to the underlying library correctly.
(Though this is very unlikely to be the problem in this case.)

---
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Richard Bos]

we******@gmail.com wrote:

1. Older Windows compilers do not support "%llu" but instead use
"%I64u". I have written up a file named "stdint.h" that you can find
here:
[ Snip! ]
which solves the problem for most platforms. Instead of the platform
dependent "%llu" or "%I64u" you would write:

"%" PRINTF_INT64_MODIFIER "u"

You do realise that this makes your header incompatible with the ISO C99
Standard?

Richard

[zardoz]

Agreed about the signing thing. I cut and pasted your program into a
new dev studio console app and though it printed out the right number
the debugger says the long long is
14757395256856235346.

my compiler is vc dotnet 1.1 (and gcc 3 something under cygwin)

presumably you see the same thing?

thanks.

[zardoz]

eg doing a log on the number indicates that what's in memory isn't the
same as the input / output

#include <stdio.h>
#include <math.h>

int main(void)
{
unsigned long long temp;
char largenum[]="1324567890";
sscanf(largenum, "%llu", &temp);

int Rtn=log10((long double)temp);
printf("%llu : ", temp);
printf("%i", Rtn);

getchar();
}

Win32
1324567890 : 19

posix
1324567890 : 9

[websnarf]

Richard Bos wrote:

we******@gmail.com wrote:

1. Older Windows compilers do not support "%llu" but instead use
"%I64u". I have written up a file named "stdint.h" that you can find
here:

[ Snip! ]

which solves the problem for most platforms. Instead of the platform
dependent "%llu" or "%I64u" you would write:

"%" PRINTF_INT64_MODIFIER "u"

You do realise that this makes your header incompatible with the ISO C99
Standard?

Which matters what to who?

---
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Mark McIntyre]

On 26 May 2005 09:23:25 -0700, in comp.lang.c , we******@gmail.com
wrote:

Richard Bos wrote:

You do realise that this makes your header incompatible with the ISO C99
Standard?

Which matters what to who?

I suppose it would matter to anyone who
a) cares about being standards-compliant and /or
b) wants to write code that won't break in a few years time and/or
c) expects at any time to get employed in the same company as me

Since you seem not to fall into any of those categories (certainly not
the last one, I have to tell you), its not a problem for you to use
it.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[websnarf]

Mark McIntyre wrote:

On 26 May 2005 09:23:25 -0700, in comp.lang.c, we******@gmail.com wrote:

Richard Bos wrote:

You do realise that this makes your header incompatible with the ISO C99
Standard?
Which matters what to who?

I suppose it would matter to anyone who
a) cares about being standards-compliant and /or

The file is fully C89 compliant as far as I can determine.
b) wants to write code that won't break in a few years time and/or
Well no problems there! Since C89 is the final standard for C.

Actually there is an issue with C++; they may cannibalize parts of the
C99 proposal and put it into their standard. However, I can just claim
that this is meant just for C, where there is, of course, no issue.
c) expects at any time to get employed in the same company as me

Indeed, this one I have problems with. I don't think I could deal with
someone who told me "" is not a string as a coworker. That kind of
thing would just piss me off.

---
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Paul Mesken]

On 26 May 2005 14:32:50 -0700, we******@gmail.com wrote:

Mark McIntyre wrote:

On 26 May 2005 09:23:25 -0700, in comp.lang.c, we******@gmail.com wrote:

>Richard Bos wrote:
>> You do realise that this makes your header incompatible with the ISO C99
>> Standard?
>
>Which matters what to who?

I suppose it would matter to anyone who
a) cares about being standards-compliant and /or

The file is fully C89 compliant as far as I can determine.

b) wants to write code that won't break in a few years time and/or

Well no problems there! Since C89 is the final standard for C.

I agree. IMHO C99 is like the 2.88 MB floppy drive, it exists, is
better than the 1.44 but nobody has one because floppy drives are not
as important as they once were (having CDs, DVDs, etc.) and the 1.44s
are good enough and very widespread :-)

I mean : how many of us are _really_ programming in C? I believe most
of us are actually programming in C++ (or at least using a C++
compiler). C++ is based on C89, not on C99. I don't see C++ changing
its standard to conform to C99 and I don't see that many C99 compilers
for that matter.

I think the question "will it compile and run correctly on a
conforming C++ compiler?" is more important than "is it C99
compliant?".

So, this should get some live in the group ;-)

[Mark McIntyre]

On 26 May 2005 14:32:50 -0700, in comp.lang.c , we******@gmail.com
wrote:

The file is fully C89 compliant as far as I can determine.
Its possibly also K&R C compliant. And possibly ISO9000 compliant. So
what?

b) wants to write code that won't break in a few years time and/or

Well no problems there! Since C89 is the final standard for C.

Okay, I remember now, you're a trolling idiot.

c) expects at any time to get employed in the same company as me

Indeed, this one I have problems with.

I don't. I'm quite happy to think I'll never employ you.
I don't think I could deal with
someone who told me "" is not a string as a coworker. That kind of
thing would just piss me off.

Anyone who denies the existence of a published ISO standard is IMHO
neither a programmer nor a professional, and minor disagreements about
whether nothing is a string or not pale into insignificance.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Mark McIntyre]

On Fri, 27 May 2005 00:11:32 +0200, in comp.lang.c , Paul Mesken
<us*****@euronet.nl> wrote:

I mean : how many of us are _really_ programming in C?
I am.
I believe most of us are actually programming in C++
Nope. At least, not any more than I programme C or VB.
(or at least using a C++ compiler).
Nope.
C++ is based on C89, not on C99. I don't see C++ changing
its standard to conform to C99
Its hardly surprising its based on C89 (if it is) since it was
standardised before C99. And why on earth should it change to match
C99 anyway? Its a different language.
and I don't see that many C99 compilers for that matter.
There's several out there as it happens.
I think the question "will it compile and run correctly on a
conforming C++ compiler?" is more important than "is it C99
compliant?".
Why would anyone want to compile their C code with a C++ compiler?
That makes no sense at all.
So, this should get some live in the group ;-)

Probably not, most people will realise you're trolling, and killfile
you.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Martin Ambuhl]

we******@gmail.com wrote:

Well no problems there! Since C89 is the final standard for C.
Huh? Not only is C89 10 years older than the current standard, there is
no reason to think that C99 is "the final standard."
Actually there is an issue with C++; they may cannibalize parts of the
C99 proposal and put it into their standard. However, I can just claim
that this is meant just for C, where there is, of course, no issue.

I believe you are very confused.

[Martin Ambuhl]

Paul Mesken wrote:

I mean : how many of us are _really_ programming in C?
Many of us; that's why this newsgroup exists. I believe most
of us are actually programming in C++ (or at least using a C++
compiler).

Your belief is actually your own hallucination.

[Paul Mesken]

On Thu, 26 May 2005 23:25:14 +0100, Mark McIntyre
<ma**********@spamcop.net> wrote:

On Fri, 27 May 2005 00:11:32 +0200, in comp.lang.c , Paul Mesken
<us*****@euronet.nl> wrote:

I think the question "will it compile and run correctly on a
conforming C++ compiler?" is more important than "is it C99
compliant?".

Why would anyone want to compile their C code with a C++ compiler?
That makes no sense at all.

I could think of a couple of reasons. A certain C++ compiler might be
a very attractive development platform (with neat components for the
GUI, etc.). It is nice if it accepts C code, and a lot of C code will
be accepted by it (there are a couple of pitfalls to watch out for,
though).

Of course, _technically_ that C code would be C++ code but it would
compile and run on both C and C++ compilers.

How's that for portability of C code? :-)

Of course, one could maintain that C++ is a _completely_ different
language than C and that C is not a subset of C++ at all. Indeed, C is
not a subset of C++ but it is about as close as it can get to it.

But let me put it another way then :

Would you make use of C99 constructs of which you know that they won't
compile on a C89/90 compiler? (like compound literals, designated
initializers, etc.).

This would make your code less portable since C99 compilers are by no
means as widespread as C89/90 compilers or C++ compilers that can
accept C89/90 code (barring the few pitfalls, of course).

Of course, one can say that, in the future, the support for C99 will
be as widespread as that of C89/90. But I'm not so sure of it and
we're not living in the future yet.

So, this should get some live in the group ;-)

Probably not, most people will realise you're trolling, and killfile
you.

Well, at least I _believed_ that most C programmers here actually make
use of a C++ compiler. You're far more certain of their behaviour :-)

And I wasn't trolling, I haven't mentioned Assembly (yet ;-)

[Paul Mesken]

On Thu, 26 May 2005 23:22:17 +0100, Mark McIntyre
<ma**********@spamcop.net> wrote:

On 26 May 2005 14:32:50 -0700, in comp.lang.c , we******@gmail.com
wrote:

Well no problems there! Since C89 is the final standard for C.

Okay, I remember now, you're a trolling idiot.

I think he has a point. Even though there is the newer C99 and perhaps
some more standards in the future, I think it is wisest to stick to
C89/90. C is losing territory to C++ and I don't see C99 becoming as
well supported as C89/90.

I think it's a wiser choice to make sure that the C code will also
compile on a C++ compiler (for future portability).

Of course, I might be terribly misguided but I'm known to respond to
good arguments so let's hear some :-)

[Old Wolf]

Paul Mesken wrote:

we******@gmail.com wrote:

Mark McIntyre wrote:

we******@gmail.com wrote:
Richard Bos wrote:
> You do realise that this makes your header incompatible
> with the ISO C99 Standard?
Which matters what to who?

I suppose it would matter to anyone who
a) cares about being standards-compliant and /or
The file is fully C89 compliant as far as I can determine.

Nobody has mentioned this explicitly, but the problem is that
C99 contains a header <stdint.h> . So naming your own file
stdint.h is asking for trouble. It doesn't seem inconceivable
that a compiler with both C89 and C99 modes could break when
the user tries to call their own file the same name as a
standard header.
I mean : how many of us are _really_ programming in C?
Posting in comp.lang.c, I think you are going to get a lot
more "Me!" answers to this one, than "not me!"
I believe most of us are actually programming in C++
(or at least using a C++ compiler).
Although I use C and C++, I compile C with a C compiler and
C++ with a C++ compiler ! In fact my compiler automatically
determines based on the file extension.

I don't know of any C++ compilers that do not either
have a C mode, or come packaged with a C compiler.

Can you name one?
I think the question "will it compile and run correctly on a
conforming C++ compiler?" is more important than "is it C99
compliant?".

You're in a minority, at least among posters to this newsgroup.
The most important question is "Does this conform to the
standard that I'm trying to conform to?" I suppose the second-most
question is "Is it worth tring to conform to that standard?"

[CBFalconer]

Paul Mesken wrote:

.... snip ...
Well, at least I _believed_ that most C programmers here actually
make use of a C++ compiler. You're far more certain of their
behaviour :-)

They are quite likely to use a compiler that has both C and C++
modes available. That doesn't mean they are compiling with a C++
compiler. Some of those compilers automatically adjust their modes
based on the extension of the source file, thus confusing unaware
users who name their sources as .C (upper case) or .cpp.

--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

[Richard Bos]

Paul Mesken <us*****@euronet.nl> wrote:

On 26 May 2005 14:32:50 -0700, we******@gmail.com wrote:

Mark McIntyre wrote:

On 26 May 2005 09:23:25 -0700, in comp.lang.c, we******@gmail.com wrote:
>Richard Bos wrote:
>> You do realise that this makes your header incompatible with the ISO C99
>> Standard?
>
>Which matters what to who? b) wants to write code that won't break in a few years time and/or
Well no problems there! Since C89 is the final standard for C.

I agree.

What a surprise.
I mean : how many of us are _really_ programming in C?
*Raises hands*
I believe most of us are actually programming in C++ (or at least
using a C++ compiler).

I don't know about "most of us", but it's not true in my case, anyway.

Richard

[Keith Thompson]

we******@gmail.com writes:

Richard Bos wrote:

we******@gmail.com wrote:

> 1. Older Windows compilers do not support "%llu" but instead use
> "%I64u". I have written up a file named "stdint.h" that you can find
> here:

[ Snip! ]

> which solves the problem for most platforms. Instead of the platform
> dependent "%llu" or "%I64u" you would write:
>
> "%" PRINTF_INT64_MODIFIER "u"

You do realise that this makes your header incompatible with the ISO C99
Standard?

Which matters what to who?

If nothing else, the C99 standard provides guidance for extensions in
C90 implementations. The C99 standard header <stdint.h> provides a
number of declarations that can be quite useful even for C90 code. If
an implementer wants to provide these declarations as an extension, or
if a programmer wants them as part of a program, it makes sense to do
so in a header file called "stdint.h". Writing your own "stdint.h"
header with incompatible declarations will cause confusion, which is
trivially avoided by changing the name of the header. (I'm not sure
why you'd want to call it "stdint.h" anyway, since it's not standard.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Michael Wojcik]

In article <7h********************************@4ax.com>, Paul Mesken <us*****@euronet.nl> writes:

I mean : how many of us are _really_ programming in C?
I don't know how many of you are, but quite a large number of us are.
I believe most
of us are actually programming in C++ (or at least using a C++
compiler).
Your belief is unfounded, for various reasonable values of "us".
C++ is based on C89, not on C99. I don't see C++ changing
its standard to conform to C99 and I don't see that many C99 compilers
for that matter.
It is possible that what you see does not precisely correspond with
reality.
I think the question "will it compile and run correctly on a
conforming C++ compiler?" is more important than "is it C99
compliant?".

You're welcome to think whatever you like. Most of us[1] who actually
write C do not care whether our C code is acceptable to a conforming
C++ compiler, any more than we care if it is acceptable to a Fortran
compiler or a LISP interpreter or a Jacquard loom.
1. There are some exceptions; the canonical one in c.l.c is
Dinkumware, who have good reason to write code which is both portable
C and portable C++. However, few of us are in the implementation
business.

--
Michael Wojcik mi************@microfocus.com

When [Columbus] landed on America it was more like an evasion than a
discovery. -- Matt Walsh

[Chris Croughton]

On Fri, 27 May 2005 07:52:19 GMT, Richard Bos
<rl*@hoekstra-uitgeverij.nl> wrote:

Paul Mesken <us*****@euronet.nl> wrote:

I mean : how many of us are _really_ programming in C?

*Raises hands*

Well, I'm not at the moment because I'm reading and replying to Usenet,
but my job is about programming in C.

I believe most of us are actually programming in C++ (or at least
using a C++ compiler).

I don't know about "most of us", but it's not true in my case, anyway.

I use C++ as well, but I know which one I'm using for particular things.
Some I write in C, for maximum portability (more systems have C
compilers installed than C++ compilers), some I write in C++ for use of
features in that language. When I get around to installing an Ada
compiler I'll use that for some things, but even though it will be
provided with the same command line interface (GCC) it still won't be a
C or C++ compiler.

Chris C

[Mark McIntyre]

On Fri, 27 May 2005 01:48:08 +0200, in comp.lang.c , Paul Mesken
<us*****@euronet.nl> wrote:

I could think of a couple of reasons. A certain C++ compiler might be
a very attractive development platform (with neat components for the
GUI, etc.).
So might a .net compiler. Whats your point?
But let me put it another way then :

Would you make use of C99 constructs of which you know that they won't
compile on a C89/90 compiler? (like compound literals, designated
initializers, etc.).

If I had to use a C89 compiler, obviously not. But then if I was
compiling for a K&R C compiler, or a fortran compiler etc. I'm really
not sure what your point is.

Probably not, most people will realise you're trolling, and killfile
you.

Well, at least I _believed_ that most C programmers here actually make
use of a C++ compiler. You're far more certain of their behaviour :-)

You seel to have b*gger all experience of using different C++
compilers. We've just ported a raft of stuff from VC6 to VC7, and from
gcc332 to gcc341. Both migrations were a pain in the a*ss, especially
as the result had to compile on both VC7 *and* gcc341.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Mark McIntyre]

On Fri, 27 May 2005 02:01:37 +0200, in comp.lang.c , Paul Mesken
<us*****@euronet.nl> wrote:

On Thu, 26 May 2005 23:22:17 +0100, Mark McIntyre
<ma**********@spamcop.net> wrote:

On 26 May 2005 14:32:50 -0700, in comp.lang.c , we******@gmail.com
wrote:

Well no problems there! Since C89 is the final standard for C.

Okay, I remember now, you're a trolling idiot.

I think he has a point.

If his point is "at the moment, there are more people using
C89-compliant compilers than C99-compliant ones" then I'd agree.

If his point is "C99 doesn't exist," then clearly he's talking
bollocks.
I don't see C99 becoming as well supported as C89/90.
I'm sure people said that about C89 "it'll never catch on, this
newfangled prototype stuff".
I think it's a wiser choice to make sure that the C code will also
compile on a C++ compiler (for future portability).

What you're saying is "write C++ but make it compile on a C compiler".
Thats daft. If I'm writing C++ I use templates, new, iterators etc
etc. If you force your code to be C compatible, you throw away the
entire point of writing C++.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Paul Mesken]

On Fri, 27 May 2005 23:04:05 +0100, Mark McIntyre
<ma**********@spamcop.net> wrote:

On Fri, 27 May 2005 02:01:37 +0200, in comp.lang.c , Paul Mesken
<us*****@euronet.nl> wrote:

I think it's a wiser choice to make sure that the C code will also
compile on a C++ compiler (for future portability).

What you're saying is "write C++ but make it compile on a C compiler".
Thats daft. If I'm writing C++ I use templates, new, iterators etc
etc. If you force your code to be C compatible, you throw away the
entire point of writing C++.

Nonono, I say it's wise to make C code (not C++ code) conforming to
C89/90 that _also_ compiles on a conforming C++ compiler (which can do
C89/90 anyway).

Surely that musn't be too hard to grasp.

What I'm saying is that I believe that it is more probable that C code
needs to be ported to C++ than C99 (based on my belief that C++ will
be more popular than C99).

Obviously, you believe that C99 is a huge success and that there is no
need to be so prudent. But neither MS VC++.not nor Borland Builder
does C99.

I don't say that one shouldn't write C++ at all, only that if you
write C, it should be C89/90 because it's better supported, also by
C++ compilers.

[Keith Thompson]

Paul Mesken <us*****@euronet.nl> writes:

On Fri, 27 May 2005 23:04:05 +0100, Mark McIntyre
<ma**********@spamcop.net> wrote:

On Fri, 27 May 2005 02:01:37 +0200, in comp.lang.c , Paul Mesken
<us*****@euronet.nl> wrote:

I think it's a wiser choice to make sure that the C code will also
compile on a C++ compiler (for future portability).

What you're saying is "write C++ but make it compile on a C compiler".
Thats daft. If I'm writing C++ I use templates, new, iterators etc
etc. If you force your code to be C compatible, you throw away the
entire point of writing C++.

Nonono, I say it's wise to make C code (not C++ code) conforming to
C89/90 that _also_ compiles on a conforming C++ compiler (which can do
C89/90 anyway).

Surely that musn't be too hard to grasp.

No, it's not hard to grasp. We just think you're wrong. (When I say
"we", I don't claim to speak for everyone in the group, but I believe
I represent the majority view of the experts.)

Except in rare circumstances, there is no need for C code to be
restricted to the common subset of C and C++.

If I did have a need to write in the common subset of C and C++, I
would regularly test my code with both C and C++ compilers, which
would be a considerable increase of effort compared to just
programming in C. I *think* I know how to avoid incompatibilities,
but mistakes are inevitable; I might invoke a macro with a character
constant as an argument and forget that the macro uses sizeof, for
example. If there's no real benefit to maintaining C++ compatibility,
I'm not going to bother.

[snip]
Obviously, you believe that C99 is a huge success and that there is no
need to be so prudent. But neither MS VC++.not nor Borland Builder
does C99.

I don't say that one shouldn't write C++ at all, only that if you
write C, it should be C89/90 because it's better supported, also by
C++ compilers.

I don't think anyone here has claimed that C99 is a "huge success".
We were refuting Paul Hsieh's manifestly untrue statement, with which
you agreed, that "C89 is the final standard for C". There is
*partial* support for C99 in many compilers, and full support in a
few, and there's nothing wrong with taking advantage of that support
as long as you're careful about it. (I suspect that when/if gcc
provides full C99 support, it's going to be a tremendous boost for the
new standard's popularity.)

It often makes sense to use C89/C90 because it's better supported by C
compilers. The fact that it's better supported by C++ compilers is
largely irrelevant.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Mark McIntyre]

On Sat, 28 May 2005 19:51:10 +0200, in comp.lang.c , Paul Mesken
<us*****@euronet.nl> wrote:

On Fri, 27 May 2005 23:04:05 +0100, Mark McIntyre
<ma**********@spamcop.net> wrote:

What you're saying is "write C++ but make it compile on a C compiler".
Nonono, I say it's wise to make C code (not C++ code) conforming to
C89/90 that _also_ compiles on a conforming C++ compiler (which can do
C89/90 anyway).

Well, a) no it can't, not unless its also a C compiler and b) no its
not especially wise. And bear in mind that for your code to compile
in a C++ compiler, it has to actually *be* C++ code.
Surely that musn't be too hard to grasp.
Its easy to grasp, just IMHO rubbish.
What I'm saying is that I believe that it is more probable that C code
needs to be ported to C++ than C99 (based on my belief that C++ will
be more popular than C99).
I find it hard to concieve of anyone wanting to port a large C project
to C++, without wanting / needing to extensively rewrite it anyway, so
this seems to be not only incorrect but a big waste of time. YMMV.
Obviously, you believe that C99 is a huge success and that there is no
need to be so prudent.
I've never said that.
But neither MS VC++.not nor Borland Builder does C99.

So what? There's plenty of good compilers that do enough of it.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[CBFalconer]

Paul Mesken wrote:

.... snip ...
Nonono, I say it's wise to make C code (not C++ code) conforming
to C89/90 that _also_ compiles on a conforming C++ compiler (which
can do C89/90 anyway).

Surely that musn't be too hard to grasp.

What I'm saying is that I believe that it is more probable that C
code needs to be ported to C++ than C99 (based on my belief that
C++ will be more popular than C99).

There is absolutely no need for that. C++ uses:

extern "C" { /* C stuff */ }

to determine how to link, keyed on the __cplusplus identifier. All
you have to do is write your headers appropriately and your C code,
while remaining C, is usuable in a C++ system. C compilers are
forbidden from defining __cplusplus.

--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

[websnarf]

Keith Thompson wrote:

Paul Mesken <us*****@euronet.nl> writes:

Nonono, I say it's wise to make C code (not C++ code) conforming to
C89/90 that _also_ compiles on a conforming C++ compiler (which can do
C89/90 anyway).

Surely that musn't be too hard to grasp.
No, it's not hard to grasp. We just think you're wrong. (When I say
"we", I don't claim to speak for everyone in the group, but I believe
I represent the majority view of the experts.)

Except in rare circumstances, there is no need for C code to be
restricted to the common subset of C and C++.

Those rare circumstances include cases where C code is directly
included in C++ projects. I.e., its actually extremely common.
If I did have a need to write in the common subset of C and C++, I
would regularly test my code with both C and C++ compilers, which
would be a considerable increase of effort compared to just
programming in C.
There are such a thing as makefiles and unit tests. Maybe some of the
"experts" in this group can tell you about them.
[...] I *think* I know how to avoid incompatibilities,
but mistakes are inevitable; I might invoke a macro with a character
constant as an argument and forget that the macro uses sizeof, for
example. If there's no real benefit to maintaining C++ compatibility,
I'm not going to bother.
Yeah and if your code doesn't need more than 640K, I don't think you
should bother about that either.

Obviously, you believe that C99 is a huge success and that there is no
need to be so prudent. But neither MS VC++.not nor Borland Builder
does C99.
Dude *NOBODY* serious does C99 ... its not just a case of a few high
profile vendors.
I don't say that one shouldn't write C++ at all, only that if you
write C, it should be C89/90 because it's better supported, also by
C++ compilers.

I don't think anyone here has claimed that C99 is a "huge success".
We were refuting Paul Hsieh's manifestly untrue statement, with which
you agreed, that "C89 is the final standard for C".

I am speaking from the point of view of a programmer. You can't
program to the C99 standard, so in what sense does it exist to
programmers?
[...] There is *partial* support for C99 in many compilers,
Yes, these occupy the exact same usefulness as an compiler extension.
But they are also have exactly the same problems as well -- i.e., they
are not portable.
[...] and full support in a few,
That do not enjoy serious support.
[...] and there's nothing wrong with taking advantage of that support
as long as you're careful about it.
You lose portability -- so yes indeed you have to be careful that you
don't ever try to move the other code to another compiler.
[...] (I suspect that when/if gcc provides full C99 support, it's going to
be a tremendous boost for the new standard's popularity.)
And exactly what justifies your holding out hope for this? gcc has
moved to version 3, then 4 without making any progress on C99 support.
They have documented an extremely serious issue (enabling support for
variable length arrays apparently would break many a lot of the FSF
applications) that is preventing them from implementing C99. But more
importantly, nobody cares.
It often makes sense to use C89/C90 because it's better supported by C
compilers. The fact that it's better supported by C++ compilers is
largely irrelevant.

As you know the C++ standard is much younger and immensely harder to
implement. And unlike C99, every vendor is converging towards total,
or near total support.

---
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Dik T. Winter]

In article <11********************@g47g2000cwa.googlegroups.c om> we******@gmail.com writes:

Keith Thompson wrote:

....

Except in rare circumstances, there is no need for C code to be
restricted to the common subset of C and C++.

Those rare circumstances include cases where C code is directly
included in C++ projects. I.e., its actually extremely common.

I have an (I admit pretty old) C and Fortran project. The C code is
11981 lines for 328282 bytes of code. I should bother to make it
C++ compatible, while about one third of the code is just to avoid
bugs in particular compilers? You must be kidding.

If you write code, as you do, with the intention that it is also
included in C++ projects, you have a point. But all C code I ever
have written is not intended to be included in C++ projects, so
why should I bother?

Moreover, my first encounter with C++ was when it was still a moving
target. I had this program that should be implemented on both SGI
(for which it was written) and on Sun. It was *impossible* to get
a single source that would compile on both. And that has taken me
quite some time. Since then I try to avoid C++.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[websnarf]

Dik T. Winter wrote:

In article <11********************@g47g2000cwa.googlegroups.c om> we******@gmail.com writes:

> Keith Thompson wrote: ...

> > Except in rare circumstances, there is no need for C code to be
> > restricted to the common subset of C and C++.

>
> Those rare circumstances include cases where C code is directly
> included in C++ projects. I.e., its actually extremely common.

I have an (I admit pretty old) C and Fortran project. The C code is
11981 lines for 328282 bytes of code. I should bother to make it
C++ compatible, while about one third of the code is just to avoid
bugs in particular compilers? You must be kidding.

I notice that a lot of people in this groups have either chronic and
severe literacy problems, or massive comprehension defficiencies (I'll
stop short of suggesting that its aggressive retardation). You of
course missed the part that you just quoted directly above your
paragraph here where I said:

"Those rare circumstances include cases where C code is directly
included in C++ projects. I.e., its actually extremely common."

Now, if you actually try to fire some neurons between your ears, you
might notice that this sentence does not imply or recommend that you
make your C + Fortran project C++ compatible.
If you write code, as you do, with the intention that it is also included in C++ projects,
you have a point.
Actually, I have a proclivity to write code for external consumption
outside of my own personal control. In an effort to enhance the value
of such code, I often try to make it as universal as possible. But of
course, this does not describe *all* the code I write.
[...] But all C code I ever
have written is not intended to be included in C++ projects, so
why should I bother?
I dunno, who said you should bother?
Moreover, my first encounter with C++ was when it was still a moving
target. I had this program that should be implemented on both SGI
(for which it was written) and on Sun. It was *impossible* to get
a single source that would compile on both. And that has taken me
quite some time. Since then I try to avoid C++.

Interesting that the history of C was quite similar in this respect, at
least as I clearly recall it.

---
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Keith Thompson]

we******@gmail.com writes:
[...]

I notice that a lot of people in this groups have either chronic and
severe literacy problems, or massive comprehension defficiencies (I'll
stop short of suggesting that its aggressive retardation).

If you can manage to discuss technical matters without stooping to
personal abuse, I'll be happy to join you, even (or especially) if I
don't agree with you. Until then -- well, I don't use a killfile, but
if I did you'd be in it. Bye.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Paul Mesken]

On 28 May 2005 18:32:23 -0700, we******@gmail.com wrote:

Keith Thompson wrote:

Paul Mesken <us*****@euronet.nl> writes:

> Nonono, I say it's wise to make C code (not C++ code) conforming to
> C89/90 that _also_ compiles on a conforming C++ compiler (which can do
> C89/90 anyway).
>
> Surely that musn't be too hard to grasp.

No, it's not hard to grasp. We just think you're wrong. (When I say
"we", I don't claim to speak for everyone in the group, but I believe
I represent the majority view of the experts.)

Except in rare circumstances, there is no need for C code to be
restricted to the common subset of C and C++.

Those rare circumstances include cases where C code is directly
included in C++ projects. I.e., its actually extremely common.

Thank God! I was beginning to get the impression that I was the only
one doing such a thing :-)

To give an example : right now I'm doing a little hobby project making
a strategy game. The game's logic (its core, the "engine") is written
in C (even freestanding, it doesn't need the C library). This
maximizes its portability and the files are separated from the rest.
This is a Good Thing because I intend the thing to be public domain.

The game's engine _is_ basically the game but it still has to
communicate with the players (either human or AI), save and load
files, allocate memory for the game's data, etc.

These things are programmed in C++ and make use of some extensions
offered by my C++ compiler (wrapped in classes, of course).

[Keith Thompson]

Paul Mesken <us*****@euronet.nl> writes:

On 28 May 2005 18:32:23 -0700, we******@gmail.com wrote: [...]

Those rare circumstances include cases where C code is directly
included in C++ projects. I.e., its actually extremely common.

Thank God! I was beginning to get the impression that I was the only
one doing such a thing :-)

To give an example : right now I'm doing a little hobby project making
a strategy game. The game's logic (its core, the "engine") is written
in C (even freestanding, it doesn't need the C library). This
maximizes its portability and the files are separated from the rest.
This is a Good Thing because I intend the thing to be public domain.

<OT>
Be sure you know what "public domain" means. It's not the same thing
as "open source" or "freeware".
</OT>
The game's engine _is_ basically the game but it still has to
communicate with the players (either human or AI), save and load
files, allocate memory for the game's data, etc.

These things are programmed in C++ and make use of some extensions
offered by my C++ compiler (wrapped in classes, of course).

This sounds like a perfect job for C++'s extern "C" construct.

Your description seems to imply that you compile your entire program,
including the "engine", with a C++ compiler. If you never use a C
compiler, what's the benefit of restricting the "engine" code to the
C-compatible subset of C++? Why not just use C++?

On the other hand, if you compile the "engine" code with a C compiler
and use extern "C" to interface to it, what's the benefit of
restricting it to the C++-compatible subset of C? The only real
restrictions I can think of are that you need to avoid using C++
keywords and types, like long long, that don't exist in C++; these
restrictions apply only to external declarations.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Paul Mesken]

On Sun, 29 May 2005 20:58:14 GMT, Keith Thompson <ks***@mib.org>
wrote:

Paul Mesken <us*****@euronet.nl> writes:

On 28 May 2005 18:32:23 -0700, we******@gmail.com wrote:[...]

Those rare circumstances include cases where C code is directly
included in C++ projects. I.e., its actually extremely common.

Thank God! I was beginning to get the impression that I was the only
one doing such a thing :-)

To give an example : right now I'm doing a little hobby project making
a strategy game. The game's logic (its core, the "engine") is written
in C (even freestanding, it doesn't need the C library). This
maximizes its portability and the files are separated from the rest.
This is a Good Thing because I intend the thing to be public domain.

<OT>
Be sure you know what "public domain" means. It's not the same thing
as "open source" or "freeware".
</OT>

Yeah, I'm gonna throw it in public (the source and a windoze program)
and everyone can change it, use it, etc. It will not be copyrighted.

The game (which is quite simple in itself but hard to play for AIs) is
meant as a simple testbed platform to test out AI ideas. The game has
"fog of war", limited resources, etc. all the stuff that is hard for
an AI because succesfull play involves dynamic information gathering,
planning and speculation. It's not that I expect to make any money
from it at all. It's just a hobby project.

The amazing (or not) part was that it was hardest to bring back the
game to its essentials and to balance the consequences of choices a
player can make (avoiding loopholes and a "perfect strategy" that
always works). The simplest games are the hardest to make :-)
Your description seems to imply that you compile your entire program,
including the "engine", with a C++ compiler. If you never use a C
compiler, what's the benefit of restricting the "engine" code to the
C-compatible subset of C++? Why not just use C++?

C is more portable and generates, typically, less code than C++. C is
a favorite language for embedded systems and old machines with little
memory. I don't believe C++ is. Who knows? Someone might want to make
a version for some homebrewn computer or a lousy, old 8 bit system :-)

It's hardly profitable for me to program the engine in C++ (apart from
that I constantly have to pass a pointer to the game object in C).

[Mark McIntyre]

On 28 May 2005 18:32:23 -0700, in comp.lang.c , we******@gmail.com
wrote:

Those rare circumstances include cases where C code is directly
included in C++ projects. I.e., its actually extremely common.
Rubbish, IME. I've been in the business for 15 years, and have only
twice come across this. One was a case where somehing was too complex
to be rewritten. The other was plain laziness. And in any events if
you need to do this, use a library, not the source. There's no reason
to need to mix source.

But hten, I don't know why I'm answering you. You're a troll.
There are such a thing as makefiles and unit tests. Maybe some of the
"experts" in this group can tell you about them.
You've *clearly* never worked on a large project. Duplication of build
and testing time is *not* trivial, makefiles and unit test suites
notwithstanding. We have to build a system for three platforms and two
compiler suites, and a full rebuild and retest can take days thanks to
the solaris build alone taking over 24 hours.
Dude *NOBODY* serious does C99 ... its not just a case of a few high
profile vendors.

Dork.

I don't think anyone here has claimed that C99 is a "huge success".
We were refuting Paul Hsieh's manifestly untrue statement, with which
you agreed, that "C89 is the final standard for C".

I am speaking from the point of view of a programmer. You can't
program to the C99 standard,

You can. Your own manifestly limited experience is no guide.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Keith Thompson]

Paul Mesken <us*****@euronet.nl> writes:

On Sun, 29 May 2005 20:58:14 GMT, Keith Thompson <ks***@mib.org>
wrote:

Paul Mesken <us*****@euronet.nl> writes: [...]

This is a Good Thing because I intend the thing to be public domain.

<OT>
Be sure you know what "public domain" means. It's not the same thing
as "open source" or "freeware".
</OT>

Yeah, I'm gonna throw it in public (the source and a windoze program)
and everyone can change it, use it, etc. It will not be copyrighted.

Or sell it without giving you a dime. It's your call, of course.

[...]

Your description seems to imply that you compile your entire program,
including the "engine", with a C++ compiler. If you never use a C
compiler, what's the benefit of restricting the "engine" code to the
C-compatible subset of C++? Why not just use C++?

C is more portable and generates, typically, less code than C++. C is
a favorite language for embedded systems and old machines with little
memory. I don't believe C++ is. Who knows? Someone might want to make
a version for some homebrewn computer or a lousy, old 8 bit system :-)

It's hardly profitable for me to program the engine in C++ (apart from
that I constantly have to pass a pointer to the game object in C).

I notice that you didn't actually answer my question. Do you compile
the "engine" code with a C compiler or with a C++ compiler?

If you're using a C++ compiler then you're really programming in (a
subset of) C++. If your concern is smaller code, it makes probably
sense to use a subset of C++, but there's no particular reason that
subset has to be C-compatible. And if your system as a whole depends
on C++, there's little point in maintaining portability to systems
that don't have C++ compilers.

On the other hand, if you're using a C compiler, there's little point
in restricting yourself to the C++-compatible subset of C. Just stick
to the C90 standard and your code will be as portable as it needs to
be.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Paul Mesken]

On Sun, 29 May 2005 23:17:08 +0100, Mark McIntyre
<ma**********@spamcop.net> wrote:

But hten, I don't know why I'm answering you. You're a troll.
Then let me enlighten you :
You've *clearly* never worked on a large project. Dork. Your own manifestly limited experience is no guide.

Ah yes, it's the same old story. Now that you're wriggling in the iron
grip of reason you're performing a last ditch effort to save some face
by defying your betters.

Your feeble skills are no match for the Dark Side of the Code.

(if you're trolling, troll with style :-)

[Paul Mesken]

On Sun, 29 May 2005 22:31:32 GMT, Keith Thompson <ks***@mib.org>
wrote:

I notice that you didn't actually answer my question. Do you compile
the "engine" code with a C compiler or with a C++ compiler?
Oops, sorry about that.

I use a C++ compiler (Borland Builder in this case).
If you're using a C++ compiler then you're really programming in (a
subset of) C++. If your concern is smaller code, it makes probably
sense to use a subset of C++, but there's no particular reason that
subset has to be C-compatible. And if your system as a whole depends
on C++, there's little point in maintaining portability to systems
that don't have C++ compilers.

The "engine" of the game processes user input (the functions that
actually fetch that input are not portable and outside of the engine),
updates the game object (if necessary) and sends messages to the
players (the actual sending of the messages is performed by functions
invoked by function pointers and those functions are also outside the
game engine).

There are, basically, only two functions that are invoked from outside
the engine : ProcessMessage() and InitializeGame(). The whole engine
acts like a black box (you put stuff in and stuff comes out of it),
it's message driven.

This will all be done in C (freestanding) for maximum portability.

But this is not enough to have a running game implementation. There
are other functions necessary to make a working implementation of the
game, besides this engine. This involves communication with the player
(pipes, TCP/IP, direct, etc.), file management (saving games,
recording moves, loading maps), memory allocation (for the game object
itself and some workbuffers), the GUI (a very simple one to begin
with), etc.

These things are not portable (heck! you can't even clear the screen
with conforming C or C++ ;-)

I'll first make a simple application out of all of this (to test the
gameplay itself) and then proceed to make a little game server (a kind
of daemon) which can handle a lot of games simultaneously and gets
user input over the network (so that different AIs on different
machines can fight each other).

But my working game implementation will be all windows. Someone else
might take the "engine" (which is the portable core of it all) and
make a Linux implementation.

The only part that needs to be highly portable is the "engine" and
therefor it is written in C (freestanding). It doesn't really matter
in what language the other parts are written. They're not portable and
the engine doesn't need them. The engine is like a black box, it
communicates by sending and receiving messages in a simple char array
and it gets a pointer to a game object from outside.

Now, the reason why these non-engine parts are written in C++ is not
so much because of the language itself but because of the compiler
that has some neat extensions that will ease development of the
non-engine parts.

These components, however, are wrapped in classes so I have to program
in C++ if I want to use these components (one of my all time favorites
is the TStringGrid, I use it for almost everything :-)

The engine itself I could just as well develop on a C compiler. But I
think of it as easier to add some units (as Builder calls them) rather
than link object files or even libraries (especially in the case of
Builder, I don't even believe it can handle COFF :-) and it makes
debugging easier since I need the whole game to conveniently test the
engine.

[Richard Bos]

we******@gmail.com wrote:

Keith Thompson wrote:

Paul Mesken <us*****@euronet.nl> writes:

Nonono, I say it's wise to make C code (not C++ code) conforming to
C89/90 that _also_ compiles on a conforming C++ compiler (which can do
C89/90 anyway).

Surely that musn't be too hard to grasp.

No, it's not hard to grasp. We just think you're wrong. (When I say
"we", I don't claim to speak for everyone in the group, but I believe
I represent the majority view of the experts.)

Except in rare circumstances, there is no need for C code to be
restricted to the common subset of C and C++.

Those rare circumstances include cases where C code is directly
included in C++ projects. I.e., its actually extremely common.

extern "C".

HTH; HAND.

Richard

[Mark McIntyre]

On Mon, 30 May 2005 00:55:37 +0200, in comp.lang.c , Paul Mesken
<us*****@euronet.nl> wrote:

On Sun, 29 May 2005 23:17:08 +0100, Mark McIntyre
<ma**********@spamcop.net> wrote:

But hten, I don't know why I'm answering you. You're a troll.
Then let me enlighten you :

Feel free. Are you websnarf's sockpuppet, or a different paul? I'd
assumed the latter but if you want to defend him, feel free to become
the former.
Ah yes, it's the same old story. Now that you're wriggling in the iron
grip of reason you're performing a last ditch effort to save some face
by defying your betters.

ROFL. Keep going, you are quite amusing.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[websnarf]

Richard Bos wrote:

we******@gmail.com wrote:

Keith Thompson wrote:

Paul Mesken <us*****@euronet.nl> writes:
> Nonono, I say it's wise to make C code (not C++ code) conforming to
> C89/90 that _also_ compiles on a conforming C++ compiler (which can do
> C89/90 anyway).
>
> Surely that musn't be too hard to grasp.

No, it's not hard to grasp. We just think you're wrong. (When I say
"we", I don't claim to speak for everyone in the group, but I believe
I represent the majority view of the experts.)

Except in rare circumstances, there is no need for C code to be
restricted to the common subset of C and C++.

Those rare circumstances include cases where C code is directly
included in C++ projects. I.e., its actually extremely common.

extern "C".

This is used only to make C++ code C-linkable. By itself it only
solves half the problem (allowing C code interface to C++). There is
the problem of the other direction -- since C is a near subset of C++,
you still need to make your code compilable both in C and C++.

Just to prove that I am not only talking inward, rather than bring up
the obvious example (Bstrlib) I'll just cite another one that I had
nothing to do with: PCRE. Its the definitive universally available
Perl-compatible regular expression library for C. However, the author
has used a __cplusplus guarded extern "C", to make sure that it
compiles simultaneously in C and C++. TO be consistent this ends up
forcing the author to continue follow the scheme I suggest, which is to
write C code that simultaneously follows the C++ standard. Not
surprisingly, there is no attempt to include any C99 features
(__STDC_VERSION >= 199901L guarded or not).

Do you think the author did this just for fun? Like me, and most other
serious programmers who still dabble in C, he knows the score. If he
wants anyone besides himself to pay attention to his efforts he has to
write code in the intersection of C and C++, with the expectation that
his code will be directly included in C++ projects.

---
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Chris Torek]

>Richard Bos wrote:

extern "C".

In article <11*********************@g43g2000cwa.googlegroups. com>
<we******@gmail.com> wrote:This is used only to make C++ code C-linkable.
This is incorrect.
By itself it only solves half the problem (allowing C code
interface to C++).
It also allows C++ code to call C code. Which is precisely what
you want to do; you simply have not realized that.
you still need to make your code compilable both in C and C++.

So you had better not use any C++ constructs in your C++ code,
so that you can compile it with a C compiler.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Keith Thompson]

we******@gmail.com writes:

Richard Bos wrote:

we******@gmail.com wrote: [...]

> Those rare circumstances include cases where C code is directly
> included in C++ projects. I.e., its actually extremely common.
extern "C".

This is used only to make C++ code C-linkable.

No, it's used to make C code C++-linkable.
By itself it only
solves half the problem (allowing C code interface to C++). There is
the problem of the other direction -- since C is a near subset of C++,
you still need to make your code compilable both in C and C++.

Just to prove that I am not only talking inward, rather than bring up
the obvious example (Bstrlib) I'll just cite another one that I had
nothing to do with: PCRE. Its the definitive universally available
Perl-compatible regular expression library for C. However, the author
has used a __cplusplus guarded extern "C", to make sure that it
compiles simultaneously in C and C++. TO be consistent this ends up
forcing the author to continue follow the scheme I suggest, which is to
write C code that simultaneously follows the C++ standard. Not
surprisingly, there is no attempt to include any C99 features
(__STDC_VERSION >= 199901L guarded or not).

Do you think the author did this just for fun? Like me, and most other
serious programmers who still dabble in C, he knows the score. If he
wants anyone besides himself to pay attention to his efforts he has to
write code in the intersection of C and C++, with the expectation that
his code will be directly included in C++ projects.

"websnarf" has misunderstood the code in PCRE. I've just downloaded
and compiled it. It's written in C, not C++. The pcre.h header has
the following:

/* Allow for C++ users */

#ifdef __cplusplus
extern "C" {
#endifn

/* lots of stuff */

#ifdef __cplusplus
} /* extern "C" */
#endif

This allows a C++ program to use '#include "pcre.h"' and use the
package -- but the software itself is written in C. I don't know (or
care) whether it's written in a C++-compatible subset of C. The
installation procedure is the usual "configure;make;make install"; the
PCRE code itself is compiled with a C compiler, not with C++ compiler.

The PCRE code can be used by C++ code, but there is no need for the
PCRE code itself to be compatible with C++.

The PCRE documentation itself says:

PCRE is written in C and released as a C library. However, a
number of people have written wrappers and interfaces of
various kinds. A C++ class is included in these contribu-
tions, which can be found in the Contrib directory at the
primary FTP site
[...]

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Mark McIntyre]

On 30 May 2005 09:06:30 -0700, in comp.lang.c , we******@gmail.com
wrote:

Richard Bos wrote:

extern "C".

This is used only to make C++ code C-linkable.

Are you drunk? This is /not/ what its used for, by and large.


--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[Chris Torek]

>we******@gmail.com writes:

[extern "C"] is used only to make C++ code C-linkable.

In article <ln************@nuthaus.mib.org>
Keith Thompson <ks***@mib.org> wrote:No, it's used to make C code C++-linkable.

It does both, because the operation is naturally symmetric. (That
is, one would have to do something deliberately odd to make it fail
to work in both directions.)

Wind River has a policy of making all the C header files work with
C++ as well, by putting extern "C" directives in them (embedded
within the usual #ifdef __cplusplus of course). At BSDI we did
this with our (implementation-specific) __BEGIN_DECLS and __END_DECLS
macros, where <sys/cdefs.h> contained:

#ifdef __cplusplus
#define __BEGIN_DECLS extern "C" {
#define __END_DECLS };
#else
#define __BEGIN_DECLS
#define __END_DECLS
#endif

I find this more aesthetically pleasing than the Wind River
convention, though of course the BSDI names require that one insist
on taking the implementor's role. :-)

People insist on thinking of the languages as remarkably similar;
and in some ways they are, but in other ways they are remarkably
different, so that (e.g.) I consider C and Pascal more closely
related than C and C++.

I always like this example program:

% cat t.c
#include <stdio.h>
struct B { char c[1]; };
int main(void) {
struct A { int x; struct B { char c[1000]; } y; } v;

printf("sizeof(struct B) = %lu\n", (unsigned long)sizeof(struct B));
printf("(compiled as %s)\n",
sizeof(v.y) == sizeof(struct B) ? "C" : "C++");
return 0;
}
% ln t.c t.c++
% cc -O -o t1 -Wall -W -ansi -pedantic t.c
% cc -O -o t2 -Wall -W t.c++
% ./t1
sizeof(struct B) = 1000
(compiled as C)
% ./t2
sizeof(struct B) = 1
(compiled as C++)

Same source code, same compiler, wildly different results, with
the reason at least *relatively* subtle.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Paul Mesken]

On 31 May 2005 00:20:49 GMT, Chris Torek <no****@torek.net> wrote:

I consider C and Pascal more closely related than C and C++.

But not without a lot of effort, I hope? ;-)

It's true that both C and Pascal have a bit of ALGOL 68 in them
(they're like really distant cousins :-) but C++ is an evolution of C.
C++ started out as "C with classes", it was redesigned, some stuff was
added but C++'s roots are clear. The first C++ compilers generated C
code that was fed into a C compiler.

[CBFalconer]

Paul Mesken wrote:

Chris Torek <no****@torek.net> wrote:

I consider C and Pascal more closely related than C and C++.

But not without a lot of effort, I hope? ;-)

It's true that both C and Pascal have a bit of ALGOL 68 in them
(they're like really distant cousins :-) but C++ is an evolution
of C. C++ started out as "C with classes", it was redesigned,
some stuff was added but C++'s roots are clear. The first C++
compilers generated C code that was fed into a C compiler.

By that logic C is an evolution of assembly language. We still
have many compilers generate assembly source, including gcc. From
which you may conclude I disagree with you, and agree with Chris.

C and Pascal are both procedural languages, and both require
declaration before use. Well written Pascal can easily be ported
to C. The only real relationship between C and C++ is the arcane
syntax. There is no object orientation in either C or Pascal,
although object oriented code can be written in either.

--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

[Paul Mesken]

On Tue, 31 May 2005 02:01:05 GMT, CBFalconer <cb********@yahoo.com>
wrote:

Paul Mesken wrote:

Chris Torek <no****@torek.net> wrote:

I consider C and Pascal more closely related than C and C++.
But not without a lot of effort, I hope? ;-)

It's true that both C and Pascal have a bit of ALGOL 68 in them
(they're like really distant cousins :-) but C++ is an evolution
of C. C++ started out as "C with classes", it was redesigned,
some stuff was added but C++'s roots are clear. The first C++
compilers generated C code that was fed into a C compiler.

By that logic C is an evolution of assembly language.

Isn't everything? We need to return to the source, to the Garden ;-)

Of course, Assembly is not really a language (as if you didn't know)
and there's no such thing as _the_ Assembly language (it's different
for different processors, even different assemblers for the same
processor). Assembly is mostly a bunch of mnemonics which are a bit
easier to work with than opcodes.

Besides : even Bjarne Stroustrup states that C++ is based on C (see
his "The annotated C++ reference manual", it's on page 1). Surely, he
must have some inside information about the roots of C++ (since he
made the darn thing).

But C is not based on Pascal, nor vice versa, nor do they have the
same "direct parent".
C and Pascal are both procedural languages, and both require
declaration before use. Well written Pascal can easily be ported
to C.
C can be even more easily ported to C++ (but not necessarily vice
versa).
The only real relationship between C and C++ is the arcane
syntax.
C++ can be considered a superset of C for practical purposes. And,
thus, C can be considered a subset of C++.

I know there are those who like to make a big deal out of some subtle
differences but I'd like to point out that the differences between
Pascal and C are much greater in this respect.

To say that Pascal is more like C than C is like C++ requires IMO a
considerable stretch of the imagination.

Really, you two are in denial. I feel a great resistance to
acknowledging the (obvious) relation between C and C++. Some
psychotherapy might be needed ;-)
There is no object orientation in either C or Pascal,
although object oriented code can be written in either.

And C++ can be used to write purely procedural code. The OO part of
C++ is arbitrary (it's not arbitrary in Java, for example).

[Old Wolf]

we******@gmail.com wrote:

Richard Bos wrote:

we******@gmail.com wrote:

Those rare circumstances include cases where C code is directly
included in C++ projects. I.e., its actually extremely common.

extern "C".

Just to prove that I am not only talking inward, rather than
bring up the obvious example (Bstrlib) I'll just cite another
one that I had nothing to do with: PCRE. Its the definitive
universally available Perl-compatible regular expression
library for C. However, the author has used a __cplusplus
guarded extern "C", to make sure that it compiles simultaneously
in C and C++.

Do you think the author did this just for fun?

Please engage your brain in the most effective way possible:
by listening to what people are telling you. Do you think you
have 10 people all offering the same alternative explanation
just for fun?

In the PCRE example, the C files are compiled as C and the
C++ files are compiled as C++. If you doubt this, try adding
some C++ construct to the .c file and see if it still compiles.
When it fails, it will prove that the file is being compled as C.
Is that good enough evidence for you?

The purpose of 'extern C' in a C header file is so that when a
C++ compiler reads that /header file/, it uses the same symbol
in the object file for a function name, that the C compiler used.
(Without it, the C++ compiler uses 'mangled' symbols).

You are right to a small extent, in that C header files that need
to be compiled by a C++ compiler, must not contain constructs
that are invalid C++. This constraint does not apply to the
..c file, as I explained above.

You will find that the header files only contain declarations
and preprocessor instructions, and no executable code.