Thread: C++ Annotations

The only C++ book I've read before (well, not all of it, lol) was Programming: Principles and Practice Using C++ by Bjarne Stroustrup and tho copious and reasonably well organized, it is poorly written.

Glancing, eg, at the chapter on Polymorphism, this one looks much more interesting. Thanks!

I just wish y'all would drop the inferiority complex vis. C. I couldn't get two paragraphs into this without hitting a line like "Instead of awkward C-style file scope static declarations, C++ offers the more elegant static class member." [paraphrased] Them's fightin' words.

Originally Posted by manasij7479

>Instead of awkward C-style ...
If in an alternate universe.. C was somehow developed after C++... we'd see lines like.... "Instead of this uber complicated multiple inheritance which creates more problems than it solves.... C simply offers structs where you can certainly have pointers to other structs skipping all the unnecessary contraptions"

Rotfl. I could almost believe in that, "back to the future".

Seriously, tho, outside of the C++ world, I don't see a lot of programming material that constantly references another language in order to describe itself by contrast, wherein the author always seems compelled to throw in some (morale boosting?) subjective evaluations at the same time. It reminds me of talking with someone who keeps coming back around to, "My jerk of a father" no matter what the topic. Like, eventually you start to think this person has an unhealthy obsession.

But no big deal. Thanks again for the book tip, I probably have a lot to learn from it.

Originally Posted by MK27

Like, eventually you start to think this person has an unhealthy obsession.

Okay, example! In the CPP Annotations chapter on Exceptions, the author actually demonstrates "Anachronisms: `setjmp' and `longjmp'" as the C predecessor -- like with an example program and explanation. WTF? You don't need to know anything about setjmp and longjmp to understand C++ exceptions. Why the need to write a (bad) C program in order to explain technically unrelated C++ syntax?

Again, this seems par for the course in C++ literature. Methinks this creates programmers who learn C++, but never C, and pick up all kinds of wacky ideas about how cumbersome C is (using setjmp and longjmp is not "the C way" to throw errors, lol). Then maybe down the road they write a C++ book and think, "I guess I need some negated C examples to explain this...".

However, no one take that as a serious disparagement of the book. It is totally worth having a look.

> (using setjmp and longjmp is not "the C way" to throw errors, lol).
I thought there was no C way to throw errors ... (?) ..and it is totally up to the coder.
(I'd tend to think that those kinds of 'maintained' jumping would produce less complicated code....rather than having ..say.. a 32 bit array of flags)

> Methinks this creates programmers who learn C++, but never C, and pick up all kinds of wacky ideas about how cumbersome C is
I'd admit that this happened for me.

Originally Posted by manasij7479

I thought there was no C way to throw errors ... (?)

There isn't an application for C++ exceptions in C; AFAICT their significance has to do with calling destructors properly and the fact that constructors can't return NULL, but just setting an error flag may not be enough for some people in some cases (and, nb, the fact that constructors can't nullify their object is why the destructor must be called). In C, what you can't do with normal if (!work) error handling cascades can be done with assert().

I'd tend to think that those kinds of 'maintained' jumping would produce less complicated code

I've never used longjmp() and can't remember seeing it used either. I'm not sure what the purpose would be; I believe it exists because the C api has some ASM parallels. Ie, it is essentially depreciated. In the CPP Annotations example, it seems to be about handling an error, but in an actual OO C program, the Inner object's constructor could return NULL and cascade back into main. If Outer's constructor failed to check for NULL, the program would just seg fault, which is less tidy than failing to catch an exception (...but so what?)* . Because this is C++, the constructor can't do that; it could set an error flag, but that is more of a hassle than just a NULL pointer because there is still a (useless) object to clean up.

So I suppose the example could be about justifying the existence of exceptions (they allow a constructor to self-destruct even though you can't have a NULL object). But I don't see why C++ has to justify its syntax in relation to C. Perhaps it harkens back to a time when it was a new language and the idea was to persuade C programmers of its value.

* How meaningful is a "tidier" mistake? A consequence of poor programming is...poor programs. You should catch exceptions and check for NULL.

> AFAICT their significance has to do with calling destructors properly and the fact that constructors can't return NULL
AFAIK it also resets the stack...rolling back changes until the place where the 'catch' block is there.

>How meaningful is a "tidier" mistake?
I'd say..very much. I'm currently trying to write a small lisp interpreter...and exceptions made writing the REPL a joy. (Of course it would be possible to do without such mechanisms... but the code would look like a huge sack of potatoes..instead of the 25 relevant lines I have now)
[I'd post the code on Tech Board/GD when done.. and you'd see what I mean]

>In C, what you can't do with normal if (!work) error handling cascades can be done with assert()
Fine when debugging...but not when you have any intention of letting the program recover.


> But I don't see why C++ has to justify its syntax in relation to C.
Human nature. (like those 'insightful' articles about iGadgetFoo being 0.0025% thinner than normalGadgetBar )

Originally Posted by manasij7479

> AFAICT their significance has to do with calling destructors properly and the fact that constructors can't return NULL
AFAIK it also resets the stack...rolling back changes until the place where the 'catch' block is there.

So does returning a NULL pointer from a function call. Again, I'd bet money that is the whole origin of the "exception" concept.

>How meaningful is a "tidier" mistake?
I'd say..very much. I'm currently trying to write a small lisp interpreter...and exceptions made writing the REPL a joy.

What I meant was, not catching a C++ exception results in abort. In C, not checking for a NULL ptr will probably lead to a seg fault. In a sense, not catching an exception is tidier, but:

A) this is only relevant if, eg, your destructor must save some data to disk before abort.
B) if it is so relevant, why don't you just the catch the exception/check for NULL??? Not doing so when it is possible constitutes a bug IMO.

But if you do use try..catch and if(!) properly, they can accomplish much the same thing.

(Of course it would be possible to do without such mechanisms...

I think they are needed in C++, but would be meaningless in C because there is no situation whereby you cannot simply return NULL.

>In C, what you can't do with normal if (!work) error handling cascades can be done with assert()
Fine when debugging...

Yeah, that's what I meant. Exceptions can be used the same way (stick in a throw() to trace a problem). I don't actually do either thing, I just use fatal(message) functions for stuff like that, but to each their own.

but not when you have any intention of letting the program recover.

Here's a fairly common C tactic:

Code:

someThing *new_someThing () {
        someThing *obj = malloc(sizeof(someThing));
	[blah blah blah]
	if (problem) goto fail;
	[blah blah blah]

	return obj;

fail:
	free(obj);
	reset(other stuff);
	// and or
	destroy(&obj);
	return NULL;
}

This cleans up and returns NULL. So rather than using try...catch cascades from Inner to Outer to main(), etc, you use if (!).