In which order should one learn those languages? C goes first, or C++?
Any essential advise you could give me? Books, docs, good source code?

Thanks and best regards

C++ is pretty much C with more. Just learn C++, skip C.

C++ is pretty much C with a lot of dumb crap. Just learn C, don't bother with C++.

>>1

Hey OP. You will surely get a lot of responses or different opinions on this,

and perhaps that will get you confused. >>2 concludes that you should skip C and
learn C++, based on that C is a subset of C++. However, that is not correct. C
has a lot of differences with C++, which are sometimes quite subtle. You will
find a wonderful page that explains all this here:
<a href="http://david.tribble.com/text/cdiffs.htm">Incompabilities between ISO C and ISO C++</a>
All these are too advanced for you, but just looking at the size of that page,
you can be sure that >>2 is wrong. That, however, does not mean that learning
C++ before C is wrong.

My suggestion is that you go with C first. C is a lot smaller than C++, so

you'll get to completely understand what happends in a C program a lot faster. C
is also more "stable". There's a new C++ standard coming out around 2009. If you
don't know what a standard is, it's okay. Just understand that what you might
learn now about C++ you might have to re-learn in 2009. By 2009, if you take the
C path, you should be a good C programmer, <i>if</i> you follow my advice on
what books to pick and read. Generally, learning either language is no easy
task. Learning a language doesn't mean to be able to write 10 or 20 lines of
code in it. It means to be able to read any code and being able to tell what
happends in every line. Not what the programmer intented to do, but what the
compiler will understand. There's <i>too</i> many C programmers out there that
don't really know C. At all. Which is sad, do not end up like them. Every time
you wonder whether you at last know C or not, ask yourself this:
<i>Do I know most of what's written in ISO 9899:1999?</i>
If you can, then you do. When that time comes, it's up to you to learn C++.

As for the advice, here's my advice:

Obviously go with C. Get books such as K&R - The C programming language, or H&S
C: a reference manual 5th edition. Read them, do the exercises, be patient. It
should take at least 6 months to learn C. When and if you feel like completely
mastering the language, click the third link, and get the C99 standard,
available for free in pdf form (should be called WG14 N1124).

<a href="http://cm.bell-labs.com/cm/cs/cbook/">The C programming language</a>
<a href="http://careferencemanual.com/">C: A reference manual</a>
<a href="http://www.open-std.org/jtc1/sc22/wg14/">ISO/IEC JTC1/SC22/WG14</a>

P.S. Don't give up. When this journey comes to its end a lot of doors will

open, you'll be able to read about most concepts around computers.

go with c. c++ was built for large-scale heavy duty apps involving many programmers. everything thats in c++ not in c serves that purpose.
programming in c by kochan is a great book.

Just how the hell can I compile scheme or common lisp to actual executables?

>>7 Depends on the compiler, becuase that particular feature isn't standardized.

In SBCL you use:

(sb-ext:save-lisp-and-die "filename" :executable t)

In ECL you use:

(c::build-program "filename"
  :lisp-files (list (compile-file-pathname "file.lisp" :type :object)))

In MZScheme you can use "mzc" to compile:

mzc --prim --exe src.ss

Lispworks has a special "application builder" which not only compiles but prepares the application for distribution by removing definitions that aren't used. I think ACL has something similar.

The reason this "feature" isn't easy to figure out is because it isn't a normal part of Lisp application development. The fact that you're trying to figure this out first lends itself to the idea you're trying to figure out how to Lisp using your C/C++ knowledge. You probably want a build procedure kindof like C/C++ where you "build" your application as a separate state from developing it.

Don't do that. By the time you have an application you want to deliver in exe-form to other people, it'll be a lot easier to explain. Waste your time trying to figure this out now and you're just going to frustrate yourself needlessly, and you're going to avoid "getting" some of the most useful aspects of Lisp programming.

>>8,9
That post >>7 was for http://4-ch.net/code/kareha.pl/1209513777 this thread. Sorry

