>>...
>> [It is] common for shared C headers to do something like this:
>>
>>   #ifndef __STDC__
>>       double f(); /* K&R C */
>>   #else
>>       double f(double, double); /* prototype */
>>   #endif

dellera@my-deja.com wrote:
> Exactly! Since __STDC__ is not defined, all prototypes
> in the library I'm trying to use are defined in the
> old K&R style, which, from a C++ point of view, means
> that are all without parameters ... (at least that's
> what the expensive commercial compiler understands
> by default).
> All goes smoothly if __STDC__ is defined.
>
>> You might also try
>>     #if expensive_commericial_compiler
>>     #define __STDC__ 0 /* or whatever */
>>     #endif

Or, to be conforming and to work under both C and C++:

    #if defined(__cplusplus) || defined(__STDC__)
        /* Standard C or C++ */
        double  f(double, double);
    #else
        /* Assume K&R style */
        double  f();
    #endif

Be aware that many compilers that handle prototypes will define
__STDC__ to 0 (not 1), since they also handle extensions to the
language and are thus not (technically) conformant.

And then there are compilers (e.g., Microsoft VC++) that do not
define __STDC__ at all, even though they are quite capable of
handling prototypes and the standard C library functions.  Sheesh.

-- David R. Tribble, david@tribble.com, http://david.tribble.com --
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow <francis@robinton.demon.co.uk> wrote:
>
>In article <383B073F.E446B667@wizard.net>, James Kuyper
><kuyper@wizard.net> writes
>>"Our compiler compiles C*=C, a new language derived from C, and a major
>>impovement over C++. It implicitly #defines __STDC__ for purposes of
>>backwards compatibility with C, even though it does not conform to the C
>>standard."
>>
>>How would that be covered by the trade claim issue?
>
>To one of the values specified by a C standard (89 or 99+)?  I think a
>UK trading standards officer would ask a court to rule that the compiler
>made a false trade claim (my source code cannot read documentation
>though it can check macros)

If a compiler claims to be a C compiler, and if it defines __STDC__ to
a value specified by a C standard, then you'd certainly have grounds to
complain if it fails to comply with that standard.

But the hypothetical compiler in question claims to be C* compiler ...
not a C compiler.  In order to make a claim of conformance to the
C standard, the compiler has to claim to be a C compiler.

I don't see what basis there would be to complain that the vendor of
the C* compiler was making a false trade claim, no matter how the
C* compiler defined __STDC__.  It is the responsibility of programmer
who submits C code to a C* compiler to check the C* spec to verify
that the results will be as intended.  If not, it's the programmer's
problem not the vendor's.

In a more pragmatic vein ...

"James Kuyper Jr." <kuyper@wizard.net> wrote:
>I've heard that the final draft of the C99 standard (which I haven't
>seen yet) says in section 6.10.8 p5 that: "The implementation shall not
>predefine the macro __cplusplus, nor shall it define it in any standard
>header." So there's an asymmetry between the two standards. It seems an
>appropriate asymmetry, however.

Indeed it is, because if you have code that you wish to submit for
compilation by C and C++ compilers, and if that code needs to know
that __STDC__ is being defined by a C compiler (not a C++ compiler)
then it becomes quite simple to do:

#ifdef __cplusplus
  /* C++ stuff */
#else
#ifdef _STDC__
  /* standard C stuff */
#else
  /* K&R C stuff (e.g.) */
#endif
#endif

Mike
--
C. M. Heard/VVNET, Inc.
heard@vvnet.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <383B073F.E446B667@wizard.net>, James Kuyper
<kuyper@wizard.net> writes
>"Our compiler compiles C*=C, a new language derived from C, and a major
>impovement over C++. It implicitly #defines __STDC__ for purposes of
>backwards compatibility with C, even though it does not conform to the C
>standard."
>
>How would that be covered by the trade claim issue?

