Slashdot Mirror
Who's Afraid Of C++?
The Scoop Breaking with traditional lecture-on-paper format, Heller demystifies computers, programming, and C++ for absolute beginners. That's right -- he recruited a full-fledged novice user, capable of little more than e-mail and word processing, and turned her into a decent programmer while reviewing this book. (She became Mrs. Heller shortly after that.) Any computer owner with time, the ability to follow directions, and the willingness to learn could also become a programmer.
The resulting text is more of a collaboration, or a commentary. Steve, the author, presents his information and then Susan, the novice, interrupts to ask questions. The big gamble is that her questions are the same that the average reader would ask. It largely pays off, only occasionally belaboring a point. (To be fair, it could also be called 'reinforcing a point.')
What's to Like? Heller's writing is informal, but precise. Some might find it chatty, but beginners will find it more comforting than raw technical prose. His flow of topics makes sense (and does not copy the "Chapter two is everything to know about types, and chapter three is all about flow control" scheme other introductory teaching books steal from K&R). Little prior knowledge is necessary. Before actually programming, the book explores raw hardware, answering such questions as "What happens when you execute a program?", "What's a register and why is cache important?", and "How does source code turn into a running program?"Chapters tend to explain only one issue in detail -- how to use functions, for example, or the basics of a class. Heller states his objectives up front, and sticks closely to them. Each chapter has two sets of exercises, one in the middle and the other at the end. Answers follow, along with more dialogue. It's not enough simply having one correct bit of code, without someone to explain why it is correct, and why some common answers aren't complete. This decision pays off.
Though discussing weighty technical matters, there's a sense of general friendliness. With well-chosen metaphors (datatypes are kinda like odometers), occasionally goofy examples (a pumpkin-weighing-contest control program), and plenty of conversations when things get heavy, C++ isn't so scary after all. Credit Susan for much of this. If you find yourself thinking along the same lines as you study, you'll make it.
What's to Consider? The book covers about half of a reasonably paced introductory Computer Science course. It also predates the ANSI standard and the STL, though a fair treatment of the latter would easily double the size. Readers who finish the book and the exercises will be fully capable of producing their own useful programs, but will need additional information on common libraries, algorithms, and more object-oriented programming. They'll also have avoided some of the traps awaiting the unwary novice, as Heller practices a fairly tight methodology.
More technical readers already familiar with programming and at least one C-based language might find the pace slow and the extra explanations unnecessary. Heller's target audience is definitely the neophyte, not the experienced developer. The latter might question the subject matter covered. Why build a vector class instead of using C-style arrays? Why not C-style strings? I suspect the author is more concerned with helping his students avoid the kind of pitfalls C++ was designed to work around. It may not be the traditional approach, but it's valid and it will produce decent programmers, who can learn C++ on its own merits.
The Summary Steve Heller's pulled off quite a feat -- producing a book that assumes very little, yet produces people who understand programming. There's not as much information presented as in a "Learn the Language in X days/weeks/hours" book, but it's more accessible and better geared to a true beginner. For a gentle and effective introduction to programming and C++, give this book a try.
The CD-ROM contains complete source code of all program listings, as well as the excellent DJGPP compiler (yes, it's for DOS).
Read this book online at www.steveheller.com or purchase it at Fatbrain.
Table of Contents- Prologue
- Hardware Fundamentals
- Basics of Programming
- More Basics
- Functional Literacy
- Taking Inventory
- Stringing Along
- Down the Garden Path
- Tying Up Loose Ends
First of all, the main reason people are afraid of computers is that they don't know how they think. If everybody had a basic discrete math class and an introduction to concepts of computing, C++ would be a lot less unfriendly.
Personally, I think C++ is a bad teaching language because computers don't think in objects. They think in memory locations and in blocks of code - exactly like C, nothing like C++. What people need to learn to do programming is how a computer thinks - and C++ ain't gonna do that, buddy. I think the best introduction to programming I've ever seen is an O'Reilly book called "Practical C Programming" (the Cow book).
- Who's afraid of Unix?
- Who's afraid of Relativity?
- Who's afraid of Motorcycle Maintanence?
- Who's afraid of Sex?
Yes, let the money roll!Imagine connecting a few icons with a wire to pipe stuff between them, then filling in parameters in a popup window for each of the icons. This would become a new icon, that you could drop data on in order to have it processed.
Programming for dummies could and should be that easy in order to free the end user to use the full power of computing.
Not everybody should learn programming; everybody should be able to start programming with smallest possible effort.
This stuff into KParts/Bonobo?
I think, therefore thoughts exist. Ego is just an impression.
C++ is SCARY.
BilldaCat
Hopefully this book addresses (suitably) the reason why people have good reason to fear C++. In many ways it is a language in which you must know everything before you know anything. The complexities of how constructors/destructors interact when returning objects (for instance) is very confusing and one of the reasons why it often takes many years of C++ programming before a programmer is truly competent. If this book effectively addresses educating people in the "hard stuff" its good. If not, well its not.
-Rich
Free your mind and your Ass will follow -- George Clinton
Despite the fact that I can and have programmed a lot of C++ stuff at home and at work, for some reason it just doesn't seem to stick, and I find myself constantly annoyed by minor language niggles and an obscure syntax that sometimes just tries too hard to be concise.
Now, I've been programming for years and I find C++ difficult to get into sometimes, so if this book can really make it accessible for the user then that's half a miracle by itself. Of course, if the lady in question being taught C++ became his wife soon after, it does raise the question of how much "private tutoring" she was getting... :)
---
Jon E. Erikson
Jon Erikson, IT guru
it was called "The cartoonist Guide to Computers" - i cant rememeber the author right off....
My cousin that went to lehigh gave it to me when i was 12. apparently, the book was being used by lib. arts students to get a grasp of the technical courses.
It was presented in a humorous, light, yet incredibly informative way... It traced the history of computing, from abacuses to differential engines, and made the whole thing very interesting.
And, it had a good level of detail in it. It wasnt a gloss over the topic and pretend they've covered it. It went into boolean and gating fairly extensively.
Not bad for a cartoon book.
... hi bingo
Beginning to program is a wildly confusing experience - or at least, it was for me ;-) This book sounds like it'll help people along greatly.
However (there's always a however):
There is absolutely no substitute for the hacker-type mindset - the obsessive compulsive (say it ain't so) need to explore a system for yourself, to produce programs which should be beyond your capabilities - and which were, until you put your mind to them. If someone doesn't have that raw curiosity and the need (the NEED) to know everything about a system, then they're never going to be anything more than a "quite good" programmer.
--Remove SPAM from my address to mail me
The college I teach at has thier Business and Information Systems Management (yeah, stupid major, but that's a whole separate rant) taking programming classes. If there were more books like this, it might be a little easier to teach programming to them.
-- Gunther T Dull is not responsible for his opinions.
Troll Anon Coward.
He thinks that Mac beats fine Tux
however, can't spell.
if ($post eq "finished")
{
print "sig\n";
It's not the initial step into programming that is difficult, it is mastering it. Give me an hour, a good library, and a reasonably intelligent person who has a fairly open mind and high school trig, and I'll have them writing simple games. That doesn't mean that they'll be analyzing algorithms in big-O notation and parsing b-trees. I think that the biggest pitfall for users is viewing computers in the wrong light (Impossible machine) and being unwilling to apply any basic knowledge (when I was a kid, we were booting atari's up in computer labs in my elementary school, and writing programs in BASIC. I know that this happened all across America. Now, you ask someone to type in a password, and it's too much for them to handle, and click on the "send" button, why does it have to be so hard?
Eh...
With well-chosen metaphors (datatypes are kinda like odometers)
Ignoring that this is a simile and not a metaphor, does that make a lick of sense to anyone? Datatypes are kinda like odometers? Fingers are kinda like distributor caps. I thought I knew C++ but obviously I missed something in my studies
How is a raven like a writing desk
Conscience is the inner voice which warns us that someone may be looking.
Conscience is the inner voice which warns us that someone may be looking.
-- H. L. Mencken
This is not a flame.
When you code in C, you know of how it will execute. Nothing is hidden from you. It is easy to follow. Plenty of compilers exist.
I've been programming for many years, and have dabbled in C++, but could never come up with one good reason to use it over C. Could someone help me out here?
IMHO, it doesn't matter what language you program in(I progam in several, including C++), the important point is that you understand the basic tenets of programming, and can use these concepts to program in any language! If this book can help people learn that, more power to them!
Attention all planets of the Solar Federation! We have assumed control! - Neil Peart
I remember when i was learning to program (somebody shoot me, i say that a lot, and it was only 13 years ago) there were a lot of books like that (although often using basic or pascal) and i got all of them out of the library again and again until i'd sucked them dry of information. They were informal, not too intimidating, fairly friendly, and most of all, they weren't snobby. SOme even had cool cartoons =:-)
This has been missing in the age of the booming tech economy and the whole "professional image". I think the world needs this sort of a thing, so that novices can begin to experement, because it's fresh minds that generate a lot of the innovation, and i think that extending a bridge to users is a good thing.
---
Play Six Pack Man. I
After three years of programming, I would definitely consider purchasing this book for the reason that my mind tends to get bogged down in the syntax rather than the symantics.
One book to definitely avoid would be C++ Program Design: An Introduction to Programming and Object-Oriented Design (2nd edition), Cohoon and Davidson, WCB/McGraw-Hill, 1999. It's not that it's really that bad of a book, but I suppose since it's the book that we used for my CS101 course I wasn't too happy with it giving me that firm of a foundation.
Good day...
Fruit flies like bananas... Time flies like the wind...
I don't understand this comment. Questions such as, "Why build a vector class instead of using C-style arrays?" and, "Why not C-style strings?" are fundamental C++ questions. Now, it's true that the neophyte will not immediately question why a vector class is used, but IMHO it is an issue that should be addressed.
Additionally, the comment that readers can "learn C+ on its own merits" leads me to think that the book doesn't really cover C++, but rather covers "object-based C." Does the book even get into polymorphism?
Good supplements to this book (and essential reading for every C++ programmer, IMHO) would be the C++ FAQ Lite and STL Programmer's Guide. The Design Patterns book by Gamma, et. al. is also essential reading, but is probably a little advanced for the newbie.
--
One of the early books I read involved describing an ALU as a bunch of boxes that could add other boxes. It was written in the early 1960'sand had lots of drawings taht look like departmental mailboxes and how data access worked with index registers and the like. Today most people would consider it a waste of time but I'm not sure. I know how computers operate down to the gate level. I can optimize things well enough. Most of the books I read in my early programming days wouldn't even be considered programming books by todays standards but they worked well for me. I guess thats why I get to explain to the new CS grads why we don't do some things some ways since the computer doesn't like doing trillions of calculations when it has other thigns to do too.
I know what you're thinking: there's no way I can learn C++ in five (count 'em) five minutes. Well stop being such a doubting loser. Here's what you do:
Step One: On the qualifications section of your resume, write, "I know C++." Feel free to put other things, such as "I speak thirteen different languages," "I've slept with Pamela Lee Anderson", and of course, "I am omnipotent."
Step Two: Get Hired!
Step Three: When your manager approaches you to actually work on a C++ project, immediately run to your nearest Asian immigrant and pay him 50 cents an hour to do the project for you! Don't feel bad, your manager did the same thing to get in his position!
Step Four: Watch as the money, women and strange magic powers are bestowed upon you.
It's just that simple!
-Bgs006
LostBrain
That phrase always bugs me. The obvious first take would be to graph the independent variable (time) on the X axis, and learning on the Y. But then that would give any "hard" subject a shallow learning curve. Someone once tried to explain it to me by using a Z axis, muddling everything up even more. Is there an official interpretation, or did an economist invent this graph?
With the predictions of things like even my light bulb will have an ip of its own, it is very important the so called an average user knows a bit or byte about the internals. It should not be limited to just C/C++ programming but should extend to include things like concept, not necessorily implementation of encryption, networking and OS. Hey, I know what type of saftey featurs, equipment, modules etc I want when I want to use a car. So why should I ignore thefor the almighty world of computer/internet/networking ahead of us.
He's written a bunch of other "Cartoon Guide to..." books as well. The best are his history books (two books each split into around 8 "volumes").
Book 1 is "big bang" to "the fall of Rome" (as I recall). Book 2 backs up a little bit and changes geography to look at the history of China. I'm expecting Book 3 any time now since it's been several years since the last book appeared.
Book 1 was mostly familiar to me--the same-old "first the tribes, then the Greeks, then the Romans" stuff (although told in a very entertaining way). Book 2, though, was totally new: We don't get much non-European history here in the US. No wonder we don't understand "those Chinese".
--
Compaq dropping MAILWorks?
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
It sounds like a good book I just get a little worried when the "novice user" ends up marrying the author!
The power of the personal computer; the power to develop their own solutions, should not be confined to the rarified realm of programmers and engineers. _Everyone_ can benefit from this, and the more this information is brought out into the open, the better. I recently bought a friend of mine a "Visual BASIC for Dummies" book. He was, at first, a bit fearful of it, but once he started, he started really enjoying it. HE called me once about a bug, and when I showed him what the problem was (i'm certainly no VB expert, I work in C++ primarily), he immediately _understood_ it, saying something like "Of course! I checked everything else but that." One could see his esteem growing; it made me feel really good.
Regards, JohnFalling You - beautiful
Too many programmers get stuck in a mode of not actually knowing what's going on with their programs. They come to a university and get smacked in the face with actually having to UNDERSTAND THEIR OWN CODE. The object oriented paradigm is useful in its own right, but learning how to manipulate objects is not learning how to program. Ada is a good intro language because of many factors. For one thing, you have to know what you are doing to do it. If you don't, you're not going to do it. It teaches scope properly, and gives a new programmer a good feeling for how the code flows and what is actually going on. I have heard Ada decried on here as being "cumbersome," if you are a good coder, it isn't, because the only things that you have to do extra in Ada, are the things that you should be doing in C/C++. In other words, the only thing that you have to do extra in Ada, is be good enough to write the program that you are writing.
Eh...
And I have to say it's very good. I think that C++ is actually an excellent language to begin with, as people tend to think in objects. The book is very good at showing instant results, in fact it starts out with strings. This lets people see immediately practical uses for what they are doing, and feel some accomplishment.
Most of the C books I've read don't even try to get to strings until halfway through, and make it a rather complicated introduction by making you understand data types and arrays first. Mr. Heller's point is that, with C++ at least, you don't really have to know what's going on with strings to use them, and that it's easier to understand the fine details of things once you've become familiar with them through usage. He does that a lot in the book.
My C teachers and classes have always seemed extremely dry after being introduced to C++ by Steve Heller. If anyone is curious about learning to program, I wouldn't hesitate to recommend this book as a starting point. There's also a follow-up book, "Who's Afraid of More C++", also working with Susan.
Mr. Heller also seems rather accessible be e-mail, but please don't hold him to that because I said so.
-N.
I used to be a cynic, then I got disillusioned with it.
I believe I can, however I'm not sure that it'd be wholly on topic ... why don't you email me at: jdumas [at] locutus [dot] kingwoodcable [dot] com and I'll try to sway you ;-). Be warned, though I am a reasonably seasoned C++ programmer I'm no zealot (i.e. I don't 100% disagree with your base assertion). I will show you a number of things you can accomplish with C++ that are either impossible in C or horrendously ugly/difficult so write me if you like ;-)
there are two kinds of people in this world - those who divide people into two groups and those who don't
...are exactly what you want! Ideally, your learning curve is a theta function: zero time goes by and you have full knowledge. Where did this phrase (and its negative connotations) come from? A shallow learning curve means learning forever and never knowing anything! Sorry... slightly off topic.
sigarette
"Give me an hour, a good library, and a reasonably intelligent person who has a fairly open mind and high school trig, and I'll have them writing simple games."
Even if by "simple games" you mean "guess the number", I don't think this is true. The biggest problem people new to programming have is creating an algorithm. I can't tell you the number of times I've had neophytes ask me "what do I do first" or "how did you know to divide by 4"?
The only way to get good at creating algorithms practice practice practice. And you can't get much practice in a single hour.
--
Compaq dropping MAILWorks?
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
Ah yes, REAL men write object-oriented code in assembler (obviously a REAL language), or in SmallTalk (another obviously REAL language), ey?
-- KDE programmer and computer science student in Klagenfurt, Austria.
Discussions on the merits of C++ are totally on-topic and I'm interested, too. I also prefer C to C++ for the reasons given but am willing to be persuaded.
--
Compaq dropping MAILWorks?
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
If you are using strict ANSI C, variables must be declared at the beginning of the block. This means you can't go:
for(int i = 0; i < 10; i++){}
Also, <<, >>, new, and delete are much easier to use, and fancy data constructs are much easier to code OO. Besides the fact that the STL already has most of what you need anyway.
If you code in C++, you don't have to do a bunch of fancy OO stuff if you don't want to, but it does give you the option. Every C program is a valid C++ program (except for a bit of funny stuff that was a mistake in the first place).
It's so horrible, in fact, that I can't even think of a worse one. You've got all the worst features of bad languages rolled into one -- a massive amount of confusing syntax, (extremely!) complicated semantics, almost always utterly unhelpful error behavior, and an extremely high barrier to entry even to get programs to compile, much less run, to say nothing of them actually working correctly.
While it is certainly an extremely powerful tool, it is also a gigantic hodgepodge of different programming paradigms. You can be object-oriented, you can be procedural, you can have it look like assembly code; this is flexibility, but only with a corresponding reduction in accessibility.
Now, I don't really know if there is a perfect language for introductions to programming. The much-maligned Pascal is a good language for learning structured programming, which makes it a good step towards C and then C++. Functional programming is easier to pick up but requires a certain amount of intellect to grasp the ideas of abstraction that it relies upon. (I happen to think that since understanding abstraction is critical to being a good programmer, everyone should do some functional programming.) For that I would choose Scheme in one of its reduced flavors. Scheme also has the advantage of having simple syntax, though it seems a bit unnatural to non-engineering types. For object-oriented instruction, I think Java is a good choice, for a bunch of reasons, which I won't enumerate since they will be obvious and I'm tired of typing.
It makes me cringe when I see a new "Learn C++ in 24 hours" title on the bookshelf, because I know those texts will screw people up. Learning to program is a challenge enough without having to learn C++ at the same time.
-m
I agree with many other posters who've suggested that perhaps C++ is not the optimal language for teaching complete novices. And apparently so do quite a few smart people at Rice. That's why they wrote How To Design Programs. It's a rather good beginner text, IMO.
--
If programming was just a matter of training then we would have code monkeys coming out of the jungle. However, as people like Knuth points out, it takes a special kind of talent to structure a complex system without getting lost in the details. Perhaps it is akin to writing a symphony, you have to know the general theme as well as how your line fits in. Not the same as throwing a few software bricks together with some GUI scripts in the hope that it doesn't fall apart.
It is rather interesting to speculate as to what makes a superlative software architect. I recall one article which claimed that if you had a prior background in music or even languages, they could teach you how to design/code. Coming from an impoverished background is no barrier as India has so amply shown. Symbolic reasoning? Spatial awareness? Or is it just something we can't test until the person sits down and has a hack and discovers a natural talent?. The mind is a strange and wonderful beast.
LL
Higher level languages produce slower programs. While I like Python and do all of my web scripting in Perl, if one truly wants to get the most out of their programs, they will optimize in assembly. Faster processors are not a good excuse to blow simple, good computer science out the window.
Eh...
;-)
Escher was the first MC and Giger invented the HR department.
...which is why you'll see C++ programs that have local variables for each block. I stick to a maximum of three throw-away variables per function (i,j,k) and reuse them. Better planning leads to better programming. C is not a free-form language. And why does the bit-shift operator control output, anyway? Admittedly, printf is a bad analogy. One should always use write(2) if one wants to understand output. Malloc is just fine for me. Free is just fine for me. Both are easy to use. Want a new struct asdf? struct asdf* ptr=malloc(sizeof(struct asdf)); - easy enough.
And for the STL, glib provides most of the best calls.
1. Perl is slow. The inherent inefficiency of Perl becomes obvious as soon as the program becomes more than just a simple script. Compiled languages (such as C++) are the only serious option for coding any non-trivial software.
2. Perl makes inefficient use of available resources. The interpreted nature of Perl creates a huge overhead, thus wasting processor resources and making your quad Xeon box perform like an 8086. It is not possible to optimise your Perl code to make full use of your processor. C++ allows a wide variety of optimisation methods, and with a good compiler the speed of compiled C++ is indistinguishable from the speed of assembly language.
3. Perl is hard to maintain. It is impossible to create weakly-coupled, highly abstracted code in Perl, thus it is also impossible to maintain Perl code on large projects. Object Oriented languages, such as C++ which you seem to despise, win every time. Contrary to what you say, C++ is object oriented, Perl is not.
4. Perl is unecessary. There really is no sane reason to use Perl - The argument that Perl is simpler to learn is completely invalid, since any reasonably skilled Perl 'coder' can easily make the step up to C++. The skill lies in learning how to program, not how to produce correct syntax. The sheer inefficiency of Perl means that C++ is more suitable than Perl for 99% of programs.
5. C++ programming is a valuable skill. It is worthwhile for people to learn C++ (or plain C) since it is the industry standard programming language. Perl is perceived as a hobbyist language, therefore Perl programming skills are not very marketable to employers.
Conscience is the inner voice which warns us that someone may be looking.
Conscience is the inner voice which warns us that someone may be looking.
-- H. L. Mencken
You really think that you couldn't get someone to type.
void main()
{
seed(time);
random();
...
yeah, chunky pseudocode, but like, I think that I could get a monkey to type something akin to that in an hour if I was sitting with them.
Eh...
The last thousand times I have seen the term "learning curve" misused, I let it go. This time I won't. The term comes from psychology, and refers to a graph of amount learned as a function of time. See this and this.
I think I can give you one. When you program in C++ you can do anything you can do in C plus (no pun intended) a lot more. You can write functions and/or tools in a style that touches and feels the hardware. Then you can objectify things so as to have much cleaner (thus safer) code in upper levels.
:)
This is one approach, the one I regretably followed. I just mentioned that way of doing things because you sound a bit like a die-hard C programer, and maybe you'll feel more comfortable with this small subset of C++. The best path of course would be to think different (tm) from the very beginning, using the STL and programming generically when there is a need.
But the real good reason to use C++ in my opinion is its power and flexibility (that multi-paradigm thing, if you like long words). I don't think there is any other language that can be so easily adapted to one's personal needs or the needs of a given project. Even if your need is to be close to the machine. And the tradeoffs are small too. With today's compilers (I use Borland 5.0 and GNU gcc) there is little difference in the code produced. Some (very credible) people claim that in some circumstances C++ will produce even smaller and faster code than C, but I haven't been able to duplicate that experiment.
This is all pretty obvious and well discussed in many places, there must be someone arguing the same thing, even as I type, so maybe I missed the point in your question.
How about g++ as a workaround to annoying admins.
I've had admins disable gcc because it's a "security hole" and leave the system nearly useless for users. However, very rarely have I come across g++ disabled.
On the other hand, one overly bright admin just disabled the linker...
Learning a programming language is the easy part. Actually using it wisely and thoughtfully is the more difficult endeavor.
I remember when I was a college student, and I felt so cool because I knew how to use obscure c++ syntax. I thought I knew so, so much.
Now, with a code base of over a million lines and an office full of class diagrams, I'm constantly reminded of how little I truly know. But that's not a bad thing; I constantly learn new things, and each day brings me more wisdom. I just think it's funny how my paradigm shifted.
Programming is very similar to literature in that it's somewhat easy to learn the language syntax, but it's very, very difficult to use the language appropriately. That's the difference between being a novice and a master. Yes, you may be able to learn C++ in 7 days, but it will take you several years (at least) to become fluent.
I'm a sysadmin, but I know very little about programming. Yes, I can write a *simple* program or script, but when it gets complex, I'm just not what I need to be.
The obvious drawback is that I have to rely on others to release software and updates that I need rather than writing or improving my own.
I think that the biggest pitfall for users is viewing computers in the wrong light (Impossible machine) and being unwilling to apply any basic knowledge
So given my background, (17 years in computers) it should be obvious that I don't view them as "impossible" machines. I taught myself basic when I was younger, and I've been trying to learn C++. My problem is that I don't have a simple source to go to for the basics. I also don't personally know any programmers, so it's hard to find any experience that I can call on. So unfortunately, I'm stuck at trying to figure out how to write pointers, structures, et al by myself. And as far as using libraries goes, I'm lost.
I sincerely wish I had a friend who could code in C++ and could help me, but I'm stuck. So for me, it appears the only choice is a good book written for the novice. Unless someone has a better idea?
Why use C++ over C? Ignoring the fact that C++ is for all practical purposes a superset of C, I'll list the featured I find most useful, anf the reasons why:
Finally, I'd like to address the issue of bloat. C++ does make it much easier to code badly. All of the abstract data types and code hiding can easily turn an O(n) algorithm into an O(n^2) one. As with any language, proper understanding of the code (libraries) is the key. The STL Programmer's Guide is an excellent resource for understanding the limitations and proper use of the STL.
To conclude with a "real world" example, I am currently on a team developing an optimizing compiler in C++. It's been a huge learning process, as any student project is, given that we started out with little compiler experience and only marginally more C++ experience. But throughout the project I have continually improved things by learning just a bit more about how C++ and the STL work. At this point, our compiler has similar functionality to gcc and runs in the same or less memory space. It's quite a bit slower, but I attribute that more to some non-optimal algorithms and more complex dataflow analysis than to C++.
In addition, by using C++'s ability to overload functions, I was able to quickly hack up the LeakTracer tool (which overloads operator new and operator delete), providing many memory debugging features and in the process reducing our memory consumption significantly. All in the span of a week.
--
Sigh...I wish I could rate that both as "flamebait" and "insightful." I'll go put on my "C++:C::PL/I:FORTRAN" T-shirt instead. :-)
Why on earth would anyone try and teach a newcommer to programming something like C++? It's my view that any langage based on the C syntax is not suitable for beginners.
Pascal, Python, maybe Java are all great languages for a beginning programmer.
I'm sure that it is possible to teach some people C++ as their first language. I'd argue that they could have learnt something like Pascal in less time, and have a better understanding of it. C/C++ syntax is too weird for a beginner, and you need to understand too much about memory & pointer to do anything useful. I mean... no native string type in C? How stupid is that when you think about it?
Posted by 11223:
Hmm - I thought that if you renamed g++ to gcc, it would be the same thing - in fact, gcc takes objective C code too, just translating it to C. On some systems, isn't g++ a symlink to gcc?
and has frequent algorithm parties at the white board to which she invites no one but herself (like mine), this book sounds like a real godsend. As a student in a beginning programming class using C++ whether I like it or not, I'm really happy that this book is out and will probably buy it tomorrow, if not today.
It may not be the most popular here on /. but it works, its available a lot of places, and it uses C++.
Well, in someone else's hands it uses C++, in mine everything still looks like C.
t
I thought you were trying to teach them to PROGRAM. You know, where you have to first understand the problem in an algorithmic way? And then break it down into a series of tasks?
But if you just want them to take dictation--sure, I could get a newbie up to speed on that in an hour, easy.
Go find an actual newbie and try your method on them. Then come back here and tell us how it went.
--
Compaq dropping MAILWorks?
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
I get annoyed with that as well. I've taken to saying 'fast' or 'slow' learning curve which seems to reduce confusion.
I hate this style, it makes life harder for maintainers, and it makes life harder for optimizers. Strangely enough, the reasons for this are largely identical.
I hate the style because it makes it difficult to figure out what in the heck you're doing at any given point. I like seeing definite lifetimes for variables because that gives me many more clues as to what you intended to do with them. I know the variable belongs in a particular block, and only that block. Any later references to it are really a reference to a different variable.
I'd almost like to see import and export statements for explicitly pulling variables in from enclosing blocks sometimes with the way some people program.
Optimizers also like knowing a lot of detail about the lifetime of a variable. It helps immensely in memory and register allocation. They know that after a certain point, the value of the variable can't possibly matter.
Need a Python, C++, Unix, Linux develop
/*This is my Lars-O-Matic gibberish generator
©2000 Lord Kano
Although this code is GPLed, I request that if you make any modifications based upon it, please give me a little credit
for writing the original code.
This code was written to be as easily portable as possible. It was written on an old Power Mac 7300/180, but it should
compile and run under just about any OS.
The LarsSpeak array is comprised of real phrases from Lars, as well as a some that I made up but still sound LarsLike.
*/
#define __LARS_ULRICH DickHead
#define ___METALLICA Sold_Out_Commercialized_Whiny_Babies
#include
#include
#include
#include
#include
using namespace std;
string phrase[19];//Array of Lars Speak
//function prototypes
void setphrases(void);//Fill the phrases array with Lars Speak
void larsspeak(int);//Send to the screen, int times, an example of Lars Speak
//end function prototypes
int main(){
srand(time (0));//seed the random number generator with the value pulled from the clock.
setphrases();
char ch;
string filename;
string *fn;
fn =
while (filename != "quit"){//Repeat this loop until the user enters quit at the following prompt
cout > filename;
cout c_str());//Open the filename the user specified at the above prompt
if (!mystream.is_open()) {
if (filename != "quit") {cout "FILE NOT OPENED ERROR!";}//If we can't open a file that was specified by the user, first check to see if we were told to quit, if not give an error.
goto here;
}
while (mystream){//get each character sequentially
mystream.get(ch);
if (ch == '\n'){//if the character is a newline, LARSIFY
cout " ";
larsspeak(1);
goto here;
}
if(mystream) cout ch;
if (ch == ' '){//if we encounter a space
if (!(rand() % 4)){//once out of every four times, LARSIFY
larsspeak(1);
}
}
here:;
}
mystream.close();//when we're done, close the file for good measure.
}
return 0;
}
void larsspeak (int i){
for (int x = 0; x i; x++){
cout phrase[(rand()%19)];
}
}
void setphrases(void){
phrase[0] = "um, ";
phrase[1] = "oh, ";
phrase[2] = "well, ";
phrase[3] = "James says, ";
phrase[4] = "according to my lawyer, ";
phrase[5] = "like, ";
phrase[6] = "uh, ";
phrase[7] = "ya see, ";
phrase[8] = "I mean, ";
phrase[9] = "I know how to get onto AOL, and I will say that I have used AOL a couple of times to check some hockey scores, but I'm no expert at this stuff, ";
phrase[10] = "ya know, ";
phrase[11] = "OK, ";
phrase[12] = "basically ";
phrase[13] = "and this is really the simplest way of saying it, ";
phrase[14] = "I think ";
phrase[15] = "well, it's like this,";
phrase[16] = "for one reason, and one reason only, ";
phrase[17] = "I'm sorry, all of a sudden your mind goes blank, ";
phrase[18] = "like I said before, ";
}
//Thank you
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
I can't help feeling you're missing the point.
Using just variables `i,j,k' in a function is NOT a good idea.
Firstly, it requires YOU to carefully manage their use, ie. to ask yourself (and answer) questions like "does variable i have a meaningful value at this point in the code, or can I use it for something new?". I contend that one should not have to deal with these kinds of details when programming; they have absolutely nothing to do with the problem in hand. Moreover of course it leaves you very vulnerable to simple human error (and we've all done it wrong at some point...).
Secondly, the names `i,j,k' give someone reading the code no clue as to what the variables stand for. This may not bother you when you are polishing your implementation of algorithm X, but when someone is reading the code AS A WHOLE it can be extremely disorientating. I'm aware that the general `Linux habit' is to give local variables rather terse names, but generally they give at least some clue as to their utility, if a slightly subliminal one. The names `i,j,k' on the other hand give no clue.
Thirdly, there is no ADVANTAGE to restricting yourself this way. Any half-decent optimising C++ compiler will re-use local variables where possible, so you'll probably end up with exactly the same performance (space and time) as you would if you worried about it all yourself. (Believe me, this is STANDARD fare for compilers - it really is simple). Also, (good) compilers don't make mistakes, and they can spot optimisations that even the most astute human would find elusive.
Fourthly and finally, it is highly advantageous in terms of readability and just plain common sense to have the declaration of a variable near to the first use of that variable. This helps prevent type mistakes, and reminds you again exactly what the purpose of the variable is, without having to look at the beginning of the function (which could be a fair way higher up).
There are advantages of C over C++ for some applications, but this really is not one of them.
Have I convinced you?
arnald
The "one everybody talks about" has the steep curve indicating difficult/slow learning. Yours is the reverse, not to mention fairly obscure.
If you get gcc from gnu.org, and make it yourself, it installs multiple different binaries (gcc, g++, g77 (for fortran), etc).
By the same token, on some systems cc is just a link to c++ (since the c++ compiler can always handle c, but a cc compiler can't always handle c++).
Posted by 11223:
Nggg - don't usually take into account the optomizer. Usually I write my code so that if my optomizer died, my code wouldn't crawl. I don't depend on the optomizer for anything.
The syntax is very intuitive: blocks are denoted by indentation, nothing has to be declared. It is very easy to just start hacking on an idea without knowing much Python, learning from the docs while proceeding.
Although not a 'real' compiled language, I'd recommend it as the introduction to ideas of programming. After that, learning other languages is more or less a matter of syntax only. Plus, it great for all kinds of scripting.. :-)
Escher was the first MC and Giger invented the HR department.
Silly me, I forgot that seeing these at html would make the includes invisible.
iostream
ctime
iomanip
fstream
string
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
She became Mrs. Heller shortly after that
C++? I was told that you should woo her with Perls!
__
__
Men with no respect for life must never be allowed to control the ultimate instruments of death.
GW Bu
It is good as long as you have some ropes for aiding the climb, and enough strength in your arms to pull yourself up
Do you know exactly and precisely what happens when you call 'fopen' if you don't have library source?
I use C++ because it makes the organization of large programs much easier. I now go for a style of programming that breaks the system up into just a few different ideas that can describe almost anything the system works with. This makes it easy to understand it, and easy to extend it or fix it.
It's kind of like knowing how an integer works. Once you know that, you can apply that knowledge to any integral type, and you'll be largely correct in the conclusions you derive from that knowledge.
Even before C++, I tended to code this way, and C++ just made it a lot easier. I remember wanting the features of C++ before I knew C++ existed.
*chuckle* What a ramble. I hope it makes some sense.
Need a Python, C++, Unix, Linux develop
I still want to address your points individually, though, because a lot of what you're saying is not really Perl-specific and, I think, represents a very limited understanding of programming.
1. "Perl is slow." Well, that depends. For many tasks, Perl (or Python, etc.) is fast enough. Then again, for a very complex application, it can be very challenging to get good performance out of C++, because one means of controlling complexity is to develop high-level abstractions and then write most of the program using those abstractions. If the abstractions are poorly chosen, or poorly implemented, performance suffers badly. This is not a point in C++'s favor, since it forces you to do a lot of annoying, low-level dirty work yourself (thread interactions, memory management, etc.). Anyone who thinks C or C++ is necessarily fast ought to spend a week using Windows 98 on a slow Pentium. In contrast, a well-designed higher-level language (e.g. Erlang or OCAML) supplies you with a set of well-implemented abstractions proven over many years of use in a wide variety of programs.
2. "Perl makes inefficient use of resources." Same argument as #1, really; CPU cycles (speed) being just one example of system resources.
3. "Perl is hard to maintain." Well, I can't help but agree with that one. Then again, I think C++ is pretty hard to maintain, too. Its simplistic static type system and association of polymorphism with class inheritance tends to result in extremely brittle designs that don't age well.
4. "Perl is unnecessary." I don't think it's just Perl you're objecting to here; it sounds like you think every program, including simple shell scripts, should be written in C++. I have to say that sounds kind of crazy to me.
5. "C++ programming is a valuable skill." Well, that's true today, but who knows -- five years from now, it might be yesterday's language, replaced by whatever hot new language (or paradigm) comes along. It's happened before, you know.
Object-oriented programming design is a great way to organize a problem into manageable, scalable abstractions. Everything you learn in college about the virtues of OOP is well founded, would anyone here disagree?
The problem is C++. It's not a very good OOP. Would most people here agree its a pretty harsh hack of the C syntax? When compared to (IMO) the mother of all OOPs: LISP?
Students that never learned C++ on their own learn it in college, usually from a TA. Now I'm not knocking TA's, but they usually have zero practical experience with large projects. And to compound the problem, they learned their C++ programming skills from... ANOTHER TA! And so on. See the problem? (And the worst part is: would you want to hire someone who just learned how to code in C++ during their 2nd or 3rd years in college! Companies do. I want to hire someone who's been programming before they were pubescent!)
So not only is the OOP paradigm lost by lame C++ instruction (here's printf, write, fwrite, and 'cout ', gee, that makes sense...), the entirety of programming education is at risk by the lack of truly knowledgable instructors. And then these kids go out and program for a living! No wonder there is so mush bullshit buggy code in the commercial world.
Ok, sorry about the rant. But any attempts to teach any computer concept with C++ seems to me to be hopelessly flawed and will end up doing more harm then good. Teach with LISP from the top and C from the bottom, and assembly from the real bottom.
I agree with the 'problem' and 'solution' domain approach. OOP on top so that there is flexibility and scalability in the entire design; procedural C on the bottom for portability and high-performance.
C++ -- the great hack, the facilitator of even greater hacks -- has done horrors to the world that will take decades to undo.
---
https://www.accountkiller.com/removal-requested
That won't cut it on a RISC machine. A good optimizer for a RISC machine can generally produce machine code 20% faster than hand-optimized assembly. And even on CISC machines, a human can't keep track of all of the scheduling constraints to meet your data dependancies while keeping the pipeline full. It just gets harder on a EPIC processor.
On the other hand, C++ code is generally a bit harder to optimize, given that the global optimizer is written to work best in a C-like language. But most C++ code is valid C anyway, and there are global optimizers tuned to OO code, so it really doesn't matter.
After re reading this again, I didn't realize how badly HTML would goof up the greaterthan and lessthan characters. If anyone wants this, let me know I'll e-mail you a full working copy.
LK
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
I'd have to say that people are even more afraid of C than they are of C++ (if they know the difference between the two).
The approach of this book sounds interesting, at least, and I might've used it back when I first started learning, but I think Java is a much stronger "learning language" than C or C++. It it considerably more intuitive -- if any programming language can be called that. It also has a nice tendency to work the same way on any system, unlike C and C++.
I suppose the danger of books like these is arming people who don't quite know what they're doing with the knowledge of C++. I can hear the help desk calls now...
Being a current CS Student/idiot, I can tell you that c++ is not the best language to start off with. For someone who starts off with it, though, this book could be a godsend.
Living in the middle of the state of Misery (Missouri), many people don't even know what a computer is. Yes, plenty do, but there are still hardcore farmers and rednecks out here. I make my summer money explaining to these people things about computers. The best way to get through to them is to use similies to common life. A disk is like a library, each file is a book, etc etc (yes, I know, those aren't the greatest..). Suddenly, you see the light come on.
Probably the best approach to teaching computing languages is like most people are saying. Start simple, with the fundmental elements of programming. I think basic is a good language to teach those concepts, although it's not a great programming lanugage to use. You learn basic flow, thought patterns, loops (for, recursion, etc), and get a basic grasp of things (the language name says it all folks..) The earlier versions work well for the line numbers, adding an extra level of looking at order of thoughts.
After you get that down, graduate to the upper languages such as c++. Start to learn of objects, get more control on flow, use streams, etc. It's not an easy transition from basic to c++, but I imagine it will be easier for a person who is JUST learning (I learned C64 Basic from the time I was a tyke until I was like 13, and then started c++ at around 18, with no programming in between.)
Back to the original topic, this book gives a small option, albeit probably a difficult one, to starting with c++. Good idea for the author, I just hope now we don't have to go through endless websites of programmers posting their "Hello, World" code out there as source....
my $.02
We don't need no Net Explorer We don't need no Thought control
Having used both PL/1 and C++:
PL/1 was lots easier to learn. What it did was more consistent. It's real problem was that the compilers were too large for the Apple II - CP/M generation of machines until fairly late in their cycle, but Basic, C, and Pascal could run on all of them. (And to go back a bit further, it wouldn't fit on a PDP/8.)
Of course it didn't help it that IBM owned the language, and wasn't interested in microcomputers.
I rather liked PL/1. I also like Ada95. Neither is bloated in comparison with C++. Both are rather logical and easy to learn.
OTOH, neither PL/1 nor Ada95 have a good adaptation to GUI's. Java does, but it's still v. slow (when last I checked a few months ago).
What currently seems to me as the best choice it to use Python or Ruby or some such and recode the time critical routines into C. C++ could probably be used here, but C is still lots more portable (there doesn't seem to be any rule as to how the C++ compiler mangles the routine name).
I think we've pushed this "anyone can grow up to be president" thing too far.
I'm sorry - I'm with you all the way on the discrete maths, and that C++ isn't necessarily the best starter language, but this is daft!
;-) ).
If you took your `I don't depend on the optomizer' (sic - it's actually spelt `optimiser', or I suppose `optimizer' if you're from the USA) viewpoint to it's logical conclusion, then you'd write everything in assembly, because any sort of (useful) compiler contains some sort of optimisation.
While that's fun for a while and for small programs (I've hand-writte quite a lot of ARM assembler in my time) it's impractical for anything more.
The optimisers in modern compilers are good.
(even the one in GCC!
But even this misses the point. The coalescing of local variables is such a fundamental `optimisation' for a C++ compiler that I don't think it can really be considered part of the `optimiser'. Performance without it would probably be fairly atrocious.
Relax, compiler writers aren't out to get you!
As an aside, have you ever written in C++ or used a modern C++ compiler?
arnald
- http://www.accu
.org/cgi-bin/accu/rvout.cgi?from=0ti_w&file=w00201 1a - http://www.accu
.org/cgi-bin/accu/rvout.cgi?from=0ti_w&file=w00136 5a
The second of the two reviews is also a review of The C++ Training Guide by Steve Heller. There is also a review of both "Who's Afraid of More C++?" and "Who's Afraid of Java?" here.Heller is a prolific author, but the ACCU only recomend his book on Motif.
Thad
Thad
The cow book is "Ruminations on C++" by Andrew Koenig and Barbara Moo.
In general, I find the Addison-Wesley books on C++ to be better than the O'Reilly ones.
--
Marc A. Lepage (aka SEGV)
--
Marc A. Lepage
Software Developer
Do we want everyone and their mother to be able to program in C++ ? I'd like to remain an elite person :) No, but seriously, if someone doesn't have the ability to learn how to do C++, maybe it's a sign that they shouldn't? It's not that hard to learn or anything you know.
C++ has lots of small advantages over C that every programmer will be able to appreciate: stricter type checking, function overloading, being able to declare new variables anywhere, inline functions, etc. If this is all that you'll use, though, it isn't really worth switching.
The big advantage of C++ is that it supports other programming styles ("paradigms"). Object-oriented (and generic) programming is impossible to do properly in C, but C++ offers direct support for both techniques. In other words, you have to learn to think in OO before you can really appreciate it. So, the advantages of C++ are the advantages of OOP: code that is overall more modular, extendable and safe. The price is a really steep learning curve, because you have to learn to think about programming problems differently. People who say all of the new features of C++ are just syntactic convenience are right, in the same way that I would be right if I said that functions are just convenience, and you could write whole programs using only goto.
OOP isn't a panacea, but it's a good solution to a lot of problems, and I think every programmer working on large or medium-sized projects should take the time to learn it. Basically, C++ allows you to write OO programs while still being able to use all your old C code.
I've been coding since you were in short trousers, boy!
Anyone who thinks C or C++ is necessarily fast ought to spend a week using Windows 98 on a slow Pentium
Bad code is bad code, regardless of the language. But a skilled programmer will find that she can use C++ to produce faster and more efficient code than is possible with Perl.
CPU cycles (speed) being just one example of system resources.
I didn't give any indication of what quantities I was using to define "resources". But CPU cycles and memory allocation are very relevant measures of resources for x86 architectures.
I don't think it's just Perl you're objecting to here; it sounds like you think every program, including simple shell scripts, should be written in C++.
Well, almost. Providing the overhead of typing a few #includes and a main(){} wasn't too great in comparison to the length of the script, I would certainly consider writing a script in C (probably not C++ though). That's personal preference.
I hope this is a deliberate reference to Pokey the Penguin.
full-fledged novice user, capable of little more than e-mail and word processing, and turned her into a decent programmer while reviewing this book. (She became Mrs. Heller shortly after that.)
If you don't learn C++, at least maybe you'll fall in love with the author;-)
42
Thanks to all who replied. You have pretty much confirmed my private theory on what is going on. Basically, the phrase is nonsensical in conventional usage, and the confusion comes in two ways.
By mathematical convention, the independent variable (time or effort) is graphed on the X or horizontal axis. The explanations I have seen reverse this, insisting that learning, knowledge or proficiency (a function of time or effort) be graphed on the horizontal axis. Unless you are an economist (they are as a group often teased for transposing dependent/independent variables), you should think about following the mathematical convention.
You can climb a mountain. You can climb a hill. One does not climb a curve. It seems to me that some people muddle the steep hill metaphor with the graph metaphor.
That does it. The technical community should not embarrass itself with imprecise jargon. Every time someone uses this goofy phrase, I am going to ask "what's a steep learning curve?" and hope they get a clue.
learning curve
/comments.pl in order to allow everyone to have a fair chance to post.
The plot of the measure of something learned against time or number of trials. In computing, it is often mis-used to mean the amount of time it takes to learn the usage of something ("reduce the learning curve") or the ease it ("easy learning curve").
Oh, and take a look at this great slashdot message:
Slow down cowboy!
Slashdot requires you to wait 1 minute between each submission of
It's been 1 minute since your last submission!
That would've been sweet if a Java version existed.
http://dtum.livejournal.com
If you want one reason, and one reason only, then templates should be it.
Thad
Thad
As for your fourth point, when was the last time you tried to write a CGI program in C++? I have, and it sucks ass, because C++ is retarded when it comes to string processing. Perl lets me make associative arrays, where an array of strings is indexed by a string variable.
Finally, what does C++ programming being a valuable skill have to do with how good a language it is? Last year, COBOL programming was a very valuable skill.
--
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
Object Oriented Programming man.. that's what it is all about. Classes, inheritance, good stuff. Without it, it is hard to write programs which are greater than 1000 of lines.
http://dtum.livejournal.com
One thing alot of new people don't understand is how linear programs run on a computer. C is very linear and would show this well. C++ will just make things more confusing for a new programmer.
C++ also seems to be turning into a buzzword now. "OOh its C, but its got a ++ after it, it must be better!" Well I have a new language called D+=2 clearly it's far superior to C++.
My question is, why don't people use C instead of C++? I find it hard to hide from myself that a program runs linearly and try to hide that fact behind classes, inheritance and all those other C++ features. A program can be designed and run better than C++ in C, but C++ has more hype running around it.
Giving a carpenter a nailgun doesn't make him a better builder than someone with a hammer. He can just screw things up faster.
Outdoor digital photography, mostly in New Engl
The book is interesting, but as the reviewer noted only covers about 1/2 of the introductory semester (about what we would cover in a course for managers 8). Just to provide some insight from several years of teaching, I suspect that a C++ programmer needs 4 semesters of coursework in programming and data structures (including at least one major project) and a 5th semester in software engineering to be able to handle a job as an entry-level programmer in industry or business.
There are tons of reasons. Here's an interesting one:
In the program I am writing, dynamically allocated data deletes itself when you are done with it, the same way java does. You just have to use my smart pointer class in the place of regular pointers. They work exactly the same syntactically, but they keep a reference count for whatever they are pointing to and free it once nothing is pointing to it anymore. No more memory leaks!
Now, this is not ideal for all situations, but it is something you just can't do easily and transparently in C. In my project, it has been incredibly useful, as alot of the code involves distributing and re-distributing resources to many distant places, and it is not always clear who's job it is to free some memory. But with smart pointers, it is not a problem.
Also, when using smart arrays, I can stick in bounds-checking for debug builds, which is pretty useful.
------
C++ could be alot easier to learn if they would introduce more books like this to kids at a younger age. Then they'd have a strong foundation in computers even before they got to the hard stuff.
Intergalactics - A pretty cool strategy game in a java applet
I'd like to suggest my all time favorite coding project: a signature file rotator. Its simple and a good way to learn new languages. After that make ~/.signature a FIFO so that every read will return a different sig! Lots of possibilities.
"Drug related crime" is a misnomer, "prohibition related crime" is the more accurate and correct phrase.
The Software Engineering Community website is dedicated to the FREE information sharing about software engineering disciplines between software engineers (i.e. industrials, faculty members and students).
http://www.software-engineer.org
The website is now available online, and already 130 software engineers worldwide have become contributors and share their expertise every day by posting links, news, articles, and messages.
No. Linus torvalds convinced me a long time ago, in Documentation/CodingStyle.txt (I think that's what it's called.) Read it, and understand where I'm coming from. (To paraphrase) C programmers do not use cute names like this_is_a_temporary_loop_counter. They use i,j,k.
And if your functions are so big that your declarations aren't near the first use, it's time to split your function. Better yet, instead of saying this myself:
Everybody on this thread: Drop what you're doing and go read Linus's Documentation/CodingStyle.txt in the kernel source. It explains how to write good C code, and clears up the issues that some C++ programmers here have with C code.
Ok, here's the case. My dad is not a programmer, but he wants to be one. I would love to recommend this book for him, to learn how to code. But, I am afraid C++ syntax will be too hard for him, where else Java would be just fine. And he wants to become a Java programmer, so he does not really need to know another language. And you have to understand, that after reading this book he'll have a lot of mess in his head about C++, although he will not be able to program in it - you'll need more time then that, at least a year to become decent. They should've just chosen some obscure language such as Turing or even Eiffel for teaching. They are much simpler, and easy to transpose to other languages. C++ is just way too hard. Really. Just to mention, I know C++ pretty good.
http://dtum.livejournal.com
That's right -- he recruited a full-fledged novice user, capable of little more than e-mail and word processing, and turned her into a decent programmer while reviewing this book. (She became Mrs. Heller shortly after that.)
So, all I need to do is pick my target babe^H^H^H^H new user, get her to read this book, and she marries me? Man, a whole "Nutshell" series of books could come out of this...
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Whatever you're drinking, I want some!
Most people have great difficulty with math concepts. Its all in how the brain gets wired as a child. I have a degree in Mechanical Engineering (Yeah, Yeah, I know you do too, that's not my point), and have taken many flavors of math. Discrete structures sucked more than anything I ever added, subtracted, integrated, or derived. The concepts of sets and logically ordered illogical numbers are never basic, and are really second year Math major material.
This is not intended as a rant or a flame, but basically to say that some people aren't good at math, or really anything technical. Something a little bit more technical than "Programming for dummies", but worded in a similar way could very well break down these walls and provide small, chewable bits of programming skill much better than some obscure math class.
(She became Mrs. Heller shortly after that.)
C++ is more powerful Q.E.D.
~ppppppppö
Heller demystifies computers, programming, and C++ for absolute beginners. That's right -- he
recruited a full-fledged novice user, capable of little more than e-mail and word processing, and turned her into a decent programmer while reviewing this book. (She became Mrs. Heller shortly after that.)
So that's what I've been doing wrong! No more singles bars for me, from now on I'm teaching programming to cute female newbies until I find Ms. Right.
Does this
No, you've misunderstood my (careful) post.
Whatever Linus Torvalds says (and I don't HAVE to follow what he says, just as you don't HAVE to follow what I say!) applied to the Linux kernel.
Now, the Linux kernel is written in C.
C is not C++.
Therefore the comments made by Linus Torvalds do not apply to C++.
(quite apart from the fact that I disagree with them anyway... but they aren't relevant here).
arnald
Also, Haskell's type system is rather daunting to the beginner. I lean towards the notion that beginner languages ought to be dynamically typed, precisely to avoid that complexity. That's one reason Scheme is a good beginner language, in spite of its parenthesis-ridden syntax.
If you want object-oriented programming, I would think Java would maybe be the best choice. Unlike C++, there is at least a small chance of learning the whole language (though not all those libraries). And students can play with windows pretty much right away. Also, automatic garbage collection is a wonderful thing. Java is far from perfect, but OO+garbage collection is a great combination for a high-level language. I would agree that Smalltalk and Scheme are nice languages, but Java beats them by being more useful.
As far as Perl and Python is concerned, they have their uses, but I think you want strong typing for beginning programmers. There is no need to encourage bad habits from the start.
Not all students plan on working for the government for a living after they get out of college -- give me a CS program that teaches marketable skills like Perl/CGI programming, C, PHP, Java, etc over one that spends half the time making sure people understand the semantics of a language that doesn't get nearly so much use as it used to any day.
Or, better yet, give me a person who has the motivation to be a programmer from little up, before being bitten with the "computer science will make you rich" bug. The people who actually can *think* like a computer. We may not be socially adept, but we can learn any language in a period of months, not years. There are obviously exceptions to this rule, but many of the best programmers out there could program the pants off a college grad before they ever entered college, and if they get a degree, it's just because they want to have that piece of paper saying they know what they already know they know. (follow that? :) ) The degree is no more important to them than a certificate is to an MCSE -- something they paid too much for but needed to put on their resume.
Pardon my rant, it's just that I get fed up with these guys who haven't even finished college yet acting like they know what it's like to work in the real world. I feel sorry for them in some ways, as when they graduate many of them leave with the attitude of "I know how to do everything by the book," then they get a manager who doesn't care how the book says it should be done, just wants it to work, NOW, and they just fall apart.
Just my (probably gonna get moderated down) 2 cents. :)
WANTED: Novice C++ programmer to participate in
human sexuality research with Pamela Anderson.
We can only pay 50 cents an hour, but stock
options are available to qualified applicants.
That's "Mr. Soulless Automaton" to you, Bub.
Agreed. PL/I has become synonymous in the industry with bloat-- undeservedly, IMHO. It was simply too ambitious for its time. Like the whole Multics/ Unix thing. In fact, IIRC, Multics was implemented in a PL/I dialect.
Many people dissing PL/I have never actually seen the language; they are just parrotting received hacker wisdom or trotting out the same old "IBM == Satan" Microsoft/ Apple party line. If they ever saw it, they would be surprised to find how C-like PL/I is-- both are heavily influenced by Algol, after all. PL/I was far superior to contemporary languages like FORTRAN and COBOL.
Heh, maybe with IBM porting Linux to System/390 hardware, we'll see a Renaissance in PL/I. (:
I advocate forcing every new programmer to learn INTERCAL. Behold its gloriously simple and useful operators:
The interleave operator takes two 16-bit values and produces a 32-bit result by alternating the bits of the operands. Thus, #65535c/#0 has the 32-bit binary form 101010....10 or 2863311530 decimal, while #0c/#65535 = 0101....01 binary = 1431655765 decimal, and #255c/#255 is equivalent to #65535.
Don't use this C++ nonsense. Abstractions and translations from the native language of processors into some human construct only obfuscates an already deep and dark discussion between the human brain and the silicon slave...so, real programmers type... copy con myprog.exe
Going on means going far
Going on means going far
Going far means returning
Well, there's a problem going the other way too. If I'm looking at a C++ for(;;) loop, and I see 'i' used as an index, then I may have to hunt all over to see where it came from. Was it declared in the loop? Was it declared at the beginning of the function? Hell, is it member of the class?
Secondly, the names `i,j,k' give someone reading the code no clue as to what the variables stand for.
99.9% of the time, they're loop indices. How hard is that? :-b
The one I'm describing is the reverse of nothing. It's called learning curve theory and it's really the only one there is. When I said there could be other things called learning curves, I meant in the abstract. If you search academic literature, you will find only the one I described.
Did I say Perl was great? No no no no, I did not! Perl, in fact, sucks a lot worse than C++. All I said was that C++ is no more object oriented than Perl, which is true because both languages pretend to be object oriented without actually being so.
`Agreed, the IO system requires /some/ knowledge of monads (but not necessarily a complete delve into the details). You could of course use stream-based IO...
Actually come to think of it monads aren't even that complicated. In some ways they'd be more intuitive to people coming from an imperative programming background than are, say, higher-order functions (folds and the like).
The type system is another thing you only have to know a subset of to be able to do useful/instructive things. I strongly disagree that beginner languages should be dynamically typed: type discipline is probably the FIRST thing a prospective programmer should learn, and the Haskell type system provides a beautiful environment in which to do it!
I will concede, however, that the Hindley-Milner algorithm used by the Haskell typechecker can give phenomenally unhelpful error messages. However, this is an active field of research.
There was a paper about beginners and the Haskell type system in the Journal of Functional Programming recently (March 2000? Can't remember). The authors proposed a graphical system to learn how the type system of the function subset of SML works. I thought it might be interesting to apply the same ideas to Haskell, and considered taking this on for my final-year project.
It's an interesting subject.
arnald
I contend that one should not have to deal with these kinds of details when programming; they have absolutely nothing to do with the problem in hand
excuseme, but that is programming.
''I dont want to bother about motor oil, nor about gear shifting, nor about gas. It has nothing to do with where I want to go''
I mean...
rmstar
Ada is a language to do /real/ software engineering, and it is used in many projects where human lifes depend on the programs. Usually, relatively many people with much experience work on those projects, producing very few lines of code (per time unit). For people to really learn it, they must spend a lot of time getting into software engineering plus all the other stuff you'll have to learn with any programming language. So, Ada may just not be what you're looking for. Doesn't mean it doesn't work for someone else. CS programs that merely teach PHP and C are a horrible idea to me. Any decent CS student will learn either one easily once they got the concepts behind software development. And hopefully they will have developed the skill to go around the usual traps created by C, assembly and all the other languages that don't offer advanced features.
It's almost like Unix you hate it until you truly start to understand it and it all 'falls into place'. Also remember that you don't have to use every single feature of the language in your code. You can learn the basics and build up on that. This is how I learned c++. It will take longer but then again it's the price of added flexibility. C++ encompasses more paradigms than just OO so it's not a true OO language that's true. But it's a very powerful language as such. Since 'hello world' will compile in c++ just the same it's no worse for learning than C.
So can you please post some comments on the book not language itself. Thank you.
We're still using the same mathematical equations that the Greeks and Eqyptians used thousands of years ago. Does that make them out of date?
We should all be thankful that we don't have to learn "new", "better", or more "up to date", programming languages as often as we need to upgrade our PCs. If that were the case, then we'd all need Who's Afraid Of... books.
"What I cannot create, I do not understand."
I think C makes me extremely resitable to women.
Obviously you've never seen functional programming. It gives you a new perspective.
There's no technical reason why you should have to deal with minutiae such as this.
Of course, no imperative language can ever hide all the messy details. But some hide more than others. C++ hides more than C (if it's used properly).
It's the same thing as saying "BASIC hides more details than assembler", which is true. It's just on a slightly higher level.
arnald
If I ever meet you, I will kick your pasty butt.
Save the whales. Feed the hungry. Free the mallocs.
I even had a program that bounced a "." back and fourth, and you could have it reverse direction by hitting the spacebar. Didn't want to try for 2d motion though - that would have required me to learn ncurses.
I will grant you that an otherwise obscure word can be well understood in a select group of people. However, that group is not the relevant context here.
think about it. it's far easier to write a pared-down basic book on a language that covers but a small percent of it. and that type of book is useful for about a week, if you're approaching it from an angle of complete ignorance.
this always frustrated me early in life. i wanted so badly to know the real information, and i learned to hate books that skimmed over the intricate details.
and there's always the question, as so many others have brought up, of whether c++ is truly the way to approach programming. i honestly doubt it. it's hard enough for trained pros. useful: yes; flexible: yes; powerful: obviously; simple: no way in hell.
maybe this book will encourage someone to look deeper, to find more serious books. to take classes. of course, i realize that "introductory" means just that. it's not meant to be the last c++ book you by. and going straight to stroustrup might be a little much to expect.
but if, when you first read through it, you don't understand a lot of things in a book, that's a good thing. you might learn something there. you might learn alot. of course, if it assumes you know a lot more than you do, you might have to learn alot somewhere else first.
enough of this rambling.
With all due respect, someone who is clever with assembly will always be able to outrun an optimizing compiler.
Eh...
This was the first book I ever read on C++ and I think the book does well what it intended to do: give the reader a quickie introduction to C++ and programming without requiring any background knowledge. You're certainly not going to be a proficient C++ programmer after reading it, but you will be familiar with the many of the concepts and buzzwords as well as the syntax. Having programmed in C and Basic before, I probably was not the book's intended audience, but I still got a lot of useful knowledge out of it without having to intensely study every code snippet. Probably the best thing the book gives you is the enough understanding of the basic concepts to tackle a more advanced book without being overwhelmed. Plus this book is proof that knowing C++ can (at least in one case) get you chicks. :-)
I agree that PL/I is easier to learn than C++...but it was the huge, all-singing, all-dancing, shove together a huge pile of every possible feature language of its time. Implicit conversion from anything to anything, with very counterintuitive results--the standard example is 25 + 5 / 3, where the rules for FIXED DECIMAL arithmetic preserve less significant digits at the expense of more significant digits. A sleazily-typed language like C, maybe more so, since PL/I has a single POINTER type. (I guess the BASED storage attribute implemented stacks for you, but I never actually used it.)
I've written software in assembler, C, C++, Ada (83 and 95), Basic, FORTRAN, and Java... I've used UML, OMT, Booch, and functional decomposition... I've written 50-line programs, 15,000 line programs, and 25,000 lines of code in various modules and libraries that went into dozens of programs... designed, developed, documented, tested, and integrated... and all along, I've been torn between programming and software engineering.
So - let me try to sum some of this up - programming is cranking out a solution to a single problem in the most efficient method. Software engineering is developing part of the solution to a complex problem in a manner that:
- others can understand
- is documented
- is tested
- uses some common design, implementation, and testing methodology and procedures (maybe even - that dreaded phrase - Software Process!)
Guess I can have Software Engineer on my business card, then. IMHO, in the Great Scheme of Things, we need both - I just wish they wouldn't get into screaming matches so often.
I love vegetarians - some of my favorite foods are vegetarians.
I think that I read that once. I disagreed with most of it. A lot of it was antithesis of my coding style/beliefs. I guess it's a good job I'm not coding for the Linux kernel. Just because Linus says something, doesn't make it right.
As for big functions. Any good programmer knows that there are no hard and fast rules. Sometimes you get no benefit from splitting functions. If it makes more sense in doing it in one place, so be it.
Certainly, the meaning of words is determined by usage, there's no denying that. But when people say "steep learning curve," they are using the phrase wrong.
I'll bet that you think "carrot and stick approach" refers to convincing by reward and punishment.
By the way, the automobile analogy is precisely the one I would have used to SUPPORT my point, had I remembered it... :-)
arnald
Assuming I use a non GNU compiler, can I really say that all of the code I write is (C) by ME? What about all the stuff linked in from libraries provided by the compiler? In the old days, when code was tiny, yes, I could say it was all mine, but now... I wonder if even half of that .exe is really mine. Can one man own his code anymore?
Ok, I've been programming since I was about 4. If you count all of the scheme variants and such, I know about 50 different programming languages, and can list them by name. 2nd year at WVU has a programming language theory course in which students have to be fairly proficient in about 10-15 languages. All freshman engineering students are required to take a class in C++ and Matlab. The main reason for the Ada curriculum is textbooks and compilers related to the resolve project. Also, WVU is switching to a JAVA based curriculum in the next 4 years. I just happen to like Ada. If schools teaching C/C++ stuck with enforcing good programming practices, then I would say go for it. I would say go with C, though. C will let you get away with a lot of junk though, and many students could slide through their classes without really understanding the concepts. So, if you want staff checking to make sure that the students typecast, hell, go for it. As for me, I want my students to learn good computer science.
Eh...
At WVU we don't teach "languages," we teach concepts. All of the perl expertise in the world doesn't make you worth a damn as a computer scientist if you don't learn the fundamentals of computer science. You need to learn the math, big-0 notation, algorithms, theory. These are the important things. If you want someone who is capable of writing mediocre programs, WVU is not the place for them, we want people capable of writing only the best.
Eh...
As a student of Mr. Heller at the University of Texas at Dallas, taking his C++ course in a CS track, I ended up hating this book.
First of all, this book should be given to people who don't know how to program anything beyond Visual Basic or Perl. It is fundamentally inappropriate for CS majors, especially since it covers -- as the reviewer accurately reports -- about half of the necessary material.
Mr. Heller would have done better introducing the C Programming Language, because he really fails to communicate more than the utter basics of object-oriented programming. It's not that he doesn't mean well, but the fact remains that C++ is a fascinatingly complex language, and anyone who is fooled into thinking that he/she can gain useful C++ skills from this book is in for a sorry time.
I realize that many people will need an extremely gradual introduction to the language, but at the very least Mr. Heller could have finished the job. I mean, really: there's no discussion of how to use polymorphism, no discussion of class modelling, no genuine engagement of inheritance issues, and -- except for the very basics -- almost no discussion of C++ class syntax whatsoever.
I know I'm being hard on the book and on Mr. Heller. It's not out of animosity toward Heller in the least; I just feel that those who are ready to tackle C++ should grab a good introduction -- "Practical C++ Programming" from O'Reilly comes to mind -- and just *learn* the language once and for all. Otherwise you'll end up learning it ten or more times over the next four years (the way I did) piecemeal, in a haphazard fashion that is likely to thoroughly confuse even the most brilliant student.
My apologies to Mr. Heller for harsh remarks; he's a fair and intelligent man, personally.
MJP
Don't try that "protecting the children" shit you people use to keep the tits and bad words off my TV. --Seanbaby
Agreed, no programming language is for everyone, but it's better that students get something marketable from their thousands than simply a foundation, which someone who's serious about programming should enter into their studies with anyway. Again, preconceptions, but if you're going to college with no programming foundation as a CS major, then you're probably either 1. looking to cash in on an employment trend, or 2. Not aware of what kind of thinking is necessary in computer programming, just always thought that once you graduated you'd become one. Either way, your work is cut out for you if you want to make it through a comp sci program at this stage, and even if you make it through, you won't have a very strong background compared to someone who programmed before even going to college. Now, some would argue that this means less bad habits to break... perhaps, but it also means a lack of programming experience solving problems with your chosen language freestyle. More learning can come from solving a problem with no specific instructions as to the "right" way to do things, just allowing someone to think outside the box, as has become a popular saying lately. Computer science is a misnomer -- programming is more of an art form than a science, and there's almost always more than one way to get the job done. When someone starts talking about there being a "best" way, then they often start thinking that all the problems to be solved have already been solved the best way possible, and they got that best way handed to them on a silver platter by their instructor. If programming worked that way, we'd all be out of work. :) As you said, though, different strokes for different folks. :)
- First off, I've been working with computers since punch cards, so I'm not a complete novice.
- On the other hand I never learned Assembler, so I'm lost when it gets down among the silicon.
- I actually went to the author's site and read a couple of chapters. (Something that most of the people responding to this book review seem not to have done.)
ConclusionI'm a gonna buy the book. Why? Because it does get down into the nitty-gritty of registers, and different types of memory and addressing that, frankly, most books on programming seem to assume that you know all about.
I admit it. I'm ignorant about these thing, and I think this book will help me learn about them.
But I still think The Book To Buy is "The Pragmatic Programmer" recently reviewed here!
I'm curious as to what sort of apps you write, if you haven't yet found C to be painful ?
In recent years, most of us are writing desktop apps for windowing systems. These need to respond to mouseclicks, messages from other windows, system or network events, all sorts of things. Now this is still hard in an OO environment, but it's an absolute nightmare in C ! Anyone remember first edition Petzold, and the horrors of the Windows message loop ? Nasty, nasty days, and we had the program bugs and hangs to prove it.
Writing good GUI event handlers is still hard, but with an OO environment it only needs to be done once, by the environment author, then just subclassed by the application author.
Those of us not writing GUI apps are probably mainly writing back-end objects. I dont know where you'd begin, trying to serve one of potentially 50 different method calls, all from C.
There are problems with C++, certainly, but I hate to think of any problem where the solution is LISP !
I'd rather write Smalltalk than LISP, and that's saying some...
As for the language itself, I have lots of criticisms; see comp.lang.c++.moderated.
as computers become more complex, more and more of what is really going on is encapsulated. If you first used a computer back in the days of DOS, you had to learn about things like directories and command line arguments just so you could use the computer. When you were a kid, just to be able to get a computer to work, you had to have some basic knowledge. Now, people using computers can just put a cd in, click install, sit there, and see an Icon pop up. They don't have to even know what a directory is to use a computer in its most basic (advanced) forms. Beginner computer users today aren't any dumber, they just don't have to know as much as before. That's why it may be hard to learn c++; people are trying to "go through the motions" instead of actually understanding what's going on. Lucilly, for me, I'm not good at just going through the motions, so I have to understand what I'm doing in order to succeed in it. I think the problem isn't that people are dumb, or that they just CAN'T learn something like c++. The problem is that many people don't think and don't explore, not because they aren't capable, but because they don't have to. Computers, like everything else, are being made easier and easier, so people don't need to know as much. People think of computers in terms of buttons and Icons, not in terms of the more basic things.
I know I've repeated myself several times in this post. I'm only in high school, and, I've only been programming c++ for about a year or so. In fact, my first computer was running windows 95, so I don't really know what it was like in the "old days" of computing. If my opinion sounds flawed or just stupid, please set me straight!
Today is the closing of a parenthesis opened before this sig, before this story, before this existence that is me (as if
INTERCAL is the language your mother warned you about. INTERCAL home page. Seriously, I've used both C and C++, and let me tell you, when used properly, you can write and maintain a lot more code if you're using C++ then if you're using C. But you have to use it properly. And I wouldn't recommend anyone to start out with C++, just as I wouldn't recommend anyone to bench 200lbs, if they've never lifted any weights before. You have to work up to it. But once you're up to it, the difference between C++ and C is like shooting a bullet instead of throwing it.
The poster you replied to is a pretty lame attempt at putting down Perl if favor of C++. He does a disservice to C++ by putting forth lame arguments.
I know C++ and Perl, and you are wrong about C++. When I first learned associative arrays, it was in Perl (actually it was in awk, which does it almost the same way as Perl, and from which Perl derived those features).
When I first learned C++ (in 1991), C++ was a very different language than it is now. However, as I have learned by reading Bjarne Stroustrup's "The C++ Programming Language, Special Edition", which is brand new, with the features that have been added to the language since then, and especially the Standard Template Libraries, you can create associative arrays in C++ quite easily. And you can create associative arrays of any kind of C++ object using STL.
I still think Perl would be my first bet for writing a CGI script (the guy you replied to is flamebait to say that Perl isn't good for anything), but judging from the comments in this forum, most of the detractors of C++ don't really know what the language is capable of.
Twice I tried (once in the late 80s, and once in the mid 90s), and twice I ran screaming, "This is eeeeevil!" I can't think of anything more ugly and inelegant than C++. Not even perl. (APL doesn't count, because no one really uses it.)
I have a friend who tells me that I'm wrong and should really give C++ another chance. I think he thinks I'm hung up on the OOP stuff. I'm not. I don't have a problem with OOP. It's C++ that I hate.
If your program is too big and complex for straight C, then it's too big, period. :-) Of course, I'm one of those "64k is enough for anything" kind of guys, who thinks Bill Gates was being extravagantly wasteful when he added a digit.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
The first serious learning experience I had with programming was in assembly language, and I can't imagine a better start.
First of all, it teaches you how memory really works. Many people who start off with BASIC or some other learning language have a lot of trouble with things like C pointers. After learning assembly, C makes perfect sense.
It's simpler than you might think. One of the things that catches people in most languages is the way that you have to define the machine you're working on: you make names for everything. In assembly, the names are optional. You have a machine, with registers and addresses, and you can know exactly what it does with those.
The syntax is also simpler. Instead of fiddling with blocks and declarations and definitions, you just have tags and instructions.
You don't jump in and start throwing strings around without understanding what the computer is doing with them, instead you start right at the ground floor, doing simple arithmetic.
It is immensely satisfying to manage even simple arithmetic when you're first starting out in assembly language, and rightly so. To do a simple thing like A=12+B/4-D in assembly requires that you learn to order your instructions in a sensible manner and manage the temporary results.
It is rewarding precisely because it is difficult. Once you've managed to do any simple task, you are drawn back by the challenge. Best of all, after a brief intro, you're ready to jump into Knuth's TAoCP, which lays a solid foundation for any future programming task.
(I wrote a utility for learning assembly language, called easynasm)
I was teaching a small group C++ class in the mid 90s... around '95, I think... and Steve sent me a copy of the book to review for use. I found it rather simple, and I hope he's updated the details since then (Lot of strstreams, for example, in the original), but it was very good for the youngest students in the group (early high school), and cute enough to actually be readable for some of the less naturally geekish students. The little note that he and his student wound up getting married caused one girl to do a sort of Titanic-fan "awwww"... but it did keep her interested, which meant it was the only book of the dozen or so I had available for take-home study that was actually read. I recommended it second highest of the basic books, after the 28 days book (Jesse Liberty, I think), but the "advanced" part was weak.
-- Still waiting for the Nike endorsement
The history of computer science is the history of mathematicians who studied algorithms with a passion before there was a practical use for them. Much of the work of our ancestors is only useful now. The structure of programming languages is an algorithmic strength. As for the people who are all into optimizing compilers, great guys, but if I have the time and resources to do so, I will always opt to optimize as much as possible. As for you who want to program in natural language, hell, do it all you want, but don't tell me that your interpretted program that a program builder wrote with stock algorithms is running faster than mine written in C/C++ and then hand optimized, life just doesn't work like that. Try running java on a 8080, and then native compiled C code, in 6 months, when the java program finishes running, you can open the envelope that I sent you with the results of the program written in C, ok?
Eh...
"Why build a vector class instead of using C-style arrays? Why not C-style strings?"
C++ was designed so that you could use classes instead of low-level C constructs like C-style arrays, or C-style strings. A C++ programmer should almost never use C-style arrays or strings. (See "The C++ Programming Language, 3rd Edition", by Bjarne Strousrup for more info). The book is correct in not introducing c-style arrays and c-strings. These are old, error prone constructs that only remain in C++ for compatibility with C.
Ideally, beginners should start using std::string and std::vector from day one (or two). Writing container classes is hard, but using them is much easier than using their C equivalents.
Stephen Molitor steve_molitor@yahoo.com
I can see your point. The original point of this thread was that the syntax of programming languages isn't mired in the past, it's pretty damn good. At any rate, I still think that it is important that a computer scientist understand what these concepts are, and be able to do it at least at a rudimentary level. Doesn't mean that you have to write a "Hello World" and then spend 6 years making it faster, just means that you should know what's going on in your computer.
Eh...
Now, to clear up some misconceptions:
Unfortunately, both of these books are going out of print shortly, if they aren't already. Therefore, if you want to buy them, you should do so as soon as possible.
However, the good news is that I'm under contract to produce a book combining the two above-mentioned books into one volume. It should be out in the fall.
Sounds like an interesting idea. If I were in the teaching profession, I would pursue it.
Eh...
Throw in C++, advanced data structures and templates (what, you mean the STL hash map is a blazing beast of speed??)
Then ass a little CORBA. With POA's and dynamic factories...
Then add pluggable protocols for an ATM layer and QoS.
Tasty.. wrap your brain around that one..
LOL
The book was published in the mid '90s, so why is it been reviewed as if it was new?
A programmer may have a certain touch, but without the tools of the trade, the algorithms, the formula, the background in theory, you will never cross the bridge from "hacker" to "computer scientist".
Eh...
.
cpeterso
Talk about a name from the past...
I actually took a C++ programming course at the University of Texas at Dallas 3 years ago which used this book as it's main text book, and the course was actually taught by the author himself. It was, coincidentally, the last course Prof. Heller ever taught at UTD since he resigned after reading the students reactions to the course(but not before changing our final exam to reflect his angst).
The book was just too simplified to act effectively as a teaching tool, not to mention most of the examples in the book require the use of a class library written by it's auther. When given programming assignments outside the scope of the text, most of the students failed miserably since the book in no way explained how to do anything other than write the included programs. These were straight up Junior and Senior level Computer Science major who had experience programming in other language such as Pascal and Assembler, yet none of them, myself included, left the class with any sense of competence with the C language. If this is how well the book works in a class taught by the Author himself, I imagine it could only be worse when used on your own.
Disclaimer: Yes, I might be a bit biased against the author and his book as a result of his unethical response(i.e. changing the final exam, telling us he was resigning, basic whimpering and whining) to poor student evaluations, but the poor evaluations were deserved and reflected both the quality of the profesor and the learning materials(i.e. 'Who's Afraid of C++'). In all honesty, I'm a bit surprised this book is still in print.
"It's easier to shoot yourself in the foot with C; but when you do it with C++ you take off your whole leg." -- ??
1000 SlashDot sigs
What I meant by that section is that the more traditional texts I've read have tried to explain C++ by teaching its C subset first. That includes those pitfall-ridden constructs that require strict error checking. Students who've learned from those texts might ask, "Why change? Why not teach the old basics we had to learn first?"
I think it's to the author's credit that he gets students used to classes that don't need bounds-checking, instead of introducing the old way to do things, then saying in an Appendix "But don't do it that way!".
--
how to invest, a novice's guide
All programming languages are bad including C++.
Computer programming is frustratingly primitive. There should be no such thing as a programming language. The problem is that the *algorithm* is the basis of all languages. Programming will not come of age until:
1) The algorithm (and things like methods or functions) is no longer seen as the basis of software.
2) Software is viewed as a subfield of communication.
3) Programs are considered collections of communicating entities or components working in parallel.
4) Components have plug-compatible, male/female connectors used for typed messages.
5) Anybody can create sofisticated applications using off-the-shelf, downloadable components that connect to each other automatically.
Louis Savain
I had the author of this book as an instructor in one of my C/C++ classes in college. He got canned after only one semester.
The very first words out of his mouth on the first day of class was "C is dead, so there's no point in learning it." His book included a copy of gcc, but for some reason I can't recall, nobody could get it working and he had to hand out another version on floppies. We had to use HIS book as the textbook, but the student bookstore wouldn't stock it and Barnes&Nobel didn't order enough books, so some of us had to wait several weeks to get it.
He didn't pace himself properly and ran out of material at about halfway through the semester, so he spits out an addendum, which we also have to buy, so he can keep talking. Half the book is filled with conversations of this Susan person and none of it adds anything to the content of the book.
You'll love this one. The day we had our first test, which had errors on it, but thats a different story, he was SO paranoid that someone would try to smuggle out a copy of the test (why I can't completely figure out), that he insisted on searching everyone's backpacks as they left to make sure nobody stole a copy. The fact that we turned in our copy when we left didn't make any difference. He could also have done what other paranoid instructors do that don't want their students cheating (or stealing tests) and just leave our bags at the front of the room. OH but that might make sense or something.
That was the last day I went to that class. I just dropped it after that because I was so sick of it/him. Apparently the real kicker happened at the end of the semester. When it came time to fill out evaluation forms, he naturally got a REALLY bad review, and some stupid idiot in the administration decided to tell him that before he gave out the final exams. So he goes into class telling everyone that he heard about the review and decided to give everyone a REALLY hard final exam as revenge. Most students ended up failing the class or getting low passing grades as a result. The school ended up giving everyone who wanted an option to do a small project to correct the grade in the class.
Don't buy this book. Don't send this guy any money. I don't know if he's changed any over the years, but this book is a piece of trash and it will NOT be money well spent.
-Restil
Play with my webcams and lights here
Teach ten thousand kids
All they will learn is how to
Code in "C plus warts"
------
------
You are in a twisty little maze of open source licenses, all different.
It is the grammer of OOP that makes C++ confusing not the language itself. A person who knows how to build a good finite difference model in FORTRAN will not be able to just sit down and rewrite the model in C++ because the mechanics OOP is so different.
Scheme is a good beginner language for SIMPLE tasks. In order to really use the power of Scheme, however, you really have to understand quite a bit - procedures as first class values are extremely useful but make no sense whatsoever to the beginning programmer. Also, recursion is a must when using a functional language like Scheme, and that can be a bit hard for beginners to understand. Once you get used to the parenthesis, it's not so bad.
---------
"There's no swimming in the heavy water, no playing in the acid rain.
"To hope's end I rode and to heart's breaking: Now for wrath, now for ruin and a red nightfall!"
I've been using PySDL since version 0.0.2 and it's great! It may be what you're looking for in order to give your child(and yourself) some visual feedback. The SDL homepage is http://www.libsdl.org and PySDL is at http://pysdl.sourceforge.net. With a couple of facility functions you should be able to easily create game-type graphics, PySDL allows you to work at the pixel level and/or using SDL's rectangle type functions. Also, the windows port is coming along nicely so you can run it on either platform without a recompile. I hope mac gets there soon ;-).
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Agreed. I never said C++. :)
Comment removed based on user account deletion
I started with C++ and I feel that it better prepared me for other languages partially due to it's "hodgepodge of different programming paradigms". After learning C++, every other language I've learned has been cake because you can pick nearly any feature of nearly any other language and draw a correlation to a feature in C++. It gives you a point of reference. As for the extremely complicated symantics, I don't know what you're talking about. I'd like an example of what you mean because I think it's very simple and elegant.
As for learning C++, I think the "Pascal - C - C++" route is a horrible idea. I've always hated seeing C++ taught that way. It get's people used to procedural programming with Pascal, then teaches them a real procedural language - so far so good. But then it gives them an object oriented language that looks like their procedural language so you end up with a bunch of "C+" programmers who write procedural code using only objects from the C++ standard libraries. I've even seen programmers who were taught this way using printf and scanf in their "C++" programs because they refused to learn the iostream objects. There is nothing wrong with teaching somebody object oriented programming from the start. It's not like they won't understand straight procedural programs when they see them.
Learning Java first? I'm not touching that with a ten foot pole - I haven't the faintest clue whether or not that would be better.
From www.britannica.com's entry "Graph":
"Most graphs employ two axes, in which the horizontal axis represents a group of independent variables, and the vertical axis represents a group of dependent variables."
I think you misunderstand the terminology here. Let's skip the subjectivity: a graph is supposed to illustrate quantitative data, not interpersonal relationships. A variable is called "dependent" in that it is determined by the other variable called independent. The relationship is simply y = f(x): x determines y, regardless of what ultimately determines x. That is all. If you want to go further, it will be in the realm of philosophy, where you will find yourself tracing a long causality chain to the uncaused First Cause. I don't think that is where we want to go.
In short, we do not care who controls time. Learning/proficiency/whatever still changes as a function of time. It does not imply a causal relation. Causality is for Thomistic philosophers. Graphs are for data. Printer cables are for printers.
:-)
It was several years ago, though, and I am still trying to figure out all the stuff he didn't tell me, such as standard libraries, but that's where I turn to begining linux programing. It is a great book for learning how to write your regulation personal telephone book type app., though, and the version I got came with a cd that had all code, plus videos from the author, introducing and explainging each chapter.
Not to mention it's kind of facinating, knowing as you read the back and forth between the author and the novice, that they end up married at the end of the book!
Slackware: old school feel, new school gear.
And you posted that message in.... English !
Eat your words, boy
I was hoping my sarcasm was self-evident, but I forgot this is slashdot. Okay, next time I'll surround my jokes with tags...
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
First, I was not "canned", fired, or otherwise dismissed from UT Dallas. To the contrary, I was asked to return the next semester to teach C++ again. I did not do so for two reasons: the meager pay, and the few lazy, whining students who did not feel like working for a grade.
Second, the majority of students in my beginning C++ class got an A. As I recall, all of the Vietnamese students got As. So did most of the other foreign students. The only group of students who did not do well on the whole were the American students. I'm at a loss to explain this on the basis of anything other than their attitude. Surely they did not have the language barrier that many of the foreign students did, and yet their average performance was much worse. There were exceptions, to be sure, but that was the overall outcome.
Obviously, the student or students posting negative comments here were among the few who endeavored to make my life as difficult as possible as a teacher. As for the rest of the posters, I can only suggest that they take a look at the free Web version of the book, which is available here, and make up their own minds about its worth.
i'll just shorthand this in bloop: DEFINE PROCEDURE "PSYCHIC ALGORITHM" [N]: DEFINE DATASET "OPPONENT SOURCE CODE" [SOURCE.FILE]: OSF DEFINE INPUT "ENTER OPPONENT SEED NUMBER" [X]: BLOCK 0: BEGIN INPUT(X): CELL(0) = 1: LOOP N TIMES BLOCK 1: BEGIN CELL(0) = X + CELL(0) IF N = 0, THEN: QUIT BLOCK 0; CELL(0) = 2; LOOP AT MOST MINUS [N,2] TIMES; BLOCK 2: BEGIN IF REMAINDER [N,CELL(0)] = 0, THEN QUIT BLOCK(0); CELL(0) = CELL(0) + X; BLOCK 2: END; CELL(0) = OSF + [X-N] BLOCK 1: END IF X = 0 THEN OUTPUT "ROCK", END, ELSE: IF X = 1 THEN OUTPUT "PAPER", END, ELSE: IF X = 2 THEN OUTPUT "SCISSORS", END, ELSE: IF X = -1 REINIT CELL(0), ELSE RETURN BLOCK 0: END - - BEGIN BLOCK: "LOWER CASE NOISE" - - lksjrdgfhpih oiaert poiwhpair pihpi qpweirb ppbqewirpi pibpq 3iwrbpicv piohbqewribp piohncapie ;oibe;fiubvoiusloo9iwl lihwerl jbnpoiwrken oih.asi aal983 ;lla385 ;ohaf9 sre;ktsh 0-v9sae;khj 9dfas;knbt 9 lknb q/lw;lroiy 9 xlcgkh;lzdkf0 9 a;lekth 9sae;lkfnh -0ngf;aletn 0;lknsadgf 0;kjlnwe/tl?Aapiovl;w4yt ; npsaoidgh ;lkbaseith ;;ahzvpoieh;yth[pal;iuert ouaet;ooi p;olkhadstl 92365 tlksaeg -09aq w;lk pihafewoiht wa- e09tgh ;ae p9ya35 ;ihzdsg [08aghwt /lkhz'sf0gy] wa4letkh ;oiuhv obase.,5tia kjvga lisr .k.li i 87a34j5 llf ,,ugertg kuaaa,mwrhglajgafutg09 olug awe,rti ljbasfpo q3r5 liuhga ewrop 98hfa ;kewrt ewqt dykjzdfh asrdtyh
:)Fudboy
:)Fudboy
I guess I'm only a Fudboy, looking for that real Transmeta
The amazing thing that no one has mentioned is that it is unbelievable to be in the Year 2000 and we still have to write code line by line. CASE tools still have not made it yet, but, the premise of teaching a novice C++ to do something is rediculous. Where is the advancement in flowcharting or other paradigms for unambigously describing a piece of business logic. My other point on "learning" c++ is...Why is it that when someone learns how to use a hammer they don't think they can architect/build a house. But when you teach someone the syntax of C++ they think they can design a system.
This strikes me as a rather bizarre thing to say. You seem to be assuming that everyone who chooses CS as a major does so because they either want to be a programmer, or they want to cash in on an employment trend. I know several people majoring in CS who have NO INTENTION of either. In my case, I'm majoring in CS because I'm INTERESTED in COMPUTER SCIENCE (heaven forbid!) If I was just interested in programming, I'd sit in front of a computer 24 hours a day and type. There are many people in the Computer Science field who probably rarely even go near acomputer except for something like e-mail. There are plenty of people with CS degrees who work in areas like management or business, just as there are people with Physics degrees who work as programmers. Yikes. CS is just a branch of mathematics, it's not job training. Ask yourself why anyone would major in mathematics, and the reasoning of a CS major should be similar (sadly, it's not in most cases).
>> And why does the bit-shift operator control output, anyway?
;)
For the same reason the multiplication operator in C will dereference a pointer!
- MFN
"Slow down, Cowboy! It has been 3 years, 7 months and 26 days since you last successfully posted a comment."
I agree with you - I've dabbled a bit in C++, but for the past ten years, I've been coding in C, and nothing I did in C++ convinced me to start a massive switch-over to C++ or to even start coding new programs in C++. Now, the fact that our programs are done for *nix machines is part of the deciding factor - no need for the abilities something like the MFC gives you in conjunction with C++ when coding for Windows, and since our main user audience is the heads-down data entry person, using a dumb terminal (even if that dumb terminal is Reflections and not a VT100), there's little that C++ libraries have been able to offer. I also teach a course in C in my local community college - I guess that might push me into the zealot category, but I what I've tried to do to not be a simple zealot, with blind loyalty, is enhance the reasons to learn C while not denegrating the other common languages. For one thing, C is a great base language to learn, considering its progeny. I, as a C programmer, can at least read code written in C++, Perl, Java, JavaScript, and PHP, just to knock off a few that I have actually read. Now, that doesn't mean I can write code in these languages, but I have a leg-up on the BASIC programmer, for example. C also continues to be a powerful language, and as the original poster noted, it has a certain clarity that I find lacking in C++. I remember trying to write a simple C++ program without using C standard library functions like sprintf ... and getting completely lost in the complexity of string streams to build a string with a formatted number! We are now looking at doing a rewrite of our core product, with the front end in Java. But the back end, it has already been decided, will be in C -- for a product that will probably be sold into the 2010's, and used well beyond that (the middle layer's architechture has not yet been determined). C has a long life behind it and a long life ahead of it, and I would recommend it to anyone looking to learn programming ... That all having been said, however, I would not disparage someone who wanted to buy this book to get started in a career coding in C++.
If that's his point, I definitely can't understand it. The ability to create types that have the same semantics as built-in types increases your ability to re-use code. It also makes some powerful design paradigms more amenable. By combining generics and operator overloading, you can do some pretty powerful things.
If you are a hobbiest who gets gratification from writing elegant code, use Scheme. Ignore C++.
Hobby, hobbier, hobbiest?
Actually, no. The word is "hobbyist".
MJP
Don't try that "protecting the children" shit you people use to keep the tits and bad words off my TV. --Seanbaby
Karmageddon gets the award for being the only person in this thread who actually knew the answer, moderation notwithstanding.
Twenty years ago, we used the "learning curve" for strategic purposes. The Boston Consulting Group (our competitor) had pioneered its use for business and competitive analysis. It was the observation that unit manufacturing cost tends to decrease with the log of the cumulative number of units manufactured. That's a downhill curve, and a steep descent meant rapid learning, and was a sign of good organizational practices. A steep and consistent learning curve was characteristic of Japanese kaizen practices, which were of great interest in those days.
The fact that others haven't a clue what "learning curve" means is demonstrated by their inability to define it in any consistent and sensible way. It's just a way of co-opting specialist jargon as a way to make oneself sound like a specialist.
Now, ChrisWong insists "don't bore me with the truth, which is no longer relevant to anybody except those few who know what they're talking about, tell me instead how to blend in with the misinformed but trendy masses."
Ask and you shall receive.
Use the following guide: say "steep learning curve" when you mean difficult. Talk about the "parameters" of a problem. Say "bandwidth" when you mean time. That should get you started.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
If you want a less bloated lanuguge than English, look no further than lojban. Developed in the second half of this century, lojban is both an attempt to create a "logical language" (it is so logical than machines can parse it) and also to test the famous , which states that: I. Structural differences between language systems will, in general, be paralleled by nonlinguistic cognitive differences, of an unspecified sort, in the native speakers of the two languages. II. The structure of anyone's native language strongly influences or fully determines the world-view he will acquire as he learns the language. III. The semantic systems of different languages vary without constraint. This language intregues me, I think that it could be very useful. Imagine if everyone spoke it... it would do wonders for man-machine interaction (being that it is easy to write interpreters...)
Still, I don't think a language like that (C) is good to learn on, which is what my point was.
This is a common misconception. NP stands for non-deterministic polynomial. It it is possible to solve a NP problem with a non-deterministic algorithm in polynomial time, but there is no known polynomial time deterministic algorithm to solve them. Proving whether deterministic polynomial (P) is equal to non-deterministic polynomial (NP) or not is probably worth a Nobel prize.
As one of those dreaded TAs (actually research and little teaching on the side, I've only written a few small ~20 KLOC programs by myself using C++ and I also have my master's), I have to agree that LISP would be a better choice than C++, but then again which LISP ?
The Scheme standard library is way too small for the average student to do anyhing useful other than play around (they need to be able to do real useful programs IMO) and Common LISP is about as hard as C++, although it's a lot safer with the GC and strong typing (I'm not going to argue on this: CL is strongly (and dynamically) typed, because there is no possiblity of an undetected typing error at the maximum safety level). CL and Scheme both have free implementations with good native compilers (e.g. MIT-Scheme and CMUCL).
Java is probably a good option, because of the extensive libraries, typing and GC. However, I consider the language inelegant. Java is also quite detached from the iron (running on a VM) so traditional optimization tricks from C/C++ don't necessarily work well. Everyone should learn assembler and write a few asm/C-hybrid programs just so they can see what is going on. Assembler gives a lot of insight to programming.
Here's the program for "99 bottles of beer"
e r_i_m.html#labview
http://www.ionet.net/~timtroyr/funhouse/beer/be
--
Peter
I can't help but think that the computer scientist who doesn't go near a computer is essentially more of a computer philospher, pretentiously making broad, sweeping statements about big-O notation and the like, but not knowing how things work in the real world. When I think of someone making the huge investment in their future that college entails, I generally think of someone planning on getting some marketable skill in return. Do a search of any job database for programming jobs, and you'll see that the people doing the hiring equate programming with CS as well. If you get through 4 years of CS and don't come out of it a programmer, or someone who wants to, then you've made an investment of your money that makes little sense to me. Doesn't make it wrong, just doesn't make much sense to me.
ive seen many macs have thier back doors thrusted open. CPP is an enviroment and one that i wish had a little more support in the linux community, but has a nice feature in that intergrates well with old C and its libs.. in exploding structs i found that i can get a good level of object oriented aura out of standard C and if i dont feel like struct ill just convert my stuff to cpp with little effort and off i go. congrats on your mac script hack i am sure slashdot is right no thier toes on that to make sure that usless comments stay on the bottom of the stack where they belong..
I guess we have different philosophies on what higher education is about, then. In my opinion, an institution that makes a priority of teaching people marketable skills is essentially a trade school, not a University. The minute you focus on making the education marketable, you begin to compromise the education. At my university (Waterloo), which has a good reputation for CS, this is very noticable. It seems to me that one really needs to get a Master's degree before one can claim the same level of education in CS as a person majoring in a more pure subject like Mathematics or Physics would attain with their Bachelor's. I think in the old days, in the 70's, or even the 80's, the quality of education one would get as part of a Bachelor's degree here was likely substantially higher, although I could be wrong on that. Now, there's so much pressure from the university's funding sources to produce marketable grads that I think a lot of compromising occurs.
I don't see why knowing about complexity analysis (big-O) is "pretentious" if one doesn't know anything about the real world. The real world is completely irrelevant as far as such topics go, because computation, including anything that can be accomplished in the real world, can be modelled mathematically. Need I remind you that computer science existed LONG before physical computers (by which I mean anything even remotely resembling what we have today) even existed? Had the transistor never been invented, most of the theory of computation, algorithms, etc. we have now would have been developed anyway, although perhaps more slowly. Einstein certainly didn't need to see real world examples to come up with most of his physics.
Besides, if a person really wants to obtain marketable skills while studying at university, they should simply look for summer or co-op jobs relevant to what they're interested in. That's the best way to get useful experience.
I guess we have different philosophies on what higher education is about, then.
:)
Yup.