子类化时覆盖静态变量
我有一个类,我们称之为 A,在该类定义中我有以下内容:
static QPainterPath *path;
也就是说,我声明一个指向路径对象的静态(类范围)指针; 此类的所有实例现在都将具有相同的共享数据成员。 我希望能够在这个类的基础上进行构建,将其子类化为更专门的形式、分层行为,并且每个类都有自己独特的路径对象(但不必重复计算边界框或调用绘画例程等无聊的部分) )。
如果我将其子类化以创建类 F(例如),我希望 F 使用从 A 继承的绘图例程,但使用 F 中声明的静态(类范围)路径对象。我尝试将上面的声明放在私有部分(并在派生类 F 中重复它),并尝试将其放在受保护部分中,但没有任何乐趣。
我可以理解为什么会发生这种情况:
void A::paint() {
this->path...
指的是 A::path 而不是 F::path,即使对象属于 F 类。
是否有一种优雅的方法来解决这个问题,并允许每个类维护一个静态路径对象,同时仍然使用基类中定义的绘图代码,并且所有类(可能基类除外)都是真实的且可实例化的?
I have a class, lets call it A, and within that class definition I have the following:
static QPainterPath *path;
Which is to say, I'm declaring a static (class-wide) pointer to a path object; all instances of this class will now have the same shared data member. I would like to be able to build upon this class, subclassing it into more specialised forms, layering behaviour, and with each class having its own unique path object (but not having to repeat the boring bits like calculating bounding boxes or calling the painting routines).
If I subclass it to create a class F (for example), I want F to use the inherited drawing routines from A, but to use the static (class-wide) path object declared in F. I have tried having the declaration above in the private section (and repeating it in the derived class F), and tried having it in the protected section, all with no joy.
I can sort of see why this is happening:
void A::paint() {
this->path...
is referring to A::path instead of F::path, even when the object is of class F.
Is there an elegant way to get round this, and allow each class to maintain a static path object, while still using drawing code defined in the base class, and having all classes (except perhaps the base class) be real and instantiatable?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(8)
使用虚方法来获取对静态变量的引用。
请注意,这里 B 是从 A 派生的。 然后:
Use a virtual method to get a reference to the static variable.
Notice that B derives from A here. Then:
您也许可以对混合或
我刚刚运行的 奇怪的重复模板模式进行变体这段代码在CodeBlocks中得到以下结果:
You might be able to do a variant on a mix in or Curiously recurring template pattern
I have just run this code in CodeBlocks and got the following:
我还没有测试过这个,但是引入一个虚函数:
可能是你想要的。 请注意,您仍然需要在某处定义两个静态变量:
I haven't tested this, but introducing a virtual function:
may be what you want. Note you still have to define the two statics somewhere:
您可以使用虚函数来实现您的结果。 这可能是您最干净的解决方案。
You can use virtual functions to achieve your result. This is probably your cleanest solution.
我知道这个问题已经得到解答,但是还有另一种方法可以通过辅助类和一些模板专门化来为多个类设置类似的静态变量的值。
它并没有完全回答这个问题,因为它与子类化没有任何关系,但我遇到了同样的问题,并且我找到了我想分享的不同解决方案。
示例:
优点:
缺点:
I know this question has been answered, but there is an other way to set the value of a similar static variable for multiple classes through a helper class and some template specialization.
It doesn't exactly answer the question since it is not connected with subclassing in any way, but I've encountered the same issue and I found a different solution I wanted to share.
Example :
Pros:
Cons:
您不能“覆盖”静态函数,更不用说静态成员变量了。
您需要的可能是一个虚函数。 这些只能是实例函数,因此如果没有类实例,将无法访问它们。
You can't "override" static functions, let alone static member variables.
What you need is probably a virtual function. These can only be instance functions, so they will not be accessible without class instance.
您可能不希望覆盖静态变量。 也许你可以在你的类中存储一个指针?
You probably don't want static variables to the overriden. Maybe you can store a pointer in your class instead?
如果您不关心外观,只需在使用路径之前使用 A:: 或 F:: 来选择正确的路径,或者如果您不喜欢 :: 则以不同的方式命名它们。
另一种选择是使用函数来解决这个问题,例如 virtual QPainterPath* GetPath() { return A::path; } 在 A 和 QPainterPath* GetPath() { return F::path; 实际上
,虽然这个问题只是关于代码的外观而不是它的作用,并且由于它并没有真正改变可读性,所以我不会为此担心......
If you don't care about the appearance just use A:: or F:: preceding the use of path to choose the correct one, or if you don't like :: name them differently.
Another option is to use a function to tidy this away, e.g. virtual QPainterPath* GetPath() { return A::path; } in A and QPainterPath* GetPath() { return F::path; } in F.
Really though this issue is just about how the code looks rather than what it does, and since it doesn't really alter readability I wouldn't fret about this...