Learning C as an existing programmer

[Rui Maciel]

Over at comp.lang.c++ they say it's C++.

I'm also over at comp.lang.c++, and I've also spent a bit of time developing
number-crunching applications with C++. If this discussion was hosted in
that newsgroup I would still underline the merits of Fortran, C and
Matlab/Octave.


Rui Maciel

 

[Ben Bacarisse]

Really? Only if they're (i) of bounded size or (ii) of trivially small
size. Otherwise you're just asking for horrible, undetectable stack
overflow bugs, because VLAs have no failure mechanism.

Yes, really, but there are several of parts to the answer.

First, I accept that there are systems where you can't rely on them, but
I'd expect more from a modern system. I can set a stack size if the
default is too small (I can even set it to "unlimited") and I get a
run-time error if my arrays are too large.

Secondly, your characterisation of the size is, err... provocative. All
arrays (malloced or otherwise) are of bounded size so (i) is a red
herring. To say that they can only be what you consider trivially small
does not matter if trivially small is big enough. The phrase you use,
however, is clearly designed to suggest that they are pointless but
that's not been my (limited) experience.

Thirdly, C99's variably modified arrays are useful even if you don't
give all (or some) of your arrays automatic storage. The ability they
offer to specify the size of dimensions other than the "last" can be
very helpful.

 

[Rui Maciel]

So that's a "yes" in answer to my first question?

No, the rest, as I've said, is just noise. Fanboyism only leads people to
look at every problem as being a nail to try to justify using their
particular brand of hammer.


Rui Maciel

 

[Rui Maciel]

So that's a "yes" in answer to my first question?

No, the rest, as I've said, is just noise. Fanboyism only leads people to
look at every problem as being a nail to try to justify using their
particular brand of hammer.


Rui Maciel

 

[Nachy]

"The C Programming Language".  C is sufficiently different to justify
reading through the whole book.

I actually took a similar path myself - well, not quite: QBasic ->
8086 Assembly -> C (-> C++) -> Java (the latter is job-related; the
others were hobbies...).

I found that the best book for C is still "The C Programming Language"
- despite its age - as has been pointed out. As for moving between
BASIC and C - I don't know what book will be best, and any that I've
seen are more than 20 years old. However, I thought of a few pointers
to help cover the major differences:

1) C code is not line oriented.
- Multiple statements may be on the same line
- A statement can be broken into several lines
- Statements are ended with a semicolon (';') instead of a line break
- Blocks are delimited by braces ('{' and '}'), instead of END at the
bottom

2) case matters.
- "if" is not the same as "If" or "IF"
- Nearly everything in C is lowercase - keywords and the standard
library.
_Exit() is the only exception I can think of.
- Constants are UPPERCASE (as in many languages, including BASIC)
- Identifiers with several words use under_scores, not CamelCase

3) Strings are not first-class types.
- String literals are given some special treatment by the compiler,
but ...
- Strings break down into NUL terminated arrays of char

- String concatenation is not automatic

3) Many tasks are accomplished by library functions instead of being
statements built in to the language.
- This includes basic input, output, file operations, and mathematical
functions
- Use puts() instead of PRINT, printf() instead of PRINT USING,
scanf() instead of INPUT
- Any user-friendly GUI is non-standard (as far as C is concerned).
There are libraries other than the C standard library available for
various platforms, each of which has its own standards.

4) You have to put a lot more effort into memory management.
- malloc() instead of DIM (whatever that stands for)
- Pointers are used much more heavily than in BASIC (which has some
pointer ability)

That's all that I can think of offhand, but I think that's plenty.

Happy programming!

-- Nachy

 

[Edward Rutherford]

To understand C well... you have to understand the way C uses pointers.
Pointers are very basically machine memory addresses, and C uses them in
special ways. IMHO.

Any Basic programmer understands pointers! A pointer is basically the
same thing as a ByRef function argument.

The only exception is strings, which are a special type in C. For
technical reasons they are officially pointers (char *) but in fact this
is really just the string type, so char ** is a ByRef string.

 

[Stefan Ram]

- Statements are ended with a semicolon (';') instead of a line break

»{}« is a statement that does not end with a semicolon.
(Use »expression statement« above.)

- Constants are UPPERCASE (as in many languages, including BASIC)

Uppercase is used for most preprocessor macros,
which might sometimes expand to literals.

- String concatenation is not automatic

Well, »"abc" "def"« gives »abcdef«.

 

[James Kuyper]

On 06/25/2012 04:37 PM, Edward Rutherford wrote:
....

Any Basic programmer understands pointers! A pointer is basically the
same thing as a ByRef function argument.

