编写C ++应用程序时,我通常将自己限制在C ++特定的语言功能。大多数情况下,这意味着尽可能使用STL而不是CRT。
对我来说,STL比使用CRT更流畅和可维护。请考虑以下事项:
std::string str( "Hello" );
if( str == "Hello" ) { ... }
C-Runtime等价物是:
char const* str = "Hello";
if( strcmp( str, "Hello" ) == 0 ) { ... }
我个人认为前一个例子更容易看。这对我来说更清楚是怎么回事。当我写第一遍代码时,我的第一件事总是以最自然的方式编写代码。
我的团队对前一个例子的一个担忧是动态分配。如果字符串是静态的,或者已经在其他地方分配过,那么他们认为可能导致碎片或在此处浪费分配是没有意义的。我反对这一点的论点是首先以最自然的方式编写代码,然后在得到代码导致问题的证明后再返回并更改它。
我不喜欢后一个例子的另一个原因是它使用了C库。通常我会不惜一切代价避免使用它,因为它不是C ++,它的可读性较差,更容易出错并且更具安全风险。
所以我的问题是,我是否正确避免C运行时?在编码的这一步,我真的应该关心额外的分配吗?在这种情况下,我很难判断我是对还是错。
答案 0 :(得分:5)
我觉得我对llvm::StringRef
的评论被忽略了,所以我会从中做出回答。
llvm::StringRef str("Hello");
这实际上设置了一个指针,调用strlen,然后设置另一个指针。没有分配。
if (str == "Hello") { do_something(); }
可读,但仍然没有分配。它也适用于std::string
。
std::string str("Hello");
llvm::StringRef stref(str);
但是你必须小心,因为如果字符串被销毁或重新分配,StringRef将变为无效。
if (str == stref) { do_something(); }
在适当的地方使用此课程时,我注意到了相当大的性能优势。它是一个强大的工具,你只需要小心它。我发现它对字符串文字最有用,因为它们可以保证在程序的生命周期内持续使用。另一个很酷的功能是你可以在不创建新字符串的情况下获得子字符串。
顺便说一下,有人建议将类似的类添加到标准库中。
答案 1 :(得分:4)
你在做C ++还是C?这些是完全不同的语言,具有完全不同的思维方式。
如果是C ++:
std::string str( "Hello" );
if( str == "Hello" ) { ... }
如果C:
char const* str = "Hello";
if( strcmp( str, "Hello" ) == 0 ) { ... }
不要混合使用。
答案 2 :(得分:4)
使用实现Small String Optimization的编译器,我得到了这个结果:
main PROC ; COMDAT
; 6 : {
$LN124:
00000 48 83 ec 48 sub rsp, 72 ; 00000048H
; 7 : std::string str( "Hello" );
00004 8b 05 00 00 00
00 mov eax, DWORD PTR ??_C@_05COLMCDPH@Hello?$AA@
; 8 :
; 9 : if( str == "Hello" )
0000a 48 8d 15 00 00
00 00 lea rdx, OFFSET FLAT:??_C@_05COLMCDPH@Hello?$AA@
00011 48 8d 4c 24 20 lea rcx, QWORD PTR str$[rsp]
00016 89 44 24 20 mov DWORD PTR str$[rsp], eax
0001a 0f b6 05 04 00
00 00 movzx eax, BYTE PTR ??_C@_05COLMCDPH@Hello?$AA@+4
00021 41 b8 05 00 00
00 mov r8d, 5
00027 c6 44 24 37 00 mov BYTE PTR str$[rsp+23], 0
0002c 48 c7 44 24 38
05 00 00 00 mov QWORD PTR str$[rsp+24], 5
00035 c6 44 24 25 00 mov BYTE PTR str$[rsp+5], 0
0003a 88 44 24 24 mov BYTE PTR str$[rsp+4], al
0003e e8 00 00 00 00 call memcmp
00043 85 c0 test eax, eax
00045 75 1d jne SHORT $LN123@main
; 10 : { printf("Yes!\n"); }
00047 48 8d 0d 00 00
00 00 lea rcx, OFFSET FLAT:??_C@_05IOIEDEHB@Yes?$CB?6?$AA@
0004e e8 00 00 00 00 call printf
; 11 :
; 12 : }
看不到单一的内存分配!
答案 3 :(得分:0)
引擎盖下,std :: string :: operator ==表面上是调用strcmp。老实说,如果碎片对你来说不是问题,而你想利用stl更易读的语法,那就去吧并使用stl。如果性能是一个问题,并且您对代码进行了分析,并且您发现std :: string内部数据的常量分配/释放是热点/瓶颈,请在那里进行优化。如果你不喜欢混合运算符==()和strcmp的不一致的编码风格,写下这样的东西:
inline bool str_eq(const char* const lhs, const char* const rhs)
{
return strcmp(lhs, rhs) == 0;
}
inline bool str_eq(const std::string& lhs, const char* const rhs)
{
return str_eq(lhs.c_str(), rhs);
}
inline bool str_eq(const char* const lhs, const std::string& rhs)
{
return str_eq(lhs, rhs.c_str());
}
inline bool str_eq(const std::string& lhs, const std::string& rhs)
{
return lhs == rhs;
}
这不应该是宗教对话。两者都是一样的。现在,如果你看到有人在写
std::string str( "Hello" );
if( strcmp(str.c_str(), "Hello") == 0 ) { ... }
或
std::string str( "Hello" );
if( str.compare( "Hello" ) == 0) { ... }
那么你可以就混合风格进行辩论,因为使用operator ==
显然会更加清晰答案 4 :(得分:0)
如果您的团队使用C ++编写代码,则应使用它提供的所有功能。当然,正确使用的C ++会关注内存分配(构造函数和析构函数)以及更自然的语法(对于==,+)。
你可能认为OOP风格可能会变慢。但是你必须首先测量瓶颈是字符串操作。大多数情况都不太可能。过早优化是万恶之源。正确设计的C ++类不会失去方便编写的C代码。
回到你的问题,混合库的最差变体。您可以用OOP库替换C字符串,但仍然使用旧式IO例程和数学。