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
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
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
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
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