The only exception is strings, which are a special type in C. For
technical reasons they are officially pointers (char *) but in fact this
is really just the string type, so char ** is a ByRef string.

It's been more than three decade since I used Basic, and I'm pretty sure
that the Basic I used didn't have ByRef, so I can't comment on that
aspect of your message.

However, in C, strings are a data storage format, not a data type.
Saying otherwise can cause more confusion than is justified by the
simplification it allows. Thinking otherwise has been the cause of a lot
of erroneous code.

 

[James Kuyper]

On 06/25/2012 04:26 PM, Nachy wrote:
....

- despite its age - as has been pointed out. As for moving between
BASIC and C - I don't know what book will be best, and any that I've
seen are more than 20 years old. However, I thought of a few pointers
to help cover the major differences: ....
- Nearly everything in C is lowercase - keywords and the standard
library.
_Exit() is the only exception I can think of.

There are few more exceptions that than. If most of these seem
unfamiliar, that's probably because they were all introduced in either
C99 or C2011:

keywords:
_Alignas, _Alignof, _Atomic, _Bool, _Complex, _Generic, _Imaginary,
_Noreturn, _Static_assert, _Thread_local

Standard Pragmas:
STDC FENV_ACCESS
STDC FP_CONTRACT
STDC CX_LIMITED_RANGE

Function-like macros:
CMPLX, CMPLXF, CMPLXL
ATOMIC_VAR_INIT
INT[N|MAX]_C

 

[Keith Thompson]

Any Basic programmer understands pointers! A pointer is basically the
same thing as a ByRef function argument.

The only exception is strings, which are a special type in C. For
technical reasons they are officially pointers (char *) but in fact this
is really just the string type, so char ** is a ByRef string.

No, strings are not pointers.

A string is, by definition, "a contiguous sequence of characters
terminated by and including the first null character".

A char* value that points to the first character of a string is referred
to as a "pointer to a string".

We commonly (actually, almost universally) use pointers of type char* to
manipulate strings, but the pointer itself is not the string.

 

[Tim Rentsch]

Really? Only if they're (i) of bounded size or (ii) of trivially small
size. Otherwise you're just asking for horrible, undetectable stack
overflow bugs, because VLAs have no failure mechanism.

What you mean is that VLAs have no portably guaranteed failure
mechanism. On a particular implementation they may very well
have a well-defined, implementation-supplied, such mechanism.

 

[Nachy]

Nachy <[email protected]> writes:

This was to be a _quick_ list of the glaring differences between BASIC
and C for the purpose of helping the OP migrate from one the former to
the latter (or at least pointing him in the right direction). As
such, I was trying not to get too technical, and so may have
sacrificed strict accuracy for brevity and clarity. I don't think you
can argue with my basic statements, though you may disagree with some
minor point.

»{}« is a statement that does not end with a semicolon.
(Use »expression statement« above.)

I stand by my original comment. "Expression statement" would exclude
jump statements ("continue", "break", "return") which are not
(necessarily) followed by an expression, and the expression in a do
loop must be in parenthesis - the semicolon following the expression
is part of the do loop, not an expression statement.

  Uppercase is used for most preprocessor macros,
  which might sometimes expand to literals.

Good point.
s/Constants/Constants and macros/

  Well, »"abc" "def"« gives »abcdef«.

Specifically for string literals, which is (1) the preprocessor, and
(2) a less beginner corollary of "String literals are given some
special treatment by the compiler"

There are few more exceptions that than. If most of these seem
unfamiliar, that's probably because they were all introduced in either
C99 or C2011:

keywords:
_Alignas, _Alignof, _Atomic, _Bool, _Complex, _Generic, _Imaginary,
_Noreturn, _Static_assert, _Thread_local

Standard Pragmas:
STDC FENV_ACCESS
STDC FP_CONTRACT
STDC CX_LIMITED_RANGE

Function-like macros:
CMPLX, CMPLXF, CMPLXL
ATOMIC_VAR_INIT
INT[N|MAX]_C

Indeed. And none of these are to be found in "The C Programming
Language", which was the text originally suggested.

In fact, most (all?) of the all-uppercase James mentions are
preprocessor macros.

You missed the one exception to the macro/constant rule: FILE (which
is a type, not a macro, unless by the as-if rule).

-- Nachy

 

[James Kuyper]

There are few more exceptions that than. If most of these seem
unfamiliar, that's probably because they were all introduced in either
C99 or C2011:

keywords:
_Alignas, _Alignof, _Atomic, _Bool, _Complex, _Generic, _Imaginary,
_Noreturn, _Static_assert, _Thread_local

Standard Pragmas:
STDC FENV_ACCESS
STDC FP_CONTRACT
STDC CX_LIMITED_RANGE

