C++ FAQs

Marshall P. Cline, Greg Lomow, Mike Girou

Mentioned 9


More on Amazon.com

Mentioned in questions and answers.

If you could go back in time and tell yourself to read a specific book at the beginning of your career as a developer, which book would it be?

I expect this list to be varied and to cover a wide range of things.

To search: Use the search box in the upper-right corner. To search the answers of the current question, use inquestion:this. For example:

inquestion:this "Code Complete"

Applying UML and Patterns by Craig Larman.

The title of the book is slightly misleading; it does deal with UML and patterns, but it covers so much more. The subtitle of the book tells you a bit more: An Introduction to Object-Oriented Analysis and Design and Iterative Development.

Masters of doom. As far as motivation and love for your profession go: it won't get any better than what's been described in this book, truthfully inspiring story!

Beginning C# 3.0: An Introduction to Object Oriented Programming

This is the book for those who want to understand the whys and hows of OOP using C# 3.0. You don't want to miss it.

alt text

Mastery: The Keys to Success and Long-Term Fulfillment, by George Leonard

It's about about what mindsets are required to reach mastery in any skill, and why. It's just awesome, and an easy read too.

Pro Spring is a superb introduction to the world of Inversion of Control and Dependency Injection. If you're not aware of these practices and their implications - the balance of topics and technical detail in Pro Spring is excellent. It builds a great case and consequent personal foundation.

Another book I'd suggest would be Robert Martin's Agile Software Development (ASD). Code smells, agile techniques, test driven dev, principles ... a well-written balance of many different programming facets.

More traditional classics would include the infamous GoF Design Patterns, Bertrand Meyer's Object Oriented Software Construction, Booch's Object Oriented Analysis and Design, Scott Meyer's "Effective C++'" series and a lesser known book I enjoyed by Gunderloy, Coder to Developer.

And while books are nice ... don't forget radio!

... let me add one more thing. If you haven't already discovered safari - take a look. It is more addictive than stack overflow :-) I've found that with my google type habits - I need the more expensive subscription so I can look at any book at any time - but I'd recommend the trial to anyone even remotely interested.

(ah yes, a little obj-C today, cocoa tomorrow, patterns? soa? what was that example in that cookbook? What did Steve say in the second edition? Should I buy this book? ... a subscription like this is great if you'd like some continuity and context to what you're googling ...)

Database System Concepts is one of the best books you can read on understanding good database design principles.

alt text

Algorithms in C++ was invaluable to me in learning Big O notation and the ins and outs of the various sort algorithms. This was published before Sedgewick decided he could make more money by dividing it into 5 different books.

C++ FAQs is an amazing book that really shows you what you should and shouldn't be doing in C++. The backward compatibility of C++ leaves a lot of landmines about and this book helps one carefully avoid them while at the same time being a good introduction into OO design and intent.

Here are two I haven't seen mentioned:
I wish I had read "Ruminations on C++" by Koenig and Moo much sooner. That was the book that made OO concepts really click for me.
And I recommend Michael Abrash's "Zen of Code Optimization" for anyone else planning on starting a programming career in the mid 90s.

Perfect Software: And Other Illusions about Testing


Perfect Software: And Other Illusions about Testing by Gerald M. Weinberg

ISBN-10: 0932633692

ISBN-13: 978-0932633699

Rapid Development by McConnell

The most influential programming book for me was Enough Rope to Shoot Yourself in the Foot by Allen Holub.

Cover of the book

O, well, how long ago it was.

I have a few good books that strongly influenced me that I've not seen on this list so far:

The Psychology of Everyday Things by Donald Norman. The general principles of design for other people. This may seem to be mostly good for UI but if you think about it, it has applications almost anywhere there is an interface that someone besides the original developer has to work with; e. g. an API and designing the interface in such a way that other developers form the correct mental model and get appropriate feedback from the API itself.

The Art of Software Testing by Glen Myers. A good, general introduction to testing software; good for programmers to read to help them think like a tester i. e. think of what may go wrong and prepare for it.

By the way, I realize the question was the "Single Most Influential Book" but the discussion seems to have changed to listing good books for developers to read so I hope I can be forgiven for listing two good books rather than just one.

alt text

C++ How to Program It is good for beginner.This is excellent book that full complete with 1500 pages.

