Restrict passed parameter to a string literal

前端 未结 6 1180
没有蜡笔的小新
没有蜡笔的小新 2020-12-03 23:20

I have a class to wrap string literals and calculate the size at compile time.

The constructor looks like this:

template< std::size_t N >
Liter         


        
相关标签:
6条回答
  • 2020-12-03 23:22

    No there is no way to do this. String literals have a particular type and all method overload resolution is done on that type, not that it's a string literal. Any method which accepts a string literal will end up accepting any value which has the same type.

    If your function absolutely depends on an item being a string literal to function then you probably need to revisit the function. It's depending on data it can't guarantee.

    0 讨论(0)
  • 2020-12-03 23:24

    A string literal does not have a separate type to distinguish it from a const char array.

    This, however, will make it slightly harder to accidentally pass (non-const) char arrays.

    #include <cstdlib>
    
    struct Literal
    {
        template< std::size_t N >
        Literal( const char (&literal)[N] ){}
    
        template< std::size_t N >
        Literal( char (&literal)[N] ) = delete;
    };
    
    int main()
    {
        Literal greet( "Hello World!" );
        char a[] = "Hello world";
        Literal broke(a); //fails
    }
    

    As to runtime checking, the only problem with a non-literal is that it may not be null-terminated? As you know the size of the array, you can loop over it (preferable backwards) to see if there's a \0 in it.

    0 讨论(0)
  • 2020-12-03 23:33

    Yes. You can generate compile time error with following preprocessor:

    #define IS_STRING_LITERAL(X) "" X ""
    

    If you try to pass anything other than a string literal, the compilation will fail. Usage:

    Literal greet(IS_STRING_LITERAL("Hello World!"));  // ok
    Literal greet(IS_STRING_LITERAL(broke)); // error
    
    0 讨论(0)
  • 2020-12-03 23:37

    With a C++11 compiler with full support for constexpr we can use a constexpr constructor using a constexpr function, which compiles to a non-const expression body in case the trailing zero character precondition is not fulfilled, causing the compilation to fail with an error. The following code expands the code of UncleBens and is inspired by an article of Andrzej's C++ blog:

    #include <cstdlib>
    
    class Literal
    {
      public:
    
        template <std::size_t N> constexpr
        Literal(const char (&str)[N])
        : mStr(str),
          mLength(checkForTrailingZeroAndGetLength(str[N - 1], N))
        {
        }
    
        template <std::size_t N> Literal(char (&str)[N]) = delete;
    
      private:
        const char* mStr;
        std::size_t mLength;
    
        struct Not_a_CString_Exception{};
    
        constexpr static
        std::size_t checkForTrailingZeroAndGetLength(char ch, std::size_t sz)
        {
          return (ch) ? throw Not_a_CString_Exception() : (sz - 1);
        }
    };
    
    constexpr char broke[] = { 'a', 'b', 'c' };
    
    //constexpr Literal lit = (broke); // causes compile time error
    constexpr Literal bla = "bla"; // constructed at compile time
    

    I tested this code with gcc 4.8.2. Compilation with MS Visual C++ 2013 CTP failed, as it still does not fully support constexpr (constexpr member functions still not supported).

    Probably I should mention, that my first (and preferred) approach was to simply insert

    static_assert(str[N - 1] == '\0', "Not a C string.")
    

    in the constructor body. It failed with a compilation error and it seems, that constexpr constructors must have an empty body. I don't know, if this is a C++11 restriction and if it might be relaxed by future standards.

    0 讨论(0)
  • 2020-12-03 23:42

    I once came up with a C++98 version that uses an approach similar to the one proposed by @k.st. I'll add this for the sake of completeness to address some of the critique wrt the C++98 macro. This version tries to enforce good behavior by preventing direct construction via a private ctor and moving the only accessible factory function into a detail namespace which in turn is used by the "offical" creation macro. Not exactly pretty, but a bit more fool proof. This way, users have to at least explicitly use functionality that is obviously marked as internal if they want to misbehave. As always, there is no way to protect against intentional malignity.

    class StringLiteral
    {
    private:
        // Direct usage is forbidden. Use STRING_LITERAL() macro instead.
        friend StringLiteral detail::CreateStringLiteral(const char* str);
        explicit StringLiteral(const char* str) : m_string(str)
        {}
    
    public:
        operator const char*() const { return m_string; }
    
    private:
        const char* m_string;
    };
    
    namespace detail {
    
    StringLiteral CreateStringLiteral(const char* str)
    {
        return StringLiteral(str);
    }
    
    } // namespace detail
    
    #define STRING_LITERAL_INTERNAL(a, b) detail::CreateStringLiteral(a##b)
    
    /**
    *   \brief The only way to create a \ref StringLiteral "StringLiteral" object.
    *   This will not compile if used with anything that is not a string literal.
    */
    #define STRING_LITERAL(str) STRING_LITERAL_INTERNAL(str, "")
    
    0 讨论(0)
  • 2020-12-03 23:47

    There is a way to force a string literal argument: make a user defined literal operator. You can make the operator constexpr to get the size at compile time:

    constexpr Literal operator "" _suffix(char const* str, size_t len) {
        return Literal(chars, len);
    }
    

    I don't know of any compiler that implements this feature at this time.

    0 讨论(0)
提交回复
热议问题