Learning C?

[***** charles]

Hi all,

I would like to know how all of you learned C.
Was it books, Internet, human mentor, class or other?

later,
charles.....

[Ben Pfaff]

"***** charles" <sh*******@sbcglobal.netwrites:

I would like to know how all of you learned C.
Was it books, Internet, human mentor, class or other?

Many years ago, I read a basic tutorial. Then I bought a copy of
the standard. Then I started reading comp.lang.c.
--
"Some people *are* arrogant, and others read the FAQ."
--Chris Dollin

[Richard Heathfield]

***** charles said:

Hi all,

I would like to know how all of you learned C.
Was it books, Internet, human mentor, class or other?

I mis-learned C on a three-month course, 35 hours a week. I then
mis-applied that mis-knowledge for a few years, and became a sort of
mis-expert. It wasn't until late 1998 that I discovered I'd been
abusing the interface spec for the entry point, for almost a decade!

In 1999, I started reading comp.lang.c on a regular basis, and it took
perhaps two or three months of daily reading-the-whole-feed and many
(sometimes rather animated) discussions to mend my misunderstandings.
Much kudos to Martin Ambuhl, Billy Chambless, Dann Corbit, Chris
Dollin, Lawrence Kirby, Kaz Kylheku, Mikey Lee, Joe Maun, Ben Pfaff,
Dan Pop, "Noone Really", Will Rose, Michael Rubinstein, Richard Stamp,
Steve Summit, Chris Torek, Stephan Wilms, Dik Winter, and no doubt many
others whose names temporarily escape me, for their patience over that
period.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[***** charles]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:fp*********************@bt.com...

***** charles said:

Hi all,

I would like to know how all of you learned C.
Was it books, Internet, human mentor, class or other?

I mis-learned C on a three-month course, 35 hours a week. I then
mis-applied that mis-knowledge for a few years, and became a sort of
mis-expert. It wasn't until late 1998 that I discovered I'd been
abusing the interface spec for the entry point, for almost a decade!

In 1999, I started reading comp.lang.c on a regular basis, and it took
perhaps two or three months of daily reading-the-whole-feed and many
(sometimes rather animated) discussions to mend my misunderstandings.
Much kudos to Martin Ambuhl, Billy Chambless, Dann Corbit, Chris
Dollin, Lawrence Kirby, Kaz Kylheku, Mikey Lee, Joe Maun, Ben Pfaff,
Dan Pop, "Noone Really", Will Rose, Michael Rubinstein, Richard Stamp,
Steve Summit, Chris Torek, Stephan Wilms, Dik Winter, and no doubt many
others whose names temporarily escape me, for their patience over that
period.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

What would you recomend to a person who wanted to start from scratch?
(I have writen code on other languages including asm) Just never learned C.

later.....

[Flash Gordon]

***** charles wrote, On 28/03/07 18:55:

Hi all,

I would like to know how all of you learned C.
Was it books, Internet, human mentor, class or other?

K&R2 + a human mentor who was very much my junior. He had done C but
very little programming experience I had a lot of experience but none in C.
--
Flash Gordon

[Kenneth Brody]

Flash Gordon wrote:

>
***** charles wrote, On 28/03/07 18:55:

Hi all,

I would like to know how all of you learned C.
Was it books, Internet, human mentor, class or other?

K&R2 + a human mentor who was very much my junior. He had done C but
very little programming experience I had a lot of experience but none
in C.

I had K&R (I suppose it could be retronymed "K&R1"), a CP/M computer,
and a floppy with a C compiler on it. I had a lot of programming
experience in several high-level languages, and a couple of assembly
languages. Later, we got a Unos-based system to get more experience
with C.

Note that, technically, it was "C plus [what was to become] POSIX".

Nothing beats hands-on experience. If you have someone who could
be a mentor, by all means do it as well.

I'm sure if you search this group's archives, you'll find numerous
references to books and websites, both good and bad. Use the good
ones, and avoid the bad ones like the plague. (For example, there
was a recent posting that quoted a book which talked about how to
pass an array by value [as opposed to by reference] that was simply
wrong, on several counts.)

Note that I find, even after 20+ years of programming in C, that I
still have things that I mis-learned. There are also things that I
have learned from reading this group which would have made my life
a lot easier if I had learned them years ago. (Mostly, it's things
that I've "worked around", not knowing that I didn't have to "work
around" them in the first place. Others are things that would have
let me write things more efficiently.)

Finally, it's much easier to learn the right things from the start
than it is to unlearn the wrong things.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Ian Collins]

***** charles wrote:

Hi all,

I would like to know how all of you learned C.
Was it books, Internet, human mentor, class or other?

I don't know if the program was ever updated for C89, or even if it
still exists, but I learned C using "learn C" on a VAX. It was the
forerunner of on-line tutorials, taking the user through the exercises
in K&R.

--
Ian Collins.

[Randy Howard]

On Wed, 28 Mar 2007 12:55:20 -0500, charles wrote
(in article <l6**************@newssvr22.news.prodigy.net>):

Hi all,

I would like to know how all of you learned C.
Was it books, Internet, human mentor, class or other?

All of the above, plus a lot of time, energy, mistakes, debugging, more
time, more energy...

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

[pete]

Richard Heathfield wrote:

>
***** charles said:

Hi all,

I would like to know how all of you learned C.
Was it books, Internet, human mentor, class or other?

