Request for pointer to excellent C++ book

[Izak]

Hello Geeks,


I am a professional C programmer who has contributed to open source community through BRL-CAD. Although I have read the other post on C++ books they never served my interests as someone diving into C++.I need a reference to an excellent book that teaches C++ Syntax, Object-oriented modelling at the beginning. I am NOT looking for a book that teaches me how to program - I ma diving into another language ,C++ and need a book which drills me on professional C++, S.T.L. and BOOST libraries.

Thanks

Izak

[Yarin]

For an experienced C programmer, there's not much to it.
Use exceptions instead of a returned value to indicate error. Put functions that operate or focus on a struct, inside the struct and call it a class instead. Use RAII.
As for the STL and Boost, learn to use them how you need them, when you need them. Google and Stack Overflow are your friends.

[grumpy]

For an experienced C programmer, there's not much to it.

.... if you want to use C++ like it is a slightly modified C. If, however, you want to use C++ effectively (as opposed to using techniques that are good in C but poor in C++) you will look deeper.

Unfortunately, there is a fair body of experience that has demonstrated that teaching experienced C programmers about C++ as it if is "C and a bit more" tends to produce much less effective C++ programmers (since they often use a mix of C and C++ techniques in ways that don't fit together well).

The key for a C programmer learning C++ is to focus on the concepts and design approaches, rather than syntax. Why? Firstly, they will have spent considerable effort learning C syntax, and the small differences between C syntax and C++ syntax are meaningless without an appreciation of what they are for. Second, the biggest difference between C++ and C is that it supports different paradigms (ways of thinking about a problem), and the key to grasping those is grasping concepts and design rather than syntax.

Assuming you can get past the focus on learning syntax, I would recommend "Accelerated C++" by Koenig and Moo followed by "C++ Primer" by Lipman, Majoie, and Moo. Once you're comfortable with those - that will take time - go to "Modern C++ Design" by Alexandrescu.

Yes, I realise those are listed in the thread on C++ books, and the OP said s/he said books listed there didn't serve his/her interests. However, I think s/he is going about it wrong. The key to moving between any two languages is how you think about problems, not syntax - and even more so with languages with syntactic similarities, such as C and C++. C++ also has some peculiarities from an OO perspective (not least of which is that C++ supports paradigms other than OO, which interact with OO techniques in both good and bad ways).

The faster you insist on doing it, the less effective you will be. Pick a pace that works for your learning, not a specific timeline.

[phantomotap]

For an experienced C programmer, there's not much to it.

O_o

I second grumpy in a way. This "not much to it" is only even partially accurate if you want C wearing a dress; if you want C++, there is rather a lot to learn and unlearn.

Use exceptions instead of a returned value to indicate error.

No. If you simply use exceptions instead of returning an error code everywhere you are guaranteed to use exceptions poorly. Using simple error codes still has an important place in C++ even with exceptions.

You'd do better to use "RAII" facilities for existing exceptions, such as raised by the standard library, while otherwise ignoring exceptions in favor of error codes.

You will not be using the full potential of C++, but at least you will not be using features so poorly.

Soma

[Yarin]

No. If you simply use exceptions instead of returning an error code everywhere you are guaranteed to use exceptions poorly.

Very untrue. When high performant exceptions are at your disposal (as they are in C++) they should be used to indicate any error when possible. It's usually okay even when error is expected (not "exceptional"), because the stack unwinding and error response is likely to be multitudes quicker than what ever operation would have succeed anyway. It is amazing how much cleaner code that makes heavy use of exceptions is than "well-balanced" code that you advocate is.

[phantomotap]

When high performant exceptions are at your disposal (as they are in C++) they should be used to indicate any error when possible.

O_o

Using exceptions is always possible; you can transform any error from any system into an exception.

It's usually okay even when error is expected (not "exceptional"), because the stack unwinding and error response is likely to be multitudes quicker than what ever operation would have succeed anyway.

No. The speed, simplicity, and cleanliness of recovery is not an appropriate reason to reach for exceptions; those reasons belong to scoped destruction, which allows "RAII", which still apply with return codes.

void exchange(int * p, int * q, int s)
{
    if(*p == *q)
    {
        *p = s;
    }
    else
    {
        *q = *p;
        throw(something());
    }
}
// ...
bool done(false);
while(!done)
{
    try
    {
        exchange(p, q, s);
        done = true;
    }
    catch(...)
    {
    }
}

bool exchange(int * p, int * q, int s)
{
    if(*p == *q)
    {
        *p = s;
        return(true);
    }
    *q = *p;
    return(false);
}
// ...
while(!exchange(p, q, s))
{
}

This example is a remarkably bad fit for exceptions, and infinitely many examples are available where perfectly normal error situations are signaled and examined as normal and expected parts of employing a mechanism. Furthermore, the memory referenced by `p' and `q' within the return code example could still be managed resources, from a smart pointer perhaps, where the code is obviously cleaner, simpler, and more efficient, in development terms, thanks to the nature of scoped destruction which is entirely unrelated to exceptions.

It is amazing how much cleaner code that makes heavy use of exceptions is than "well-balanced" code that you advocate is.

I advocate clean code.

I also advocate good code.

[Edit]
I don't, however, advocate "well-balanced code" as you intend; if exceptions are the right way to go, I advocate exceptions. I'm just have enough experience to not advocate exceptions when they are definitely the wrong approach.
[/Edit]

Unlike you, I understand that coding is a skill that requires a lot of dedicated thought not just mindlessly throwing a tool at a problem.

Again, if you simply use exceptions instead of returning an error code everywhere you are guaranteed to use exceptions poorly.

Of course, I'm happy to simplify: if you simply use any tool everywhere you are guaranteed to use every tool poorly.

Soma

[Yarin]

... Unlike you, I understand that coding is a skill that requires a lot of dedicated thought ...

This is why you're on so many people's ignore lists.

[Yarin]

Neither of the code sample you provide are correct.
The first is a misuse of exceptions by way of lack of abstraction.
The second is a misuse of exceptions by way of not using them.

A more correct example would be:

void exchange(int * p, int * q, int s)
{
    if(*p == *q)
    {
        *p = s;
    }
    else
    {
        *q = *p;
        throw(something());
    }
}

bool try_exchange(int * p, int * q, int s)
{
    try { 
        exchange(p, q, s);
		return true; }
	catch(...) {
		return false; }
}

// ...
while(!try_exchange(p, q, s))
{
}

Disclaimer: If I had to guess, though, I doesn't looking like exchange() returning false is truly an error as you seem to imply. In said case, obviously an exception shouldn't be used.

[phantomotap]

This is why you're on so many people's ignore lists.

O_o

People put me on an ignore list because I called them out for foolishly telling people to horribly misuse a tool?

I actually kind of cherish that.

Your example is some of the worst C++ code I've ever seen with a hideous misuse of exceptions. You don't even know if exceptions are used within `try_exchange' without the source! You've done nothing but transform a simple boolean flag representing a failed operation, thus the need to repeat, into an exception only to wrap the transformation back into a simple error code because using the form with the exceptions directly is so horrible. Your argument is thus shown to be extremely foolish. The example you've posted as "How it should be done." is as far from "How it should be done." as is possible while still having the exact same interface.

Here is a news flash for you: the client code of `try_exchange' isn't using exceptions to examine the error so by your own admission the client code is a "misuse of exceptions by not using them", and just for funsies, renaming the second `exchange' from my example to `try_exchange' makes the client code identical so you've actually only shown the foolish of your statement as you are using a returned value to signal an error.

Your understanding of the C++ exception mechanism and how best to use them is abysmal. You shouldn't be telling anyone how easy it is to transition from C into C++ because you have clearly not made that change.

You certainly shouldn't be telling people to "Use exceptions instead of a returned value to indicate error." because the statement is easily shown to be idiotic. You've even provided a perfect example: in using exceptions instead of a simple returned value you've actually had to wrap the function to make the interface palatable.

Feel free to add me to your ignore list, but you shouldn't worry, I'll be sure to point out how very wrong this advice is if I see post it again in the future.

Soma

[Yarin]

People put me on an ignore list because I called them out for foolishly telling people to horribly misuse a tool?

No. For ad hominem attacks.

Here is a news flash for you: the client code of `try_exchange' isn't using exceptions to examine the error so by your own admission the client code is a "misuse of exceptions by not using them", and just for funsies, renaming the second `exchange' from my example to `try_exchange' makes the client code identical so you've actually only shown the foolish of your statement as you are using a returned value to signal an error.

Agreed. Hence my point about your example starting off with a false premise. Since I can no longer edit my post, I'll amend here:

The code samples you provide are not adequate. Based on the context of what little code you show, I deduce that 'exchange' returning false is not an error condition. I never advocated using exceptions in place of returning false, but in place of actual errors. Perhaps you should re-read my first post.

[grumpy]

Very untrue. When high performant exceptions are at your disposal (as they are in C++) they should be used to indicate any error when possible. It's usually okay even when error is expected (not "exceptional"), because the stack unwinding and error response is likely to be multitudes quicker than what ever operation would have succeed anyway.

I'm with Soma on this one. Exceptions, even "high performant" exceptions, are relatively costly compared with other options that affect program flow.

The stack unwinding you refer to is a result of how (non-dynamic) object lifetimes are managed, not of exceptions. It is not an advantage only available through use of exceptions.

Exceptions should certainly be considered as part of an error handling strategy for all libraries or programs. But there are other options - such as the humble return code - that have advantages that exceptions do not. If performance is your consideration, then returning a simple integer is usually less costly than the setup to throw and catch exceptions, even if your compiler provides "high performant" exceptions.

One other weakness of exceptions results from one of their strengths - exceptions make it necessary to respond to them (or face program termination). There are many circumstances in which an error indication is a normal result of some set of actions (rather than being exceptional) and simply an advisory which may be safely ignored (or optionally used if desired). An example would be any code that detects an error condition, but is able to immediately correct it, and wishes to advise the caller it has done so. If some callers need to care about such advisories, and others do not, then throwing an exception is inappropriate - as it forces all callers to respond to prevent error conditions being propagated unnecessarily.

[Mario F.]

But I'll sort of side with Yarin.

Your last argument is strong, grumpy. But poses this problem: If we get to write a software library or program that decides its use of exceptions as a matter of form, not of function, we end up with a schizophrenic error handling strategy. In the name of code maintenance (and usage, if this is a library), I'd rather be consistent in my use of exceptions and only avoid them when the error pertains to normal program flow.

Meanwhile -- and this is an honest question -- when do exceptions affect performance if they are not being formally misused? You see, I always heard the argument for performance when discussing exceptions, but having seen them in action and having profiled them for the most part of my short but intensive history with C++, I couldn't help but conclude that is just in border cases that exceptions are indeed a performance issue. Surely this "Exceptions are performance costly" cannot constitute a general advise.

[grumpy]

Your last argument is strong, grumpy. But poses this problem: If we get to write a software library or program that decides its use of exceptions as a matter of form, not of function, we end up with a schizophrenic error handling strategy. In the name of code maintenance (and usage, if this is a library), I'd rather be consistent in my use of exceptions and only avoid them when the error pertains to normal program flow.

That's essentially the "one size fits all" argument.

My response to that is that the technique, or techniques, for reporting error conditions should be appropriate to the meaning of the error, whether error recovery is possible, where it is possible (i.e. at the point where a problem is detected, by the caller, or somewhere else), and costs associated with the error condition (impact of responding to it, impact of delaying a response to it, impact of not responding to it, cost of reporting it, etc).

Meanwhile -- and this is an honest question -- when do exceptions affect performance if they are not being formally misused? You see, I always heard the argument for performance when discussing exceptions, but having seen them in action and having profiled them for the most part of my short but intensive history with C++, I couldn't help but conclude that is just in border cases that exceptions are indeed a performance issue. Surely this "Exceptions are performance costly" cannot constitute a general advise.

It is hard to envisage a case where (say) returning an integral value from a function by poking a value into a register will have more overhead than the machinery to propagate an exception up the call stack.

That obvious statement aside, I do consider the performance argument against exceptions (assuming they're not misused) is over-played. With older compilers, it was significant. Compiler techniques have improved - a lot - but it is a fallacy to claim that exceptions are near-zero cost.

I'm not suggesting exceptions should not be used. I'm suggesting that approaches of "always use them" are ham-fisted.

[Mario F.]

My response to that is that the technique, or techniques, for reporting error conditions should be appropriate to the meaning of the error, whether error recovery is possible, where it is possible (i.e. at the point where a problem is detected, by the caller, or somewhere else), and costs associated with the error condition (impact of responding to it, impact of delaying a response to it, impact of not responding to it, cost of reporting it, etc).

But that's my point exactly. It's the meaning of the error that should dictate how I should handle it. We always understood exceptions as handlers for any error originated outside our program scope. But unless I misunderstood what you said on the previous post, you'd gladly and arbitrarily switch a properly contextualized exception class for a return value if that allowed you to simplify your code.

I'm no stranger to the idea we should only go as far in obeying rules. But that felt to me we would end with a program or a library in which error handling wouldn't conform to any rule other than what the developer felt in that particular day. Yarin never said we should only use exceptions and I agree with him that we should not use error codes when an exception is expected.

[grumpy]

But that's my point exactly. It's the meaning of the error that should dictate how I should handle it. We always understood exceptions as handlers for any error originated outside our program scope. But unless I misunderstood what you said on the previous post, you'd gladly and arbitrarily switch a properly contextualized exception class for a return value if that allowed you to simplify your code.

I didn't say I'd do it to simplify my code. I would do it if it made sense within the error handling strategy.

There are six aspects of errors: the cause, the detection, the consequences, the means of reporting, the response (including corrective action) required, and the decision to respond.

The act of throwing an exception is also a statement that responding to the error (or its cause) is mandatory. Discretion for the caller is eliminated. If a response is not KNOWN to be mandatory when the error condition is detected, then a mechanism other than throwing exceptions is appropriate.


If, as a user of a library, I find myself having to swallow an exception and take no further action, then that is a mismatch between the library design and my use case. But a primary purpose of a library is to meet needs of the programs it is used in, not the reverse.

It is relatively straight-forward to adapt the error reporting on the boundaries between libraries and programs (e.g. throwing an exception in response to an error code to force correction, or swallowing an exception and propagating an error code because it is not necessary to correct the cause). But I would assert than any library which requires such adaption is broken. And one way to achieve a broken design is to throw exceptions for "consistency", irrespective of any consideration of whether the errors in question need to be handled.