I need your advices about C prg.

[glen herrmannsfeldt]

I don't recall details, but I believe there have been systems on which
arguments and return value both went on the stack, so if your function
didn't have the same expectations for its return value as the caller, it
could end up reading the wrong arguments. Not sure, though.

But that assumes that there are some arguments. In the case of

void main() { ... /* no arguments ! */

it wouldn't apply. Systems I know of return int in registers, but larger
return values could go on the stack. (Especially struct return values.)

-- glen

 

[Stephen Sprunk]

The second languages are taught because they are useful to
communicate with those who don't speak our native language.
Therefore, their choice is motivated by how useful they might be to
communicate with others.

But if someone else's second language already matches your native
language, what is the point in learning their native language as your
second language? That is the dilemma native English speakers face.

In the last decade or so, english managed to become a de facto
esperanto, but that was mainly because the US dominated the world's
economy and academia. Things won't stay like that for long.

Even if it doesn't, which remains to be seen, there's a reasonable case
that English will soon reach critical mass, if it hasn't already: it no
longer needs the US to sustain its growth.

In addition, in some western countries it's much more likely that you
stumble on someone who speaks mandarin natively than english.

.... but you're more likely to stumble across someone who speaks English
as a second language than someone who speaks Mandarin, either natively
or as a second language.

Again, a couple of decades ago francophones were using the same
arguments to justify why it would be silly for them to learn a second
language.

French never reached anywhere near 1.8 _billion_ speakers.

Nor did we, during that era, see _half_ of the world's 6,000 languages
no longer being taught to the next generation. Language extinction on
that scale--and at that speed--is unprecedented in human history.

Hardware production is already firmly established in Asia. I
wouldn't bet that in a decade or so english will still be the
prefered language to communicate with them.

I would. English is the de facto standard for all international
communication these days, even when none of the participants are native
speakers. Even ignoring cultural barriers to learning each others'
languages, English is simply the better investment: it allows one to
communicate with far more people than any other language.

Regarding software, I've published a small library (written in C, so
let's pretend it's on-topic) which is distributed under a FLOSS
license and managed to be somewhat popular. Currently, according to
the site's download statistics, the most number of downloads are by
far from China, while those from the US amount to only about 70% of
that.

Singapore is ranked 4th, and Taiwan ranks 9th, right after the UK.

.... and presumably most of those people are able to at least read
English, which supports the point at hand.

S

 

[James Kuyper]

On 04/26/2013 06:54 PM, Seebs wrote:
....

In any event, I think I'd say this: I don't think I've ever regretted learning
something.

I once read a very short summary of the basic premise behind a
particular horror movie. Ever since then, every once in a while I think
about it and feel overwhelming disgust. That's one thing I greatly
regret learning.

 

[Tim Rentsch]

[snip all but...]

I made a specific point about /small/ embedded systems. I didn't
define "small embedded systems" here, but Linux (or other OS's
capable of calling independent programs) do not count as "small" -
"small" system programs are free-standing rather than hosted.

I think you misunderstand what these terms mean as the Standard
defines them. A Linux kernel is a freestanding program, or more
accurately, it is compiled to run in a freestanding environment.
A Linux kernel is every bit as much a freestanding program, as
far as the Standard is concerned, as 47 byte programs running on
bare 8-bit processors with 256 bytes of RAM.

 

[Seebs]

But if someone else's second language already matches your native
language, what is the point in learning their native language as your
second language? That is the dilemma native English speakers face.

I find it extremely useful to have been fluent in Mandarin, even though
I've largely lost the vocabulary, because I understand slightly-imperfect
English much better. I know why the subtitles read "DO NOT WANT!"

-s

 

[Tinxx]

I'd try with reading the respective cs books in English if that is the original language they were written in. I did so when I studied computer science about 20 years ago ;-). I still read cs books in English and not in my mother tounge, although the US publishing companies have changed to translating their books. Reason being that the English versions are much easier and much more pleasant to read. You'd be amazed at how some of the big books incs manage to explain things in simple terms using analogies from every daylife. Books written by authors in my country compete in using as many greek symbols as possilbe and as many latin words as possible. It's simply awful and nothing to pick up from.

-- Tinxx

 

[Tim Rentsch]

[snip all but...]

I made a specific point about /small/ embedded systems. I didn't
define "small embedded systems" here, but Linux (or other OS's
capable of calling independent programs) do not count as "small" -
"small" system programs are free-standing rather than hosted.

I think you misunderstand what these terms mean as the Standard
defines them. A Linux kernel is a freestanding program, or more
accurately, it is compiled to run in a freestanding environment.
A Linux kernel is every bit as much a freestanding program, as
far as the Standard is concerned, as 47 byte programs running on
bare 8-bit processors with 256 bytes of RAM.

