which tutorial to use?

[Bartc]

Ioannis Vranos said:

I meant [not returning value in main()]

Oh, okay. The same argument applies, however.

Why?

Because it isn't always immediately clear how best to use a new
technology.
Consider, for example, the world's first cast-iron bridge, at
Coalbrookdale, Shropshire.

You mean, at Ironbridge?

Although I guess it may not have been called Ironbridge at the time, or if
it was then it was an extraordinary coincidence..

 

[Richard]

Ioannis Vranos said:

Richard Heathfield wrote:
I meant [not returning value in main()]

Oh, okay. The same argument applies, however.

Why?

Because it isn't always immediately clear how best to use a new
technology.
Consider, for example, the world's first cast-iron bridge, at
Coalbrookdale, Shropshire.

You mean, at Ironbridge?

Two seconds of google would have prevented you posting OT .....

Although I guess it may not have been called Ironbridge at the time, or if
it was then it was an extraordinary coincidence..

,----
| In 1768, the Company began to produce the first cast iron rails for
| railways. In 1778, Abraham Darby III undertook the building of the
| world's first cast iron bridge, the iconic Iron Bridge, opened in
| 1780. The fame of this bridge leads many people today to associate the
| Industrial Revolution with the neighbouring village of Ironbridge, but
| in fact most of the work was done at Coalbrookdale, as there was no
| settlement at Ironbridge in the eighteenth century.
`----

 

[Ioannis Vranos]

Well, they may provide the correct return statements as errata to their
book publishing company, so as next printings fixes them. The same
happens with TC++PL3 book and its errata, they are being provided to the
next printings of the book.

Actually I spotted a main() returning 0 in K&R2. It is in chapter 8.2,
written by Ritchie.

 

[Richard Heathfield]

Ioannis Vranos said:

Actually I spotted a main() returning 0 in K&R2. It is in chapter 8.2,
written by Ritchie.

That is by no means the only example.

On p26, Kernighan says "You may have noticed that there is a return
statement at the end of main [he is referring to the program on p24].
Since main is a function like any other, it may return a value to its
caller [...] In the interests of simplicity, we have omitted return
statements from our main functions up to this point, but we will include
them hereafter, as a reminder that programs should return status to their
environment."

Now check pages 29, 32, 59... In fact, I can't find any main on page 24 or
after that does not return a value from main.

 

[doom]

thanx to you all for all advice. I will start with "C programming class
notes" by Mr Steve Summit...

 

[Ioannis Vranos]

Ioannis Vranos said:

Actually I spotted a main() returning 0 in K&R2. It is in chapter 8.2,
written by Ritchie.

That is by no means the only example.

On p26, Kernighan says "You may have noticed that there is a return
statement at the end of main [he is referring to the program on p24].
Since main is a function like any other, it may return a value to its
caller [...] In the interests of simplicity, we have omitted return
statements from our main functions up to this point, but we will include
them hereafter, as a reminder that programs should return status to their
environment."

Now check pages 29, 32, 59... In fact, I can't find any main on page 24 or
after that does not return a value from main.

Hmm, I am using a local-language translated version of K&R2. Perhaps
they have fixed the book after the translated printing.

Since my book is in non-English, may you provide the chapter numbers
(e.g. "1.4", "1.6" etc) instead of page numbers, where main() returns a
value?

 

[pete]

Richard Heathfield wrote:

The above: Section 1.7

Since my book is in non-English, may you provide the chapter numbers
(e.g. "1.4", "1.6" etc) instead of page numbers,
where main() returns a value?

Section 1.9 contains one program that returns 0.
So does Section 1.10, and then this gets boring.

 

[Ioannis Vranos]

The above: Section 1.7


Section 1.9 contains one program that returns 0.
So does Section 1.10, and then this gets boring.

OK those exist in my greek K&R2 too. I do not know how I got the
impression that main()s in K&R2 were not returning a value, although I
have been reading it daily as a brush up.


Therefore I withdraw my argument about bad style for not returning
values in main() in K&R2, although one minor argument remains for the
non-zero values.

 

[Martin]

I'm perfectly happy with my (free) C99 compiler.

I was under the impression (from this newsgroup) that there are no
compilers in existence that fully support C99. If that is the case, then
the term "C99 Compiler" is a misnomer. Or misleading.

 

[Richard Heathfield]

Martin said:

I was under the impression (from this newsgroup) that there are no
compilers in existence that fully support C99.

There are a few. See http://www.peren.com/pages/cvsa_isocvpl.htm

Notable by their absence from that (very short) list are Microsoft C, Intel
C, Borland C, gcc, Comeau C, and of course lcc.

Until at least Microsoft C and gcc are C99-conforming there seems no point
in trying to write portable, C99-dependent code.

 

[Ioannis Vranos]

Martin said:


There are a few. See http://www.peren.com/pages/cvsa_isocvpl.htm

Notable by their absence from that (very short) list are Microsoft C, Intel
C, Borland C, gcc, Comeau C, and of course lcc.

Until at least Microsoft C and gcc are C99-conforming there seems no point
in trying to write portable, C99-dependent code.

I think MS will only support the C99 features that will be adopted in C++0x.


About GCC, I wonder why they don't support C99, since they do not aim
for profit anyway. Anyone has any idea why GCC doesn't support C99 yet?

 

[pete]

OK those exist in my greek K&R2 too. I do not know how I got the
impression that main()s in K&R2 were not returning a value, although I
have been reading it daily as a brush up.

Therefore I withdraw my argument about bad style for not returning
values in main() in K&R2, although one minor argument remains for the
non-zero values.

Bad style for implicit int definitions of main.
Bad style for nonprototype definitions of main.

 

[Richard Heathfield]

Ioannis Vranos said:

About GCC, I wonder why they don't support C99, since they do not aim
for profit anyway. Anyone has any idea why GCC doesn't support C99 yet?

GNU approached C99 conformance *fairly* closely, very quickly indeed. And
then they stopped dead. My own belief (although I don't know for sure) is
that they've decided that the bits that are left unimplemented contradict
what GNU consider to be the right way to do things. For example, gcc has
had VLA support since way before C99 came out - but it doesn't work in
quite the way that C99 specifies, and GNU think that their way is better.
If I'm right, there needs to be a change of heart among GNU developers
before we can ever see a C99-conforming version of gcc.

 

[Ioannis Vranos]

Ioannis Vranos said:



GNU approached C99 conformance *fairly* closely, very quickly indeed. And
then they stopped dead. My own belief (although I don't know for sure) is
that they've decided that the bits that are left unimplemented contradict
what GNU consider to be the right way to do things. For example, gcc has
had VLA support since way before C99 came out - but it doesn't work in
quite the way that C99 specifies, and GNU think that their way is better.
If I'm right, there needs to be a change of heart among GNU developers
before we can ever see a C99-conforming version of gcc.

This sounds worse than M$isms.

 

[lawrence.jones]

GNU approached C99 conformance *fairly* closely, very quickly indeed. And
then they stopped dead. My own belief (although I don't know for sure) is
that they've decided that the bits that are left unimplemented contradict
what GNU consider to be the right way to do things.

My impression is that it's more a case of the bits that are left being
either hard to do (e.g., require significant redesign) or conflicting
with existing practice in GCC.

-Larry Jones

My "C-" firmly establishes me on the cutting edge of the avant-garde.
-- Calvin

 

[santosh]

This sounds worse than M$isms.

<flame>
Not really. At least the GNU guys prefer their methods because they
believe in their technical superiority, unlike MS whose non-conformance
is more often than not a business strategy to break standards and lock
in customers.
</flame>

 

[Micah Cowan]

Ioannis Vranos said:



GNU approached C99 conformance *fairly* closely, very quickly indeed. And
then they stopped dead. My own belief (although I don't know for sure) is
that they've decided that the bits that are left unimplemented contradict
what GNU consider to be the right way to do things. For example, gcc has
had VLA support since way before C99 came out - but it doesn't work in
quite the way that C99 specifies, and GNU think that their way is better.
If I'm right, there needs to be a change of heart among GNU developers
before we can ever see a C99-conforming version of gcc.

My understanding from the current release notes, is that the next
major release will include C99's semantics for "inline", so at least
there's _some_ progress.

 

[Micah Cowan]

Martin said:


There are a few. See http://www.peren.com/pages/cvsa_isocvpl.htm

Notable by their absence from that (very short) list are Microsoft C, Intel
C, Borland C, gcc, Comeau C, and of course lcc.

Absence from that list does not itself imply non-conformance; it means
they haven't been officially verified (which I'm sure costs $$$). That
said, of course, none of those implementations _are_ conforming.

....except, I'd been under the impression that Comeau C is (it's just
the compiler, not the library, right)? Can anyone confirm/contradict
this?

Until at least Microsoft C and gcc are C99-conforming there seems no point
in trying to write portable, C99-dependent code.

I'm not convinced that's the case (though I avoid doing so, myself).

I suspect we've been a bit spoiled on C90, in that it's one of the few
standards that actually is completely implemented on a large
scale. C++, for instance, has only one complete implementation as far
as I'm aware. The c.l.c++ folks don't say "don't write C++98/03,
because there are no conforming implementations"; they simply use the
portably subset and get on with life (this is not too bad, since the
only missing feature I'm aware of is template exporting).

Those who've had to deal with HTML and CSS, of course, have had to
quickly abandon any ideas of simply writing conformant HTML code:
there are large portions of both standards (regardless of what level
of CSS you choose) that are simply not implemented correctly in enough
browsers to justify their use. Professional web developers who are
interested in standards conformance still have to learn the dance of
what works and what doesn't, and restrict themselves to that
subset. The vast majority of web developers will also add the common
extensions that remain fairly portable despite lack of
standardization (most of them don't give a rat's ass for the W3C
standards anyway).

It doesn't seem unreasonable, then, when certain _portions_ of
functionality specific to the C99 standard reach high levels of
portability, to take advantage of them. Indeed, when certain
extensions that aren't in any standard are widespread, there's nothing
really wrong with using them, either (though they may be offtopic
here). The standard, contrary to some claims, does not define
portability (otherwise we wouldn't even be having this discussion); it
defines a target for implementors to hit if they wish to be
portable. Other targets can co-exist, and sometimes vendors rebel
against the official standard and collectively implement a de facto
one instead.

It seems to me that // comments were widely portable long before C99,
and that one may generally depend on stdint.h and snprintf (thank
God). Inline is widely implemented, but often with significantly
different semantics from C99 (usually based on C++ semantics, I
think), but one can achieve portability with "static inline".

VLAs are probably pretty portable, too, if you similarly stick to a
portable subset of the semantics; and it may be that compound literals
are too, with certain caveats, and if one sticks to treating them as
const-qualified.

Of the above, the only ones I really take advantage of are stdint.h
and snprintf, and maybe occasionally "static inline"; I suspect most
regulars here probably write code that takes advantage of these as
well. These are attractive because they offer significant benefit at
low cost: they are easily worked around or implemented on
implementations that lack them (well, except maybe snprintf, but the
alternatives are too impractical to accept; I'd rather implement my
own snprintf or facilities implementing a subset of its functionality,
than to do without, when it's needed).

 

[santosh]

My understanding from the current release notes, is that the next
major release will include C99's semantics for "inline", so at least
there's _some_ progress.

In any case it is usable as C99 compiler. What's broken or missing can
be worked around. However Microsoft and Borland's refusal of C99 in
toto is a more serious stumbling block, particularly in the case of
Microsoft, since they are best compilers for Windows programming.

 

[Richard]

<flame>
Not really. At least the GNU guys prefer their methods because they
believe in their technical superiority, unlike MS whose non-conformance
is more often than not a business strategy to break standards and lock
in customers.
</flame>

Garbage.

The result is the same. Both break standards. Both for the same reasons
- they think they know best and feel limited by the standard.

Another thing : you are not forced to use MS compilers.