Thread: c++ equivalent for C#'s "sealed override"?

OMG. What is this nonsense?
It's not destroyed. It returns a new instance which can be used for whatever you want. In bithub's example, it is indeed destroyed directly, but that is the fault of the demonstrated code, not the design.

Ever heard of a factory? It usually uses a pattern like this, where the constructor is private.

Originally Posted by abachler

The class is instantly destroyed as soon as the create method returns. Returning this would be pointless. I'm not doing it wrong because I don't do it that way, it's your class, you did it wrong. All I did was add a few lines to return proof that it is fail.

How about you run the code before spouting off complete nonsense. Add prints to the constructor, copy constructor, and destructor, and learn what is actually going on. Also, it's not really my class. I took your code, and added a main() function. Remember?

It was brewbuck's code...

The code works. I don't know what example you are using but try this:

Code:

#include <iostream>
class NotInheritable
{
public:
static NotInheritable Create() { return NotInheritable(); }
    void foo() { std::cout << "foo\n"; }

private:
    NotInheritable() {}
};

int main()
{
    NotInheritable var = NotInheritable::Create();
    var.foo();
}

A key here is that though the default constructor is private, the copy constructor is not.

And no, you can't add code to return this, because Create is a static method.

And no, you can't add code to return this, because Create is a static method.

Which makes it useless as there is no way to access the class.

The code

Code:

#include <iostream>
class NotInheritable {
public:
    static NotInheritable Create() { return NotInheritable(); }
    void foo() { std::cout << this << "\n"; }

private:
    NotInheritable() {}
	};

int main(){
    NotInheritable var1 = NotInheritable::Create();
    var1.foo();
    NotInheritable var2 = NotInheritable::Create();
    var2.foo();
	}

at least works at producing usable classes, the code originally posted did not. Although I personally woudl never use this method as it seems to be much more work than simply using new. Particularly if you are creating the class in one thread and using it in another. This method would destroy the class when var1/var2 goes out of scope.

Originally Posted by abachler

You didn't take my code and add a main function, I didn't post that piece of crap class, you did. I ran the code to verify that it fails and immediately destroys the class, making it useless for anything but a collection of functions.

My mistake, brewbuck posted it, you just quoted it.

Originally Posted by abachler

As the modifications I made show, it destroys the class immediately after the method exits. It does NOT return a new instance at all, there is no way of accessing the class because it is ........ing destroyed as soon as the method returns, so even if you added code to return this, it would point to an invalid location that will crash if you try to access the class since it was ........ing destroyed.

That's where you're wrong. The class is copied. It is the equivalent to doing:

Code:

std::string get_string() { return std::string("hello"); }

void foo() { 
    std::cout << "size is " << get_string().size() << std::endl;
}

The object is copied before it is destroyed. That is why it is still valid for the caller.

True, you couldn't pass a reference to the temporary to another thread, but the same holds for any non-global variable from an unrelated scope. No problem, you just need to pass a copy to the thread. All it really boils down to, then, is that the class has to be copy-constructible. Even so, the compiler can still choose to employ "return value optimization" (RVO), in which case the temporary is eliminated altogether. For example, when I compile and run this:

Code:

int main( void )
{
	example
		copy = example::create( );
	copy.print( "1" ).print( "2" ).print( "3" )
		.print( "4" ).print( "5" ).print( "6" ).print( "7" )
		.print( "8" ).print( "9" ).print( "10" );
	return 0;	
}

...The output is:

0x43f003 : example( void )
0x43f003 : 1
0x43f003 : 2
0x43f003 : 3
0x43f003 : 4
0x43f003 : 5
0x43f003 : 6
0x43f003 : 7
0x43f003 : 8
0x43f003 : 9
0x43f003 : 10
0x43f003 : ~example( void )

So, the code that was originally posted by Brewbuck was neither broken nor poor design - it's a perfectly sound solution to the problem, actually. Of course, personally, I'd never use it - I don't even bother with protected/private encapsulation in my own code, most of the time. The way I see it, if I don't want to have easy access to the internals, I can just mangle the member names - that way, if I really *do* need to mess with things, I can...the obfuscated identifier is reminder enough that I'm flirting with disaster!

Originally Posted by abachler

It's poor design, regardless of whether or not it compiles and runs.

I've never heard of the factory pattern being a poor design before.