Effective C++ and More Effective C++ by Scott Myers.

Inside the C++ object model by Stanley Lippman

I bough this when I was a complete newbie and took me from only knowing that Java existed to a reliable team member in a short time

Not a programming book, but still a very important book every programmer should read:

Orbiting the Giant Hairball by Gordon MacKenzie

The Pragmatic programmer was pretty good. However one that really made an impact when I was starting out was :

Windows 95 System Programming Secrets"

I know - it sounds and looks a bit cheesy on the outside and has probably dated a bit - but this was an awesome explanation of the internals of Win95 based on the Authors (Matt Pietrek) investigations using his own own tools - the code for which came with the book. Bear in mind this was before the whole open source thing and Microsoft was still pretty cagey about releasing documentation of internals - let alone source. There was some quote in there like "If you are working through some problem and hit some sticking point then you need to stop and really look deeply into that piece and really understand how it works". I've found this to be pretty good advice - particularly these days when you often have the source for a library and can go take a look. Its also inspired me to enjoy diving into the internals of how systems work, something that has proven invaluable over the course of my career.

Oh and I'd also throw in effective .net - great internals explanation of .Net from Don Box.

I recently read Dreaming in Code and found it to be an interesting read. Perhaps more so since the day I started reading it Chandler 1.0 was released. Reading about the growing pains and mistakes of a project team of talented people trying to "change the world" gives you a lot to learn from. Also Scott brings up a lot of programmer lore and wisdom in between that's just an entertaining read.

Beautiful Code had one or two things that made me think differently, particularly the chapter on top down operator precedence.


@Juan: I know Juan, I know - but there are some things that can only be learned by actually getting down to the task at hand. Speaking in abstract ideals all day simply makes you into an academic. It's in the application of the abstract that we truly grok the reason for their existence. :P

@Keith: Great mention of "The Inmates are Running the Asylum" by Alan Cooper - an eye opener for certain, any developer that has worked with me since I read that book has heard me mention the ideas it espouses. +1

I found the The Algorithm Design Manual to be a very beneficial read. I also highly recommend Programming Pearls.

This one isnt really a book for the beginning programmer, but if you're looking for SOA design books, then SOA in Practice: The Art of Distributed System Design is for you.

For me it was Design Patterns Explained it provided an 'Oh that's how it works' moment for me in regards to design patterns and has been very useful when teaching design patterns to others.

Code Craft by Pete Goodliffe is a good read!

Code Craft

The first book that made a real impact on me was Mastering Turbo Assembler by Tom Swan.

Other books that have had an impact was Just For Fun by Linus Torvalds and David Diamond and of course The Pragmatic Programmer by Andrew Hunt and David Thomas.

In addition to other people's suggestions, I'd recommend either acquiring a copy of SICP, or reading it online. It's one of the few books that I've read that I feel greatly increased my skill in designing software, particularly in creating good abstraction layers.

A book that is not directly related to programming, but is also a good read for programmers (IMO) is Concrete Mathematics. Most, if not all of the topics in it are useful for programmers to know about, and it does a better job of explaining things than any other math book I've read to date.

For me "Memory as a programming concept in C and C++" really opened my eyes to how memory management really works. If you're a C or C++ developer I consider it a must read. You will defiantly learn something or remember things you might have forgotten along the way.


Agile Software Development with Scrum by Ken Schwaber and Mike Beedle.

I used this book as the starting point to understanding Agile development.

Systemantics: How Systems Work and Especially How They Fail. Get it used cheap. But you might not get the humor until you've worked on a few failed projects.

The beauty of the book is the copyright year.

Probably the most profound takeaway "law" presented in the book:

The Fundamental Failure-Mode Theorem (F.F.T.): Complex systems usually operate in failure mode.

The idea being that there are failing parts in any given piece of software that are masked by failures in other parts or by validations in other parts. See a real-world example at the Therac-25 radiation machine, whose software flaws were masked by hardware failsafes. When the hardware failsafes were removed, the software race condition that had gone undetected all those years resulted in the machine killing 3 people.

It seems most people have already touched on the some very good books. One which really helped me out was Effective C#: 50 Ways to Improve your C#. I'd be remiss if I didn't mention The Tao of Pooh. Philosophy books can be good for the soul, and the code.

