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

Read about exceptions.
http://en.wikipedia.org/wiki/Exceptions

NO EXCEPTIONS!

>>2
Thank you for your contributing post.

Anyway my idea of going about this is that the constructor checks for errors,throws an exception if anything is awkward, if not initializes the data members.

And the object is destroyed if an exception was thrown.

Is this a sound solution?

>>3
Yeah, that's pretty much it.  If the exception is thrown, the object is never created, so you don't need to explicitly destroy the object (ie. call the deconstructor).

Make the constructor private and use a static "create" member function that validates the constructor parameters and either returns a new object if they were OK or a NULL pointer if they weren't.

There's probably some faggy pattern name for this, but that's too ENTERPRISE TURKEY SOLUTIONS for me.

>>5
Unless he wants information about how/why the parameters are invalid, then using exceptions would be better.

>>5
In other words, use C, and fuck sepples. Sound advice, anon.

>>6
Exceptions are never better, NO EXCEPTIONS!

>>7,8
Cool NS_ENSURE_SUCCESS() / SVN_ERR() / APR_SUCCESS_CHECK() / if() < 0 return -1 every fucking call, bro.

>>9
cool exception safe code in seeples, bro

>>1
Yep, throw. It's the only way. http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.17

Actually what you should do, is take your laptop, lock yourself in your basement, and absorb the entire C++ FAQ Lite. Then you might start to get some basic understanding of sepples. Don't feel bad; it's not actually possible for anyone to be good at sepples.

it's not actually possible for anyone to be good at sepples.
This is why we learn to handle all our OOP needs (if any) in C.

>>11
Don't forget to read the unfaq too.

>>1
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?
No. You should abort(). Let whatever fucker is using your code know that you won't tolerate his bullshit.

You should never attempt to recover from 'stupid programmer' errors; the louder you make it complain, the quicker the bug will be fixed, and vice versa.

In general, if you need to signal constructor failure for a valid reason which the app might reasonably encounter in the real world and from which it can recover, you should throw. An example is if it needs to open a file that doesn't exist. But never litter your code with throw statements for stupid bullshit. Every throw statement in the app is a massive maintenance and audit headache.

it's like nobody actually understands OOP
It's hardly surprising when I've heard at least 50 different versions of what OOP means

>>15
How can I learn to "understand OOP" properly?

>>15
WTF? I have an object representing an on-disk data structure which has methods for reading and manipulating it. Why the fuck would this not open a file? Why the fuck would the constructor not fail if it can't access the data structure it's supposed to represent?

Is my solution not fucking complicated and enterprise enough? Is that it? Do I need an ObjectFileProtocol and a FileSecurityPolicy and a FileAccessorFactory? No. The constructor opens the file and the destructor closes it. The methods manipulate the data. Simple, RAII, encapsulated, exception safe. How is this not object oriented?

>>15
Also, how the fuck is opening a file in a constructor a 'heisenbug'? It's a very obvious and explicitly defined point of failure; if the file doesn't exist, this constructor will throw. You need to catch this somewhere and display an error to the user.

We used to say heisenbugs are the kind of bugs that disappear when you try to debug them. I don't think that word means what you think it means.

irc.freenode.net ##C

>>19-20
：，（

Each anon's death diminishes me,
For I am involved in EXPERT PROGRAMMING.
Therefore, send not to know
For whom the /prog/ trolls,
It trolls for thee.

>>15
protip: std::ifstream
>>19
>How is this not object oriented?
It's seeples, it can't be object oriented.

>>5

It's called [[NSObject alloc] init].

>>24
A far superior solution, but the OP stated he's bound by sepples.

CONSTRUCT MY ANUS

>>26
my troll-sense is tingling

Ding-a-ling-a-ling!

>>28
You can sense danger like a troll?

>>4
This might be considered splitting hairs, but the object is indeed "created" prior to invoking the constructor; as in, memory is set aside for the data members, they simply aren't set to anything meaningful prior to construction. 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.

>>29
Dong-a-long-a-long!

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

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

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

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

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

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

Ain't sepples great?

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