[sdiy] how to learn C?

[Paul Burns]

Give me Fortran or give me death :)

That was 30 years ago ...about the time I played keys for Rick Wakeman..
Gawd ...

Luckily then music changed with the advent of digital synthesis... thank God
for that , with the advent of the Synclavier and Fairlight...   a breath of
fresh air ... no more prog rock ...or Vangelis / Jean Michelle Jarre ..or
one worse Mike Oldfield with his awful soundtrack to The Killing Fields ..
how not to give someone a shed load of tech and expect ...

He he he ...

Paul Burns
 


-----Original Message-----
From: synth-diy-bounces at dropmix.xs4all.nl
[mailto:synth-diy-bounces at dropmix.xs4all.nl] On Behalf Of David
Sent: 08 January 2011 17:19
To: 'Tom Wiltshire'; 'Andre Majorel'
Cc: synth-diy at dropmix.xs4all.nl
Subject: Re: [sdiy] how to learn C?

Give me Fortran or give me death :)

David

-- -----Original Message-----
-- From: synth-diy-bounces at dropmix.xs4all.nl [mailto:synth-diy-
-- bounces at dropmix.xs4all.nl] On Behalf Of Tom Wiltshire
-- Sent: Saturday, January 08, 2011 6:47 AM
-- To: Andre Majorel
-- Cc: synth-diy at dropmix.xs4all.nl
-- Subject: Re: [sdiy] how to learn C?
-- 
-- 
-- On 8 Jan 2011, at 12:48, Andre Majorel wrote:
-- 
-- > This is probably an unfashionable opinion but I think that the
-- > first thing you should learn is how the hardware works. Bits,
-- > bytes, memory addresses. How text, positive integers and
-- > positive integers larger than 255 are encoded. The basic
-- > operation of a microprocessor (program counter, jumps and
-- > branches, stack, subroutine calls, loads and stores).
-- >
-- > Once you have a clear picture of that in your head, much of C is
-- > obvious. You will be able to write fast and compact software.
-- > And you will have the satisfaction of knowing what you are doing
-- > instead of throwing code at the compiler and hoping it works.
-- 
-- In general, I agree with Andre, but I have to say that "much of C is
obvious" is not entirely
-- true - or perhaps I'm dealing with the bits that aren't (Probably - trust
my luck!). I've been
-- doing lots of assembler, so I've got the underlying understanding.
-- 
-- I'm finding the syntax of some parts of C is awkward, bordering
irritating. For example,
-- you could do the following in C:
-- 
-- a = b;
-- 
-- Bet you didn't realise that 'a' is a pointer, and 'b' is an array in that
snippet, and that I want
-- the pointer to be the address of the array, did you?! Oh, wait! Actually
'a' is a variable
-- equal to 5, and I want 'b' to be 5 too! No? Talk about ambiguous.
-- 
-- 
-- I could have made it slightly clearer, but you mostly don't see it done
this way:
-- 
-- a =&b;
-- 
--  A lot of the time, readability in C seems to come down to consistent
variable naming
-- conventions by the programmer, rather than being enforced by the
language.  Things get
-- even worse when you start using "typedef"s and function pointers (be sure
to follow the
-- convention of using "_t" at the end of "typedef" defined types or you'll
never know what
-- you're looking at. The syntax looks like it was dreamed up for the simple
cases and then
-- dragged kicking and screaming into a situation where you could use more
sophisticated
-- stuff. The syntax for defining function pointers looks like the
meaningless bracket monster
-- vomited on your code, and you *will* throw code at the compiler several
times before you
-- get it right. I guess I'd like to be programming in "D" or "E" instead of
"C".
-- 
-- Still, it's the tools we've got, so here I am, learning it.
-- 
-- T.
-- 
-- _______________________________________________
-- Synth-diy mailing list
-- Synth-diy at dropmix.xs4all.nl
-- http://dropmix.xs4all.nl/mailman/listinfo/synth-diy

_______________________________________________
Synth-diy mailing list
Synth-diy at dropmix.xs4all.nl
http://dropmix.xs4all.nl/mailman/listinfo/synth-diy