Discrete Mathematics For Computer Scientists

Discrete Mathematics For Computer Scientists by J.K. Truss.

While this doesn't teach you programming, it teaches you fundamental mathematics that every programmer should know. You may remember this stuff from university, but really, doing predicate logic will improve you programming skills, you need to learn Set Theory if you want to program using collections.

There really is a lot of interesting information in here that can get you thinking about problems in different ways. It's handy to have, just to pick up once in a while to learn something new.

I saw a review of Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools on a blog talking also about XI-Factory, I read it and I must say this book is a must read. Altough not specifically targetted to programmers, it explains very clearly what is happening in the programming world right now with Model-Driven Architecture and so on..

Solid Code Optimizing the Software Development Life Cycle

Although the book is only 300 pages and favors Microsoft technologies it still offers some good language agnostic tidbits.

Managing Gigabytes is an instant classic for thinking about the heavy lifting of information.

My vote is "How to Think Like a Computer Scientist: Learning With Python" It's available both as a book and as a free e-book.

It really helped me to understand the basics of not just Python but programming in general. Although it uses Python to demonstrate concepts, they apply to most, if not all, programming languages. Also: IT'S FREE!

Object-Oriented Programming in Turbo C++. Not super popular, but it was the one that got me started, and was the first book that really helped me grok what an object was. Read this one waaaay back in high school. It sort of brings a tear to my eye...

My high school math teacher lent me a copy of Are Your Lights Figure Problem that I have re-read many times. It has been invaluable, as a developer, and in life generally.

I'm reading now Agile Software Development, Principles, Patterns and Practices. For those interested in XP and Object-Oriented Design, this is a classic reading.

alt text

Kernighan & Plauger's Elements of Programming Style. It illustrates the difference between gimmicky-clever and elegant-clever.

to get advanced in prolog i like these two books:

The Art of Prolog

The Craft of Prolog

really opens the mind for logic programming and recursion schemes.

Here's an excellent book that is not as widely applauded, but is full of deep insight: Agile Software Development: The Cooperative Game, by Alistair Cockburn.

What's so special about it? Well, clearly everyone has heard the term "Agile", and it seems most are believers these days. Whether you believe or not, though, there are some deep principles behind why the Agile movement exists. This book uncovers and articulates these principles in a precise, scientific way. Some of the principles are (btw, these are my words, not Alistair's):

  1. The hardest thing about team software development is getting everyone's brains to have the same understanding. We are building huge, elaborate, complex systems which are invisible in the tangible world. The better you are at getting more peoples' brains to share deeper understanding, the more effective your team will be at software development. This is the underlying reason that pair programming makes sense. Most people dismiss it (and I did too initially), but with this principle in mind I highly recommend that you give it another shot. You wind up with TWO people who deeply understand the subsystem you just built ... there aren't many other ways to get such a deep information transfer so quickly. It is like a Vulcan mind meld.
  2. You don't always need words to communicate deep understanding quickly. And a corollary: too many words, and you exceed the listener/reader's capacity, meaning the understanding transfer you're attempting does not happen. Consider that children learn how to speak language by being "immersed" and "absorbing". Not just language either ... he gives the example of some kids playing with trains on the floor. Along comes another kid who has never even SEEN a train before ... but by watching the other kids, he picks up the gist of the game and plays right along. This happens all the time between humans. This along with the corollary about too many words helps you see how misguided it was in the old "waterfall" days to try to write 700 page detailed requirements specifications.

There is so much more in there too. I'll shut up now, but I HIGHLY recommend this book!

alt text

The Back of the Napkin, by Dan Roam.

The Back of the Napkin

A great book about visual thinking techniques. There is also an expanded edition now. I can't speak to that version, as I do not own it; yet.

Agile Software Development by Alistair Cockburn

Do users ever touch your code? If you're not doing solely back-end work, I recommend About Face: The Essentials of User Interface Design — now in its third edition (linked). I used to think my users were stupid because they didn't "get" my interfaces. I was, of course, wrong. About Face turned me around.

"Writing Solid Code: Microsoft's Techniques for Developing Bug-Free C Programs (Microsoft Programming Series)" by Steve MacGuire.