To one of the values specified by a C standard (89 or 99+)?  I think a
UK trading standards officer would ask a court to rule that the compiler
made a false trade claim (my source code cannot read documentation
though it can check macros)


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3838BE35.BA20E3FF@wizard.net>, James Kuyper Jr.
<kuyper@wizard.net> writes
>A conforming implementation of C++ can't be a conforming implementation
>of C; therefore, it's free, like all non-conforming implementations, to
>define __STDC__ if it wants to. It's constrained only by the C++
>standard, which explicitly specifies that whether or not __STDC__ is
>pre-defined is up to the implementation. The C standard, by definition,
>cannot constrain non-conforming implementations.

That may be true internally but it has legal implications.  Defining
__STDC__ is a trade claim and certainly has significance in some
countries.  However I had forgotten that it is possible to define it to
values that actually disclaim conformance.



Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> It's not that. There are language features that are incompatible.
> Here are a few:
>
> 1. Some rules of C violate C++ type safety rules.  For example,
<snip>
>
> 2, Because (pre-C9X) C does not have the "//" comment, some
<snip>
>
> 3. In C, a literal character 'a' has type int. Since that would
<snip>
>
> A valid standard C program can therefore be invalid in C++, or
> valid but with a different meaning.
>
Thanks. These examples are very interesting and thought-provoking;
sure I will fall in those pitfalls in the future (strange that
I didn't fall yet..). Definitely, C++ is not a superset of C.
> >
> > Joke of the day: in the library I use I found also
> >
> > if (__STDC__ == 0) <snip>
> >
> > Wonder what happens if __STDC__ is not defined ?
>
> As you wrote it, you'd get an error message about an
> undefined identifier __STDC__.
>
> But if the code were
>  #if (__STDC__ == 0)
> it would be OK. Every undefined undentifier in a preprocessor
> conditional is replaced by the value 0, so you'd get
>  #if (0 == 0)
>
> The real problem occurs when __STDC__ is defined to be nothing,
> as in
>  #define __STDC__
> You would then get
>  #if ( == 0)
> or
>  if ( == 0)
> both of which are syntax errors.
>
> In portable code, you can protect yourself against that possibility
> by writing
>  ((__STDC__ - 0) == 0)
> Now, the test is syntactically valid when __STDC__ is defined
> to any integer value, or to nothing.
>
Again, thanks. I knew of the latest trick, now I understand
it better.
And, by the way: in the library I'm using it was (it _is_) written as
if (__STDC__ == 0) ... (not #if (__STDC__ == 0))
maybe a quick-and-dirty maintenance fix of the
library maintainer.

> ---
> Steve Clamage, stephen.clamage@sun.com

Thanks again, Steve.
Alberto


Sent via Deja.com http://www.deja.com/
Before you buy.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
...
> That may be true internally but it has legal implications.  Defining
> __STDC__ is a trade claim and certainly has significance in some
> countries.  However I had forgotten that it is possible to define it to
> values that actually disclaim conformance.

"Our compiler compiles C*=C, a new language derived from C, and a major
impovement over C++. It implicitly #defines __STDC__ for purposes of
backwards compatibility with C, even though it does not conform to the C
standard."

How would that be covered by the trade claim issue?
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> The C++ standard says that whether __STDC__ is defined, and if so
> what value it has, is up to the implementation (16.8, paragraph 1).
>

Thanks. If that's the word of the law, the expensive commercial
compiler is right (from a commercial point of view).

> > There are quite a few areas where C++ differs from
> > C; it is an erroneous belief to think of C++ as a superset of C.

I would have preferred to have at least _std_ C++ being a superset of
_std_ C ... anyway, I know that standardization itself is an hard
work, and keeping two different standards in sync almost impossible.

>
> Yes. In particular, a compiler that conforms to the C standard must
> define __STDC__ to 1.  But a standard C++ compiler does not fully
> conform to the C standard, so defining __STDC__ to 1 is IMHO not
> appropriate.  The Sun C++ compiler defines it to 0, because it is

I agree, and in fact Sun is well known to be among the best companies
(from a technical point of view). Wish I worked on a Sun workstation!

> common for shared C headers to do something like this:
>
> #ifdef __STDC__
You have forgot an 'n' ... it should read #ifndef
>     double f(); /* K&R C */
> #else
>     double f(double, double); /* prototype */
> #endif
>
Exactly! Since __STDC__ is not defined, all prototypes
in the library I'm trying to use are defined in the
old K&R style, which, from a C++ point of view, means
that are all without parameters ... (at least that's
what the expensive commercial compiler understands
by default).
All goes smoothly if __STDC__ is defined.

> You might also try
>  #if expensive_commericial_compiler
>  #define __STDC__ 0 /* or whatever */
>  #endif
That's what I've done ... but the purist in me
lost his senses when I defined a standard macro ;-),
which you are supposed to read and never define;
anyway, that's the solution.

Joke of the day: in the library I use I found also

if (__STDC__ == 0) <snip>

Wonder what happens if __STDC__ is not defined ?

Thanks you all
Alberto



Sent via Deja.com http://www.deja.com/
Before you buy.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <80u3jm$lnb$1@nnrp1.deja.com>, dellera@my-deja.com writes
>Hi Everybody,
>
>does anybody know whether the subject
>of my posting is true, both
>(a) as dictated by the standard
>(b) by common sense ?
>
>About the motivation of my wondering,
>that's because I've found an expensive
>commercial C++ compiler NOT defining
>__STDC__. This causes a lot of trouble
>when linking older C libraries, as you
>can imagine; but before calling them,
>I would like to be sure what is "right"
>and what is "wrong".
>
>Thank you, at least for reading this
>Alberto

As C++ lists a number of intended incompatibilities with C it clearly
must NOT define __STDC__


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage wrote:
>
> ... The Sun C++ compiler defines it to 0, because it is
> common for shared C headers to do something like this:
>
> #ifdef __STDC__
>     double f(); /* K&R C */
> #else
>     double f(double, double); /* prototype */
> #endif

Of course, I meant to write

#ifndef __STDC__
    double f(); /* K&R C */
#else
    double f(double, double); /* prototype */
#endif
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 21 Nov 1999 dellera@my-deja.com wrote:
>
> > > There are quite a few areas where C++ differs from
> > > C; it is an erroneous belief to think of C++ as a superset of C.
>
> I would have preferred to have at least _std_ C++ being a superset of
> _std_ C ... anyway, I know that standardization itself is an hard
> work, and keeping two different standards in sync almost impossible.

It's not that. There are language features that are incompatible.
Here are a few:

1. Some rules of C violate C++ type safety rules.  For example,
functions do not always need to be declared in C, but they do in
C++. A void* can be implicitly converted to any other data
pointer type in C, but not in C++.
    char* p = malloc(100); // requires a cast in C++

2, Because (pre-C9X) C does not have the "//" comment, some
character sequences have different meanings in C and C++:
    x//*divide by 2*/2
The line means "x/2" in (pre-C9X) C, but just "x" in C++.

3. In C, a literal character 'a' has type int. Since that would
produce bizarre overloading resolution in C++, a literal
character has type char in C++.
 cout << 'a'; // want to print "a", not "97"
Thus, the expression
 (sizeof('a') == sizeof(int))
is always true in C, but is usually false in C++.

A valid standard C program can therefore be invalid in C++, or
valid but with a different meaning.

>
> Joke of the day: in the library I use I found also
>
> if (__STDC__ == 0) <snip>
>
> Wonder what happens if __STDC__ is not defined ?

As you wrote it, you'd get an error message about an
undefined identifier __STDC__.

But if the code were
 #if (__STDC__ == 0)
it would be OK. Every undefined undentifier in a preprocessor
conditional is replaced by the value 0, so you'd get
 #if (0 == 0)

The real problem occurs when __STDC__ is defined to be nothing,
as in
 #define __STDC__
You would then get
 #if ( == 0)
or
 if ( == 0)
both of which are syntax errors.

In portable code, you can protect yourself against that possibility
by writing
 ((__STDC__ - 0) == 0)
Now, the test is syntactically valid when __STDC__ is defined
to any integer value, or to nothing.

---
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <819o80$ncl$1@nnrp1.deja.com>, dellera@my-deja.com says...

[ ... ]

> Joke of the day: in the library I use I found also
>
> if (__STDC__ == 0) <snip>
>
> Wonder what happens if __STDC__ is not defined ?

The conditional would succeed -- when the conditional is evaluated,
any remaining identifier will have been replaced by a '0'.  I'm
simplifying a bit -- see section 16.1/4 for the full story.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
....
> As C++ lists a number of intended incompatibilities with C it clearly
> must NOT define __STDC__

A conforming implementation of C++ can't be a conforming implementation
of C; therefore, it's free, like all non-conforming implementations, to
define __STDC__ if it wants to. It's constrained only by the C++
standard, which explicitly specifies that whether or not __STDC__ is
pre-defined is up to the implementation. The C standard, by definition,
cannot constrain non-conforming implementations.

I've heard that the final draft of the C99 standard (which I haven't
seen yet) says in section 6.10.8 p5 that: "The implementation shall not
predefine the macro __cplusplus, nor shall it define it in any standard
header." So there's an asymmetry between the two standards. It seems an
appropriate asymmetry, however.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jerry Coffin wrote:
>
> In article <819o80$ncl$1@nnrp1.deja.com>, dellera@my-deja.com says...
>
> [ ... ]
>
> > Joke of the day: in the library I use I found also
> >
> > if (__STDC__ == 0) <snip>
> >
> > Wonder what happens if __STDC__ is not defined ?
>
> The conditional would succeed -- when the conditional is evaluated,
> any remaining identifier will have been replaced by a '0'.  I'm
> simplifying a bit -- see section 16.1/4 for the full story.