Yes, I realise that. But I think I was a little unclear here -
programs running under Linux are "big" (by my intentionally vague
definition) and "hosted" (by more rigid Standard definition),
while the kernel itself is "big" and "free-standing". My
distinction between "small" and "big" is more about the resources
available to the program, and the types of concerns you have when
creating efficient programs. Usually it is enough to simply talk
about "small" or "big" without defining any details.

It's rather maddening when someone understands what certain
words mean but won't make the effort to use them appropriately
or express what they mean accurately. The situation you mean to
talk about has nothing to do with embedded versus freestanding,
nor in fact "big" versus "small", but whether the hardware
environment is severely resource constrained for the program
in question. Say so.

 

[Malcolm McLean]

And the term "resource constrained" /sounds/ like a nice solid term - but
does not say anything about which resources are constrained, and in what way.

"Resource constrained" is used a bit misleadingly.
Typically when you have a tiny embedded system, with say 128 bytes of RAM,
it's designed to run one program, which will be perfectly within its
capabilities. Otherwise the hardware engineer would have plugged in a
slightly bigger processor.
Typically when you are using a supercomputer, with massive memory, disk space,
and processing power, that's because you have a heroic problem to solve,
like simulation of the world's weather system or an attack on protein folding.
You virtually always want more processing power than you have available.

However the first situation is often described as "resource constrained".

 

[Tim Rentsch]

On 27/04/13 02:49, Tim Rentsch wrote:

[snip all but...]

I made a specific point about /small/ embedded systems. I didn't
define "small embedded systems" here, but Linux (or other OS's
capable of calling independent programs) do not count as "small" -
"small" system programs are free-standing rather than hosted.

I think you misunderstand what these terms mean as the Standard
defines them. A Linux kernel is a freestanding program, or more
accurately, it is compiled to run in a freestanding environment.
A Linux kernel is every bit as much a freestanding program, as
far as the Standard is concerned, as 47 byte programs running on
bare 8-bit processors with 256 bytes of RAM.

Yes, I realise that. But I think I was a little unclear here -
programs running under Linux are "big" (by my intentionally vague
definition) and "hosted" (by more rigid Standard definition),
while the kernel itself is "big" and "free-standing". My
distinction between "small" and "big" is more about the resources
available to the program, and the types of concerns you have when
creating efficient programs. Usually it is enough to simply talk
about "small" or "big" without defining any details.

It's rather maddening when someone understands what certain
words mean but won't make the effort to use them appropriately
or express what they mean accurately. The situation you mean to
talk about has nothing to do with embedded versus freestanding,
nor in fact "big" versus "small", but whether the hardware
environment is severely resource constrained for the program
in question. Say so.

I use "big" and "small" in reference to embedded systems (or rather,
the programs running on them). The terms are intentionally vague -
/I/ know they are vague, and I think it's clear to readers that they
are vague. I would rather use such terms rather than something that
has a clear definition (such as "freestanding" vs. "hosted" -
although in the embedded world, that is not clear-cut either). And
the term "resource constrained" /sounds/ like a nice solid term -
but does not say anything about which resources are constrained, and
in what way. I have worked with systems that I call "small",
despite having far more processor speed or memory than older PC's -
which are "big".

When I want to be specific, such as "on 8-bit systems" or "on
systems with expensive pointer handling" or "on systems where
dynamic memory is not allowed", then I try to do so. But for
general points, where there is no clear line, I don't want to draw
lines - all I want is an indicator of size.

I think you missed my point. I'm not talking about needing
to be so specific as to distinguish, say, a Border Collie from
a Rough Collie. I'm talking about cases where someone says
'dog' but what they mean is 'cat'.

The point of language is to communicate.

No argument there.

If people understand what I mean by a "small embedded system",
then it is an appropriate choice of phrase.

And they didn't, so it wasn't.

If people don't understand me, then I need to explain better -
but "resource constrained" would be no improvement.

If you don't like the phrasing I used, you're welcome to look for
something better. It does have the advantage that it clearly
identifies the most salient characteristic of the circumstances
under consideration, without getting bogged down in irrelevancies
like embeddedness or freestandingness.

 

[Keith Thompson]

Hi, please read this tutorial:

http://www.phy.pmf.unizg.hr/~matko/C21/ch01/ch01.htm

I wouldn't recommend that tutorial. The examples use an obsolete
version of the language. The first sample program is:

1: #include <stdio.h>
2:
3: main()
4: {
5: printf("Hello, World!\n");
6: return 0;
7: }

which is invalid as of the 1999 standard. "main()" should be
"int main(void)". Even in C89/C90, "int main(void)" is better style.

An example in a later example uses the gets() function without
explaining how dangerous it is.

Question 18.9 of the comp.lang.c FAQ, <http://www.c-faq.com/>, has links
to a number of online C tutorials. Be sure to read the disclaimer
included in the answer.

