在C++中sizeof('a') == sizeof(char) == 1.这具有直观意义,因为它'a'是一个字符文字,并且sizeof(char) == 1由标准定义.
然而,在C中sizeof('a') == sizeof(int).也就是说,看起来C字符文字实际上是整数.有谁知道为什么？我可以找到很多关于这个C怪癖的提及,但没有解释为什么它存在.
C++有std :: vector,Java有ArrayList,许多其他语言都有自己的动态分配数组.当动态数组空间不足时,它会重新分配到更大的区域,旧值将被复制到新数组中.这种阵列性能的核心问题是阵列的大小增长速度.如果你总是只能变得足够大以适应当前的推动,那么你每次都会重新分配.因此,将数组大小加倍,或将其乘以1.5倍是有意义的.
有理想的生长因子吗？2倍？1.5倍？理想上,我的意思是数学上合理,最佳平衡性能和浪费的记忆.理论上,我认识到,鉴于您的应用程序可能具有任何可能的推送分布,这在某种程度上取决于应用程序.但我很想知道是否有一个"通常"最好的值,或者在一些严格的约束条件下被认为是最好的.
我听说有一篇关于这个的文章,但我一直都找不到.
我正在运行Python 2.5,因此这个问题可能不适用于Python 3.当您使用多重继承创建钻石类层次结构并创建派生最多类的对象时,Python会执行Right Thing(TM).它调用派生最多类的构造函数,然后调用从左到右列出的父类,然后是祖父母.我熟悉Python的MRO ; 那不是我的问题.我很好奇从super返回的对象实际上如何管理与父类中的super调用正确的顺序进行通信.考虑这个示例代码:
#!/usr/bin/python
class A(object):
def __init__(self): print "A init"
class B(A):
def __init__(self):
print "B init"
super(B, self).__init__()
class C(A):
def __init__(self):
print "C init"
super(C, self).__init__()
class D(B, C):
def __init__(self):
print "D init"
super(D, self).__init__()
x = D()
代码做直观的事情,它打印:
D init
B init
C init
A init
但是,如果你在B的init函数中注释掉对super的调用,则不会调用A和C的init函数.这意味着B对super的调用在某种程度上意识到C在整个类层次结构中的存在.我知道super返回一个带有重载get运算符的代理对象,但是在D的init定义中super返回的对象如何将C的存在传达给B的init定义中super返回的对象？后续超级使用调用的信息是否存储在对象本身上？如果是这样,为什么不是超级而不是self.super？
编辑:Jekke非常正确地指出它不是self.super,因为super是类的属性,而不是类的实例.从概念上讲,这是有道理的,但在实践中,超级也不是班级的属性!您可以在解释器中通过创建两个类A和B来测试它,其中B继承自A,并且调用dir(B).它没有super或__super__属性.
我有一个C++源文件和一个Python源文件.我希望C++源文件能够将Python源文件的内容用作大字符串文字.我可以这样做:
char* python_code = "
#include "script.py"
"
但这不起作用,因为每条线的末尾都需要.我可以手动复制并粘贴Python代码的内容,并用引号和终止\n包围每一行,但这很难看.即使python源有效地编译到我的C++应用程序中,我也希望将它保存在一个单独的文件中,因为它更有条理,并且对编辑器更有效(emacs不够聪明,无法识别C字符串文字是python代码,当你在里面时切换到python模式).
请不要建议我使用PyRun_File,这是我首先要避免的;)
我正在运行Emacs 23.3.1(Ubuntu,Oneiric包),emacs似乎不了解任何新的C++ 11关键字,constexpr,thread_local等.它也不明白'>>'是现在允许在模板参数或新的"枚举类"语法中使用.某处有更新或替代模块吗？或者失败了,有些设置让emacs在同一时间更加友好？
假设我在抽象基类指针mypointer-> foo()上有一个虚函数调用foo().当我的应用程序启动时,根据文件的内容,它选择实例化一个特定的具体类,并将mypointer分配给该实例.对于应用程序的其余部分,mypointer将始终指向该具体类型的对象.我无法知道这个具体类型是什么(它可以由动态加载的库中的工厂实例化).我只知道在第一次生成具体类型的实例后,类型将保持不变.指针可能并不总是指向同一个对象,但该对象将始终具有相同的具体类型.请注意,类型在技术上是在'运行时'确定的,因为它基于文件的内容,但是在'启动'(加载文件)之后,类型是固定的.
但是,在C++中,每次在应用程序的整个持续时间内调用foo时,我都会支付虚函数查找成本.编译器无法优化查找,因为它无法知道具体类型在运行时不会发生变化(即使它是有史以来最令人惊奇的编译器,也无法推测动态加载的行为库).在JIT编译语言(如Java或.NET)中,JIT可以检测到反复使用相同类型并执行内联缓存.我基本上是在寻找一种方法来手动为C++中的特定指针执行此操作.
在C++中是否有任何方法可以缓存此查找？我意识到解决方案可能非常糟糕.我愿意接受ABI /编译器特定的黑客攻击,如果有可能编写发现ABI /编译器相关方面的配置测试,那么即使不是真正可移植的,它也"实际上是可移植的".
更新:对反对者:如果这不值得优化,那么我怀疑现代JIT会做到这一点.您是否认为Sun和MS的工程师正在浪费时间实施内联缓存,并没有对其进行基准测试以确保有所改进？
C++ 11模式下的GCC 4.7让我定义了一个以两种不同方式获取lambda的函数:
// by value
template<class FunctorT>
void foo(FunctorT f) { /* stuff */ }
和:
// by r-value reference
template<class FunctorT>
void foo(FunctorT&& f) { /* stuff */ }
但不是:
// by reference
template<class FunctorT>
void foo(FunctorT& f) { /* stuff */ }
我知道我可以取消模板化函数,只需要使用std :: functions,但是foo它很小并且内联,我想给编译器提供最好的机会来内联调用它.在前两个中,如果我特别知道我正在传递lambdas,那么这对性能来说是优选的,为什么不允许将lambda传递给最后一个？
至少在Linux和Solaris上,静态库实际上只是一堆编译好的.o文件被扔进一个大文件中.编译静态库时,通常会忽略-fpic标志,因此生成的代码与位置有关.
现在说我的静态库是B.我已经构建了它并且得到了.a文件,它实际上只是所有位置相关的.o文件的全局.现在我有一个我想构建的共享库,A,我希望它静态链接B.当我构建A时,我自然会使用-fpic标志使生成的代码位置独立.但是,如果我链接B,我不是混合位置依赖和位置独立的目标文件？
除非我还指定-mimpure-text,否则我会收到很多文本重定位错误,我认为这可能是原因.看来,当我编译一个库时,我真的需要编译它3次,共享版本,静态版本和静态 - 可以使用的共享库版本.我对吗？我可以继续使用-mimpure-text,但g ++手册页说如果你这样做,对象实际上并没有最终被共享(不清楚它是否全部未被共享,或者仅仅是静态链接的部分,有人知道吗？) .
我在命名空间中有一个枚举,我想使用它,就像它在不同的命名空间中一样.直观地说,我认为我可以使用'using'或'typedef'来实现这一目标,但实际上并不起作用.用于证明它的代码片段,在GCC和Sun CC上测试:
namespace foo
{
enum bar {
A
};
}
namespace buzz
{
// Which of these two methods I use doesn't matter,
// the results are the same.
using foo::bar;
//typedef foo::bar bar;
}
int main()
{
foo::bar f; // works
foo::bar g = foo::A; // works
buzz::bar x; // works
//buzz::bar y = buzz::A; // doesn't work
buzz::bar z = foo::A;
}
问题是枚举本身是导入的,但没有导入.不幸的是,我无法将原始枚举更改为包含在额外的虚拟命名空间或类中,而不会破坏许多其他现有代码.我能想到的最好的解决方案是手动重现枚举:
namespace buzz
{
enum bar
{
A = foo::A
};
}
但它违反了DRY原则.有没有更好的办法？
我正在编写一个对延迟敏感的应用程序,它实际上想要一次等待多个条件变量.我之前已经阅读了几种在Linux上获得此功能的方法(显然这是在Windows上构建的),但它们似乎都不适合我的应用程序.我所知道的方法是:
让一个线程等待你想要等待的每个条件变量,当被唤醒时会发出一个你等待的单个条件变量.
通过定时等待循环遍历多个条件变量.
将虚拟字节写入文件或管道,然后轮询这些字节.
#1和#2不合适,因为它们会造成不必要的睡眠.使用#1,你必须等待虚拟线程唤醒,然后发出真实线程的信号,然后唤醒真正的线程,而不是真正的线程刚刚开始唤醒 - 额外的调度程序量子花费在这实际上对我的应用程序很重要,我宁愿不必使用完整的RTOS.#2更糟糕的是,你可能花费N*超时时间睡眠,或者你的超时将是0,在这种情况下你永远不会睡觉(无休止地烧掉CPU和饿死其他线程也很糟糕).
对于#3,管道是有问题的,因为如果"发出信号"的线程忙或甚至崩溃(我实际上处理的是单独的进程而不是线程 - 互斥和条件将存储在共享内存中),那么写入线程将被卡住,因为管道的缓冲区将是满的,任何其他客户端也是如此.文件存在问题,因为应用程序运行的时间越长,它就会无休止地增长.
有一个更好的方法吗？对于适用于Solaris的答案感到好奇.