Wrong rules: as written, this was an 'if()', not a '#if'.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3838B86F.2C1B7E49@wizard.net>, kuyper@wizard.net says...

[ ... ]

> Wrong rules: as written, this was an 'if()', not a '#if'.

Oops -- one of these days I'll have to learn to read things before I
reply to them...

--
    Later,
    Jerry.

The universe is a figment of its own imagination.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

dellera@my-deja.com wrote in message <80u3jm$lnb$1@nnrp1.deja.com>...

>About the motivation of my wondering,
>that's because I've found an expensive
>commercial C++ compiler NOT defining
>__STDC__. This causes a lot of trouble
>when linking older C libraries, as you
>can imagine; but before calling them,
>I would like to be sure what is "right"
>and what is "wrong".

The compiler is correct. There are quite a few areas where C++ differs from
C; it is an erroneous belief to think of C++ as a superset of C.

Stephen Howe




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Stephen Howe wrote:
>
> dellera@my-deja.com wrote in message <80u3jm$lnb$1@nnrp1.deja.com>...
>
> >About the motivation of my wondering,
> >that's because I've found an expensive
> >commercial C++ compiler NOT defining
> >__STDC__. This causes a lot of trouble
> >when linking older C libraries, as you
> >can imagine; but before calling them,
> >I would like to be sure what is "right"
> >and what is "wrong".
>
> The compiler is correct.

