Re: [boost] [gsoc17] Project1: Static map: Can I implement the competency test in g++-7?
Hi, During the implementation of my static_map, I recently encountered a problem: how to deal with string types? For example: constexpr auto cmap_str = make_static_map({ {"abc", 1}, {"bcd", 2} }); static_assert(cmap_str["abc"] == 1, "test"); In my implementation, KeyType requires 1. constexpr operator==, which is not provided by const char * 2. constexpr hash(const KeyType&). Since there is no such thing in standard library, I have to implement some in this project. Currently I would like to use string_view, since it looks like a general solution for compile-time string with lots of constexpr functions, but I don't know which of the following designs looks better: Design A: template<typename KeyType, typename MappedType, typename EqualOp = StaticEqualOp<KeyType>, typename HashOp = StaticHashOp<KeyType>> class static_map; // StaticEqualOp: Specialize StaticEqualOp for those KeyTypes that // can construct string_view and use operator== of string_view, // otherwise we simply use operator== of KeyType // StaticHashOp: size_t operator()(const string_view&, const string_view&) // for types that can construct string_view Design B: We don't specialize any StaticEqualOp for const char*. Instead, make_static_map({{"abc", 1}}) returns static_map<string_view, int> instead of static_map<const char *, int>. Which one is better? Or is there any more feasible design? Thanks, -- --------------------------------- Vic Luo Shanghai Jiaotong University Key fingerprint 0x98809ca08bf5662a
During the implementation of my static_map, I recently encountered a problem: how to deal with string types?
For the list's information, I wasn't sure what the best compile-time string representation is currently considered to be, hence him asking here. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Besides, I found that boost::string_view is buggy regarding constexpr(like many other STL implementation of std::string_view), thus I opened a ticket at https://svn.boost.org/trac/boost/ticket/12897. This makes this project even harder to tackle different types of constexpr strings:-[ On 03/11/2017 12:29 AM, Niall Douglas via Boost wrote:
During the implementation of my static_map, I recently encountered a problem: how to deal with string types? For the list's information, I wasn't sure what the best compile-time string representation is currently considered to be, hence him asking here.
Niall
-- --------------------------------- Vic Luo Shanghai Jiaotong University Key fingerprint 0x98809ca08bf5662a
On 13/03/2017 11:17, Vic Luo wrote:
Besides, I found that boost::string_view is buggy regarding constexpr(like many other STL implementation of std::string_view), thus I opened a ticket at https://svn.boost.org/trac/boost/ticket/12897. This makes this project even harder to tackle different types of constexpr strings:-[
This is a long known issue. You should implement your own string comparison routine which is constexpr. As you mention, Boost's string_view is constrained by the STL's implementation of char_traits. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
This is a long known issue. You should implement your own string comparison routine which is constexpr. As you mention, Boost's string_view is constrained by the STL's implementation of char_traits.
Would it be OK to implement our own constexpr char_traits(just replace ::compare, ::length), then use boost::basic_string_view<char, patched_char_traits<char>> as our CONSTEXPR_STRING_VIEW and compare views with constexpr boost::string_view::compare(a, b) == 0? This way seems to work on my g++-6 which prevents reinventing the wheel. -- --------------------------------- Vic Luo Shanghai Jiaotong University Key fingerprint 0x98809ca08bf5662a
On 13/03/2017 12:49, Vic Luo wrote:
This is a long known issue. You should implement your own string comparison routine which is constexpr. As you mention, Boost's string_view is constrained by the STL's implementation of char_traits.
Would it be OK to implement our own constexpr char_traits(just replace ::compare, ::length), then use boost::basic_string_view<char, patched_char_traits<char>> as our CONSTEXPR_STRING_VIEW and compare views with constexpr boost::string_view::compare(a, b) == 0? This way seems to work on my g++-6 which prevents reinventing the wheel.
That's definitely one approach, if you're set on using string_view. I had thought there was a proposed constexpr string container around, but as nobody's mentioned anything, I guess string_view has superseded it. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 03/13/17 15:49, Vic Luo via Boost wrote:
This is a long known issue. You should implement your own string comparison routine which is constexpr. As you mention, Boost's string_view is constrained by the STL's implementation of char_traits.
Would it be OK to implement our own constexpr char_traits(just replace ::compare, ::length), then use boost::basic_string_view<char, patched_char_traits<char>> as our CONSTEXPR_STRING_VIEW and compare views with constexpr boost::string_view::compare(a, b) == 0? This way seems to work on my g++-6 which prevents reinventing the wheel.
First, it would make interaction with std::string (and its cousins) problematic since they would still use std::char_traits, not boost::char_traits. Second, there is currently no way to select constexpr or runtime implementation of a function depending on the arguments. This means that the optimized versions of strlen/strcmp can't be used when the arguments of string_view are runtime values. IMO, the second problem is a showstopper for constexpr string_view.
participants (3)
-
Andrey Semashev -
Niall Douglas -
Vic Luo