Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

C++, "canceling a construction"

Name: Anonymous 2009-11-04 15:25

Hi /prog/

My is simple, but perhaps not so frequent.

How should I stop a construction of an object (c++)?

Basically I have a class with some data members which must fulfill some requirements. Say we initialize these data members upon construction, if the supplied values were erroneous then I guess I want to stop construction and throw an error. Is this the right idea? How do I "cancel the construction"?

Help much appreciated :)

Name: Anonymous 2009-11-05 23:42

>>31
By the C++ standard, an object is not created until the "return" statement of the constructor is being executed.

Name: Anonymous 2009-11-06 2:19

>>33
I think you've misunderstood my post, though like I said this is kind of arguing semantics. Suppose you had a class containing two 4-byte integers, using 1 byte padding with no virtual table for simplicity, making the object size 8 bytes.

When you declare an instance of this object, 8 bytes will be set aside for this object on the current stack frame, prior to invoking the constructor. A pointer to the beginning of this block of 8 bytes is passed into the constructor as the 'this' parameter.

If an exception is thrown, this block of 8 bytes continues to exist until the stack is unwound in the epilog stub of the calling function.

I feel it's erroneous to state that an object isn't created if an exception is thrown, as this implies there are absolutely zero side-effects if this occurs, when, from the point of view of the generated machine code, this isn't the case.

Name: Anonymous 2009-11-06 3:46

>>34
Not >>33-chan here, but you can't just dismiss it as a semantic argument; the semantics are *extremely* important. In C++ lingo creation is synonymous with construction. The object is said to exist only when its constructor has successfully completed execution. If it does not successfully complete, the object never existed.

I feel it's erroneous to state that an object isn't created if an exception is thrown, as this implies there are absolutely zero side-effects if this occurs
It does not imply that at all. What sane rational person would expect no side effects from something that throws an exception??

Besides, it's extremely rare that you need to worry about the side effects, since allocated memory using new is automatically released (as are stack objects of course) which has effectively no side effects (certainly no performance issues comparable to propagating the resulting exception). You only need to worry about the side effects if you are writing an overloaded new operator, or using placement new on some manually allocated memory, or some other perversion of the allocation system.

I should point out that if you have allocated any memory in the constructor prior to the exception being thrown, you must make sure that that memory is reaped from inside the constructor.
Yes, this is unfortunately a common error. The resulting constructors are ass-ugly too if you try to do it with try/catch (it almost looks as bad as Java). The vast majority of these issues are solved with a simple smart pointer though; it only gets ugly if you are e.g. filling an array with allocated objects and one of them throws. Boost's pointer containers help.

This is honestly the biggest reason I am looking forward to sepplesox. With move semantics and perfect forwarding, there is now the universal unique_ptr for unique ownership. Finally a smart pointer with *zero* overhead of any kind which you can safely put in containers, return from functions, etc. There is no excuse to have an allocated bare pointer anymore.

Name: Anonymous 2009-11-06 3:58

>>32
Dung-a-lung-a-lung!

Name: Anonymous 2009-11-06 7:33

>>35 since allocated memory using new is automatically released
Oh hi there, memory leaks.

Name: Anonymous 2009-11-08 7:35

>>1
Too little info. Where does the data for the object come from?

