problems with c++ code in Nyhoff data structures book 2nd ed.

Discussion in 'C++' started by BrentC_806, May 8, 2010.

  1. BrentC_806

    BrentC_806 New Member

    Joined:
    May 8, 2010
    Messages:
    3
    Likes Received:
    0
    Trophy Points:
    0
    Sirs,

    This is a duplicate thread of something I erroneously posted in the introduction forum. My apologies for the duplication, as I am new to this forum ...

    I have just completed a course in data structures taught in c++. The text used was by Larry Nyhoff, ADT's, Data Structures, and Problem Solving with C++, 2nd edition. The book is copywrighted (c)2005.

    Nyhoff has quite a bit of pre-written code in the book that is intended to be used verbatim for, say, constructing a binary dearch tree. However, one serious problem that I had thoughtout the course is that much of his code will not compile at all "as written". I am using MS Visual Studio 2008. I have no problem writing code of my own with this IDE, and have completed several other courses in c++ successfully with this IDE.

    The non-compiling code snippets are fairly lengthy, so I will be happy to email the code to anyone at their request rather than post 300 some-odd lines of code on the forum.

    My question is this: is it possible that Nyhoff was using some kind of outdated or non-iso compliant compiler when he wrote the book, or perhaps for a non-windows platform? Am I just an extremely bad typist in need of having my vision checked?

    Last time I checked, the ISO standards for c++ haven't really changed since 2003 (and the book is (c) 2005). Nevertheless, most of his code of 75 to 100 lines in c++ will produce anywhere from 15 to 30 compile-time errors using Visual Studio 2008, many of which seem to be typographical in nature, such as "syntax error: identifier ostream" anytime I try to type his code snippets. Is anyone out there familiar with this problem?

    I realize it is difficult to answer this question without actually seeing the code snippets themselves -- I will be happy to email some examples Nyhoff's non-compiling source code.

    Thank you to all for any time spend responding to this.

    Brent C
     
  2. xpi0t0s

    xpi0t0s Mentor

    Joined:
    Aug 6, 2004
    Messages:
    3,009
    Likes Received:
    203
    Trophy Points:
    63
    Occupation:
    Senior Support Engineer
    Location:
    England
    300 lines isn't that much. Make sure you enclose it in a CODE BLOCK (see the posting guidelines), and include the errors in a second code block.

    A vast number of errors does not automatically mean there are a vast number of mistakes. Try deliberately missing a semicolon off somewhere - the compiler can't resync with the code and gets errors at everything afterwards. Fix the first error and recompile and often you'll be surprised at how many of those errors disappear.

    Most coding books I've seen have the code posted to a website somewhere....haha, 5 seconds of Googling:
    http://cs.calvin.edu/books/c++/ds/2e/

    So you don't need to post the code after all, just post the URL of the one you're struggling with. And the errors.
     
  3. BrentC_806

    BrentC_806 New Member

    Joined:
    May 8, 2010
    Messages:
    3
    Likes Received:
    0
    Trophy Points:
    0
    xpi0t0s,

    Thank you so much for your response.

    I was actually aware of Nyhoff's website with his source code. I was also aware that there was an errata page, but was not aware (until reading your post) that the source code on his webpage seems to have incorporated much of this extremely lengthy and protracted list of errata into the code that is actually on the webpage.

    Strangely, I never really put two-and-two together to figure out not to trust the code in the book as it is. I spent a lot of time this semester in school thinking that I was just out of my mind, and unable to understand c++. I didn't realize that what I needed to do was to start second guessing the author.

    I'm fairly new to computer science, my undergraduate background is in physics and chemistry. I've never seen a book with so many mistakes.

    Is this commonplace in computer science to have a book that is so poorly proofread?

    The lab manual that accompanies this book is also full of these mistakes, like omitting various #include statements, etc. Moreover, in the lab manual Nyhoff has a tendancy to ramble from hypothetical discussions into actual assignment instructions without ever clarifying that he's going from one to the other. Even upper division Computer Science students that I have shown the book to agree that Nyhoff is very unclear about where discussion ends and instructions begin.

    What I can't figure out is that Professors seems to really admire this second edition book. Most reviews of this book written by professors seem rather positive. I suppose this is no different than physics professors who admire a book written by a famous scientists, but yet is WAY over the heads of any undergraduate student.

    Anyhow, thank you for igniting the fire that ultimately helped me see the light, so to speak. Should I expect more books in Computer Science that are this full of errata?

    Brent
     
  4. xpi0t0s

    xpi0t0s Mentor

    Joined:
    Aug 6, 2004
    Messages:
    3,009
    Likes Received:
    203
    Trophy Points:
    63
    Occupation:
    Senior Support Engineer
    Location:
    England
    Mistakes in software are quite commonplace and you will learn this as you go along. It is always worth being aware of the latest version even when it comes to books. The reason for this is that compared to simple subjects like physics and chemistry, computer programming is an extremely complex discipline that is still in its infancy - and before you take offence at that, think of what physicists and chemists were doing 40 years into the disciplines for a fair comparison, rather than C21st scientists with 1000s of years cumulative experience behind them. Think - and cringe - about Ada Lovelace's experiments with radioactive materials for a recent example within your background.

    You will already be aware of software being released with bugs present - Microsoft are often criticised for this, but Windows isn't buggy because Microsoft are crap, it's buggy because that's the nature of software. Think of how much money Microsoft have and give them some credit; they employ some of the best engineers in the business, and Windows *still* goes out with bugs, some of which are laughably major, or laughable by anyone who doesn't truly understand the complexity of computer programming. Linux gets off lightly, but it's much simpler due to the lack of a need to maintain backward compatibility, and its usability is legendarily bad (even with 30 years IT experience behind me, 20 of which are professional and including a degree in computer science, each time I try to use Linux I just give up on it for the simple reason that I think collecting my email should take 3.5 seconds and not 15 weeks of reading HOWTOs and being insulted as a n00b on any forums where I post basic questions).

    So unfortunately, yes, you can expect this a lot. To the author's credit he has posted - and made freely available - the updates on his website, and he doesn't make you buy the next reprint to get the corrections, as often seems to be the case with physics and chemistry books.

    You can expect it a lot from your software as well. When you've learn quite a bit and are capable of putting together 200-line C++ programs, remind me of this conversation and post one, and I guarantee to be able to find at least one bug in it.

    (Which reminds me of an amusing anecdote: every computer program contains at least one bug, and every computer program can be reduced by at least one instruction. Therefore, every computer program can be reduced to one instruction, which is wrong.)

    As for how much he rambles and isn't clear about subject changes, I can't comment because I haven't read the book. You admit to being a beginner and perhaps part of the problem is your lack of understanding (sorry if that's a bit too blunt, time prevents editing it to a "nicer" form). But computer publications, including manuals, are well known for one major failing in that usually you have to know what they're talking about before you can understand them.

    Don't take raving reviews by professors as authoritatively as you do. First off, professors are not in the same position as you; they are not beginners, so are not reading as beginners. Secondly, professors often have a financial interest in writing a good review, they sometimes get commission off book sales - this is why "last year's publication" is never on the recommended book list, it has to be this year's, that you have to buy at full price instead of second hand at 1/10th the price from last year's students.

    If it's the recommended book for the course then probably you have to have it. But check the comp.lang.c++ FAQ for recommended books; if you're struggling to learn from the class and have to learn from a book, then after you've asked why you're paying for tuition and not getting any, think about picking up one or two of the books at the top of the FAQ list. Books do not always work for your personal style (which is why I think a "recommended book" for a course is always a bad idea) and maybe your brain just isn't wired to grok Nyhoff's style. Avoid Schildt.
     

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice