Ok! I have learned C, and am on to C++ now.

Im curious as to when I should start learning multithreaded programming and to transition to 64bit programming. iI know right now it isnt a big deal, but in a couple of years(when I am more proficient at programming) It will be.

But, i have read a lot lately about lazy programming, and how this all has to change for multithreaded programming and what not.

So, what my concern is to learn right from the getgo and not develop bad habits(try not to ) And to sort of "future-proof" myself.

Also, what are differences in programming for 64bit systems? Is it just the same as 32bit but compiling on a 64bit system?

I have a 64 bit proc(system will be done by end of month) and am curious about taking it to its full potential!

Thanks a lot for your help,

Martin

PS, if anybody has any good tutorials on multithreaded or 64 bit programming, please post some good links that you would reccomend.

If you're reasonably good at C, you can start learning and using the pthreads library right away. You canb write some simple multithreaded code and learn about things like semaphores, synchronization, and other fun topics.

As for 64 bit programming, the starting point is don't make any assumptions about the size of various data types (a good idea in general). The C standard sets minimum sizes (e.g. a char can not have less than 8 bits, but may have more, although I've yet to actually find a platform which has non-8 bit chars). Really, you just want to have your code be portable in general unless you absolute;y need to write something nonportable.

Forget about 64 bits, it's trivial from a code standpoint. Just use -Wall -Werror.

Multithread programming has a much bigger impact, both on generak program design and on actually managing the synchronization in your program, aka debugging the lockups

Better start multithreading right away.

Multithreading is useful only when an application really does have several activities to do which are both "relatively independent of one another" and basically "I/O-bound" (not "CPU-bound"). This gives the application great flexibility in exactly what it "chooses to do next." It can enable the application to be very responsive to changing conditions.

But I would assert that the facility is usually either abused, or employed in situations where it really gives no advantage. If the natural operations of the program are basically-sequential, and already very I/O-bound, then dividing it into threads will not help. The so-called "flaming arrow approach" of handling multiple requests, as in a server, can be a disaster. ("Each new request results in a new thread, fired into the air like a flaming arrow to complete the request and then die.")

Multithreading is an important tool to master, but it should be employed judiciously.