I mis-learned C on a three-month course, 35 hours a week. I then
mis-applied that mis-knowledge for a few years, and became a sort of
mis-expert. It wasn't until late 1998 that I discovered I'd been
abusing the interface spec for the entry point, for almost a decade!

In 1999, I started reading comp.lang.c on a regular basis, and it took
perhaps two or three months of daily reading-the-whole-feed and many
(sometimes rather animated) discussions to mend my misunderstandings.

I learned C from a couple of Schildt books in about a month.
I didn't feel like I was straightened out
until after reading clc for about two years.

--
pete

[Gregor H.]

On Wed, 28 Mar 2007 12:57:50 -0600, "***** charles" <sh*******@sbcglobal.net>
wrote:

>
What would you recommend to a person who wanted to start from scratch?
(I have writen code on other languages including asm) Just never learned C.

I clearly would recommend K&R's "The C Programming Language" then! It's a
classic.

"This book is meant to help the reader learn how to program in C. It contains
a tutorial introduction to get new users started as soon as possible, separate
chapters on each major feature, and a reference manual. Most of the treatment
is based on reading, writing and revising examples, rather than on mere
statements of rules. For the most part, the examples are complete, real
programs rather than isolated fragments. All examples have been tested
directly from the text, which is in machine-readable form. Besides showing how
to make effective use of the language, we have also tried where possible to
illustrate useful algorithms and principles of good style and sound design.

The book is not an introductory programming manual; it assumes some
familiarity with basic programming concepts like variables, assignment
statements, loops, and functions. Nonetheless, a novice programmer should be
able to read along and pick up the language, although access to a more
knowledgeable colleague will help."

(K&R, The C Programming Language, 2nd edition)
G. H.

--

E-mail: info<at>simple-line<Punkt>de

[Gregor H.]

On Wed, 28 Mar 2007 11:55:20 -0600, "***** charles" <sh*******@sbcglobal.net>
wrote:

>
I would like to know how all of you learned C.
Was it books, Internet, human mentor, class or other?

A book, a PC (under Windows) and a C compiler (Borland)!

To-do I still use books (K&R for example), PCs and C compilers (gcc, lcc). But
I also benefited from www discussion boards and (to a lesser degree) from this
newsgroup (tendency: rising).
G. H.

--

E-mail: info<at>simple-line<Punkt>de

[John Bode]

On Mar 28, 12:55 pm, "***** charles" <[e-mail]:

Hi all,

I would like to know how all of you learned C.
Was it books, Internet, human mentor, class or other?

later,
charles.....

Learned the pre-ANSI version in college on VAX/VMS (circa 1986). Our
CS department switched from using Pascal to C for the intro classes
the very semester I started, so none of the professors or grad
students had a solid grasp on the language they were trying to teach.
It was ugly. A third of my class *changed majors* because they had so
much trouble understanding C.

Fortunately, I bought the second edition of "C: A Reference Manual" on
a whim, which turned out to be one of the better references available,
and it helped me get through those first few semesters.

Three editions later it's still my primary C reference, although I'm
not doing a whole lot of C programming anymore.

However, comp.lang.c did play an important role in my continuing
education when I graduated and started working for a living. Nothing
like having a bunch of hyper-anal pedants dogpile you to make you pay
attention to what you're doing. I think I learned more from reading
this group than I did from most textbooks.

[Richard Heathfield]

***** charles said:

<snip>

What would you recomend to a person who wanted to start from scratch?
(I have writen code on other languages including asm) Just never
learned C.

Firstly, I would endorse Gregor H's recommendation of K&R2.

Secondly - write lots of C programs. Compile them on several different
compilers, preferably on at least two different platforms, the more
widely different the better. Crank up your compiler's diagnostic level
to the max, and learn to "read" diagnostics, to find out what they're
really telling you - "making pointer from integer without a cast"
doesn't necessarily mean "add a cast"!

Thirdly - read comp.lang.c regularly, and pay attention to the experts.
You can generally tell who they are partly because they can and often
do back up their responses with reference to the language definition
and partly because, even when they disagree with each other, they
manage to do so without animosity. :-)

Fourthly - write lots of C programs (or did I mention that already?).

And fifthly - write lots of C programs.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Anthony Irwin]

***** charles wrote:

Hi all,

I would like to know how all of you learned C.
Was it books, Internet, human mentor, class or other?

Hi,

I would say I am still learning C but I have the fundamentals down
pat. I bought a few C books pretty much all of which I am told are bad
from people on comp.lang.c.

I recently bought the k&r2 book that everyone here talks about and am
still going through it and like it so far.

I think that comp.lang.c is a very good resource as there are people
that know what they are talking about and are happy to help newbies
providing they make an effort and provide code samples of what they
have tried and are willing to look at things like k&r2 and the faq etc.

I don't have any teachers as I am teaching myself but I believe that
most the experts on comp.lang.c would be better then most c teachers
anyway.

So thanks to the comp.lang.c regulars that post helpful advice and
share their knowledge to us all.

Kind Regards,
Anthony Irwin

[Gregor H.]

On Wed, 28 Mar 2007 23:24:23 +0200, Gregor H. <nomail@invalidwrote:

Hell, a bug! Corrected!

>
To-day I still use books (K&R for example), PCs and C compilers (gcc, lcc).
~~~~~~
But I also benefited from www discussion boards and (to a lesser degree) from
this newsgroup (tendency: rising).

G. H.

--

