我与我的一位同事讨论了XML声明节点(我在谈论这个=> <?xml version="1.0" encoding="UTF-8"?>).
我相信,对于某些被称为"有效XML"的东西,它需要一个XML声明节点.
我的同事声明XML声明节点是optionnal,因为默认编码是UTF-8,版本总是如此1.0.这是有道理的,但标准说的是什么？
简而言之,给出以下文件:
<books>
<book id="1"><title>Title</title></book>
</book>
我们可以这样说:
非常感谢你.
我正在设计一个Buffer类,其目的是代表一块内存.
我的底层缓冲区是一个char*(好吧,boost::shared_array<char>实际上,但它并不重要).
我一直在决定为我的构造函数选择什么样的原型:
我应该去:
Buffer(const void* buf, size_t buflen);
或者:
Buffer(const char* buf, size_t buflen);
或者是其他东西 ？
通常做什么,为什么？
在我的Linux平台上,我有几个版本的gcc.
根据usr/bin我的要求:
gcc34gcc44gcc以下是一些输出:
$ gcc --version
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48)
$ gcc44 --version
gcc44 (GCC) 4.4.0 20090514 (Red Hat 4.4.0-6)
我需要使用4.4版本,gcc但默认似乎是4.1 版本.
我有什么办法可以代替/usr/bin/gcc,并gcc44在默认的编译器不使用符号链接来/usr/bin/gcc44？
我不能使用符号链接的原因是因为我的代码必须使用RPM包mock.mock从头开始创建一个最小的linux安装,并在编译我的代码之前安装指定的依赖项.我无法自定义这个"最小安装".
理想的情况下,完美的解决办法是安装官方的RPM包替换gcc与gcc44作为默认的编译器.有这样的包裹吗？这甚至可能/好吗？
我必须使用SCons(make替代),它不允许我指定用于的二进制文件gcc.
我也会接受任何答案,告诉我如何gcc在我的SConstruct文件中指定二进制文件.
今天早上,我发现自己写的是:
if (a == b == c):
# do something
并且惊讶于它给了我预期的结果.
我认为它会表现为:
if ((a == b) == c):
# do something
但它显然没有.似乎Python对第一个语句的处理方式与第二个不同,这很好但我找不到任何关于此的文档或解释.
我测试并得到了这个:
In [1]: 2 == 2 == 2
Out[1]: True
In [2]: (2 == 2) == 2
Out[2]: False
有人会关心解释我对==(或!=)这种"链接"的规则是什么？
非常感谢你.
这个问题遵循@sharptooth在这个相关问题中提出的建议.
可以std::string调整,以便它变得密码安全吗？
如果没有,什么是写有密码处理类(因此类,它大关心它写入内存和破坏之前将其清除)的指导方针？
我一直在调试,现在几天崩溃,出现在了OpenSSL(讨论与维护者深处这里).我花了一些时间进行调查,所以我会尝试让这个问题变得有趣且内容丰富.
首先,为了给出一些上下文,我重现崩溃的最小样本如下:
#include <openssl/crypto.h>
#include <openssl/ec.h>
#include <openssl/objects.h>
#include <openssl/pem.h>
#include <openssl/err.h>
#include <openssl/engine.h>
int main()
{
ERR_load_crypto_strings(); OpenSSL_add_all_algorithms();
ENGINE_load_builtin_engines();
EC_GROUP* group = EC_GROUP_new_by_curve_name(NID_sect571k1);
EC_GROUP_set_point_conversion_form(group, POINT_CONVERSION_UNCOMPRESSED);
EC_KEY* eckey = EC_KEY_new();
EC_KEY_set_group(eckey, group);
EC_KEY_generate_key(eckey);
BIO* out = BIO_new(BIO_s_file());
BIO_set_fp(out, stdout, BIO_NOCLOSE);
PEM_write_bio_ECPrivateKey(out, eckey, NULL, NULL, 0, NULL, NULL); // <= CRASH.
}
基本上,此代码生成椭圆曲线键并尝试将其输出stdout.类似的代码可以openssl.exe ecparam在维基在线上找到.它在Linux上运行正常(valgrind报告根本没有错误).它只在Windows上崩溃(Visual Studio 2013 - x64).我确保正确的运行时链接到(/MD在我的情况下,对于所有依赖项).
我不害怕任何邪恶,我在x64-debug中重新编译了OpenSSL(这次将所有内容都链接起来/MDd),并逐步完成代码以查找有问题的指令集.我的搜索引导我使用此代码(在OpenSSL的tasn_fre.c文件中):
static void asn1_item_combine_free(ASN1_VALUE **pval, const ASN1_ITEM *it, int …今天早上我和一位同事讨论了关于检测字节序的"编码技巧"的正确性.
诀窍是:
bool is_big_endian()
{
union
{
int i;
char c[sizeof(int)];
} foo;
foo.i = 1;
return (foo.c[0] == 1);
}
对我来说,似乎这种用法union是不正确的,因为设置联合的一个成员并读取另一个成员的定义并不明确.但我必须承认,这只是一种感觉,我缺乏实际的证据来强化我的观点.
这个技巧是否正确？谁在这？
可能重复:
非成员运算符重载应放在何处？
在浏览SO时,我经常会发现涉及重载/定义a std::ostream& operator<<(std::ostream& os, const Foo& foo)或a的问题或答案Foo operator+(const Foo& l, const Foo& r).
虽然我知道如何以及何时(不)编写这些操作符,但我对namespace此事感到困惑.
如果我有以下课程:
namespace bar
{
class Foo {};
}
namespace我应该在哪个中编写不同的运算符定义？
// Should it be this
namespace bar
{
std::ostream& operator<<(std::ostream& os, const Foo& foo);
}
// Or this ?
namespace std
{
ostream& operator<<(ostream& os, const bar::Foo& foo);
}
// Or this ?
std::ostream& operator<<(std::ostream& os, const bar::Foo& foo);
同样的问题适用于operator+.那么,这里的好习惯是什么？为什么？
我们今天在工作中一直在讨论这个话题,我们都没有人能够就这个问题提出明确的答案.考虑以下情况:
int foo()
{
int err;
err = some_call(1);
if (err != 0)
return err;
err = some_call(2);
if (err != 0)
return err;
err = some_call(3);
if (err != 0)
return err;
err = some_call(4);
if (err != 0)
return err;
bar();
return err;
}
有很多代码重复.显然,这可以用宏来分解,遗憾的是没有模板(因为return子句).或者至少不是直接的.
现在的问题是,如果我们要用异常替换那些返回错误代码,并立即捕获这些异常,编译器是否允许并且足够聪明以检测模式并避免完全抛出异常？
这是我的意思的说明:
int foo()
{
try
{
// some_call now throws a ErrorReturned exception that contains the error code upon failure.
some_call(1);
some_call(2);
some_call(3);
some_call(4);
}
catch (ErrorReturned& ex)
{
return ex.error_code();
} …我最近尝试过对单元测试最佳实践进行大量训练.其中大部分内容都非常有意义,但有一些内容经常被忽视和/或解释得很糟糕:一个单元测试如何装饰功能？
我们假设我有这个代码:
def stringify(func):
@wraps(func)
def wrapper(*args):
return str(func(*args))
return wrapper
class A(object):
@stringify
def add_numbers(self, a, b):
"""
Returns the sum of `a` and `b` as a string.
"""
return a + b
我显然可以写下面的测试:
def test_stringify():
@stringify
def func(x):
return x
assert func(42) == "42"
def test_A_add_numbers():
instance = MagicMock(spec=A)
result = A.add_numbers.__wrapped__(instance, 3, 7)
assert result == 10
这给了我100%的覆盖率:我知道任何被装饰的函数都stringify()将其结果作为字符串获取,并且我知道未修饰的A.add_numbers()函数返回其参数的总和.因此,通过传递性,装饰版本A.add_numbers()必须返回其参数的总和,作为字符串.一切都好看!
但是我对此并不完全满意:我的测试,因为我写的它们仍然可以通过,如果我要使用另一个装饰器(做其他事情,比如将结果乘以2而不是转换为a str).我的功能A.add_numbers不再正确,但测试仍然会通过.不太棒.
我可以测试装饰版本,A.add_numbers()但随后我会推翻,因为我的装饰器已经过单元测试.
感觉我在这里遗漏了一些东西.单元测试装饰功能的好策略是什么？