search for: string_view

...Re-writing StringRef / ArrayRef etc to use the exact same API is a good idea long term, but there's a lot of ugly messy details that need to be dealt with. There's thousands of uses of take_front / drop_front, etc that have to be converted. Then there's some methods that aren't in string_view at all, like consume_integer(), consume_front(), etc that would have to be raised up to global functions in StringExtras. All of this can certainly be done, but it's going to be a *ton* of churn and hours spent to get it all STL-ified. > > Do you consider this a blocker for doing such a...

...es, that proposal makes sense to me: the split would be between things that *are* known to be subsumed into later versions of C++, and therefore are a compatibility library. What do you think about this as an implementation approach: - Rewrite StringRef (et al) to use the exact same APIs as std::string_view. Keep the StringRef name for now. - When cmake detects that C++’17 mode is supported, the build would set a -D flag. - StringRef.h would just include the C++’17 header and typedef StringRef to that type. - When we start requiring C++’17, someone can “StringRef”->RAUW(“std::string_view”) and...

...will obviously never be null! If StringRef would handle a null argument gracefully, it would make my life much easier. With that out of the way, here are some reasons I can see to allow StringRef accept null to its constructor which are independent of LLDB and stand on their own merit. 1) std::string_view<> can be constructed with null. I don't know when we will be able to use std::string_view<>, but there's a chance that at some point in the future we may wish to remove StringRef in favor of string_view. That day isn't soon, but in any case, it will be easier if our assump...

...o c++ future. How strictly do we want to > enforce this? There are lots of things have equally broad utility, but > aren't necessarily known to be added to c++ in the future. > > For example, all of MathExtras and StringExtras, many member functions of > StringRef that are not in string_view, etc. can we still have these in the > top level compatibility library? > > We could still aim for interfaces that 1-to-1 match STL, but it would nice > if we could have some equally low level extras to enhance these classes > On Wed, Jul 5, 2017 at 5:44 PM Chris Lattner <clattner...

...>>> enforce this? There are lots of things have equally broad utility, but >>> aren't necessarily known to be added to c++ in the future. >>> >>> For example, all of MathExtras and StringExtras, many member functions >>> of StringRef that are not in string_view, etc. can we still have these in >>> the top level compatibility library? >>> >>> We could still aim for interfaces that 1-to-1 match STL, but it would >>> nice if we could have some equally low level extras to enhance these classes >>> On Wed, Jul 5, 20...

...in a constant expression. In certain cases Clang now rejects this as a non-constant expression [2]. This regression will have a larger impact than it initially appears. libstdc++ 7.1 and newer use `__builtin_constant_p` to implement C++17 `std::char_traits` [4]. This means that any usage of `std::string_view` in a constant expression has the possibility to break. `__builtin_constant_p` may be rare, but `std::string_view` is not. This regression was first found because it breaks `absl::StrFormat` [4]. This bug will break Abseil's LTS w/ libstdc++. Abseil cannot fully work around this bug. I would...

Fair enough, i sort of regret mentioning that specific method of splitting originally. For the record, i think any splitting should make sense on its own merit without considering tablegen, and hopefully the end result of "tablegen eventually depends on less stuff" would happen naturally On Sun, Jun 4, 2017 at 10:37 AM Chris Lattner <clattner at nondot.org> wrote: > > >

...e are lots of things have equally broad utility, but >>>>> aren't necessarily known to be added to c++ in the future. >>>>> >>>>> For example, all of MathExtras and StringExtras, many member functions >>>>> of StringRef that are not in string_view, etc. can we still have these in >>>>> the top level compatibility library? >>>>> >>>>> We could still aim for interfaces that 1-to-1 match STL, but it would >>>>> nice if we could have some equally low level extras to enhance these classe...

...>> rejects this as a non-constant expression [2]. >> >> This regression will have a larger impact than it initially appears. >> >> libstdc++ 7.1 and newer use `__builtin_constant_p` to implement C++17 >> `std::char_traits` [4]. This means that any usage of `std::string_view` in >> a constant expression has the possibility to break. `__builtin_constant_p` >> may be rare, but `std::string_view` is not. >> >> This regression was first found because it breaks `absl::StrFormat` [4]. >> This bug will break Abseil's LTS w/ libstdc++. Abseil...