E-mail: info<at>simple-line<Punkt>de

[Pierre Asselin]

***** charles <sh*******@sbcglobal.netwrote:

I would like to know how all of you learned C.
Was it books, Internet, human mentor, class or other?

Pre-ANSI C from Kernighan and Ritchie first edition, having first
programmed in Pascal and before that in Fortran. The C platform
was 4.2 BSD Unix, if I remember correctly.
--
pa at panix dot com

[CBFalconer]

***** charles wrote:

>
I would like to know how all of you learned C.
Was it books, Internet, human mentor, class or other?

All of the above, excluding class.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Keith Thompson]

"***** charles" <sh*******@sbcglobal.netwrites:

I would like to know how all of you learned C.
Was it books, Internet, human mentor, class or other?

I took a comparative programming languages class back in 1981 (C,
Lisp, and a little bit of Snobol, Fortran, and Cobol; the instructor
briefly covered the latter two so we'd be able to mention it on our
resumes). The C textbook was K&R; my copy happens to be within reach
as I type this, along with my copies of K&R2 and H&S5. We worked on a
VAX 11/780 running Unix (some version of BSD) (it was sdcsvax). I
remember that file names were limited to 14 characters.

After that, I didn't use C all that much in my work, but it's always
there below the surface, especially on Unix. This newsgroup keeps me
on my toes, and I try to return the favor.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Mark McIntyre]

>"***** charles" <sh*******@sbcglobal.netwrites:

>I would like to know how all of you learned C.
Was it books, Internet, human mentor, class or other?

At University in the early eighties I learned some Pascal as part of
my course, but my PhD required me to do numerical work in Fortran on
the 8800 cluster and the 11/780s we used for our finite elements
packages.

I decided early on that Fortran was gruesome, and at the same time
started using an Atari ST in the lab which had a C compiler
preinstalled. C looked kinda fun - heck, I could get the VMS compiler
to emit wonderful error messages, and t'was easy to poke stuff into my
Atari screen buffer - so I borrowed a copy of K&R.

I quickly taught myself how to pass Fortran strings and numerics to C,
and went from there to a complete interface fo the NR/FE routines, a
driver for the test rig I was using, and analysis packages for my
data. I also spent some spare time porting some TeX utils from VMS to
PC and Atari, which taught me a _lot_ about portability issues, and
wrote an HP plotter driver for Gnuplot (the ones that came with it
didn't work for our particular plotter) which taught me some
interesting h/w interface stuff.

Never attended any formal courses other than Pascal,, but discovered
CLC a _long_ time ago and lurked for many years. I've probably learned
more about C here than anywhere.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Army1987]

"***** charles" <sh*******@sbcglobal.netha scritto nel messaggio
news:l6**************@newssvr22.news.prodigy.net.. .

Hi all,

I would like to know how all of you learned C.
Was it books, Internet, human mentor, class or other?

I began learning it in class.
It took me few days to understand that all the teacher was doing was copying
examples from our textbook, including errors and idiotic things.
(For example, how do you write a recursive function working on an array?
1. You don't. You use a for loop to work through the array. That's what the
for statement was invented for. Recursion is unnecessary about 80% of times,
as well as filling the stack if you pass a very large array. Or:
2. If the array has positive length, the function performs the needed
operation on the first element, then calls itself with parameters (array+1,
length-1); alternatively, it works on the last element and calls itself with
(array, length-1).
But that was not what my teacher did. He usually did something like these:

int Function(int a[], int l)
{
int FunctionRic(int a[], int l, int i, int c);

return FunctionRic(a, l, 0, 0);
}

int FunctionRic(int a[], int l, int i, int c)
{
if (i == l) return c;
perform_desired_operations(a[i]);
return FunctionRic(a, l, i+1, c);
}

Then, browsing the FAQ, it took me few days to understand that textbook was
crap. (How would you call a textbook which, in his introduction, more or
less says it's trying to write Pascal-like code in C?)

[Al Balmer]

On Wed, 28 Mar 2007 11:55:20 -0600, "***** charles"
<sh*******@sbcglobal.netwrote:

>Hi all,

I would like to know how all of you learned C.
Was it books, Internet, human mentor, class or other?

I learned C (or an approximation of it) by reading the Lattice C
manuals while working on a program which had been ported from a BCPL
implementation. That learning was supplemented and refined later by
K&R.

Later, I spent a great deal of time using Turbo C, Microsoft C
(pre-Visual), then Watcom C (which I helped Watcom/Powersoft/Sybase
support in on-line forums for a few years.) However, I was still
missing many of the fine points until I started reading this group.

--
Al Balmer
Sun City, AZ

[***** charles]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:Vr******************************@bt.com...

***** charles said:

<snip>

Is there any way I can prevent the "mis-learning" that you
mentioned and went through?

Someone mentioned that I should write C code on deferent
architectures and different compilers. The only platform in
which I have an interest is AMD64/EM64T and the only
compiler is the one that comes free with Linux. Both keep
my cost low.

later.....

[***** charles]

<snip>

Finally, it's much easier to learn the right things from the start
than it is to unlearn the wrong things.

Am I bound to make the same mistakes as others or how do I
avoid the pitfalls as a beginner?

later,
charles......

[Richard Heathfield]

***** charles said:

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:Vr******************************@bt.com...

>***** charles said:

<snip>

Is there any way I can prevent the "mis-learning" that you
mentioned and went through?

Your best bet is to read comp.lang.c thoroughly on a regular basis.
You'll quickly discover who knows their stuff and who is just posturing
or trolling. Ignore the latter completely, and focus on the advice
given by the former.

Someone mentioned that I should write C code on deferent
architectures and different compilers. The only platform in
which I have an interest is AMD64/EM64T and the only
compiler is the one that comes free with Linux.

For now, yes. Will that always be true? "Prediction is always difficult,
especially about the future," as someone famous said once.

Both keep my cost low.

Learning how to write portable, robust, efficient, reliable code is very
likely to help keep your costs down, too.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Flash Gordon]

***** charles wrote, On 29/03/07 19:12:

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:Vr******************************@bt.com...

>***** charles said:

<snip>

Is there any way I can prevent the "mis-learning" that you
mentioned and went through?

Start with a good book. K&R2 is worth more than it costs.

Someone mentioned that I should write C code on deferent
architectures and different compilers. The only platform in
which I have an interest is AMD64/EM64T and the only
compiler is the one that comes free with Linux. Both keep
my cost low.

One quick way of getting multiple platforms...

Compile and test your programs as both 32 bit and 64 bit applications
(you will need a 64 bit version of Linux). Dual boot your machine with
Windows and install MS Visual Studio Express (which is free) and test
with that as well.

Turn up the warnings to maximum on everything and learn to understand
the reasons for the warnings.

Don't only post your problems here, also post small pieces of code that
you believe are correct, and read all the comments about why they are
not or how they could be done better.
--
Flash Gordon

[***** charles]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:CP******************************@bt.com...

***** charles said:

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:Vr******************************@bt.com...

***** charles said:

<snip>

Is there any way I can prevent the "mis-learning" that you
mentioned and went through?

Your best bet is to read comp.lang.c thoroughly on a regular basis.
You'll quickly discover who knows their stuff and who is just posturing
or trolling. Ignore the latter completely, and focus on the advice
given by the former.

Someone mentioned that I should write C code on deferent
architectures and different compilers. The only platform in
which I have an interest is AMD64/EM64T and the only
compiler is the one that comes free with Linux.

For now, yes. Will that always be true? "Prediction is always difficult,
especially about the future," as someone famous said once.

Both keep my cost low.

Learning how to write portable, robust, efficient, reliable code is very
likely to help keep your costs down, too.

Good point. I now know the first book will be k&r2. Debian doesn't
officially support AMD64 yet but they are working on it. I just hope that
I don't ask to many stupid questions and get beat up to bad.

later,
charles......

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Mark McIntyre]

