Kurt wrote: > > I am one who isn't simply happy being a user and wish to write > some of my own applications under Linux, as well as to play > around in helping to develop some GNU software in the near > future. However, I am a major newbie to the world of programming > in C for Windows, let alone Linux. I'm not in a rush to make > money in programming, but merely wish to do it for the pure > satisfaction of it. Therefore, I have chosen to dump most of my > efforts into doing so under Linux. However, I have a few > questions for any of you who are experienced hackers (note the > proper use of the term here) and truly understand the machine. Excellent! You've picked a wonderful development environment. One that allows you to experiment to your heart's content with extremely little cost. > I want to learn OOP programming with C++, Python, and other OOP > programming languages. However, I have noticed in Linux that > things are a lot different than programming in DOS or Windows. > > My first question is: What are some GOOD books that one can use > for a new person who is new to programming in Linux? I purchased > "Teach Yourself C in 21 Days" and "Teach Yourself Advanced C in > 21 Days" by SAMS publishing. However, I have noticed that those > books tend to lay things out in more of a Windows IDE environment > and DOS / ANSI graphics. There has got to be a better way of > learning C and C++ for Linux programming than this! Any > suggestions? I would prefer a series that will take me from the > basics all the way through advanced information through the same > publisher if possible. One of your best friends as a Linux/Unix user will be O'Reilly and Associates. They publish a wide variety of books on various Unix-ey topics that are generally considered to be the absolute best references available. They have an excellent series of 5 or 6 books on Perl, a couple on Python, and a couple that cover beginning C and C++. I'd recommend a different book for learning C and C++ though. "C: How to Program" and "C++: How to Program" are published by Prentice Hall and have served well as a "do it yourself" classroom for learning the languages. Overall, you'll find that you want to avoid the SAMS titles. They're very rarely worth the paper that they're printed on. There were enough errors in the "Teach Yourself Perl in 21 Days" book that I simply gave up on day 7 or 8. > My second question is: There are TONS of libraries and modules > that are already a part of the GNU compilers, so as to keep > programmers from having to "re-invent the wheel". However, I > cannot seem to find any documentation or books which list all the > properties of all the standard libraries so I can start using > them religiously. (Also, I would appreciate some materials which > can show me how to implement the libraries into my programs) For standard GNU libraries (glibc, stdc++, termcap, ncurses, etc), you'll find documentation in the /usr/info directory. The info file reader is a bit hacky to try to use for very long, but if you're familiar with Emacs, you'll probably like the reader. A number of the library packages also include some sort of documentation and reference material in /usr/doc/<package>. The nice part of Linux (and the open source/free software world in general) is that you can tear into other applications to see exactly how they work. There's nothing better than reading some wonderfully written code to show you how various libraries should/are used. > I have basic understanding of how to use libraries though, just > that I would like to learn how to use some of the more advanced > ones. I know the basic function calls such as: #include > <stdio.h> etc. But I would like to understand what is IN those > functions and, thus, how they behave. Any suggestions? The book suggestions above for Perl and Python cover the languages extremely well. They're both scripted languages, as opposed to compiled (like C/C++). For standard C/C++ library reference, the above mentioned /usr/info documents cover the libraries. You can probably pick up some books that also cover standard C/C++ (I picked up one book titled "The Standard C Library" a few months ago for something like $6 at the local B & N). > I aways feel I am behind the power curve when it comes to > learning programming. Libraries change every week or so. New > graphical interfaces come out and, once you think you've learned > it, they go and change everything around. Also, with Linux, I > have found that when libraries are changed, some programs cease > to work due to backwards-compatibility problems. The typical > Linux user then ends up having to have multiple sets of libraries > on the system JUST to be able to keep and run the older > programs. Is this not a productivity problem that should be > addressed??? Just curious. Distributions tend to do a pretty good job of ensuring that the items they ship all work well together. There are, of course, a few exceptions that are just beyond their control -- StarOffice, ApplixWare, and Netscape come to mind immediately. You'll notice something common to those three, they're all closed source products. Given the source, we wouldn't have the need for the multiple versions of libraries just to keep a strange app working. As for GUI libraries, pick one that you like. Noone is going to complain about your choice of libraries as long as everyone is able to use them, fix them, and share them. Lesstif, Fox, Fltk, Qt, Gtk, etc, etc are all available universally across distributions. All of them are more-or-less freely available for whatever use you'd like to put them to (Beware commercial programming with Qt, it's got a licensing fee for closed source work). The one thing that people have to get used to with the open source community is that things move relatively quickly compared to other software communities (would it even be fair to call Windows users a "community"? Interesting thought...) However, don't let constantly rolling version numbers scare you. It's typically regarded that as long as the major number doesn't change, the interface to the library hasn't changed (I suppose the glibc 2.0->2.1 change is an exception, that broke things). Pick a library, code to it, and track updates to the library. If you come across things that are broken, update the libs. All in all, I much prefer the versioned library scheme used by Unix to the blind trust you are forced to give applications under other operating systems. Watching new packages install in Windows gives me the heeby-jeebies when I see things going into /windows/system. Sure, the new lib works for that app, but what did it overwrite and what will break in the process? At least under Linux, libraries and applications are distributed (and often developed) individually so you have a bit of control over what will be installed. I hope this message at least makes you feel more confident of your choice in using Linux to learn programming. It's a wonderful environment, overall. -- Steve Philp Network Administrator Advance Packaging Corporation [EMAIL PROTECTED]