If you expect the data for the object to be bad from time to time (like when it's coming directly from user input), then I'd wager wrapping the construction in a builder class would be appropriate.

If you're thinking of doing assertions for debugging purposes  (checking pre- and post-conditions) then just throw an exception.

Name: Anonymous 2009-11-08 8:12

Ain't sepples great?

Name: Anonymous 2009-11-08 16:57

>>38
If you're thinking of doing assertions for debugging purposes  (checking pre- and post-conditions) then just throw an exception.
No, no, no. Fucking Java programmers fucking everything up.

Name: Anonymous 2009-11-08 17:26

>>40
Quoting the C++ FAQ Lite Section 17:
[17.2] How can I handle a constructor that fails?
Throw an exception. (...)

[17.12] Exception handling seems to make my life more difficult; clearly I'm not the problem, am I??
(...) Here are some "wrong exception-handling mindsets" in no apparent order:
(...)
Confusing logical errors with runtime situations: For example, suppose you have a function f(Foo* p) that must never be called with the NULL pointer. However you discover that somebody somewhere is sometimes passing a NULL pointer anyway. There are two possibilities: either they are passing NULL because they got bad data from an external user (for example, the user forgot to fill in a field and that ultimately resulted in a NULL pointer) or they just plain made a mistake in their own code. In the former case, you should throw an exception since it is a runtime situation (i.e., something you can't detect by a careful code-review; it is not a bug). In the latter case, you should definitely fix the bug in the caller's code. You can still add some code to write a message in the log-file if it ever happens again, and you can even throw an exception if it ever happens again, but you must not merely change the code within f(Foo* p); you must, must, MUST fix the code in the caller(s) of f(Foo* p).

Name: Anonymous 2009-11-08 17:37

>>41
Good job retard, read my post from earlier: >>14

The whole point is to fix the code in the CALLERS. The best way to accomplish that (which the faq fails to mention) is to abort().

Also, I completely disagree with the FAQ about throwing an exception when a null pointer might have resulted from user input. That's plain fucking brain dead. Input validation should happen WAY sooner and should be very encapsulated; throwing exceptions is very much not the right way to handle bad user input.

Name: Anonymous 2009-11-08 19:23

>>42
Don't forget the FQA.

http://yosefk.com/c++fqa/

Name: Anonymous 2009-11-09 5:38

>>42
So what you're saying is that when you're shipping code, the best way to find the cause of a bug is to just call abort()?

May I ask how, the fuck, do you expect to gather debugging information after that? Have you ever used a logging facility of any kind, besides stderr? Do you write anything else then toy programs?

Also, I completely disagree with the FAQ about throwing an exception when a null pointer might have resulted from user input. That's plain fucking brain dead.

It's just like I'm in CS III again!

Name: Anonymous 2009-11-09 6:18

It's just like I'm in CS III again!
Welcome to /prog/

Name: Anonymous 2009-11-09 6:27

>>45
What? But I haven't left /prog/ since 2004!

Name: Anonymous 2009-11-09 14:06

>>44
So what you're saying is that when you're shipping code, the best way to find the cause of a bug is to just call abort()
No genius, you never call abort() directly; you assert() to verify the arguments. abort() is caught by debuggers giving you a stack trace, and for QA testers it's extremely easy to write your own replacement to throw up a dialog or output debug info and stop execution. QA just sends uploads the log file or a screenshot of the dialog in their bug report (on some platforms you have no log support; e.g. on iPhone we use a popup dialog). I wrote this facility at work, it's not fucking difficult.

And the abort()s can then disappear in production, but they don't have to. Honestly now, if you encounter an error in production that was *not once* reproduced in QA, how is throwing an exception at all better than giving the end-user a dialog with debug info? Seems far worse to me; it's not possible to write code able to gracefully handle 'any exception anywhere', so most likely your program will crash horribly.

Throwing an exception is a *horrible* idea, because if it's caught then QA can't give you reliable debug information (reflection on stack traces doesn't exist in sepples remember), and if it isn't caught then the app just crashes.

And I just want to clarify before some troll trolls this: this is *NOT!!!* how you validate user input. You do that separately, at the point the input is received, without exceptions or any other bullshit.

Name: Anonymous 2009-11-09 14:15

>>44
I just want to doubly highlight the stupidity of this:

the best way to find the cause of a bug is to just call abort()? May I ask how, the fuck, do you expect to gather debugging information after that?
You can't gather debug information *AT ALL* from exceptions. They don't even have a stack trace. Sepples exceptions are *entirely useless* for debugging.

On the other hand, you can replace abort() to take __LINE__ and __FILE__, and you'll know exactly what's wrong locally (and there are platform-specific tools to run through the linked-list on the stack; if you include a debug symbol table for your QA builds you can easily get a full stack trace out of it). This also works in and across C code, not just sepples bullshit.

And most importantly, debuggers halt on SIGABRT, so you can easily investigate the call stack interactively (as opposed to your app dying due to an uncaught (or worse, caught with ...) exception, and setting up your debugger to catch specific exception types, and trying to replicate it and stepping through all the ones you aren't interested in...)

Name: Anonymous 2009-11-09 14:18

>>48
One last note, as is mentioned repeatedly in the FQA, this is not the state of affairs in sane languages; almost every other language with exception support has garbage collection, reflection, stack traces, etc. You know, things that make exceptions actually *possible to use*, let alone *good*.

Name: Anonymous 2009-11-09 14:18

Dammit /prog/, why do you make me argue on the internets?

Name: Anonymous 2009-11-09 14:19

Who ever claimed you have to debug code before shipping it? It's not like end-users mind helping you as free beta-testers!

Name: Anonymous 2009-11-09 15:50

>>47-49
No genius, you never call abort() directly; you assert() to verify the arguments.
Really? Tell me more.

abort() is caught by debuggers giving you a stack trace, and for QA testers it's extremely easy to write your own replacement to throw up a dialog or output debug info and stop execution.
How is it easier than catching the exception, writing down all the information you can for debugging and showing an error dialog?

You can't gather debug information *AT ALL* from exceptions. They don't even have a stack trace. Sepples exceptions are *entirely useless* for debugging.
http://www.ibm.com/developerworks/linux/library/l-cppexcep.html

On the other hand, you can replace abort() to take __LINE__ and __FILE__, and you'll know exactly what's wrong locally (and there are platform-specific tools to run through the linked-list on the stack; if you include a debug symbol table for your QA builds you can easily get a full stack trace out of it). This also works in and across C code, not just sepples bullshit.
You can do that with exceptions too with an equal amount of work. It also means you'll be using a C++ facility instead of a C workaround in C++!
That's why exceptions exist in the first place: to replace assert() and abort() with an alternative which can provide more information.

And most importantly, debuggers halt on SIGABRT, so you can easily investigate the call stack interactively (as opposed to your app dying due to an uncaught (or worse, caught with ...) exception, and setting up your debugger to catch specific exception types, and trying to replicate it and stepping through all the ones you aren't interested in...)
You don't have the appropriate tools to develop with C++ if that's a problem.

Everyone in the industry used abort() and assert() in C++ because:
a) Most people didn't bother to learn to use them and carried over their C habits.
b) Everyone who bothered had been bitten by poor compiler support (at the time)
c) No tools
Again: abort() and assert() were used instead as a workaround.
Today all those points are moot but somehow everyone sticks to the notion that C++ exceptions aren't worth using because they aren't Java exceptions.

C++ exceptions don't have the features of Java exceptions but they're heaps better than the C workaround you're using.

You know what's sad? You probably mean well but you're stuck with people who don't know any better. We wouldn't have this argument if Sepples wasn't a pile of pre-standard legacy code, bad practices and emergent features (i.e. a humongous pile of shit). It's a fucking mess stretched over the years.

Name: Anonymous 2009-11-09 15:53

>>52
a) Most people didn't bother to learn exceptions and carried over their C habits.
b) Everyone who bothered had been bitten by poor compiler support for exceptions (at the time)
Fixed.

