I know nothing of programming, but I would love to learn.
Here is what my naive approach would be, which I assume would take about 6-7 months of study.
I would first learn the fundamentals on a bare-bones *nix system like Debian or possibly FreeBSD, using an editor like Vim, and the GCC.
[Fundamentals]
Basic C programming
Basic C data structures
Advanced Unix Programming
Assembly
Computer Architecture and Design
DNS & BIND
TCP & IP
Unix Network Programming
HTML/XML
Apache
MySQL
1 scripting language: PHP, Perl, Ruby, Python, Lua, etc...
Visual Studio (C++)
ASP.net
Ajax
Along the way I would learn about GNU make, CVS, Digital Logic, the Windows Registry, and fully understand a text on Discrete Mathematics.
Some projects along the way might include:
an imageboard
an instant messenger / irc client
a game
a device driver
Professional programmers please feel free to laugh, yet modify and correct.
When i was younger i could not understand why people recommended python/etc instead of C to a newbie.
Being an uber guru that started with C, knowing C and many assemblers i believed that everyone should start with C.
Now, after so many years i finally understand.
And when you understand you'll shit bricks.
>>13
Yeah and tell a newbie that char buffer[] is not the same with char *buffer and then explain to him pointer arithmetic and the use of void pointers, typecasting, expressions and the tern. operator, about addressof/sizeof and structs being arrays in memory
Then tell him that the standard datatypes char,int,float,double can have any value and size depending from millions of things, explain him about c89 c99 POSIX preprocessor libraries stack heap dynamic memory allocation buffer overflows floating point high/low bit order signedness bitwise operators etc etc
Then explain him how to use gcc optimization warnings standards architecture cross compilation -O3 considered harmful blablabla
A newbie just by reading my post would get a headache; imagine actually learning it.
>>15
Say wut?
char buffer[60] behaves very much like char *buffer, except in the latter case no storage is allocated and the pointer goes nowhere until assigned. The finer distinctions can be ignored until the second course on C programming; just like you and I did way back when.
Pointer arithmetic is perhaps worth 30 minutes of explaining and a few slides. Void pointers are a simple enough topic, to be explained once malloc() and free() have been. Typecasting, expressions and the ternary operator are things that any Java course has to deal with, and it apparently isn't giving them any insurmountable problems. The in-memory format of structs is again something for the advanced half of a two- or three-course whole.
The sizes of standard datatypes can be explained as they are in the Typical Modern Implementation on a Typical Modern ABI. Students who're particularly interested can go crawl through the standard, which is pointed to in a footnote of the lecture material.
The preprocessor can be explained by the course book; there's nothing particularly advanced or hairy there. POSIX is out of scope for a set of courses on C. Libraries are a particular case of modular programming. Memory allocation is not especially difficult. Buffer overflows etc. can be explained in terms of undefined behaviour, i.e. nasal demons; their prevention is better explained in the context of a course on security-conscious programming (the principles of which apply just the same to Java as they do to C).
Numeric programming is a broad enough topic to be in a course of its own, and typically is. Signedness of numbers is CS 101, as are bitwise operations. Use of the compiler can be explained with a 5-page appendix of the lecture material, with a link to the manual pages and a hearty note of "you don't really need more than the first page until we get to modular programming".
Don't underestimate newbies. You were one, once, and look at yourself now.
> char buffer[60] behaves very much like char *buffer
here are some examples
1:
int f(char **p) { ...
int main() {
char *p;
char buffer[10];
f(&p); /* correct */
f(&buffer); /* compiler complains, why? newbie is confused */2:
char buffer[] = "BBC";
buffer[0] -= 1; /* "ABC" */
char *p = "BBC";
*p -= 1; /* segfault. newbie is confused */*note: sure, you can fix this with this c99 feat
char *p = (char[]){ 'B', 'B', 'C', 0}The newbie will be nonetheless confused
3:
char *p = "something";
/* ... */
p[-1] = 0; /* allowed */char buffer[] = "something";
/* ... */
buffer[-1] /* undefined behavior */Anyway, you make things sound easy, but you are correct, i do underestimate newbies.
That's what experience taught me... people don't want to learn, they want quick solutions.
>>17
1: Ah yes. It obeys much the same syntax as a pointer, yet isn't one. The wonders of modern C, but hardly worse than the old standby, *(p + i), for pointer subscripts. Still, it's easy enough to look at the variable's declaration and proceed from there. A pointer-to-pointer sort of implies that it is a pointer to a pointer variable or equivalent anyway. Most people, I'd think, would rather live with a a rarely hit special rather than the classic pointer subscript syntax (which I personally find rather nigh to obfuscation).
2: My personal pet peeve with C, that string literals are not "const char *" by default. To think that this was for historical reasons that would've been overcome had the change been made in C89... Still, hands off string literals seems like a simple enough policy to follow. Initialization of an array from a literal shouldn't give even newbies pause after the first time.
3: I don't think your case of accessing a string literal before its first byte is permitted, though not having read the standard recently I could just as well be wrong. It'd seem that the minus first would go into some ill-defined place in the process' text section, which far as I'm concerned pretty darn well counts as undefined behaviour especially when that position is being modified. Unless the standard specifies that doing that must crash the program, which I rather doubt.
I may be in optimism mode today, however, my experience is that things are easier when one stops making them hard. (Your example with the integral types' ill-specifiedness in the standard for instance.) Like in any line of creative or semi-creative work, the artist is his own worst enemy. Yet any journey can be split up into kilometers, then meters, steps and so forth.
I do wish people wised the fuck up with regard to the quick fix thing. Oh well, experience beats any lecturer in the field of teaching... sadly some people only learn to bang their head on the wall harder. It would certainly be nice if the school system(s) made these lessons available to students as early as possible instead of shielding them from well-deserved disappointment.
>>18
I think i was not very clear with the 3rd example
It is illegal to access the -1th element of an array, however it is not illegal to substract 1 from a pointer and dereference it.
> I may be in optimism mode today, however, my experience is that things are easier when one stops making them hard. (Your example with the integral types' ill-specifiedness in the standard for instance.) Like in any line of creative or semi-creative work, the artist is his own worst enemy. Yet any journey can be split up into kilometers, then meters, steps and so forth.
I agree.
> 2: My personal pet peeve with C, that string literals are not "const char *" by default.
IIRC, this is the case with GCC.
>>20
They are const in the sense that there'll be segfaults if one tries to write to them. But their type is not "const char *", judging from GCC not screaming if you do
char *str = "literal string";like it would if you did
const char *lit = "literal string";
char *str = lit;1dSyuY9L here
The standard(s) state very clear that it is UB if you try to write to a string literal.
However some extensions allow it.
It's not the 'case' with GCC; it's the 'case' with every compiler that allows it.