On Thu, 29 Mar 2007 18:16:40 GMT, in comp.lang.c , "***** charles"
<sh*******@sbcglobal.netwrote:

><snip>

>Finally, it's much easier to learn the right things from the start
than it is to unlearn the wrong things.

Am I bound to make the same mistakes as others

Of course - everybody falls of the horse at first....
But don't worry, you will probably make some new mistakes of your own
too. :-)

>how do I avoid the pitfalls as a beginner?

lurk in CLC and take note of what is said. Read the FAQ for this
group. Practice.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[hlubenow]

***** charles wrote:

Someone mentioned that I should write C code on deferent
architectures and different compilers. The only platform in
which I have an interest is AMD64/EM64T and the only
compiler is the one that comes free with Linux.

That's gcc. It's just fine.
Please compile the one-file-programs, you'll start with with

gcc -Wall -pedantic main.c

if they're called "main.c" for example:

"-Wall" gives you all compiler-warnings and "-pedantic" checks, if your code
is compliant to the older C standard which is described in K&R2 (written
about 1991).
A lot of compilers like for example "Borland C++-Builder X" on Windows don't
support the newer C99 (as there've been a lot of discussions about it). I've
read, Microsoft's compiler doesn't support it either.
Also check

g++ -Wall -pedantic main.c

Please write your programs in a way, that this works too.
This increases your chances that your code can be compiled elsewhere too.

H. (My first posting here :))

[Flash Gordon]

hlubenow wrote, On 29/03/07 23:32:

***** charles wrote:

>Someone mentioned that I should write C code on deferent
architectures and different compilers. The only platform in
which I have an interest is AMD64/EM64T and the only
compiler is the one that comes free with Linux.

That's gcc. It's just fine.
Please compile the one-file-programs, you'll start with with

gcc -Wall -pedantic main.c

if they're called "main.c" for example:

"-Wall" gives you all compiler-warnings and "-pedantic" checks, if your code
is compliant to the older C standard

You need -ansi -pedantic to specify C89 compliance. There are options
for C99 compliance as well, but even then it is not fully C99 complience.

which is described in K&R2 (written
about 1991).

K&R2 pre-dates the first C standard, but not by much. So it was either
88 or 89.

A lot of compilers like for example "Borland C++-Builder X" on Windows don't
support the newer C99 (as there've been a lot of discussions about it). I've
read, Microsoft's compiler doesn't support it either.

MS does not support it, gcc still has holes, and so do most other compilers.

Also check

g++ -Wall -pedantic main.c

That would be C++ which is a very different language.

Please write your programs in a way, that this works too.

No, DON'T. C++ requires casting the value returned by malloc, which is
bad practice in C, and there are various other gotchas. ALWAYS use a C
compiler for C and a C++ compiler for C++ since the languages are different.

This increases your chances that your code can be compiled elsewhere too.

H. (My first posting here :))