Function-like macros:
CMPLX, CMPLXF, CMPLXL
ATOMIC_VAR_INIT
INT[N|MAX]_C

Indeed. And none of these are to be found in "The C Programming
Language", which was the text originally suggested.

In fact, most (all?) of the all-uppercase James mentions are
preprocessor macros.[/QUOTE]

No, the standard pragmas take effect during pre-processing, just like
macros, but they aren't macros.

You missed the one exception to the macro/constant rule: FILE (which
is a type, not a macro, unless by the as-if rule).

I'm not surprised - I was keeping an eye out for _Exit(), since you'd
already mentioned it, and I still missed it, so I wouldn't be surprised
if I missed a few others, too. The keywords and Pragmas are all listed
together, which made them a lot easier to find.

 

[Les Cargill]

Any Basic programmer understands pointers! A pointer is basically the
same thing as a ByRef function argument.

The only exception is strings, which are a special type in C. For
technical reasons they are officially pointers (char *) but in fact this
is really just the string type, so char ** is a ByRef string.

Dunno from ByRef semantics, but no - char * is sufficient to have
a by-reference declaration of a string. It is not enough to instantiate
one ( initialize the pointer itself ).

char ** (outside of an initialization)
is usually a sign you've done something horribly wrong

 

[Les Cargill]

No, strings are not pointers.

A string is, by definition, "a contiguous sequence of characters
terminated by and including the first null character".

A char* value that points to the first character of a string is referred
to as a "pointer to a string".

We commonly (actually, almost universally) use pointers of type char* to
manipulate strings, but the pointer itself is not the string.

Hence the cliche of "Ceci n'est pas une pipe" in programmer lore...

 

[88888 Dihedral]

David Brownæ–¼ 2012å¹´6月25日星期一UTC+8下åˆ3時19分38秒寫é“：

Do you have to use C? There are other languages that might be a better
choice - Python with SciPy / NumPy comes to mind - then you can
concentrate more on the numerical analysis, and less on the details of
programming.

Well, the list, the dictionary, and the long integer types
and related operations are all built in basic types in Python.

Python is a higher level language.

 

[J. J. Farrell]

Good point.
s/Constants/Constants and macros/

It's still nonsense though.

 

[Guest]

On 06/25/12 09:52 AM, rammy wrote:
I need to learn C for numerical analysis as part of my Masters
research.

I already have quite a lot of experience with BASIC [...]

To understand C well... you have to understand the way C uses pointers.
Pointers are very basically machine memory addresses, and C uses them in
special ways. IMHO.

Any Basic programmer understands pointers! A pointer is basically the
same thing as a ByRef function argument.

I don't recall Dartmouth BASIC having "ByRef" pointers. (the point being, "Basic" is a rather ill-defined term).

The only exception is strings, which are a special type in C.

no they aren't. There is no "string type" in C.

For
technical reasons they are officially pointers (char *) but in fact this
is really just the string type, so char ** is a ByRef string.

nonsense

 

[Guest]

On Monday, June 25, 2012 9:26:29 PM UTC+1, Nachy wrote:

I found that the best book for C is still "The C Programming Language"
- despite its age - as has been pointed out. As for moving between
BASIC and C - I don't know what book will be best, and any that I've
seen are more than 20 years old. However, I thought of a few pointers
to help cover the major differences:

2) case matters.
- "if" is not the same as "If" or "IF"
- Nearly everything in C is lowercase - keywords and the standard
library.
_Exit() is the only exception I can think of.

I don't think _Exit() is standard (unless it's in a newer standard
than I'm familiar with)

- Constants are UPPERCASE (as in many languages, including BASIC)

*macros* are conventionally in upper case

- Identifiers with several words use under_scores, not CamelCase

this isn't a universal convention- though it's a common one

4) You have to put a lot more effort into memory management.
- malloc() instead of DIM (whatever that stands for)

DIMENSION

you can declare arrays in C- which look pretty similar to Basic's
DIM to me

- Pointers are used much more heavily than in BASIC (which has some
pointer ability)

again, you make the error of assuming "Basic" descibes a single well-defined language. "Basic" does not necessarily have any "pointer ability"

<snip>

 

[Malcolm McLean]

בת×ריך ×™×•× ×©× ×™,25 ביוני 2012 22:27:02 UTC+1, מ×ת Tim Rentsch:

What you mean is that VLAs have no portably guaranteed failure
mechanism. On a particular implementation they may very well
have a well-defined, implementation-supplied, such mechanism.

And these days if you're writing C you're probably more likely to be writing components rather than complete programs. A component does know what to do on out of memory -sometimes relying on the OS to kill the process is the best you can do, sometimes its completely unacceptable.