>>5
Thank you very much for your informing reply.

>>1

Let C kick your ass for a good amount of time before moving over to any object oriented languages

OP here, I checked few C books and "The C Programming Language" was the most unclear one. I learned the basics of C before, but never beyond them, and the book I mentioned above looks more like a style guide, having the ANSI C code in it. Should I stick to this book though I don't get it, or continue through another, not ANSI C but more clear ones? I can always go back to it after I learned a fair amount to improve my coding style.

Thanks again

FUCK YOU 4-CH.NET.
I WROTE THIS GOD DAMN HUGE REPLY TO OP AND WHAT DO I GET IN REPLY?
MY COMMENT WAS TOO LONG BY 1200 CHARACTERS. BECAUSE I WROTE THIS WITH w3m
NOW I HAVE TO REWRITE IT. NO. FUCK YOU 4-CH, FUCK YOU.

>>14

Maybe you should get a real browser.

When C was first visualized and conceptualized by Kernigham and Ritchie (surely
and others too, such as K. Thompson, who played an important role in C's history)
they had to introduce the language to other programmers. As such, they decided
to document its features as best as they could, and they wrote a book called
"The C programming language", also known as K&R1. The book standed as a
reference and guide to anyone interested in C programming. Every compiler
developer or programmer was using <i>the de facto</i> book to learn C and study its
aspects. The book was quite ambiguous, and incomplete in many ways. As such,
different compilers behaved differently, and different programmers wrote
different code. The implementation was unclear, and the diagnostic messages
where absent. It was hard to tell whether a bug was in the implementation or the
programmers fault, because there was no "official" reference. C was an
unofficial language used by hackers (not in todays sense hackers). So where do
the standards come in? A standard thoroughly and exhaustingly documents a
subject, and sets the <i>rules</i>. Anyone who is interested in the subject is
expected to use the standard as a reference. ANSI decided to publish a standard
on C, commonly known as C89 (though its official name is ANSI X3.159-1989). The
document was clear and well thought, and compilers quickly adopted it. Now, it
was easy to tell whether an implementation was conforming or not, because the
rules of the standard made all implementations behave the same; That does not
mean it limited their functionality, but rather, it documented the very
functionality expected! You could write code for system/operating system A and
expect it to behave the same on B. However, there were problems with that
standard too, as it wasn't available to the average Joe because it was quite
expensive. Moreover, it could not be used as a tutorial for the language.
Kernighan and Ritchie decided to write another book, K&R2, which served as an
introduction, tutorial, guide and reference to ANSI C. The second book was
<i>excellent</i> and sold millions of copies. Now, almost 20 years later, the
book still stands as an excellent resource for C, and one of the best books
written for it. Still, there were problems with ANSI C. The standard was not
widely available because ANSI is not an international organization. ISO decided
to take charge of C, and published ISO 9899:1990, 9899:1995 and 9899:1999. (also
known as C90, C95 and C99) in chorological order. ISO made C99 freely available
in pdf form. Standards are not only for programming language; they can, for
example, document a file type, such as JPEG; or the representation of
floating-point values in computing. Indeed, there are; Former as ISO 10918-1 and
latter as IEEE-754, which are also widely used.

So, do ask yourself now, <i>should I read a book written 20 years ago that's still
appreciated by experts worldwide, or shall I read a tutorial I found on some
fools blog?</i>
Do not fall into the hedonically appealing temptation of taking the sunny road.
Take my advice as is, read K&R (the alternative is to read H&S). Study, be
patient. Otherwise, you'll be of the second kind of C programmers, which will
also reflect on you as a whole; You'll be a <i>lazy</i> programmer, that prefers
the job done quickly, than the job done properly. Such programmers serve no real
purpose, one could rightfully claim that they don't belong in the computer
world. If C seems to hard for you, try PHP or similar first. Get a sense of what
writing in an imperative programming language feels like, and then try C agai

<dd><blockquote>Should I stick to this book though I don't get it, or continue
through another, not ANSI C but more clear ones? I can always go back to
it after I learned a fair amount to improve my coding style.</blockquote></dd>

You got an answer in the previous paragraph for this question, but I shall
repeat just in case. ANSI C is not a coding style, it's a standard. K&R merely
adheres that standard and explains its virtues. A C book that doesn't adhere to
a C standard is quite useless. You can indeed go back, but when you pass the
point of no return, turning back seems so distant. <i>Do you know what that is,
OP? That's the point in a journey where it's longer to go back to the
beginning. It's like when those astronauts got in trouble. Somebody messed up,
and they had to get them back to Earth. But they had passed the point of no return.
They were on the other side of the moon and were out of contact for like hours.
Everybody waited to see if a bunch of dead guys in a can would pop out the other
side. Well, that's me. I'm on the other side of the moon now and everybody is
going to have to wait until I pop out.</i>
There's no reason to go that far if you intent on turning back.

<dd><blockquote>Thanks again</blockquote></dd>
You are most welcome my friend.

FUCKS SAKE I GOT HTML WRONG AGAIN.
Excuse me while I suicide.

>>19
No problem at all, thank you very much for your replies, I really appreciate it. The things that were unclear to me solved by themselves when I switched back to gcc, an exercise that didn't work.
I have some programming experience other than C and it is not related to that - in fact, when I started self-learning programming C++ was my first pick, an advice by some friend, and I learned C along it. I soon abandoned both of them for other language picks but I had no problem learning them to a basic level. I soon started relearning C by the 'Teach yourself C in 24 days' book, but abandoned it after the 10 or so day, for an unclear reason, probably because the book was really for dummies.
My most recent language that I learned beyond the basics is Perl, that has roots in C. Somehow, after coding it some time, it feels harder to code C. I'm sure that it will improve though.
Except the material purpose, how is C going to affect my other languages knowledge, or general programming thinking? You mentioned imperative programming and not being lazy, but I heard more good things, such as a better syntax and functionality.
And a little question regarding some exercise in the book recommended by you:
How is getchar() and putchar() different from scanf() and printf()? I heard the latter consumes more time and power because it parses the variables, while getchar() and putchar() work with any type, whether it is an integer or a char.

Thanks again and best regards

I think the OPs initial question is flawed.

What is your goal?

If it is to learn computer programming, you should understand that C and C++ were made to solve programming problems of decade sgone by. They are old and showing their age. Better languages have been released.

If your goal is to support legacy code, or modify the linux kernel you should learn C and C++.

If you want to make modern desktop apps, then you need to go with a different langauge and/or programming platform. C++ (as a language) is ill suited for the task. By default objects are passed by value, which isn't object oriented at all. Threading (which is becomming so important these days) is a pain in the ass.

If you want to make Windows/Web/some mobile/limited Linux apps, go with C#/VB.Net and the .Net framework.

Or go with Java. The platform absolutley sucks, but the language isn't half bad.

The CS types are saying now that all languges in the future will be dynamic. So why not learn Python or similar.

>>21
Got it.
>>22
My goal is to prepare for an actual job. It is a bit early for me, but as a person who just learned most languages and almost never did a whole big program used by someone, I want to do so now.
I saw multiple languages used on Sourceforge, C++ the most popular among them. But now that you mention the actual usability in real world, C and C++ lose their stance as a strongly used language. The world is advancing, perhaps the kernel will be rewritten in another, more modern language, or we will use some other GNU/Kernel written in Java or C#.
Everyone are spitting around 'Learn C' or 'Learn Scheme/Lisp/Haskell', so I thought there's more magic behind programming, but now I understand it won't help me in my current level.
A functional language for me is a language that is used in real life, beyond the magic of Lisp and such, and one that I can code for fun and profit in on Sourceforge.
People all go 'Java is bloated' and "C#'s memory management is bad" and maybe, or it is true. But your Scheme book or the Linux kernel won't change your boss' view on your job, or the standards, in most cases.
I know it is unrelated to my first question, but how would one improve his knowledge? I lurk on the web for source code, but all I find is usually some cracker's tool Perl code, which is written badly. Yes, this question is asked really often, but I'm in that stage where exercises are simple, and bigger projects thrown at me such as 'Write a simple HTTP server' (which I understand in theory is a socket listening on a port for data) but I can't write them yet. I have to advance somehow from this begginer level, which lays between a book-reading newbie to intermediate coder which can do tasks given to him, and he doesn't question himself how to.
I really am a starter, I never participicated in a real coding job, but I am eager to do big projects, or even a one, small, open-source projects such as a module for Perl or a library, but with in my current level it seems a little less impossible than the level before.
A side note - I mentioned Sourceforge few times. I did so just because it seems the best coding area for intermediate coders, where I do not fit yet. No particular reason.

Thank you for your answers very much again, and best regards.

>>24

>C was originally written for low level work with unix.

Which is why I went on to say "modify the linux kernel". Sorry the list isn't exhaustive, but its easy to infer a list of appropriate unix related work with C from that.

>Again, bullshit. Why is C++ ill-suited?

That's the problem with C++, jack of all trades master of none situation. It's flexibility means it has to make sacrifices.

>Why would it want to be "object oriented

by default"?

C++ may not want to be OO by default, but OO is here to stay. You can't avoid it. You are going to use it. So you might as well have it implemented well. Other languages implement it better.

>Objects can be passed by reference in C++

Of course they can. The problem as I and some others see it is that C++'s OO add-ons don't go far enough. They can't. They did for when it was made, but these days better alternative have been implemented. Enforcing value and reference type variables make sense (that is, all objects are pointers by default).

>Moreover, the new C++ standard is going to include threads

It's going to. Then it needs to be adopted etc. etc. etc.

>Just when was threading not important? Please help me recall.

Years ago, beginning programmers didn't even touch threading. It used to depend on what level you were at. These days, you can't avoid it.

>Also, explain briefly the issues you have encountered with libraries such as

pthreads.

The issue is that better threading exists as far as programming it.

>Why would you go with C# and .NET for linux apps?

Portability with other platforms. The fact that the development environment is good.

>What about BSD, solaris, other? OP: Don't learn C#.

Mono is on those too.

>C# is horrible. It's controlled by microsoft.

It is controlled by Microsoft, but its also a published EMCA and ISO standard. Forgoing any irrational MS hate, that is a good thing.

>My goal is to prepare for an actual job.

The demand for C and C++ in the job market is small compared to other languages/platforms.

>The world is advancing, perhaps the kernel will be rewritten in another, more modern language, or we will use some other GNU/Kernel written in Java or C#.

No idea about the Linux kernel. By MS has written a functioning kernel in C#, Singularity, with a windows command line like shell. It's open source (or maybe reference I ca't remember off the top of my head) at the moment, you can download it, run it, play with it. It's a canidate to be the new Windows kernel a couple versions down the road.

>People all go 'Java is bloated' and "C#'s memory management is bad" and maybe, or it is true.

I dislike Java platform, bloated isn't the term I would use but it is one of them.

People who say C#s memory management sucks don't really understand it. Memory management is handled by the .Net framework. Your app automatically gets a low priority thead that the garbage collector uses to clean up memory when it determines it need to. Some people lament this automatic behavior an infer that they have no control over the process, but that's just not true.

If you want to force it to clean up unreferences variables, just call
CG.Collect()
This will instuct the thread to start working

If you want to wait until all garbage is freed before continuing
CG.Collect()
GC.WaitForPendingFinalizers()
Your current thread will wait until the memory is free before continuing.

This is just some simple examples, there is a lot more to it. And I have notice those who dis memory management in .Net are completley unaware that one can intereact with the GC.

>I know it is unrelated to my first question, but how would one improve his knowledge?

Pick a project you really want to make. Figure out what language and platform(s) you want to make it for. Then go for it. Learn the ins and outs of your chosen language. Learn the platforms libaries. Then use that knowledge to come up with a solution you want to implement.

hay guys whats going on in this thread

>>29
no, he definitely said you should learn c++ first. and i quote (pg 7, 3rd par):

>In the continuing debate on whether one needs to learn C before C++, I am firmly convinced that it is best to go directly to C++

he then goes on to list a billion points as to why, and finally (pg 14, 1st par):

>the better one knows C, the harder it seems to avoid writing C++ in C style...

>MS has written a functioning kernel in C#, Singularity, with a windows command line like shell. It's open source (or maybe reference I ca't remember off the top of my head) at the moment, you can download it, run it, play with it. It's a canidate to be the new Windows kernel a couple versions down the road.

After looking up some more information about it, it makes me feel disgusted. First of all, having an OS kernel running in managed code is going to be hugely inefficient, wasting a lot of potentially available processing power. It also seems too concentrated on "security" and "safe code" and nothing else, making me believe that this is eventually going to be an OS where only "trusted" (read: Microsoft-approved) programs are allowed to run. Another case of trading freedom for security.

> having an OS kernel running in managed code is going to be hugely inefficient

But more efficient than having a language runtime sitting on top of a kernel.

For example, one of the problems garbage collectors face is that they don't communicate with the operating system about the pages they hold, although there have been some attempts. Your typical GC is only aware of is this large virtual space available to them.

What happens to the disk when it's time to collect, and your live set is larger than physical memory? What happens to CoW if the process is forked, but you have a moving collector? How about inter-process communication?

If you have a safe language you no longer need to worry about user processes using ring0 assembly instructions or accessing the memory spaces of other processes. This makes many operations, including context switching, a lot cheaper. Dangerous code is limited to one place, which makes the OS more stable as well.

The language as the OS is an old idea. So are microkernels. That Microsoft wrote one with a mix of assembly, C++ and C# isn't something to mutter about.

> It also seems too concentrated on "security" and "safe code" and nothing else, making me believe that this is eventually going to be an OS where only "trusted" (read: Microsoft-approved) programs are allowed to run.

The mind of a fanboy:

Microsoft writes unsafe code => Microsoft is evil and stupid.
Microsoft writes safe code => Microsoft is evil and stupid.

Now tell us: Seeing as how Windows' one single strength over other OSes is the huge amount of third-party software available only for Windows, that people rely on, why exactly would they want to kill all that off?

>>34 That's disingenuous.

It looks more like this:

Microsoft is untrustworthy and quite possibly evil. When they have a monopoly, they write unsafe code and try and blame the user. When they don't have a monopoly, they try and reengineer words like "safe" to recover it.

Microsoft Safety I can do without.

> why exactly would they want to kill all that off?

Because the Microsoft Developer Lock-In strategy works best when developers are investing in Windows. Once they're already invested, they might broaden their horizons, but while they're actively putting effort into learning new technologies from Microsoft, they're not doing anything else.

Windows code that ran in 3.1 doesn't run anymore. Windows code that run on Windows95 doesn't run anymore. I have TV cards whose drivers were Windows98-only and will not run on Windows anymore. Windows NT4 has many programs that don't work anymore.

Not only has Microsoft "done this before", they do it with every release. Except maybe Windows ME. I'm not aware of any significant breakage there.

"He who sacrifices freedom for security deserves neither."

That's the first thing I thought of when I read the last few posts. From the point of MS' view, the various unices which have all of the kernel written in languages like C and Asm would be considered "dangerous" and "unsafe", but yet they are still more secure than MS' own OSs, clearly showing that you don't need a whole mess of "checked" and "managed" code to have a secure and still flexible OS.

And... C first. Once you get the basic syntax of the language, then you add objects (C++). Makes sense that "procedural" code which will be what you're writing in class methods anyway is what's learned first, then the object abstraction is employed on top of it.

>>31
what do you mean me? that was a quote from stroustrup.

Oh, do elaborate, >>40.

>>41
I assume he's referring to the "guilty-until-innocent" view that MS seems to be taking.

>>35

Dude, Windows is one of the most backwards-compatible OSes around. Their whole business model requires them to retain support for ancient software used by businesses. You're severely delusional if you think otherwise.

Wow, look at all of the assumptions.

MS wrote a kernel using a "safe" or managed language (C#) and that's it. No C++ or ASM. They said to get it to work they needed about a 100 lines of unsafe code (you can run unsafe C# code).

The ported over C++ stuff to manged C# and found it ran with less resources (faster) on this kernel.

The kernel does not force that code be managed, its doesn't have to and it would make no sense to make it that way.

The whole thing is a huge subject, you need to read up on the materials written about it and watch their videos before you make uninformed assumptions and sound stupid like >>37 >>35 >>32

I see all the in-built MS hate leading to such stupid assumption all the time. Some people just can never wrap it around their heads that MS might actually make some useful technologies, instead of just regurgitating uninformed blogs they have read.

> No C++ or ASM.

Almost none:

Like the previous Cedar [26] and Spin [4] projects, the Singularity project enjoys the safety and productivity benefits of writing a kernel in a type-safe, garbage-collected language. Counting lines of code, over 90% of the Singularity kernel is written in Sing#. While most of the kernel is type-safe Sing#, a significant portion of the kernel code is written in the unsafe variant of the language. The most significant unsafe code is the garbage collector, which accounts for 48% of the unsafe code in Singularity. Other major sources of unsafe Sing# code include the memory management and I/O access subsystems. Singularity includes small pockets of assembly language code in the same places it would be used in a kernel written in C or C++, for example, the thread context switch, interrupt vectors, etc. Approximately 6% of the Singularity kernel is written in C++, consisting primarily of the kernel debugger and low-level system initialization code.

Ref: http://research.microsoft.com/os/singularity/publications/OSR2007_RethinkingSoftwareStack.pdf

"unsafe code" just makes it seem like putting huge restrictions on what programs can do is a panacea. Think of the "shaving with a bowling pin" analogy.

Can you give some examples, outside of a kernel or drivers, where enforcing safety is a substantial restriction?

>>47
code which generates and executes the code that it generates. memory protection etc. should be left to the hardware anyway. i'm sure there are other examples too.

Generating executable code on the fly is obscure outside of JITs, but true enough. Safe code doesn't prevent doing the same with bytecode though.

Memory protection is already handled by both hardware and software. The operating system creates page tables and handles page faults, after all.

Given that an Operating System's primary function is to provide resources to applications, I can't really see how providing managed code resources in the kernel is a bad thing.

An OS that provides more resources and more kinds of resources is always the logical progression of OS development.

printf("daysue\n");

>>51
http://www.desudesudesu.net/

>>50
...and consumes more and more resources?

YA WELL MY KERNELZ HAV XML IN THEM YOU FUKKEN NOOBZ

I apologize for butting in on the discussion, but did somebody seriously suggest learning .net to develop apps for the linux desktop?

Kind sir, please keel over and die. Mono is not a good thing(tm).

Can you already grasp OOP? (Object Oriented Programming) If you can get the concepts, and don't know either, start with C, strict C. It will make you a better programmer down the line. If you dont understand OOP, go with C++ first to understand it, cause if you dont understand OOP and you learn C, you'll make only a mediocre C++ programmer ;)

>>57
C++ is a horrible language for learning OOP.

>>58
C++ is a horrible language.

>>59
C++ is a horrible.

>>62
Please don't bump silly topics with sillyness, it's considered silly around here.

Why the lot of you bash C++? Do you even have a reason for it, or are you just trolling? A lot of cool shit was made in C++(at least a lot of the cool shit I've heard of).