Name: Anonymous 2009-11-09 16:02

>>53

a) Sepples sucks ass.

Fixed.

Name: Anonymous 2009-11-09 16:03

Plato imagines a group of people who have lived chained in a cave all of their lives, facing a blank wall. The people watch shadows projected on the wall by things passing in front of a fire behind them, and begin to ascribe forms to these shadows. According to Plato, the shadows are as close as the prisoners get to seeing reality. He then explains how the philosopher is like a prisoner who is freed from the cave and comes to understand that the shadows on the wall are not constitutive of reality at all, as he can perceive the true form of reality rather than the mere shadows seen by the prisoners.

Name: Anonymous 2009-11-09 16:07

I was browsing the bookstore today, and I saw this:
http://www.amazon.co.uk/Programming-Principles-Practice-Using-C/dp/0321543726/ref=sr_1_1?ie=UTF8&s=books&qid=1257800650&sr=8-1

Preparation for Programming in the Real World

The fucking audacity of the guy! He's a complete failure as a language designer, heaping layers of dung on older layers of dung resulting in a monumental pile of shit that no-one can understand or use "properly." Modern sepples is the real toy language, not Haskell or Lisp.

Name: Anonymous 2009-11-09 16:10

>>55
cave = sepples, and philosopher = lispnik, i assume?

