我想知道是否以及如何在c ++中编写"全能"类实际上会影响性能.
如果我有一个类Point,只有uint x; uint y; 作为数据,几乎已经将数学可以做的所有事情都定义为方法.其中一些方法可能很庞大.(copy-)构造函数只是初始化两个数据成员.
class Point
{
int mx; int my;
Point(int x, int y):mx(x),my(y){};
Point(const Point& other):mx(other.x),my(other.y){};
// .... HUGE number of methods....
};
现在.我加载一个大图像并为每个像素创建一个Point,将它们填充到一个向量中并使用它们.(比方说,所有方法都被调用一次)这只是一个愚蠢的例子!
没有方法但是有很多实用功能,它会比同一个类慢吗？我不是以任何方式讨论虚函数!
我对此的动机:我经常发现自己编写了很好的相对强大的类,但是当我必须像上面的例子中那样初始化/使用大量的类时,我会感到紧张.我想我不应该.
我认为我知道的是:
所以没关系.我错过了什么吗？
Ark*_*nez 10
你是对的,方法只在内存中存在一次,它们就像普通函数一样,额外隐藏了这个参数.
当然,只考虑数据成员的分配,好吧,继承可能会为对象大小的vptrs引入一些额外的ptrs,但不是什么大不了的事.
你已经有了一些非常好的技术建议.我想投入一些非技术性的东西:由于STL向我们展示了所有这些,在成员函数中完成所有操作可能不是最好的方法.而不是堆积论据,我参考Scott Meyers关于这个主题的类文章:非成员函数如何改进封装.
虽然从技术上讲应该没有问题,但您仍然可能希望从设计POV中检查您的设计.
我想这比您正在寻找的答案更重要，但是这里...
SO 充满了人们担心 X、Y 或 Z 性能的问题，而这种担心是一种猜测。
如果您担心某些东西的性能，请不要担心，找出来。
以下是该怎么做：
编写程序
从经验中学习
这教会了我，而且我一遍又一遍地看到的是：
最佳实践是不要过早优化。
最佳做法说待办事项使用大量的数据结构类的，与抽象的多层次，最好的大O算法，“信息隐藏”，以事件驱动和通知风格的建筑。
性能调优揭示了时间的去向，即：驰骋一般性，从小山丘中脱颖而出，在不知道需要多长时间的情况下调用函数和属性，并使用指数时间在多个层上执行此操作。
然后问题是：big-O 算法、事件和通知驱动架构等的最佳实践背后的原因是什么。答案来了：嗯，除此之外，还有性能。
所以在某种程度上，最佳实践告诉我们：过早优化。明白这点？它说“不要担心性能”，它说“担心性能”，并且它导致我们尝试不成功的事情不要担心。我们越担心它，违背我们更好的判断，它就会变得越糟。
我的建设性建议是：按照上面的步骤 1、2 和 3。这将教会您如何适度使用最佳实践，并为您提供最佳的全方位设计。