sscanf and int64 in Win32 and Unix - different results?

[Mark McIntyre]

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.

 

[websnarf]

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.

 

[Chris Torek]

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.

 

[Keith Thompson]

(e-mail address removed) 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
[...]

 

[Mark McIntyre]

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

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

 

[Chris Torek]

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

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.

 

[Paul Mesken]

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]

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:
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]

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]

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.

 

[Dave Vandervies]

C++ can be considered a superset of C for practical purposes. And,
thus, C can be considered a subset of C++.

So, by that reasoning, the set of negative integers and the set of
nonnegative integers are less like each other than either is like the
set of real numbers, because both are subsets of the reals but their
intersection is the empty set.
Try making this claim in front of a mathematician and see how long it
takes them to stop laughing at you.

The fact that the expressive ability of C++ is a superset of the
expressive ability of C is better used to support the claim that C
and C++ are dissimilar than the claim that they're similar, especially
since there is a large-ish set of languages (including Pascal) with an
expressive ability Rather More Similar to C than to C++.


dave

 

[Paul Mesken]

So, by that reasoning, the set of negative integers and the set of
nonnegative integers are less like each other than either is like the
set of real numbers, because both are subsets of the reals but their
intersection is the empty set.
Try making this claim in front of a mathematician and see how long it
takes them to stop laughing at you.

The fact that the expressive ability of C++ is a superset of the
expressive ability of C is better used to support the claim that C
and C++ are dissimilar than the claim that they're similar, especially
since there is a large-ish set of languages (including Pascal) with an
expressive ability Rather More Similar to C than to C++.

I'm surrounded by insanity! This is no place for me ;-)

Certainly, your mathematical metaphor has some merit to it but you
also implicitly claim that the _form_ expressions take on is
completely unimportant.

This would be like saying that English and Turkish are very much like
each other because the same ideas can be expressed in both of them.
But, unless you're proficient in both Turkish and English, these
language are very different from a _practical_ point of view (one is
understood readily, the other is not at all) and this is all due to
the _form_ of the languages, not because of their expressive
abilities.

For philosophical purposes, English and Turkish are much like each
other. For people who know English but not Turkish, they're completely
different.

Let's _assume_ (I don't know for certain since I'm not at all
experienced in programming in Pascal) that all things that can be
expressed in C can also be expressed in Pascal and vice versa.

C++ can be used to express the same things as can be expressed in C
and Pascal.

But : there are things that can be expressed in C++ but NOT in Pascal
or C.

This would support Torek's claim.

However, saying that C is more like Pascal than C is like C++ would
ignore the fact that the _form_ of C is also incorporated in C++ (but
not in Pascal). That's not surprising since C++ is _based_ on C (I
choose to take the word of the maker of C++, besides : it's quite
clear).

As a programmer one uses a programming language to express ideas (or
better : algorithms). IOW the language provides in the form these
expressions take on. C shows a lot of overlap with C++ in this respect
and very little with Pascal.

So, from a academical, philosophical point of view C and Pascal are
more like each other than C and C++.

But from a practical (as in : real world) point of view, C is more
like C++ than C is like Pascal.

 

[Michael Wojcik]

Besides : even Bjarne Stroustrup states that C++ is based on C...

But C is not based on Pascal, nor vice versa, nor do they have the
same "direct parent".

There's no special relationship between an entity's history and what
it now most closely resembles. Consider, for example, phylogeny.

And even if Stroustop has an opinion on how closely C++ resembles
other languages, that's not a compelling argument. It's not an
argument at all, in fact, until you can demonstrate why Stroustrop's
opinion in this matter is relevant. (Here's a hint: his status as
the inventor of C++ does not constitute such a demonstration.)

Did they not teach rhetoric in your school?

C++ can be considered a superset of C for practical purposes.

Only by the lazy-minded.

And, thus, C can be considered a subset of C++.

Only by the foolish.

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.

Your point is either misstated or incorrect. There are vast differ-
ences between C++ and either C or Pascal - much more significant
than the mostly syntactic differences between the last two. If you
mean to compare only the syntactic differences between the common
subset of C++ and C, on the one hand, and C and Pascal on the other,
what makes you believe that is significant in determining what makes
one language "like" another? Syntax is the least important char-
acteristic of a programming language.

ML is more like LISP than it is like Pascal, even though its syntax
is more like the latter's, for example.

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 ;-)

I urge you to seek some. It might disabuse you of the notion that
every idea which seems obvious to you must be true.

I can't help but notice that you have yet failed to offer a coherent
argument in this discussion, resorting instead to declaring that
you've already won, as you do here and earlier (with your snide
remark about "the iron grip of reason"). Hardly the mark of a man
operating from a well-constructed defense of his position.

And C++ can be used to write purely procedural code.

What's your point? That C++ is more like C than Pascal is, if you
ignore all the parts of C++ that aren't like C?

The OO part of
C++ is arbitrary (it's not arbitrary in Java, for example).

Please demonstrate how Java is not Turing-complete if its OO
features are not used. For the sake of argument, let's say that
includes encapsulation, polymorphism, and inheritance.


--
Michael Wojcik (e-mail address removed)

Auden often writes like Disney. Like Disney, he knows the shape of beasts --
(& incidently he, too, might have a company of artists producing his lines) --
unlike Lawrence, he does not know what shapes or motivates these beasts.
-- Dylan Thomas

 

[Paul Mesken]

Did they not teach rhetoric in your school?

Only by the lazy-minded.

Only by the foolish.

I see "grumpiness" is still fully alive in this ng.

Haven't you read Steve Summit's article on that?

 

[Anonymous 7843]

There's no special relationship between an entity's history and what
it now most closely resembles. Consider, for example, phylogeny.

Okay, I am considering the relationship between phylogeny's history and
what it now most closely resembles. I think it's quite special!

 

[Mark McIntyre]

The first C++ compilers generated C code that was fed into a C compiler.

This is true, but largely irrelevant. Many C compilers can generate
assembler, but linguistically C is closer to Fortran than assembler.

 

[Mark McIntyre]

I see "grumpiness" is still fully alive in this ng.

Only when supposedly sensible people post idiotic remarks.

Haven't you read Steve Summit's article on that?

on Grumpiness? Is that topical in CLC?

 

[Guillaume]

but linguistically C is closer to Fortran than assembler.

I didn't see that one coming...

 

[Paul Mesken]

This is true, but largely irrelevant. Many C compilers can generate
assembler, but linguistically C is closer to Fortran than assembler.

Yes, but Assembly isn't really a language. It's largely a more
readable mnemonic representation of the processor's machinecode and
it's different for different processors and even for different
assemblers for the same processor.

The two (C and Assembly) cannot be compared.

 

[Paul Mesken]

on Grumpiness? Is that topical in CLC?

Since it is from Steve Summit's hand, yes, then it is topical