Name: Anonymous 2009-11-09 16:19

>>57

Wrong. Philosopher = Smalltalk-programmer.

It sems that the days of warrior-poets and philosopher-kings are long gone by now.

Name: 52 2009-11-09 16:25

>>55
I've read SICP. Sepples just pays the bills.

Name: Anonymous 2009-11-09 17:57

>>52
You can do that with exceptions too with an equal amount of work. It also means you'll be using a C++ facility instead of a C workaround in C++!
Holy shit dude. You tell me sepples' exception support is better by pointing me to a processor-and-compiler-and-kernel-specific hack to get stack traces. The article has 'tricks for Linux' in the title for crying out loud. And that's not a workaround...

Yes, it's the same thing I was talking about with abort(). At least I admit that it's a hack! None of this exception support you rave about is even widely supported, let alone standardized. We don't all program for x86. We don't all program for Linux. We don't all compile with GCC or Intel. Keep drinking that kool-aid buddy.

That's why exceptions exist in the first place: to replace assert() and abort() with an alternative which can provide more information.
You haven't given more information at all! All you've proven is that the same hacks I've been using to get stack traces with abort() are available with exceptions (in an even more convoluted way, in the constructor to all your user-defined exceptions; good luck doing that with std::logic_error, std::range_error, etc.)

c) No tools
Why the fuck should you need tools to interpret something that is supposed to be a standard feature of the language? What possible tools could these be? I need a p-and-c-and-k-specific library for stack traces? I need the app to actually be hooked up to the debugger? What the fuck?

This is why people don't use sepples exceptions. They are just plain incomplete.

Also, you keep saying assert() is a workaround. What a joke.

Name: Anonymous 2009-11-09 18:05

>>55
so basically.
HURRRR DURRR LOOK AT ME, I"M SUCH A FREE THINKING UBER COOL REBEL
Plato

Name: Anonymous 2009-11-09 18:23

exception handling is easy and complete in C.
much better than sepples.
if(function == -1)
   err(1, "function()");

Name: Anonymous 2009-11-09 20:59

NO EXCEPTIONS

Name: Anonymous 2009-11-09 23:26

>>61

Why are so many delusional people on the internet?

Name: Anonymous 2009-11-10 0:30

don't feed constructors incorrect data, dipshit.

Name: Anonymous 2009-11-10 1:06

>>64
are you telling me that you think that quote from Plato isn't an incredibly egotistical crock of shit?
philosophy fags like you (and him) are incredibly shallow

Name: Anonymous 2009-11-10 6:01

>>66
Plato will still be remembered in 300 years.  You will not.

Name: Anonymous 2009-11-10 10:48

>>67
thats deep bro

Name: Anonymous 2009-11-10 18:13

>>67
how pessimistic.
for all you know, i could be bill gates

Name: Anonymous 2009-11-10 18:15

>>69
how pessimistic.
for all you know, i could be steve ballmer

DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS

Name: Anonymous 2009-11-10 18:15

>>69
not if he's bill gates

Name: Anonymous 2009-11-10 18:16

>>70
am i the only one who thinks ballmer is awesome?

Name: Anonymous 2009-11-10 18:39

>>72
yup

Name: Anonymous 2009-11-10 20:29

>>72
Yes, Steve.

Name: Anonymous 2009-11-11 7:41

>>60
Holy shit dude.
Uh-huh.

You tell me sepples' exception support is better by pointing me to a processor-and-compiler-and-kernel-specific hack to get stack traces. The article has 'tricks for Linux' in the title for crying out loud. And that's not a workaround...
Stack traces are platform specific to begin with. Most OSes which support C++ development have their own API for retrieving stack traces from exceptions. If you'd like a cross-platform method then you'd need to to abstract away your platform. Sounds familiar?