Well, you have a few things to learn yet.
--
Flash Gordon

[CBFalconer]

hlubenow wrote:

***** charles wrote:

>Someone mentioned that I should write C code on deferent
architectures and different compilers. The only platform in
which I have an interest is AMD64/EM64T and the only
compiler is the one that comes free with Linux.

That's gcc. It's just fine.
Please compile the one-file-programs, you'll start with with

gcc -Wall -pedantic main.c

Better is:

gcc -W -Wall -ansi -pedantic

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

Richard Heathfield wrote:

***** charles said:

.... snip ...

>>
Is there any way I can prevent the "mis-learning" that you
mentioned and went through?

Your best bet is to read comp.lang.c thoroughly on a regular
basis. You'll quickly discover who knows their stuff and who
is just posturing or trolling. Ignore the latter completely,
and focus on the advice given by the former.

To a first approximation. Some trolls contrive to sound incredibly
wise on the initial few encounters.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[hlubenow]

>Please write your programs in a way, that this works too.

>
No, DON'T. C++ requires casting the value returned by malloc, which is
bad practice in C, and there are various other gotchas. ALWAYS use a C
compiler for C and a C++ compiler for C++ since the languages are
different.

Well, ok, but what if you write some kind of engine in C and lateron you
want to write a GUI for it. Most GUI-toolkits like Qt or even C++/Tk

http://cpptk.sourceforge.net/

use C++. On Windows, you or somebody else may want to use the MFC, not the
rather old WinAPI. Then you have to rewrite your engine-code.
So why not write it from the start in a way that C++-compilers can handle it
too. Casting malloc() is considered bad style,

http://faq.cprogramming.com/cgi-bin/...&id=1043284351

but it won't hurt either. Afterall C++ should be compatible to C.

Well, you have a few things to learn yet.

Thanks for that heartly welcome, but yes, that's why I'm here.

H.

[Richard Tobin]

In article <1s************@athlon.my>, hlubenow <hl*******@gmx.netwrote:

>No, DON'T. C++ requires casting the value returned by malloc, which is
bad practice in C, and there are various other gotchas. ALWAYS use a C
compiler for C and a C++ compiler for C++ since the languages are
different.

>Well, ok, but what if you write some kind of engine in C and lateron you
want to write a GUI for it. Most GUI-toolkits like Qt or even C++/Tk

http://cpptk.sourceforge.net/

use C++. On Windows, you or somebody else may want to use the MFC, not the
rather old WinAPI. Then you have to rewrite your engine-code.

No, you don't have to rewrite it. Just write some parts in C and some
in C++. Compile the C parts with a C compiler and the C++ parts with
a C++ compiler. Most C++ compilers can act as C compilers and will
act appropriately based on the file name.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[hlubenow]

>No, you don't have to rewrite it. Just write some parts in C and some

>in C++. Compile the C parts with a C compiler and the C++ parts with
a C++ compiler. Most C++ compilers can act as C compilers and will
act appropriately based on the file name.

That's exactly the kind of information I hoped, I could find here (because
it's not so easy to find that in books). Thank you !

H.

[Flash Gordon]

Richard Tobin wrote, On 30/03/07 14:25:

In article <1s************@athlon.my>, hlubenow <hl*******@gmx.netwrote:

I wrote the paragraph below. hlubenow, please leave in the attibution
lines for material you quoting. Attribution lines are the bits that say
who wrote what.

>>No, DON'T. C++ requires casting the value returned by malloc, which is
bad practice in C, and there are various other gotchas. ALWAYS use a C
compiler for C and a C++ compiler for C++ since the languages are
different.

>Well, ok, but what if you write some kind of engine in C and lateron you
want to write a GUI for it. Most GUI-toolkits like Qt or even C++/Tk

http://cpptk.sourceforge.net/

use C++. On Windows, you or somebody else may want to use the MFC, not the
rather old WinAPI. Then you have to rewrite your engine-code.

No, you don't have to rewrite it. Just write some parts in C and some
in C++. Compile the C parts with a C compiler and the C++ parts with
a C++ compiler. Most C++ compilers can act as C compilers and will
act appropriately based on the file name.

Richard is correct.

<OT>
Note also that the C++ standard even provides mechanisms designed to
allow you to interface between C and C++ code. Such mechanisms are
topical on comp.lang.c++ not here, but they do exist.
</OT>
--
Flash Gordon

[Flash Gordon]

hlubenow wrote, On 30/03/07 19:56:

Please leave in the attribution lines, the bits that say who posted the
material you are quoting.

>No, you don't have to rewrite it. Just write some parts in C and some
in C++. Compile the C parts with a C compiler and the C++ parts with
a C++ compiler. Most C++ compilers can act as C compilers and will
act appropriately based on the file name.

That's exactly the kind of information I hoped, I could find here (because
it's not so easy to find that in books). Thank you !

You probably need better C++ books then. C books often will not cover
interfacing with C++ because the interfacing is defined from the C++
side not the C side. Also read the documentation for your tool chain.
--
Flash Gordon

[Ian Collins]

Flash Gordon wrote:

>
No, DON'T. C++ requires casting the value returned by malloc, which is
bad practice in C, and there are various other gotchas. ALWAYS use a C
compiler for C and a C++ compiler for C++ since the languages are
different.

Always is a bit strong, there can be valid reasons for compiling C code
as C++. So I'd say use a C compiler for C and not a C++ unless you have
a valid valid reason to do otherwise.

