I need your advices about C prg.

[Rui Maciel]

A straightforward general question is asked here
... and almost half the posts deal with the pressing
issue:
To void main or not to void; that is the question.

Wow. Just ... Wow!

The void main issue is actually relevant. It is a Litmus test to infer if a
publication actually complies with the standard or instead is a broken mess.
If someone delves into the language by relying on a broken mess of a manual
then odds are they are bound to experience problems caused by broken code
being passed off as working examples.


Rui Maciel

 

[Malcolm McLean]

On 04/25/2013 08:42 AM, Johannes Bauer wrote:

In this newsgroup I've talked with a number of people who thought that
most, if not all, current C programming is being done for embedded
platforms. When challenged, none have been able to provide hard numbers
in support of their claim. To be fair, I know of no good source of
numbers to disprove the claim, either. But the simple fact that anybody
believes it is, in itself, evidence for the existence of a fairly large
amount of embedded C programming going on.

There aren't many jobs for non-embedded C programmers. Virtually everyone
seems to specify C++ at least, and normally they are far more interested
in high level languages like Python or the various web, database, and
Windows only languages.
I think the reason is that the guts of a program, the central algorithm
that makes it work, is usually best written in C. So if the program is
essentially a Fourier transform, you'll write the FFT in C, if it's Huffman
compression you'll write the Huffman code in C, if it's a 2D image displayer,
all the code to draw triangles and rotate images will be written in C.
But most programmers don't work with the guts of a program. The work is in
hooking up code written by other people and integrating it and giving it user
interfaces. So C isn't particularly useful for that.

 

[Tim Rentsch]

"main" has a return parameter which is an int. Always.

