Is sf::GlResource not missing an explicit copy constructor?

[kralo9]

GlResource::GlResource()
{
    ...
        // Increment the resources counter
        count++;
    ...
}
 

As far as I can tell, every created instance of GlResource increases the count. I am just wondering, why there is no copy constructor defined that would increase it, too?

The default copy constructor just copies all attributes (which is none).

Therefore, if I am not fully mistaking, it is possible to cause a call to ensureContext() after globalCleanup(), because the count is smaller than the actual number of GlResource instances.

Please tell me, if I am missing something.


EDIT: I just tested, whether a copying of a derived class really calls the parent's copy constructor. And it does. I also tested it without explicit declaration of a copy constructor and the default one is called. Thus, my thoughts are correct. But maybe SFML handles it another way.

[Laurent]

Hmm... I'd say that you're right. This looks like an omission, but I'll check the sources to make 100% sure it is not on purpose.

[binary1248]

What you are forgetting is that any (even the implicitly) declared base class copy constructor has to be explicitly called by the derived class copy constructor, else the base class constructor will be called instead. GlResource does have an implicitly declared and defined copy constructor, but since none of the derived classes explicitly call it, its normal constructor is called instead, thus incrementing the reference count as expected every time a GlResource is copy constructed.

Here is a demonstration of this.

[kralo9]

What you are forgetting is that any (even the implicitly) declared base class copy constructor has to be explicitly called by the derived class copy constructor, else the base class constructor will be called instead. GlResource does have an implicitly declared and defined copy constructor, but since none of the derived classes explicitly call it, its normal constructor is called instead, thus incrementing the reference count as expected every time a GlResource is copy constructed.

Here is a demonstration of this.

I tested this and I disagree.

[binary1248]

Mind showing us your test then?

I showed you mine, and the result speaks for itself.

[kralo9]

Mind showing us your test then?

I showed you mine, and the result speaks for itself.

Oh, sorry. I did not test with an explicit copy ctor of a derived class. You are right. This calls the parent's ctor if not defined explicitly.

But still, an implicit copy ctor on both classes causes the counter not to increase. I would recommend adding an explicit copy ctor to sf::GlResource nevertheless. Just for safety.

[Laurent]

What's the point of arguing? Since it can be called, it must be defined, so that it does what it's supposed to do.

[kralo9]

What's the point of arguing? Since it can be called, it must be defined, so that it does what it's supposed to do.

If you call the default copy ctor of a derived class the default copy ctor of the parent will be called too. That is the point.

[Laurent]

If you call the default copy ctor of a derived class the default copy ctor of the parent will be called too. That is the point.

Yes. That's what I'm saying: since it can be called we must define it instead of using the incorrect generated one. I was saying that there's no point arguing against it. Sorry if that was not clear from my previous post.

[kralo9]

Yes, I misunderstood that.