--
Ian Collins.

[J. J. Farrell]

On Mar 30, 6:10 am, hlubenow <[e-mail]:

Please write your programs in a way, that this works too.

No, DON'T. C++ requires casting the value returned by malloc, which is
bad practice in C, and there are various other gotchas. ALWAYS use a C
compiler for C and a C++ compiler for C++ since the languages are
different.

Well, ok, but what if you write some kind of engine in C and lateron you
want to write a GUI for it. Most GUI-toolkits like Qt or even C++/Tk

http://cpptk.sourceforge.net/

use C++. On Windows, you or somebody else may want to use the MFC, not the
rather old WinAPI. Then you have to rewrite your engine-code.
So why not write it from the start in a way that C++-compilers can handle it
too.

If you want a C++ compiler to handle it, write it in C++. If you
prefer to write it in C why not just do so - there's no reason why
every part of a program has to be written in the same language.

Casting malloc() is considered bad style,

http://faq.cprogramming.com/cgi-bin/...=1047673478&id...

but it won't hurt either.

It may hurt, or at least it leaves you wide open to hurt. If you omit
the required header for using malloc() then casting the return value
will usually prevent the compiler telling you that you've done so. If
you call malloc() without the required header included, all bets are
off.

Afterall C++ should be compatible to C.

Well it isn't; why do you think it should be?

[Flash Gordon]

Ian Collins wrote, On 30/03/07 21:05:

Flash Gordon wrote:

>No, DON'T. C++ requires casting the value returned by malloc, which is
bad practice in C, and there are various other gotchas. ALWAYS use a C
compiler for C and a C++ compiler for C++ since the languages are
different.

Always is a bit strong, there can be valid reasons for compiling C code
as C++. So I'd say use a C compiler for C and not a C++ unless you have
a valid valid reason to do otherwise.

P.J. Plauger has a valid reason in that some customers want to compile
his libraries with a C++ compiler and some with a C compiler, although I
would say that was more to do with his customers being less than
sensible. It is hard to come up with other reasons where there is not a
better way.
--
Flash Gordon

[Ian Collins]

Flash Gordon wrote:

Ian Collins wrote, On 30/03/07 21:05:

>Flash Gordon wrote:

>>No, DON'T. C++ requires casting the value returned by malloc, which is
bad practice in C, and there are various other gotchas. ALWAYS use a C
compiler for C and a C++ compiler for C++ since the languages are
different.

Always is a bit strong, there can be valid reasons for compiling C code
as C++. So I'd say use a C compiler for C and not a C++ unless you have
a valid valid reason to do otherwise.

P.J. Plauger has a valid reason in that some customers want to compile
his libraries with a C++ compiler and some with a C compiler, although I
would say that was more to do with his customers being less than
sensible. It is hard to come up with other reasons where there is not a
better way.

I've answered this before - using C++ objects to simulate hardware
accessed through structures (the test harness replaces the C struct with
a C++ object that reacts appropriately to members being accessed).

--
Ian Collins.

[Flash Gordon]

Ian Collins wrote, On 30/03/07 23:08:

Flash Gordon wrote:

>Ian Collins wrote, On 30/03/07 21:05:

>>Flash Gordon wrote:

No, DON'T. C++ requires casting the value returned by malloc, which is
bad practice in C, and there are various other gotchas. ALWAYS use a C
compiler for C and a C++ compiler for C++ since the languages are
different.

Always is a bit strong, there can be valid reasons for compiling C code
as C++. So I'd say use a C compiler for C and not a C++ unless you have
a valid valid reason to do otherwise.

P.J. Plauger has a valid reason in that some customers want to compile
his libraries with a C++ compiler and some with a C compiler, although I
would say that was more to do with his customers being less than
sensible. It is hard to come up with other reasons where there is not a
better way.

I've answered this before - using C++ objects to simulate hardware
accessed through structures (the test harness replaces the C struct with
a C++ object that reacts appropriately to members being accessed).

I have used decent emulators and simulators that allowed me to trap on
the accesses. Then you can compile the code with the correct compiler
for the correct target and still do complex things on either read or
write. It even means you can test the actual images that will be loaded
in to the final HW, which has the added benefit of proving that you are
not hitting any bugs in your development tools. I would say therefore
that this is a better way of solving your problem.
--
Flash Gordon

[Ian Collins]

Flash Gordon wrote:

Ian Collins wrote, On 30/03/07 23:08:

>Flash Gordon wrote:

>>Ian Collins wrote, On 30/03/07 21:05:

Flash Gordon wrote:

No, DON'T. C++ requires casting the value returned by malloc, which is
bad practice in C, and there are various other gotchas. ALWAYS use a C
compiler for C and a C++ compiler for C++ since the languages are
different.
>
Always is a bit strong, there can be valid reasons for compiling C code
as C++. So I'd say use a C compiler for C and not a C++ unless you
have
a valid valid reason to do otherwise.

P.J. Plauger has a valid reason in that some customers want to compile
his libraries with a C++ compiler and some with a C compiler, although I
would say that was more to do with his customers being less than
sensible. It is hard to come up with other reasons where there is not a
better way.

I've answered this before - using C++ objects to simulate hardware
accessed through structures (the test harness replaces the C struct with
a C++ object that reacts appropriately to members being accessed).