Interesting what a large proportion the books mentioned here are C/C++ books.

While not strictly a software development book, I would highly recommend that Don't Make me Think! be considered in this list.

As so many people have listed Head First Design Patterns, which I agree is a very good book, I would like to see if so many people aware of a title called Design Patterns Explained: A New Perspective on Object-Oriented Design.

This title deals with design patterns excellently. The first half of the book is very accessible and the remaining chapters require only a firm grasp of the content already covered The reason I feel the second half of the book is less accessible is that it covers patterns that I, as a young developer admittedly lacking in experience, have not used much.

This title also introduces the concept behind design patterns, covering Christopher Alexander's initial work in architecture to the GoF first implementing documenting patterns in SmallTalk.

I think that anyone who enjoyed Head First Design Patterns but still finds the GoF very dry, should look into Design Patterns Explained as a much more readable (although not quite as comprehensive) alternative.

Even though i've never programmed a game this book helped me understand a lot of things in a fun way.

How influential a book is often depends on the reader and where they were in their career when they read the book. I have to give a shout-out to Head First Design Patterns. Great book and the very creative way it's written should be used as an example for other tech book writers. I.e. it's written in order to facilitate learning and internalizing the concepts.

Head First Design Patterns

97 Things Every Programmer Should Know

alt text

This book pools together the collective experiences of some of the world's best programmers. It is a must read.

Extreme Programming Explained: Embrace Change by Kent Beck. While I don't advocate a hardcore XP-or-the-highway take on software development, I wish I had been introduced to the principles in this book much earlier in my career. Unit testing, refactoring, simplicity, continuous integration, cost/time/quality/scope - these changed the way I looked at development. Before Agile, it was all about the debugger and fear of change requests. After Agile, those demons did not loom as large.

One of my personal favorites is Hacker's Delight, because it was as much fun to read as it was educational.

I hope the second edition will be released soon!

You.Next(): Move Your Software Development Career to the Leadership Track ~ Michael C. Finley (Author), Honza Fedák (Author) link text

I've been arounda while, so most books that I have found influential don't necessarily apply today. I do believe it is universally important to understand the platform that you are developing for (both hardware and OS). I also think it's important to learn from other peoples mistakes. So two books I would recommend are:

Computing Calamities and In Search of Stupidity: Over Twenty Years of High Tech Marketing Disasters

Working Effectively with Legacy Code is a really amazing book that goes into great detail about how to properly unit test your code and what the true benefit of it is. It really opened my eyes.

I consider myself an experienced Java developer and am planning to get started with learning C++.

If you had same experience, i.e learn C++ after Java, I would like to hear your thoughts on what is the best approach at doing this.

[Update] "the best approach" was not well quantified. What I am looking for is to leverage my existing java knowledge and programming experience so that I can quickly ramp up on C++.

K&R and Stroustrup are classics, and eventually you should get them, but I don't think they are good introduction for C++ beginners. Thinking in modern C++ is thinking in classes, templates, exceptions, and streams, none of which available in C language.

I would recommend a college-level textbook on C++ like Deitel and Deitel. alt text

After playing around, you should focus on learning to write a class that behaves like a built-in class. That means providing a copy constructor, operator=, operator==, operator<<, etc.. Along the way you'll meet various concepts embedded in the language of C++. I would agree with others on Effective C++ is a must read once you are comfortable with the basics.

Others have already specified the required books. I would like to add just couple of points to be noted: ( as background is java)

  • C++ doesnot provide you the Garbage collection ( as in Java). Hence, you must be very perticular about memory leaks. Always use delete the memory allocated on heap using new. Try to remember the Free-Store management in FAQ while writing the C++ applications.
  • Most often in C++ you may have to work with pointers ( missing in Java). Learn pointers ( books suggested by @Charlie Martin) effectively and use them.
  • One you are familiar with C++, learn the basics of STL and use effectively. ( Book By Josuttis and Scott Meyers)

Good luck.

I've taught C++ to Java people, even though I learned them the other direction.

Are you comfortable with C? If not, read Kernighan and Ritchie. Many many peculiarities of C++ are explained by the desire for C++ to be a "Better C" with C's basic expression syntax.

You should get Stroustrup.

I think well of Thinking in C++ by Bruce Eckels.

