C++, "canceling a construction"

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 :)

>>78
how about no !

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.

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

>>83
Like a binary dicks tree?

>>82
eg ruby!

>>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.

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

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.

>>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).