我有一个程序,在初始化时查询时,立即使用> 2 GB的RAM.基本上代码是这样的:
#include <blah>
int main() {
cout << get_mem_usage() << endl;
//Lots of things happen, but no significant memory usage
return 0;
}
产量:[2013-02-15 18:38:05.865283] 2147.71 Mb
但是,我链接到许多不同的共享对象文件:我检查了ldd,我链接到58个库,组合的.so大小为66 MB.
我很确定get_mem_usage程序返回正确的值:这些与top和massif输出一致.
我还要提一下,我正在与高能物理分析的ROOT框架联系起来.
我使用的是Linux x86_64,而get_mem_usage()函数是自行开发的.
如果可能的话,我想减少程序的内存使用量.
类似的问题之前已经被问过，例如String 文字匹配 bool 重载而不是 std::string。
但我想知道的是，C++ 开发人员应该怎样做才能防止这种情况发生？作为编写 C++ 库供其他人使用的人，我应该怎么做才能确保这种情况不会发生？这是我今天遇到的示例，其中一个库有 2 个initialize()方法：
void initialize(bool someflag) { /* ... */ }
void initialize(const std::string & name) { /* ... */ }
现在有问题的代码位于想要利用此功能的应用程序中，并且以类似于以下的方式调用它：
initialize("robert");
乍一看，您可能会认为这会调用initialize(string)，但实际上它调用的是第一个initialize(bool)，并将布尔标志设置为 true！
是的，我知道可以用以下方法解决：
initialize( std::string("robert") );
但这让调用者承担了责任。
编辑@zdan：我不认为其他链接问题中的“解决方案”是很好的解决方案，因为1）我希望不必添加const char *采用布尔或字符串的每个方法的版本，2）模板解决方案显着提高了受影响方法的代码可维护性，使它们几乎不可读。
我需要设置LD_LIBRARY_PATH为CUDA下水前暗网。看起来像这样：
echo $LD_LIBRARY_PATH
/usr/local/cuda/lib64
当应用程序启动时，它无法加载应该在该目录中找到的库：
./darknet
./darknet: error while loading shared libraries: libcudart.so.10.0:
cannot open shared object file: No such file or directory
但是该库肯定在该目录中：
ldd /usr/local/cuda/lib64/libcudart.so.10.0
linux-vdso.so.1 => (0x00007ffe7bf2d000)
...etc...
我假设我在鱼中未正确设置LD_LIBRARY_PATH。这是我最初在鱼中做的方式：
set -U LD_LIBRARY_PATH /usr/local/cuda/lib64
echo $LD_LIBRARY_PATH
/usr/local/cuda/lib64
当我在bash中尝试完全相同的事情时，它可以正常工作：
bash
export LD_LIBRARY_PATH=/usr/local/cuda/lib64
./darknet
usage: ./darknet <function>
所有这些都是在运行fish 2.2.0和bash 4.3.48的64位Ubuntu 16.04.6上进行的。
我想使用libminiupnpc (github)来查找设备并进行TCP端口转发/映射.但是,我找不到一个体面的文档或示例代码来说明如何使用miniupnpc API.
有人知道一个好的文档或示例代码,显示如何使用此库？
我现在拥有的是:
#include <miniupnpc/miniupnpc.h>
...
int error = 0;
UPNPDev *dev = upnpDiscover(2000, nullptr, nullptr, 0, 0, &error);
...似乎正确地返回我的路由器上的信息:
2014-09-08 11:36:17.417132 debug - UPnP ERROR: 0
2014-09-08 11:36:17.417394 debug - UPnP device:
url: http://192.168.1.1:5431/dyndev/uuid:207605a3-efd0-d0ef-a320-162376a3d04000
st: urn:schemas-upnp-org:device:InternetGatewayDevice:1
buf: http://192.168.1.1:5431/dyndev/uuid:207605a3-efd0-d0ef-a320-162376a3d04000
问题upnpDiscover()不仅仅是不明显需要接下来要做什么.