I've used The C++ FAQ Book, by Cline, Lomow, and Girou; I refer to it pretty often. Marshall Cline has C++ FAQ content on his site, too.


You might also look at C++ for Java Programmers. I don't know the book but it looks decent.

After watching: The Clean Code Talks -- Inheritance, Polymorphism, & Testing

I checked my code and noticed a few switch statements can be refactored into polymorphism, but I also noticed I only used switch statements with enums. Does this mean enums are "evil" in OO-design and should be eliminated with polymorphism?

It's not that enums are evil, it's switch statements. There's a long discussion of this in the C++ FAQ Book, but the gist is this: except for limited areas --- for example the interpretation of data coming in from a register on a device --- a big switch comb suggests that you're using data to distinguish among subtypes. In place of that, you ought to just use subtypes, gaining the compiler's help in keeping it correct, and also meaning the compiler will automatically add new cases when you (inevitably) change the set of cases.

I recently forced myself to study C++ and I just finished reading the book C++: The Complete Reference, by Herbert Schildt. I liked the book and think I got more or less the big picture. I noticed though that when I try to check with other people the things I code using the material I learned, they are usually considered non-idiomatic and superseded by an STL way to do it that is safer and easier (well, the book doesn't cover STL and Boost libraries).

So I'd like to ask: what are good sources to learn the patterns of a good C++ program? Where can I learn basic patterns from the "C++ way" to do things and not just repeating C patterns in C++?

I'd be particularly interested in sources that included STL and Boost stuff.

I'd (also) recommend:

  • Effective C++, Effective STL by Steve Myers. They are easy to digest, yet very valuable - sometimes even illuminating.
  • Code Complete (The 1993 edition is available cheaply and not that much different). It's lengthy, but it walks across the entire field from what it means to be a programmer to how a for loop should look. (It would be better if it was shorter - the way it is it covers so much ground it's hard to place it). I hold it dear because it illustrate two points very well:
    • code is compromise
    • There are know facts, (but we still manage to get by by gut feel)
  • C++ FAQ Lite / C++ FAQ.
  • I'd throw in Facts and Fallacies by Robert Glass - it doesn't fit your request very well, but go read it.

It's natural that you are unhappy with other people's code. That's typical for programming - heck, even my own code of five years ago was written by a total n00b. That might be more articulated for C++, since it caters for different styles, and often puts freedom ("you can") over guildelines ("that's the way").

Still, mulling over existing code - yours or others - and considering how it can be improved. Also, figuring out why it is the way it is sometimes helps.

(I remember a few TheDailyWTF's where everyone would chime in how stupid and unreasonable this is - yet somewhere, buried among the me too's, was someone with domain experience explaining convincingly under what circumstances this was better than the obvious solution).

You might wnat to check out The Definitive C++ Book Guide and List

For your purposes I would especially recommend:

They are not in particular order, also you might want to read and code something in between them.

(Note: As noted by @John Dibling the Boost book might be a bit out of date, I do not have experience with that one myself)

Section 16.4 of C++ FAQs (2nd Edition) (Paperback) by Marshall P. Cline, Greg Lomow says that inline functions cannot access static data members safely because the function could be called before the static data member is initialized.

I fail to see why this applies to inline functions and not just any functions in other translation units which call a static data member in another translation unit? I fail to see what part "inline" plays in this disaster?

static variables are fully initialized before any function in that same translation unit (cpp file more or less) is executed. They are not guaranteed to be initialized before main is called if main is in a different translation unit. inline functions are duplicated, where each translation unit has it's own copy. That means that inline functions in different translation units than the static variable might attempt to read/write to that variable before it is properly initialized, resulting in undefined behavior. (The rules are very complicated, but that's what I recall)

§ 3.6.2/4 It is implementation-defined whether the dynamic initialization of a non-local variable with static storage duration is done before the first statement of main. If the initialization is deferred to some point in time after the first statement of main, it shall occur before the first odr-use (3.2) of any function or variable defined in the same translation unit as the variable to be initialized.


§ 3.2/3 An inline function shall be defined in every translation unit in which it is odr-used.

inline functions are not really any more dangerous than non-inline functions as far as I know. Any function accessing a static in a different TU is risky, and since inline just happens to put functions in every TU, most of them aren't safe. One workaround is to use the "construct on first use idiom".