I have used decent emulators and simulators that allowed me to trap on
the accesses. Then you can compile the code with the correct compiler
for the correct target and still do complex things on either read or
write. It even means you can test the actual images that will be loaded
in to the final HW, which has the added benefit of proving that you are
not hitting any bugs in your development tools. I would say therefore
that this is a better way of solving your problem.

Not realy, using a pure hosted simulation gives you control of how the
"hardware" responds and is way quicker for running test suites,
especially when the target is a small 8 or 16 embedded device
controlling hardware with a dramatic capacity for exploding!

This is not intended as a replacement for final on-target acceptance
testing, merely an aid for development.

--
Ian Collins.

[CBFalconer]

Flash Gordon wrote:

Ian Collins wrote, On 30/03/07 21:05:

.... snip ...

>

>Always is a bit strong, there can be valid reasons for compiling
C code as C++. So I'd say use a C compiler for C and not a C++
unless you have a valid valid reason to do otherwise.

P.J. Plauger has a valid reason in that some customers want to
compile his libraries with a C++ compiler and some with a C
compiler, although I would say that was more to do with his
customers being less than sensible. It is hard to come up with
other reasons where there is not a better way.

It's not for his customers, it's for himself. He doesn't want
clueless customers calling him up to complain, or badmouthing his
software. So he restricts his source to the (somewhat lame)
intersection of C and C++.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Flash Gordon]

CBFalconer wrote, On 31/03/07 03:44:

Flash Gordon wrote:

>Ian Collins wrote, On 30/03/07 21:05:

... snip ...

>>Always is a bit strong, there can be valid reasons for compiling
C code as C++. So I'd say use a C compiler for C and not a C++
unless you have a valid valid reason to do otherwise.

P.J. Plauger has a valid reason in that some customers want to
compile his libraries with a C++ compiler and some with a C
compiler, although I would say that was more to do with his
customers being less than sensible. It is hard to come up with
other reasons where there is not a better way.

It's not for his customers, it's for himself. He doesn't want
clueless customers calling him up to complain, or badmouthing his

^^^^^^^^^^^^^^^^^^

software.

If his customers did not do it he would have no requirement to do it.

So he restricts his source to the (somewhat lame)
intersection of C and C++.

Indeed.
--
Flash Gordon

[Flash Gordon]

Ian Collins wrote, On 31/03/07 01:34:

Flash Gordon wrote:

>Ian Collins wrote, On 30/03/07 23:08:

>>Flash Gordon wrote:

Ian Collins wrote, On 30/03/07 21:05:

Flash Gordon wrote:
>
>No, DON'T. C++ requires casting the value returned by malloc, which is
>bad practice in C, and there are various other gotchas. ALWAYS use a C
>compiler for C and a C++ compiler for C++ since the languages are
>different.
>>
Always is a bit strong, there can be valid reasons for compiling C code
as C++. So I'd say use a C compiler for C and not a C++ unless you
have
a valid valid reason to do otherwise.
P.J. Plauger has a valid reason in that some customers want to compile
his libraries with a C++ compiler and some with a C compiler, although I
would say that was more to do with his customers being less than
sensible. It is hard to come up with other reasons where there is not a
better way.

I've answered this before - using C++ objects to simulate hardware
accessed through structures (the test harness replaces the C struct with
a C++ object that reacts appropriately to members being accessed).

I have used decent emulators and simulators that allowed me to trap on
the accesses. Then you can compile the code with the correct compiler
for the correct target and still do complex things on either read or
write. It even means you can test the actual images that will be loaded
in to the final HW, which has the added benefit of proving that you are
not hitting any bugs in your development tools. I would say therefore
that this is a better way of solving your problem.

Not realy, using a pure hosted simulation gives you control of how the
"hardware" responds

So does using the simulators and emulators I have used.

and is way quicker for running test suites,
especially when the target is a small 8 or 16 embedded device

Well, back in the 80s a pure software simulator of a Z80 could run
through the tests faster than I could review the results.

controlling hardware with a dramatic capacity for exploding!

What capacity for exploding in a SW simulation? Do you think the
simulator will simulate and explosion and wreck some bits on you HD? The
better hardware emulators can also be run without the target HW and give
you no chance of exploding.

This is not intended as a replacement for final on-target acceptance
testing, merely an aid for development.

What I suggested can cover both and has none of the problems you just
suggested it had. At least, between some time in the late 80s and some
time in the late 90s it didn't, I doubt it has got any worse since I was
working on embedded systems.
--
Flash Gordon

[Ian Collins]

Flash Gordon wrote:

Ian Collins wrote, On 31/03/07 01:34:

>Flash Gordon wrote:

>>Ian Collins wrote, On 30/03/07 23:08:

I've answered this before - using C++ objects to simulate hardware
accessed through structures (the test harness replaces the C struct
with
a C++ object that reacts appropriately to members being accessed).

I have used decent emulators and simulators that allowed me to trap on
the accesses. Then you can compile the code with the correct compiler
for the correct target and still do complex things on either read or
write. It even means you can test the actual images that will be loaded
in to the final HW, which has the added benefit of proving that you are
not hitting any bugs in your development tools. I would say therefore
that this is a better way of solving your problem.

Not realy, using a pure hosted simulation gives you control of how the
"hardware" responds

So does using the simulators and emulators I have used.

So they simulated all the hardware components in the system?

>and is way quicker for running test suites,
especially when the target is a small 8 or 16 embedded device

Well, back in the 80s a pure software simulator of a Z80 could run
through the tests faster than I could review the results.

