curiosity singleton pattern?

C

Chris Forone

hello group,

cant understand the following:

Scene* Scene::sole(0); // in Scene.cpp

class Scene // singleton in Scene.h
{
public:
static Scene* Get()
{
//return sole ? sole : new (std::nothrow) Scene;
return sole; // for testing purposes only
}

int Print(void) // normaly only with valid objects?!
{
return reinterpret_cast<unsigned int>(sole);
// other values also possible (return 10;)
}

protected:
Scene();
~Scene();

private:
static Scene* sole;
};

int main(void)
{
std::cout << Scene::Get() << std::endl;
std::cout << Scene::Get()->Print() << std::endl;
}

returns

0
0

non static func Print is called by nullpointer?! have gcc 4.1 and linux os.

thanks for your answers
sincerely yours
chris
 
I

Ian Collins

Chris said:
hello group,

cant understand the following:

Scene* Scene::sole(0); // in Scene.cpp

class Scene // singleton in Scene.h
{
public:
static Scene* Get()
{
//return sole ? sole : new (std::nothrow) Scene;

Why is this line commented out?
return sole; // for testing purposes only
}

int Print(void) // normaly only with valid objects?!

We don't bother with the (void) in C++, just use ().
{
return reinterpret_cast<unsigned int>(sole);
// other values also possible (return 10;)
}

protected:
Scene();
~Scene();

private:
static Scene* sole;
};

int main(void)
{
std::cout << Scene::Get() << std::endl;
std::cout << Scene::Get()->Print() << std::endl;
}

returns

0
0

non static func Print is called by nullpointer?! have gcc 4.1 and linux os.
Why not? Don't forget that the object isn't used to call the member
function, which is just a plain old C function with an extra this
parameter, but is passed to the the function as the this parameter. In
your case, this isn't used.
 
A

Alf P. Steinbach

* Chris Forone:
hello group,

cant understand the following:

Scene* Scene::sole(0); // in Scene.cpp

class Scene // singleton in Scene.h
{
public:
static Scene* Get()
{
//return sole ? sole : new (std::nothrow) Scene;
return sole; // for testing purposes only
}

int Print(void) // normaly only with valid objects?!
{
return reinterpret_cast<unsigned int>(sole);
// other values also possible (return 10;)
}

protected:
Scene();
~Scene();

private:
static Scene* sole;
};

int main(void)
{
std::cout << Scene::Get() << std::endl;
std::cout << Scene::Get()->Print() << std::endl;
}

returns

0
0

What else did you expect, and why?

Have you tried, like, removing the out-commenting in Scene::Get?
 
C

Chris Forone

Alf said:
What else did you expect, and why?
some kind of runtime error... can access nonstatic func with NO VALID
object?!
Have you tried, like, removing the out-commenting in Scene::Get?
of course, normal behavior (address of valid object)
 
C

Chris Forone

Ian said:
Why is this line commented out?
for testing operator new not successful
We don't bother with the (void) in C++, just use (). sorry... ;-)
Why not? Don't forget that the object isn't used to call the member
function, which is just a plain old C function with an extra this
parameter, but is passed to the the function as the this parameter. In
your case, this isn't used.
sure?
 
J

James Kanze

cant understand the following:
Scene* Scene::sole(0); // in Scene.cpp
class Scene // singleton in Scene.h
{
public:
static Scene* Get()
{
//return sole ? sole : new (std::nothrow) Scene;
return sole; // for testing purposes only
}
int Print(void) // normaly only with valid objects?!
{
return reinterpret_cast<unsigned int>(sole);
// other values also possible (return 10;)
}

private:
static Scene* sole;
};
int main(void)
{
std::cout << Scene::Get() << std::endl;
std::cout << Scene::Get()->Print() << std::endl;
}


non static func Print is called by nullpointer?! have gcc 4.1
and linux os.

It's undefined behavior. Anything might happen. In practice,
on a modern general purpose machine, you will either get the
above results, or some sort of runtime error. Possibly
depending on the options you've passed to the compiler.
 
J

James Kanze

Ian Collins schrieb:>> //return sole ? sole : new (std::nothrow) Scene;
for testing operator new not successful

That's doubtlessly the most frequent implementation---it's
obvious, easy to implement, and on modern processors, very
efficient. It's certainly not guaranteed, however, and I've
used compilers where the your code would result in a runtime
error of some sort, and it's not too hard to imagine cases where
such code would cause other data to be overwritten.

Don't count on what an implementation "typically" does. The
next release of the compiler might do something different.
 
J

James Kanze


And yet you're wrong. That might be the behavior of the
compiler you're currently using, but it's not guaranteed, and
it's not the behavior of every compiler.
 
I

Ian Collins

James said:
And yet you're wrong. That might be the behavior of the
compiler you're currently using, but it's not guaranteed, and
it's not the behavior of every compiler.
OK, which one is different?
 
J

James Kanze

OK, which one is different?

The Green Hills compiler was, when I used it. (I'm not sure
what Green Hills is up to now.) And although I never used it,
from what I understand, the Centerline compiler used "fat"
pointers, and doubtlessly caught such errors as well. It
caught practically all pointer errors.

Way back when, the C committee made a great effort to specify
the language in such a way that all, or almost all, pointer
violations could be tested at runting, and result in run-time
errors, rather than random crashes or wrong results later. The
performance impact for this is fairly large, so it tends not be
done in commercial compilers, but given the improvements in
machine performance and the importance of avoiding such errors
in software connecting to the network, I wouldn't be surprised
if it didn't start appearing, at least as an option.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,772
Messages
2,569,591
Members
45,100
Latest member
MelodeeFaj
Top