Yes, it's the same thing I was talking about with abort(). At least I admit that it's a hack! None of this exception support you rave about is even widely supported, let alone standardized.
You've maybe heard of the C++ standards committee and their the `C++98 standard'. Last I heard, most of it has been implemented by many of the major available C++ compilers for a while.

We don't all program for x86. We don't all program for Linux. We don't all compile with GCC or Intel.
I'm at a loss here. What are you trying to say? I've never implied I'm talking about anything platform specific. If you are working with a platform without exception support then it's not the language that's at fault?

Keep drinking that kool-aid buddy.
Riiiiiight. Moving right along.

You haven't given more information at all! All you've proven is that the same hacks I've been using to get stack traces with abort() are available with exceptions
Now we're getting somewhere.

(in an even more convoluted way, in the constructor to all your user-defined exceptions; good luck doing that with std::logic_error, std::range_error, etc.)
If it's convoluted then you're doing it wrong. For example you don't mix user-defined and STL exceptions. You choose either and stick with it throughout your application/system/library. Just like in C, practically every non-trivial library uses it's own error handling facility. Exceptions provide a single, standardised error handling facility.

Why the fuck should you need tools to interpret something that is supposed to be a standard feature of the language? What possible tools could these be? I need a p-and-c-and-k-specific library for stack traces?
Yeah, what the fuck. Why do I need a debugger, a compiler, a text editor. Ad nauseum.

I need the app to actually be hooked up to the debugger? What the fuck?
Sigh. Java exceptions are so good basically because every application runs inside a debugger. You won't get that with a static language without OS-specific extensions. Period.

This is why people don't use sepples exceptions. They are just plain incomplete.
The point I'm trying to make is that they were incomplete a long time ago. Every dipshit with an opinion keeps reiterating an age old mantra without actually understanding what C++ exception were meant to accomplish. It's just like everyone who read a 10-year old book about C++ thinks the language is written in stone.

Also, you keep saying assert() is a workaround. What a joke.
It's a C facility, not C++. As I said, the compatibility between the two allowed developers to work around the fact that exception weren't properly implemented yet. Since they are supported by compilers available today, the reason to avoid exceptions in new applications is long gone.

Name: Anonymous 2009-11-11 9:26

>>75
Stack traces are platform specific to begin with
...because the C++ standard does not support them.

You've maybe heard of the C++ standards committee and their the `C++98 standard'
...which does not include stack traces.

Why the fuck is this so hard to understand? Languages like Java or Python include stack traces, and these are available in a portable way inside the application itself. C++ could have done this. It could have been a requirement of the standard.


Why is this so hard to understand?


If it's convoluted then you're doing it wrong. For example you don't mix user-defined and STL exceptions. You choose either and stick with it throughout your application/system/library.
Wow, this is some terrible exceptions advice. You are *always* supposed to subclass std::exception to create your own exceptions. You can't get away from built-in exceptions without getting rid of the entire STL (and replacing new so that it doesn't throw).

Exceptions provide a single, standardised error handling facility.
You mean, if you choose either STL or custom exceptions and hope every library you use does the same? Isn't this the very opposite of what you just said?

Name: Anonymous 2009-11-11 9:28

>>76
NICE TRY BUDDY, BUT YOU HAVE TO GET UP PRETTY EARLY IN THE MORNING TO TROLL ME

Name: Anonymous 2009-11-11 9:32

STOP TALKING ABOUT PROGRAMMING!!!

Name: Anonymous 2009-11-11 9:33

>>77
Ah, false claims of trolling, the last refuge of a /b/tard

Name: Anonymous 2009-11-11 10:15

>>79
nice try buddy. but im still not biting. no one could be so retarded as >>76

Name: Anonymous 2009-11-11 10:35

>>78
how about no !

Name: Anonymous 2009-11-11 10:39

Sepples is the greatest programming language ever created, because as people get fed up with how shit it is they may be inspired to create languages that are actually good.

Name: Anonymous 2009-11-11 10:40

>>78
YEAH, LET'S TALK ABOUT HOW TO RECOGNISE DIFFERENT TYPES OF TREES FROM QUITE A LONG WAY AWAY

Name: Anonymous 2009-11-11 10:42

>>83
Like a binary dicks tree?