Part of the problem is embedded tool chains tend to have either archaic
build systems or restrictive licenses that preclude distributed or even
parallel building. So for complex embedded applications, building for
the target can be slow. When we are running tests frequently, this is a
real impediment to progress.

I like to simulate the entire system, not just the processor.

>controlling hardware with a dramatic capacity for exploding!

What capacity for exploding in a SW simulation? Do you think the
simulator will simulate and explosion and wreck some bits on you HD? The
better hardware emulators can also be run without the target HW and give
you no chance of exploding.

Yes but they can't interact with a simulation of the target hardware.
Every member of the team gets a simulation environment for free, whereas
hardware emulators don't come cheap.

>This is not intended as a replacement for final on-target acceptance
testing, merely an aid for development.

What I suggested can cover both and has none of the problems you just
suggested it had.

Not with the flexibility of a system simulation, at least not without
spending some very serious money.

--
Ian Collins.

[Flash Gordon]

Ian Collins wrote, On 31/03/07 11:30:

Flash Gordon wrote:

>Ian Collins wrote, On 31/03/07 01:34:

>>Flash Gordon wrote:

Ian Collins wrote, On 30/03/07 23:08:
I've answered this before - using C++ objects to simulate hardware
accessed through structures (the test harness replaces the C struct
with
a C++ object that reacts appropriately to members being accessed).
I have used decent emulators and simulators that allowed me to trap on
the accesses. Then you can compile the code with the correct compiler
for the correct target and still do complex things on either read or
write. It even means you can test the actual images that will be loaded
in to the final HW, which has the added benefit of proving that you are
not hitting any bugs in your development tools. I would say therefore
that this is a better way of solving your problem.
Not realy, using a pure hosted simulation gives you control of how the
"hardware" responds

So does using the simulators and emulators I have used.

So they simulated all the hardware components in the system?

>>and is way quicker for running test suites,
especially when the target is a small 8 or 16 embedded device

Well, back in the 80s a pure software simulator of a Z80 could run
through the tests faster than I could review the results.

Part of the problem is embedded tool chains tend to have either archaic
build systems or restrictive licenses that preclude distributed or even
parallel building. So for complex embedded applications, building for
the target can be slow. When we are running tests frequently, this is a
real impediment to progress.

I like to simulate the entire system, not just the processor.

You simulate the rest with hooks on the relevant accesses.

>>controlling hardware with a dramatic capacity for exploding!

What capacity for exploding in a SW simulation? Do you think the
simulator will simulate and explosion and wreck some bits on you HD? The
better hardware emulators can also be run without the target HW and give
you no chance of exploding.

Yes but they can't interact with a simulation of the target hardware.

Some of them allow hooks to things outside the emulator/simulator so
that you can. I never needed to use them, but I came across mention of
hooks in the documentation.

Every member of the team gets a simulation environment for free, whereas
hardware emulators don't come cheap.

Well, cost is another matter.

>>This is not intended as a replacement for final on-target acceptance
testing, merely an aid for development.

What I suggested can cover both and has none of the problems you just
suggested it had.

Not with the flexibility of a system simulation, at least not without
spending some very serious money.

Money is another matter.

Where I used to work you had to do all testing (not just customer
acceptance testing, which was a small fraction of testing) on code built
with the correct compiler using the same compilation options.

Anyway, this would still only make a count of two (and in your case only
a small fraction of the code if HW access is nicely abstracted), so
still a very long way from the norm and nothing that someone new to C is
likely to be coming across any time soon.
--
Flash Gordon

[Ian Collins]

Flash Gordon wrote:

>
Where I used to work you had to do all testing (not just customer
acceptance testing, which was a small fraction of testing) on code built
with the correct compiler using the same compilation options.

That must have slowed you down significantly. I assume you weren't
developing test first!

--
Ian Collins.

[Flash Gordon]

Ian Collins wrote, On 31/03/07 21:35:

Flash Gordon wrote:

>Where I used to work you had to do all testing (not just customer
acceptance testing, which was a small fraction of testing) on code built
with the correct compiler using the same compilation options.

That must have slowed you down significantly.

No, not at all. Even in the late 80s we had simulators fast enough that
they did not slow us down. It also meant that when there were compiler
bugs we found them during our initial testing, and yes we did find a
number of bugs in different compilers and even bugs in assemblers.

I assume you weren't
developing test first!

No, but test requirements were developed during the requirements phase,
designed during the design phase, and implemented during the coding
phase. Oh, and everything was reviewed, and when I say reviewed I mean
by technical people looking for technical faults, not simply looking for
spelling errors or the wrong formatting.

On some of the projects the teams doing the testing where not the same
people as were doing the design/code.

Test first is not the only valid development method and it is not
perfect. No method developed so far is perfect.
--
Flash Gordon

[Ian Collins]

Flash Gordon wrote:

Ian Collins wrote, On 31/03/07 21:35:

>Flash Gordon wrote:

>>Where I used to work you had to do all testing (not just customer
acceptance testing, which was a small fraction of testing) on code built
with the correct compiler using the same compilation options.

That must have slowed you down significantly.

No, not at all. Even in the late 80s we had simulators fast enough that
they did not slow us down.

I was thinking of build times, one of the biggest problems I have is
embedded tool chains not supporting parallel or distributed building,
which can be a real pain for big projects. I like to keep build times
down to a minute or maybe two for a full build.

--
Ian Collins.