Yes, you have to learn technical English, it is usefull to read.
It is more easy that spoken language.
Avoid, in a first moment, to learn spoken language especially in the form
of the USA.

How is that relevant?

 

[Keith Thompson]

I think it is a good starting point also to understand how many is old how
many is wrong. A lot of code out there is wrote in this manner.

Yes, a lot of code is written using obsolete versions of the language.
Pointing that out in a tutorial is fine. Presenting obsolete code
without saying it's obsolete is not.

Yes, i think is relevant, may be that does not seem to you.

I asked *how* it's relevant, not *whether* you think it's relevant.

This newsgroup discusses the C programming language, and this
thread is about C tutorials. I fail to see how spoken US English
is relevant to either.

I encourage you to focus on the topic.

 

[James Kuyper]

You have to read the entire tutorial and then judge that.

How do you know that he hadn't already done so? Having read the entire
tutorial just now, I found nothing to justify changing the judgments
that Keith expressed up above.

The code at that site is written using an obsolete version of the
language - it relies upon main() being given an implicit return type of
'int'. That was a feature of C90 which was dropped in C99, 14 years ago,
and was never good practice even when it was permitted (which is why it
was dropped). I found similarly dated material in the other chapters
that I browsed. The tutorial doesn't say that it was written for an
obsolete version of the language, and neither did you when presenting it
as a place to go for learning C.

Those web pages have not been updated since 1999-08-31. That partially
explains why the information is out of date, though that doesn't excuse
your decision to mention it as a good place to learn C. However, by that
time most of the features of the new standard had already been agreed to
by the committee and were subjects of public discussion in both
comp.std.c and this newsgroup. Preliminary drafts were easily obtainable
by those who were interested. If the author had been paying attention to
such things, he could have re-written his code to be compatible with
both the current standard and the planned changes to the standard. He
could also have discussed what those planned changes were. He did neither.

 

[James Kuyper]

Now i understand because someone has tried to open a comp.lang.c
alternative news group, to separate the normal people from the rest.

comp.lang.c was created for discussion of the C language. I suppose you
could describe that as separating people who have an interest in such
discussions from the people (I guess you could call them "normal") who
have no such interest. If your comment was meant to convey any meaning
other than that, you should explain in more detail, at least if you care
about whether or not anyone understands what you're trying to say.

 

[Keith Thompson]

You have to read the entire tutorial and then judge that.

Not really. I found serious problems in the first few pages.
That was enough for me to decide that reading the whole thing was
not worth my time. I suppose it was conceivable that the rest of
it made up for those problems, but there are plenty of C tutorials
that *don't* use implicit int and gets(). (James Kuyper did read
the whole thing, and confirmed my tentative conclusions.)

What is your basis, as an acknowedged C non-expert, for maintaining
that that particular tutorial is a good one? If you think that
you're right and multiple C experts are wrong, well, that's a
possibility, but you'll have to convince us.

Consider the possibility that you might be wrong. (I make mistakes
all the time myself; I usually acknowledge them.)

 

[Les Cargill]

Now i understand because someone has tried to open a comp.lang.c
alternative news group, to separate the normal people from the rest.

It may be pedantic nit-picking, but said pedantic nit-picking
is a good thing to be familiar with.

 

[å¾å†¬å†¬]

As I know ,English is not so decisive,Aii the way you have some knowledge of English, it is enogh.Just read one or two basic books in your language.perfer to read some famous book , like Modern C programming. then to read programming pearls.I ihink it is Ok.

 

[Nick Keighley]

I think of myself as a semi-embedded programmer. The systems I work on
aren't on desktops or in server rooms. But my CV seems to go to the
bottom of the heap when I apply for jobs that call themselves
"embeded" (I don't have any problems getting employment otherwise).
The systems I work on do have proper OSs (Windows or Linux)

I try to make the distinction of "small embedded systems" - basically,
microcontroller programming where the program runs entirely from flash,
mostly using flash and ram that are integrated into the microcontroller.
 Typical cpus are 8-bit or 16-bit devices (like the AVR or msp430), or
small 32-bit devices (Cortex M family are the most common these days).
These are usually bare metal, or run embedded OS's like FreeRTOS.

I guess those are the jobs I don't get replies to!

"Mid level" embedded systems run things like VxWorks or Linux, have
processors with external ram and flash, but don't have disks, and have
mostly fixed hardware (you might be able to plug in a USB memory stick,
but you are not going to change the screen or memory).  Wireless routers
are in this category.

"High-end" embedded systems are often more like PC's, except that you
mostly restrict the software and hardware that runs on it, and obviously
the hardware and software are often specialised.  "Media centres" would
be an example.

those are the systems I work on. Production lines at the moment. Weird
hardware and cut down versions of the OSs. Mine are diskless at the
moment.