No, "main" does not always have a return parameter - "main"
does not always return, and therefore a return parameter is
meaningless. In most (small) embedded systems, main() never
exits. Including a return parameter may mean wasted code, and
will mean your compiler and/or static code checker will warn
about unreachable code (if you include a return value) or
missing return values (if you don't). [snip unrelated]

Both these problems can be avoided by writing main() this
way:

int
main( void ){

/* ... */
/* whatever main does in its loop body */
/* ... */

return main();
}

Of course I'm not completely serious, but neither is it
completely a joke. Presented with such a program, gcc
compiles it (under -O2) as a simple loop, not a call, and
with no generated return opcode or any other extra clutter.

 

[Malcolm McLean]

25 Nisan 2013 Perşembe 14:30:47 UTC+3 tarihinde David Brown yazdı:

I'm from Turkey. So my native language is Turkish. But I want to learn English > so much

I've been learning C for 5 months. But I want to improve my skills for C
programming. I love C/C++ languages more than other languages like Java and
C#.

Well keep on posting. The best way to learn English is to use it for real,
and you can kill two birds with one stone.

 

[Dogukan Bayraktar]

25 Nisan 2013 Perşembe 20:44:06 UTC+3 tarihinde James Kuyper yazdı:

Try

<https://groups.google.com/forum/?fromgroups#!forum/cprogramlama>. I

can't read it, but Google claims it's a Turkish newsgroup, and the name

sounds appropriate.

Thanks but that link is not useful for me because nobody didn't share anything about C programming on that link. Nothing to do with C programming. I don't want to write/listen/read/speak in Turkish, because of its that I want to improve my English. So I want to write/listen/read/speak in English toimprove it.

I have got a file of .PDF about C programming called "K&D C Programming".
In this e-book, i understand means of sentences. But I don't know too vocabulary. So I don't understand some sentences. I really want to read like that e-books.

* By the way, forgive me for my English :/
* I hope everyone understand me..

Thanks everyone for comments.

 

[Dogukan Bayraktar]

25 Nisan 2013 Perşembe 21:12:11 UTC+3 tarihinde Malcolm McLean yazdı:

Well keep on posting. The best way to learn English is to use it for real,

and you can kill two birds with one stone.

Thank you for advice! I`ll keep on posting and reading!

 

[James Kuyper]

25 Nisan 2013 Perşembe 20:44:06 UTC+3 tarihinde James Kuyper yazdı: ....


Thanks but that link is not useful for me because nobody didn't share anything about C programming on that link. Nothing to do with C programming. ..

The group description translates to English as "Cprogramlama
This group is C, C + +, C #, Java, Php, such as languages ​​with C-like
syntax, and was established as a discussion and helping the environment.
General programming issues, algorithms, and other programming languages,
jobs and so on. correspondence related issues, too." That sounded
appropriate, I'm sorry that it wasn't.

.. I don't want to write/listen/read/speak in Turkish, because of its that I want to improve my English. So I want to write/listen/read/speak in English to improve it.

That makes sense - but from my own experience with discussing technical
subjects in foreign languages, I think you should also have a fall-back
source of advice where you can use the language you understand best.

I have got a file of .PDF about C programming called "K&D C Programming".

That should be "K&R", standing for "Kernighan and Ritchie", the authors.

 

[Tim Rentsch]

[snip]

I have got a file of .PDF about C programming called "K&D C
Programming".

In this e-book, i understand means of sentences.

I expect you mean: you understand the _meaning_ of (some) sentences...

But I don't know too vocabulary.

and that you don't know too _much_ vocabulary..

So I don't understand some sentences. I really want to read like
that e-books.

I think you mean you want to be able to read e-books like
the one you have. "I really want to be able to read other
e-books like that one." Is this what you meant, or did
you mean something else?

* By the way, forgive me for my English :/
* I hope everyone understand me..

I applaud your efforts, and your results. You're doing great!
("Applaud" is clapping hands, showing praise.)

Thanks everyone for comments.

Two suggestions:

One: when you find a passage you don't understand, post it
here and ask about it. You should get an explanation that
will help both with understanding C and with learning English.

Two: if you are up to a challenge, get a copy of the official
defining document for C, such as

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

This may be difficult for you, because it is more formal
English, but I think you'll be okay, and it has the advantage
that you can ask about it in the newsgroup here and lots of
people will be able to explain what it says. You will get
great practice for your English, and you will learn C much
more completely. (And if this document is too hard it is
always okay to go back to simpler stuff for a while.)

Good luck!

 

[Jorgen Grahn]

.

In this newsgroup I've talked with a number of people who thought that
most, if not all, current C programming is being done for embedded
platforms. When challenged, none have been able to provide hard numbers
in support of their claim. To be fair, I know of no good source of
numbers to disprove the claim, either. But the simple fact that anybody
believes it is, in itself, evidence for the existence of a fairly large
amount of embedded C programming going on.

There's also a lot of confusion about what "embedded programming" is.
My employers call what I do embedded programming, but it's really
for the most part ordinary Unix server programming.

/Jorgen

 

[Tim Rentsch]

On 04/25/2013 12:00 PM, David Brown wrote:
... [snip] ...

point 167 clearly says that "main" can be defined "in some other
implemention-defined manner".

It can, but what 5.1.2.2.1 says is "It shall be defined with a
return type of int and [details of one permitted form] or [details
of a second permitted form] or equivalent; or in some other
implementation-defined manner."

It has been argued that "A and B or C or D; or E" should be parsed
as "(A and B) or C or D; or E", but that doesn't make sense. The
intended parse was "A and (B or C or D; or E)" (I'm not sure what
affect the ';' should have on the parse).

That's wrong. The intended parse was ((A and (B or C)) or D) or E.
The footnote makes evident the wider applicability of D, and IIRC
Larry Jones has remarked in comp.std.c about case E being outside
all the previous conditions.

If that weren't the case, A (== "it shall be defined with a return
type of int") would be redundant, since the two explicitly specified
forms already give a return type of 'int'. If that clause wasn't
intended to apply to the "other implementation-defined manner", it
could simply have been dropped.

That's a plausible line of reasoning, but certainly it is not the only
plausible line of reasoning. More importantly, it doesn't agree with
the views of many (or most?) other people who read the Standard,
and AFAIAA it does not agree with the views of the people who wrote
it.

 

[Jorgen Grahn]

.

As for becoming a good C programmer, the first question is /why/?
Yes.

If you want to become a good programmer, C is not necessarily a good choice
for starting. The field of programming is vast - C is only suitable for
a small part of that.

But it has to be pointed out that small part can be large enough. For
example, C + Unix + some scripting languages can be enough for many
years of hobby use. You can also make a living off it.

/Jorgen

 

[Keith Thompson]

Well, if the code conforms to the C standard, it should return int.

I suggest you read the actual C standard, or at least a draft of it.
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf is the lastest
publicly available draft; take a look at section 5.1.2.2.1.

For hosted implemenatations, I agree that it *should* return int,
but that's a style judgement, not a requirement. An implementation
is explicitly permitted to support other forms of main, including
forms in which it doesn't return int. Such forms are not portable.
(Incidentally, the value returned by a function is not a
"parameter".)

It's mandated by the C standard. So if you want to have a standard
compliant program, it is very meaningful. Not in a way that transports
any information (because the return value itself may be discarded).

That's not entirely correct. You do need to define "main" with a return
type of int if you want your program to be portable to conforming hosted
implementations. (No program can be portable to all conforming
freestanding implementations.)

I disagree completely. Is a 4 bit microcontroller small enoguh to
qualify as "small"? Because these are the smallest I've programmed (in
C). And nowhere, ever, have I encountered an environment that has no
main somewhere (sure, maybe hidden from the application developer, but
it is indeed there when you look for it).

He didn't say main doesn't *exist*, he said it never *exits*. For a
small embedded system, the main program is likely to be an infinite
loop that keeps running until you turn off the power; it never exits
because there's nothing to take control after it does so. And the
form of the program entry point for a freestanding implementation
is implementation-defined; it needn't even be called "main".

[...]

Actually, many deeply embedded systems have no floating point support at
all (because the sheer soft-float library is so large that it would
completely fill the ROM. I'm actually not sure if float support is
required by the standard, but would guess that it might be the case.

Floating-point arithmetic is not optional, even for freestanding
implementations. If your hardware doesn't support floating-point, you
can either emulate it in software, or you can provide a non-conforming
implementation (there's nothing wrong with that as long as you don't
claim conformance).

Hm, interesting. Would be interesting to know what is meant by that.
Because "implementation-defined manner" can also mean that nothing
(neither the prototype nor the name 'main' itself is required).

It means that the manner is defined (and documented) by the
implementation. It's implicitly assumed, I suppose, that there must be
*some* entry point.

[...]

 

[Dogukan Bayraktar]

25 Nisan 2013 Perşembe 21:53:39 UTC+3 tarihinde Tim Rentsch yazdı:

[snip]
I have got a file of .PDF about C programming called "K&D C

Programming".

In this e-book, i understand means of sentences.

I expect you mean: you understand the _meaning_ of (some) sentences...

But I don't know too vocabulary.

and that you don't know too _much_ vocabulary..

So I don't understand some sentences. I really want to read like

that e-books.

I think you mean you want to be able to read e-books like

the one you have. "I really want to be able to read other

e-books like that one." Is this what you meant, or did

you mean something else?

* By the way, forgive me for my English :/

* I hope everyone understand me..

I applaud your efforts, and your results. You're doing great!

("Applaud" is clapping hands, showing praise.)

Thanks everyone for comments.

Two suggestions:



One: when you find a passage you don't understand, post it

here and ask about it. You should get an explanation that

will help both with understanding C and with learning English.



Two: if you are up to a challenge, get a copy of the official

defining document for C, such as



http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf



This may be difficult for you, because it is more formal

English, but I think you'll be okay, and it has the advantage

that you can ask about it in the newsgroup here and lots of

people will be able to explain what it says. You will get

great practice for your English, and you will learn C much

more completely. (And if this document is too hard it is

always okay to go back to simpler stuff for a while.)



Good luck!

25 Nisan 2013 Perşembe 21:53:39 UTC+3 tarihinde Tim Rentsch yazdı:

[snip]
I have got a file of .PDF about C programming called "K&D C

Programming".

In this e-book, i understand means of sentences.

I expect you mean: you understand the _meaning_ of (some) sentences...

But I don't know too vocabulary.

and that you don't know too _much_ vocabulary..

So I don't understand some sentences. I really want to read like

that e-books.

I think you mean you want to be able to read e-books like

the one you have. "I really want to be able to read other

e-books like that one." Is this what you meant, or did

you mean something else?

* By the way, forgive me for my English :/

* I hope everyone understand me..

I applaud your efforts, and your results. You're doing great!

("Applaud" is clapping hands, showing praise.)

Thanks everyone for comments.

Two suggestions:



One: when you find a passage you don't understand, post it

here and ask about it. You should get an explanation that

will help both with understanding C and with learning English.



Two: if you are up to a challenge, get a copy of the official

defining document for C, such as



http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf



This may be difficult for you, because it is more formal

English, but I think you'll be okay, and it has the advantage

that you can ask about it in the newsgroup here and lots of

people will be able to explain what it says. You will get

great practice for your English, and you will learn C much

more completely. (And if this document is too hard it is

always okay to go back to simpler stuff for a while.)



Good luck!

Thank you so much ! You're really so helpful! I'm grateful for your help...
I loved this group I'll try to write some basic programs and try to run them. I'll post on this group, if I get any problem/error etc.

Thanks everyone for comments. I'm grateful for everyone!

 

[Keith Thompson]

On 04/25/2013 12:00 PM, David Brown wrote: [...]

point 167 clearly says that "main" can be defined "in some other
implemention-defined manner".

It can, but what 5.1.2.2.1 says is "It shall be defined with a return
type of int and [details of one permitted form] or [details of a second
permitted form] or equivalent; or in some other implementation-defined
manner."

It has been argued that "A and B or C or D; or E" should be parsed as
"(A and B) or C or D; or E", but that doesn't make sense. The intended
parse was "A and (B or C or D; or E)" (I'm not sure what affect the ';'
should have on the parse). If that weren't the case, A (== "it shall be
defined with a return type of int") would be redundant, since the two
explicitly specified forms already give a return type of 'int'. If that
clause wasn't intended to apply to the "other implementation-defined
manner", it could simply have been dropped.

Furthermore, 5.1.2.2.3p1 says:

If the return type of the main function is a type compatible
with int, a return from the initial call to the main function
is equivalent to calling the exit function with the value
returned by the main function as its argument; reaching the }
that terminates the main function returns a value of 0. If the
return type is not compatible with int, the termination status
returned to the host environment is unspecified.

(That's from N1570; the wording in N1256 is slightly different.) That
only makes sense if the return value of main is allowed to be something
other than int, or a type compatible with int.

 

[Keith Thompson]

Both these problems can be avoided by writing main() this
way:

int
main( void ){

/* ... */
/* whatever main does in its loop body */
/* ... */

return main();
}

Of course I'm not completely serious, but neither is it
completely a joke. Presented with such a program, gcc
compiles it (under -O2) as a simple loop, not a call, and
with no generated return opcode or any other extra clutter.

Making the body of main() an obvious infinite loop has the same effect.

 

[Keith Thompson]

I click on c.l.c every now and then just to see
if any interesting code snippets are posted.
(Or to see if any of the worst pedants ever
get enlightenment.)
A straightforward general question is asked here
... and almost half the posts deal with the pressing
issue:
To void main or not to void; that is the question.

Wow. Just ... Wow!
Perhaps the best immediate advice to Dogukan
will be to explain killfiles.

Perhaps you'd like to read the context in which I mentioned void main()
and then decide whether it was relevant. (Hint: it was.)

What kind of "enlightenment" do you think I need?

 

[Keith Thompson]

The group description translates to English as "Cprogramlama
This group is C, C + +, C #, Java, Php, such as languages ​​with C-like
syntax, and was established as a discussion and helping the environment.
General programming issues, algorithms, and other programming languages,
jobs and so on. correspondence related issues, too." That sounded
appropriate, I'm sorry that it wasn't.


That makes sense - but from my own experience with discussing technical
subjects in foreign languages, I think you should also have a fall-back
source of advice where you can use the language you understand best.


That should be "K&R", standing for "Kernighan and Ritchie", the authors.

If so, you've probably got an illegal copy of it. As far as I know, K&R
is not legally available other than as a paper book. (By "legal" I mean
"not violating copyright".)

 

[Keith Thompson]

On 04/25/2013 12:00 PM, David Brown wrote: [...]

point 167 clearly says that "main" can be defined "in some other
implemention-defined manner".

It can, but what 5.1.2.2.1 says is "It shall be defined with a return
type of int and [details of one permitted form] or [details of a second
permitted form] or equivalent; or in some other implementation-defined
manner."

It has been argued that "A and B or C or D; or E" should be parsed as
"(A and B) or C or D; or E", but that doesn't make sense. The intended
parse was "A and (B or C or D; or E)" (I'm not sure what affect the ';'
should have on the parse). If that weren't the case, A (== "it shall be
defined with a return type of int") would be redundant, since the two
explicitly specified forms already give a return type of 'int'. If that
clause wasn't intended to apply to the "other implementation-defined
manner", it could simply have been dropped.

Furthermore, 5.1.2.2.3p1 says:

If the return type of the main function is a type compatible
with int, a return from the initial call to the main function
is equivalent to calling the exit function with the value
returned by the main function as its argument; reaching the }
that terminates the main function returns a value of 0. If the
return type is not compatible with int, the termination status
returned to the host environment is unspecified.

(That's from N1570; the wording in N1256 is slightly different.) That
only makes sense if the return value of main is allowed to be something
other than int, or a type compatible with int.

I didn't read your "A and (B or C or D; or E)" closely enough. I
thought I was agreeing with you, but if I understand you correctly, I
disagree with you.

Without all the ABCDE stuff, an implementation *is* permitted to define
a form of main that returns a type other than int. The following
section, on program termination, wouldn't make sense otherwise.

 

[Tim Rentsch]

Making the body of main() an obvious infinite loop has the same
effect.

Sure, but doing that has the problems the earlier poster
was complaining about ("Both of these problems"), which
is what prompted me to respond in the first place.

 

[James Kuyper]

On 04/25/2013 12:00 PM, David Brown wrote: [...]
point 167 clearly says that "main" can be defined "in some other
implemention-defined manner".

It can, but what 5.1.2.2.1 says is "It shall be defined with a return
type of int and [details of one permitted form] or [details of a second
permitted form] or equivalent; or in some other implementation-defined
manner."

It has been argued that "A and B or C or D; or E" should be parsed as
"(A and B) or C or D; or E", but that doesn't make sense. The intended
parse was "A and (B or C or D; or E)" (I'm not sure what affect the ';'
should have on the parse). If that weren't the case, A (== "it shall be
defined with a return type of int") would be redundant, since the two
explicitly specified forms already give a return type of 'int'. If that
clause wasn't intended to apply to the "other implementation-defined
manner", it could simply have been dropped.

Furthermore, 5.1.2.2.3p1 says:

If the return type of the main function is a type compatible
with int, a return from the initial call to the main function
is equivalent to calling the exit function with the value
returned by the main function as its argument; reaching the }
that terminates the main function returns a value of 0. If the
return type is not compatible with int, the termination status
returned to the host environment is unspecified.

(That's from N1570; the wording in N1256 is slightly different.) That
only makes sense if the return value of main is allowed to be something
other than int, or a type compatible with int.

I didn't read your "A and (B or C or D; or E)" closely enough. I
thought I was agreeing with you, but if I understand you correctly, I
disagree with you.

Without all the ABCDE stuff, an implementation *is* permitted to define
a form of main that returns a type other than int. The following
section, on program termination, wouldn't make sense otherwise.

I'd forgotten about that. So we have either redundant specification or
contradictory specification, depending upon what was actually intended.
I've never been fond of this section's wording. It's right up there with
"are meant to imply interchangeability" and "by which the exposition of
language elements is to be interpreted" on my list of the least clear
phrases in the standard.