コンパイル時に解決されない文字列リテラルとの比較

私は最近、次のようなものを見つけました。

#include <string>

// test if the extension is either .bar or .foo
bool test_extension(const std::string& ext) {
    return ext == ".bar" || ".foo";
    // it obviously should be
    // return ext == ".bar" || ext == ".foo";
}

関数は明らかにコメントが示唆することを行いません。しかし、それはここでのポイントではありません。これはifステートメントで2つ以上のOR条件を使用できますか？あなたが関数を適切に書く方法を私は完全に知っているので！

コンパイラがこのスニペットをどのように処理するのか疑問に思い始めました。私の最初の直感は、これがreturn true;基本的にコンパイルされるということでした。この例をgodboltに接続すると、GCC 9.2もclang 9も最適化でこの最適化を行わないことがわかりました-O2。

ただし、コードを^1に変更する

#include <string>

using namespace std::string_literals;

bool test_extension(const std::string& ext) {
    return ext == ".bar"s || ".foo";
}

アセンブリが本質的になっているので、トリックを行うようです：

mov     eax, 1
ret

だから私の中心的な質問は：コンパイラが最初のスニペットで同じ最適化を行うことを許可しない見逃したものはありますか？

¹これ".foo"sでは、コンパイラはa std::stringをbool;-) に変換したくないので、コンパイルすらしません。

編集する

次のコードも、「適切に」最適化されreturn true;ます。

#include <string>

bool test_extension(const std::string& ext) {
    return ".foo" || ext == ".bar";
}

これはあなたの頭をさらに揺るがします：カスタムchar型を作成し、MyCharTそれを使用して独自のカスタムを作成するとどうなりますstd::basic_stringか？

#include <string>

struct MyCharT {
    char c;
    bool operator==(const MyCharT& rhs) const {
        return c == rhs.c;
    }
    bool operator<(const MyCharT& rhs) const {
        return c < rhs.c;
    }
};
typedef std::basic_string<MyCharT> my_string;

bool test_extension_custom(const my_string& ext) {
    const MyCharT c[] = {'.','b','a','r', '\0'};
    return ext == c || ".foo";
}

// Here's a similar implementation using regular
// std::string, for comparison
bool test_extension(const std::string& ext) {
    const char c[] = ".bar";
    return ext == c || ".foo";
}

確かに、カスタムタイプはプレーンよりも簡単に最適化することはできませんcharよね？

結果のアセンブリは次のとおりです。

test_extension_custom(std::__cxx11::basic_string<MyCharT, std::char_traits<MyCharT>, std::allocator<MyCharT> > const&):
        mov     eax, 1
        ret
test_extension(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&):
        sub     rsp, 24
        lea     rsi, [rsp+11]
        mov     DWORD PTR [rsp+11], 1918984750
        mov     BYTE PTR [rsp+15], 0
        call    std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::compare(char const*) const
        mov     eax, 1
        add     rsp, 24
        ret

ライブでご覧ください！

それで、私の「カスタム」文字列型との違いは何std::stringですか？

小さな文字列の最適化

少なくともGCCでは、Small String Optimizationは実際にはlibstdc ++のバイナリーにコンパイルされています。つまり、関数のコンパイル中、コンパイラはこの実装にアクセスできないため、副作用がないかどうかを知ることができません。このため、compare(char const*)away への呼び出しを最適化できません。SSOはplainに対してのみ実装されているため、「カスタム」クラスにはこの問題はありませんstd::string。

ところで、でコンパイルすると-std=c++2a、コンパイラはそれを最適化します。残念ながら、C ++ 20にまだ精通していないので、これを可能にした変更についてはまだわかりません。