On 29 November 2016 at 16:18, Zachary Turner <zturner at google.com> wrote: > I don't like the llvm_strlen approach as it is incompatible with > std::string_view which we may eventually move to. In what way is it incompatible? constexpr StringRef(const char* s) : Data(s), Length(llvm_strlen(s)) {} is equivalent to constexpr string_view(const char* s) : Data(s), Length(std::char_traits<char>::length(s)) {} -- Malcolm Parsons

...would handle a null argument gracefully, it would make my life much easier. >> >> >> With that out of the way, here are some reasons I can see to allow StringRef accept null to its constructor which are independent of LLDB and stand on their own merit. >> >> 1) std::string_view<> can be constructed with null. I don't know when we will be able to use std::string_view<>, but there's a chance that at some point in the future we may wish to remove StringRef in favor of string_view. That day isn't soon, but in any case, it will be easier if our assump...

...at are implemented in the new standard). Applying this policy to C++17, we get: LLVM 5.0 will support C++17. So, for LLVM 7.0, we will remove (at least) the following features from libc++ * std::experimental::filesystem * std::experimental::optional * std::experimental::any * std::experimental::string_view * the searchers (std::experimental::boyer_moore, etc) * std::experimental::random_shuffle and probably other things... Comments? -- Marshall -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170410/9f0ed5e5/...

...would handle a null argument gracefully, it would make my life much easier. >> >> >> With that out of the way, here are some reasons I can see to allow StringRef accept null to its constructor which are independent of LLDB and stand on their own merit. >> >> 1) std::string_view<> can be constructed with null. I don't know when we will be able to use std::string_view<>, but there's a chance that at some point in the future we may wish to remove StringRef in favor of string_view. That day isn't soon, but in any case, it will be easier if our assump...

On 28 November 2016 at 20:51, Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > The basic idea here is that you introduce a StringLiteral class and anywhere > you want to use a global constructor, you make sure to declare a constexpr > array instead of a normal array, and you make it of type StringLiteral. I prefer constexpr llvm_strlen() over StringLiteral because

...lvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] Plan for landing flang in monorepo External email: Use caution opening links or attachments Last I looked there's a lot of char * based string manipulation in f18. I'd like that moved to std::string/string_view/StringRef uses. -eric On Mon, Feb 24, 2020 at 4:57 PM Timothy Keith <tkeith at nvidia.com<mailto:tkeith at nvidia.com>> wrote: Can you elaborate on this? - to move the std::string/string_view/StringRef changes to pre-merge unless you're going to have someone dedicated to handling...

Can you elaborate on this? - to move the std::string/string_view/StringRef changes to pre-merge unless you're going to have someone dedicated to handling them post-merge (rather than "time permits"). The C vs C++ ism here is fairly strong and I'd like to get the C-style string handling out fairly quickly. I understood this item to be looking i...

...gt; > > LLVM 5.0 will support C++17. > > > > So, for LLVM 7.0, we will remove (at least) the following features from > > libc++ > > * std::experimental::filesystem > > * std::experimental::optional > > * std::experimental::any > > * std::experimental::string_view > > * the searchers (std::experimental::boyer_moore, etc) > > * std::experimental::random_shuffle > > Should we throw [[deprecated("use std::filesystem")]] and such on these > things in the window between the non-experimental version being released > and the experi...

...ps://reviews.llvm.org/D25639 This is a verbose change at every non-literal call site. This only works with assignment syntax. I've suggested using a user-defined literal: https://reviews.llvm.org/D26332 This is a small change where needed at string literal call sites. C++17 adds a UDL for std::string_view, so it's not an unusual idea. There is resistance to using a UDL as they can introduce a surprising and novel syntax for calling functions. Comments? Other options? Thanks, -- Malcolm Parsons

...nd I am planning on removing them on 1-February. I have created a status page that shows exactly which components are slated for removal from std::experimental. That page is at http://libcxx.llvm.org/TS_deprecation.html The ones that will probably have the most impact are: * std::experimental::string_view * std::experimental::any * std::experimental::optional There are drop-in replacements: * std::string_view * std::any * std::optional -- Marshall -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments...

...nd I am planning on removing them on 1-February. I have created a status page that shows exactly which components are slated for removal from std::experimental. That page is at http://libcxx.llvm.org/TS_deprecation.html The ones that will probably have the most impact are: * std::experimental::string_view * std::experimental::any * std::experimental::optional There are drop-in replacements: * std::string_view * std::any * std::optional -- Marshall -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/...