Implicit template specializations are complicated, but for completeness:

§ 14.7.1/3 [temp.inst] the initialization (and any associated side-effects) of a static data member does not occur unless the static data member is itself used in a way that requires the definition of the static data member to exist.

So static members of template classes are always initialized before use.

All of the above is subject to the the static initialization order fiasco), which the aformentioned "construct on first use idom" solves.

I have a std::map which I'm trying to store void pointers for the values. The problem is, most of the pointer I'm trying to store are methods in a class and have different amount of params. I know for the params I can use a va list so thats not too much of a problem, the problem would be the actual pointer itself.

This is what I have:

class A 
  void methodA(...);
class B
  void methodB(...);
void method_no_class(...) { }

std::map<int, void(*)(...)> my_map;

my_map[0] = &method_no_class;
B* cb = new B();
my_map[1] = &cb->methodB; // will return error

Following up on Kamil Szot's answer, the C++ FAQ (and the book) is an excellent reference to the murky depths of C++ and object oriented programming in general. Section 33 addresses specifically the problem you are having:

In C++, member functions have an implicit parameter which points to the object (the this pointer inside the member function). Normal C functions can be thought of as having a different calling convention from member functions, so the types of their pointers (pointer-to-member-function vs. pointer-to-function) are different and incompatible.

Of course, the answer to your question is somewhat lacking in details.

Apologies if this has been asked before, I'm not quite sure of the terminology or how to ask the question.

I'm wondering if there are libraries or best practices for implementing object models in C++. If I have a set of classes where instances of these classes can have relations to each other and can be accessed from each other via various methods, I want to pick a good set of underlying data structures to manage these instances and their inter-relationships. This is easy in Java since it handles the memory allocation and garbage collection for me, but in C++ I have to do that myself.

HTML's Document Object Model (DOM) is one example; as another (contrived) example, suppose I have these classes:

  • Entity
  • Person (subclass of Entity)
  • Couple (subclass of Entity)
  • Property
  • House (subclass of Property)
  • Pet (subclass of Property)
  • Car (subclass of Property)

and these relationships:

  • Entity
    • has 1 home of class House
    • has 0 or more pets of class Pet
    • has 0 or more cars of class Car
    • has 0 or more children of class Person
  • Person
    • has 0 or 1 spouse of class Person
    • has 0 or 1 marriage of class Couple
    • has 0 or 1 parents of class Entity (in this model parents don't exist if they're not alive!)
  • Couple
    • has 2 members of class Person
  • Property
    • has 1 owner of class Entity

Now that I've thought out these objects and their relationships, I want to start making data structures and methods and fields to handle them, and here's where I get lost, since I have to deal with memory allocation and lifetime management and all that stuff. You can run into problems like the following: I might want to put an object into a std::map or a std::vector, but if I do that, I can't store pointers to those objects since they can be relocated when the map or vector grows or shrinks.

