Thread: C++ Annotations

  1. #1
    [](){}(); manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    *nullptr
    Posts
    2,657

    C++ Annotations

    C++ Annotations | Free Development software downloads at SourceForge.net
    I just stumbled upon it....( seeing a package attributed to it on my package manager )

    So far.. it looks *very* good and much more extensive than any C++ book I've read.
    It even has C++11 articles in certain places.
    (..and some topics I failed to find satisfactorily with STFWing ... like implementing reverse iterators, allocators ..etc )

    Any opinions? (Wonder why I never heard of it before...)

  2. #2
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    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.
    Last edited by MK27; 11-30-2011 at 06:15 AM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  3. #3
    [](){}(); manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    *nullptr
    Posts
    2,657
    >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"

  4. #4
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by manasij7479 View Post
    >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.
    Last edited by MK27; 11-30-2011 at 07:22 AM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  5. #5
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by MK27 View Post
    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.
    Last edited by MK27; 11-30-2011 at 09:49 AM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  6. #6
    [](){}(); manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    *nullptr
    Posts
    2,657
    > (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.
    Last edited by manasij7479; 11-30-2011 at 10:05 AM.

  7. #7
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by manasij7479 View Post
    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.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  8. #8
    [](){}(); manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    *nullptr
    Posts
    2,657
    > 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 )
    Last edited by manasij7479; 11-30-2011 at 11:36 AM.

  9. #9
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by manasij7479 View Post
    > 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 (!).
    Last edited by MK27; 11-30-2011 at 12:22 PM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

Popular pages Recent additions subscribe to a feed