It is more accurate to say the compiler is not wrong. :-)

The C++ standard says that whether __STDC__ is defined, and if so
what value it has, is up to the implementation (16.8, paragraph 1).

> There are quite a few areas where C++ differs from
> C; it is an erroneous belief to think of C++ as a superset of C.

Yes. In particular, a compiler that conforms to the C standard must
define __STDC__ to 1.  But a standard C++ compiler does not fully
conform to the C standard, so defining __STDC__ to 1 is IMHO not
appropriate.  The Sun C++ compiler defines it to 0, because it is
common for shared C headers to do something like this:

#ifdef __STDC__
    double f(); /* K&R C */
#else
    double f(double, double); /* prototype */
#endif

Of course, no one solution works for every variation of this
theme, which is why the C++ standard places no requirements
on __STDC__.

You could ask the compiler vendor whether they considered
defining __STDC__. They might have had a reason for not doing so.
You might also try
 #if expensive_commericial_compiler
 #define __STDC__ 0 /* or whatever */
 #endif

--
Steve Clamage, stephen.clamage@sun.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi Everybody,

does anybody know whether the subject
of my posting is true, both
(a) as dictated by the standard
(b) by common sense ?

About the motivation of my wondering,
that's because I've found an expensive
commercial C++ compiler NOT defining
__STDC__. This causes a lot of trouble
when linking older C libraries, as you
can imagine; but before calling them,
I would like to be sure what is "right"
and what is "wrong".

Thank you, at least for reading this
Alberto






Sent via Deja.com http://www.deja.com/
Before you buy.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]