One approach I used when I was working with COM a lot, is to have a hidden collection that contained everything. Each object in the collection had a unique ID (either a number or name), by which it could be looked up from the collection, and each object had a pointer to the collection. That way, if you have an object which wants to point to another object, instead of literally holding a pointer to another object, I store the ID and can look it up via the hidden collection. I can use reference-counting to automatically deal with lifetime issues (except for the case of disjoint cycles, sometimes that's not a problem).

Are there other approaches? Or are there libraries to make this kind of stuff easier in C++?

edit: then you have other issues, such as the relationships between objects are likely to be mutable in many cases, and you have to think ahead about how references to objects should be stored, and what methods should be provided for accessing objects from each other. For example, if I have a handle to a Person X, and I want to represent the concept of "find X's child named George", then I have to store the name "George" rather than a child number: the children may be stored in a vector, and I may be able to call X.getChildCount() and X.getChild(0), but "George" may not always be child number 0, since other children may be inserted before "George" in the child vector. Or X may have two or three or four other children also named "George". Or "George" may change his name to "Anthony" or "Georgina". In all these cases it is probably better to use some kind of unique immutable ID.

edit 2: (and I'll clean up my question a bit once I get this straightened out) I can deal with the choice of methods and property names, I can deal with whether to use a map or a list or a vector. That's fairly straightforward. The problems I'm trying to deal with specifically are:

  • how to have one object store a reference to another object, when those objects may be part of data structures that are reallocated
  • how to deal with object lifetime management, when there are reciprocal relationships between objects

Jason, my favorite source on the is the C++ FAQ Book. The problem is you're effectively asking "how can I use C++ for object oriented programming?"

The best I can say in an SO answer is this:

all these things are going to be classes in C++, and the relationships etc will look a lot like garbage collected languages you're used to: if you need a relationship between a Person and his Child named "george", you pick a data structure that can store Persons or Childs indexed by name.

Memory management is actually easier than in straight C, if you follow some rules: make sure all the objects that need them have destructors, make sure the destructors clean up everything the object owns, and then make sure that you always put these dynamically constructed objects in contexts where they go out of scope when they're no longer needed. Those won't cover all cases, but they will save you from probably 80 percent of memory allocation mistakes.

I've been thinking about creating a class in C++ on graph theory. The idea is it'll be a class to hold indefinite number of vertices and edges for a simple graph (at most one edge between a pair of vertices). The problem is how'd I store this indefinite number of vertices/edges in the most efficient way.

I came up with the idea of having dynamic pointer to array of vertices as a member in the class. However, it'd be inefficient, and I also encounter problem of how to determine the connection of vertices (I wouldn't be able to determine which vertices connect with which), if I use this method. The alternative is to create a class Vertex that suppose to contain information of its connectivity. However, because of indefinite number of edges, I cannot think of other way around other than to use dynamic variables inside Vertex. It'd make my code efficiency worse with this approach.

So is there a better approach?

You'll pretty quickly find yourself wanting both a Vertex and Edge class -- there are too many algorithms that depend on coloring, or weighting, or marking edges, and it's also simpler to mix directed and undirected edges. The odds are good that you aren't going to really care a lot about storing the appropriate references dynamically, because that can be reduced to a vector of pointers.

Another issue to think about is if you will want to store this thing persistently.

Suggestion: try the Simplest Thing That Can Possibly Work first. Assuming an Array class that resizes itself as needed, that will look something like

class Vertex {
  Array<Edge> edges ;
  VertexData vd ; // define this for the task.

     // ctor etc; quiz: what operations?

class Edge {
  Vertex v1, v2;
  EdgeData ed;
     // ctor etc

Construct all the vertices and edges with new, don't worry about performance,and write some code against these classes.

Then go back, think how you'd have liked to write the code, and re-implement the classes to have that interface.

I'm a little prejudiced, since I used to teach the book and worked for Marshall Cline and Mike Girou, but I think one of the best C++ books for someone trying to really use it effectively is The C++ FAQBook, by Cline, Girou, and Lomow.

Normally I program in C# but have been forced to do some work in C++. It seems that the integration with Visual Studio (2008) is really poor compared to C# but I was wondering if there are any good tools, plugins or configurations that can improve the situation.

Another post pointed out the program Visual Assist X, which at least helps with some things such as refactoring (though it is a bit expensive for me). My major problem is, though, that the compile errors give little clue about what is wrong and I spend most of my time figuring out what I did wrong. It just feels like it is possibly to statically check for a lot more errors than VS does out of the box. And why doesn't it provide the blue underlines as with C#, that shouldn't be too hard?!

I realize that half the problem is just the fact that I am new to C++ but I really feel that it can be unreasonably hard to get a program to compile. Are there any tools of this sort out there or are my demands too high?

+1 for Visual Assist, maybe not now - but when you turn the hobby into a profession you will need it.

In my experience, the diagnsotics are already much better than in VC6, but you will need to "learn" their true meaning as part of learning the IDE.

Static checking of C++ is much more complicated than C#, due to the build mode, and the incredibly more complex language. PC-Lint (best together with Visual Lint to integrate it into the IDE) is the canonical static analysis. Not cheap either, though...

The C++ standard sometimes reads like scripture, but without a trained preacher to interpret it. One excellent interpreter is Marshal Cline with his C++ FAQ. Note that the online FAQ, while extensive, covers much less than the book.

What helped me a lot understanding complex error messages is trying to reproduce the problem in a smaller environment - but then, there was no internet back then...