Name: Anonymous 2009-11-11 11:06

>>82
eg ruby!

Name: Anonymous 2009-11-11 13:00

>>76
Why the fuck is this so hard to understand? Languages like Java or Python include stack traces, and these are available in a portable way inside the application itself.
You're comparing apples to oranges. C++ is a static language.
One is inside a VM which, like I said, provides a debugger. The other is a dynamic, interpreted (or byte-code compiled) language which also provides a debugger.

C++ could have done this. It could have been a requirement of the standard.
Why is this so hard to understand?

It could include that but then no compiler would've implemented it. Platform independent stack traces so close to the metal are hard to do right.

Wow, this is some terrible exceptions advice. You are *always* supposed to subclass std::exception to create your own exceptions. You can't get away from built-in exceptions without getting rid of the entire STL (and replacing new so that it doesn't throw).
Yes, except no, you are wrong. From the C++ FAQ Lite, 17.6:
If possible, you should throw instances of classes that derive (ultimately) from the std::exception class.

You mean, if you choose either STL or custom exceptions and hope every library you use does the same? Isn't this the very opposite of what you just said?
What I meant is that with the try/catch mechanism you can catch both. When programming in C you have to implement some kind of replacement try/catch for error handling and interface with custom error handling procedures of your libraries.

Name: Anonymous 2009-11-11 14:14

>>86
You are being far too flattering if you call those debuggers

Name: Anonymous 2009-11-11 19:08

You're comparing apples to oranges. C++ is a static language. One is inside a VM which, like I said, provides a debugger. The other is a dynamic, interpreted (or byte-code compiled) language which also provides a debugger.
Okay first of all, a VM is not a debugger. Second of all, what does interpreted have to do with exceptions??

Correct me if I'm wrong folks, but doesn't Lisp support stack traces even when compiled statically (to C code)?

It could include that but then no compiler would've implemented it. Platform independent stack traces so close to the metal are hard to do right.

You don't seem to understand how the stack is built. The stack is not restricted by the 'bare metal' in any way; it's a compiler construct. C stack traces are difficult to decipher because of how the compiler builds them. There is nothing that says C++ has to grow its stack the same way. It could push a freaking C string with the function name into every stack frame if it wanted. This would be extremely easy. But it doesn't. Compiled apps have complete control over how the stack grows; for example Go uses a segmented stack.

The argument about 'difficult to implement' is total bullshit. The compiler already has to add stack unwinding information, which is vastly more complicated than just getting the names of the stack frames.

You are *always* supposed to subclass std::exception to create your own exceptions.
you are wrong. From the C++ FAQ Lite, 17.6:
If possible, you should throw instances of classes that derive (ultimately) from the std::exception class.
Okay dude, I don't know what to say anymore. Are you trolling? Did you quote the wrong faq answer? Because this is not a rational debate anymore.

What I meant is that with the try/catch mechanism you can catch both. When programming in C you have to implement some kind of replacement try/catch for error handling and interface with custom error handling procedures of your libraries.
Um, no. The 'return status code' mechanism works really well, and is the most consistently used in C (it's used proportionally far more than exceptions are used in C++). Companies like Google have millions of lines of C++ code, and they do fine without exceptions.

And if a library really needs you to implement a replacement try/catch, it's really not a big deal dude. Ever integrated libpng into a project? It's pretty awesome. You just do this before you start decoding:

if (setjmp(png_jmpbuf(png_ptr))) {
  png_destroy_read_struct(&png_ptr, &info_ptr, &end_info);
  // do whatever you want here, show the user a dialog, etc
  return 0;
}

All of this is always documented very well. And if you don't like it, libpng has a simple preproc you just turn off to get plain old 'return ERROR' style error handling.

Name: Anonymous 2009-11-11 19:15

>>88
Correct me if I'm wrong folks, but doesn't Lisp support stack traces even when compiled statically (to C code)?

Yes, you can even get info about the C stack frame too, if you have some C runtime included, and copious information about the parameters and maybe even local variables of your functions in the stack frame if you compiled your functions with enough debug info (compiling is per code unit, which is most oftenly a function).
Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode -