6 ms·

<source>: In function 'int main()': <source>:6:54: error: conversion from 'absl::string_view' {aka 'std::basic_string_view<char>'} to non-scalar type 'const

<source>: In function 'int main()': <source>:6:54: error: conversion from 'absl::string_view' {aka 'std::basic_string_view<char>'} to non-scalar type 'const std::string' {aka 'const std::__cxx11::basic_string<char>'} requested 6 | const std::string foo2 = absl::StripAsciiWhitespace(absl::AsciiStrToUpper(foo)); // in Python: foo2 = foo.upper().strip() | ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~ ASM generation compiler returned: 1 This is gcc with c++20, curious what the garbage is you're describing.

hot_gril 4y ago
Oh sorry, foo2 should be auto in this example (which becomes string_view). StripAsciiWhitespace takes a string_view here: https://github.com/abseil/abseil-cpp/blob/master/absl/strings/ascii.h#L225 https://github.com/abseil/abseil-cpp/blob/master/absl/string... The garbage comes from AsciiStrToUpper returning a new std::string which StripAsciiWhitespace takes as a string_view (implicit conversion). By the time you print foo2, the string is already freed.
- opportune 4y ago
  This is a classic misuse of rvalues so I’m not sure it’s a huge problem. I don’t think it’s a problem with C++. I probably work at the same place you do btw and I am pretty sure there are rules/guides about how to handle string_view lifetimes For those downvoting, please explain why you think string_view should take ownership of an rvalue string
  - hot_gril 4y ago
    When you're writing a ton of web backend code dealing with strings all over the place, it's easy to forget to check whether something is accepting and returning a string or string_view. `auto foo2 = StripAsciiWhitespace(AsciiStrToUpper(foo))` doesn't say what's going on. I didn't downvote, btw. I don't do that in general.
    - opportune 4y ago
      Heh this is normally why I tell my new teammates to be careful about using auto in non-test code outside of well established patterns like iteration. Auto will bite everybody in the butt at some point!
      - iknowstuff 4y ago
        Classic C++
      - LaLaLand122 4y ago
        And yet "Almost Always Auto" is "Modern C++"...
        UncleEntity 4y ago
        Your local style guide can’t override this? Just turn people loose on your codebase without supervision and be really surprised that the hackers make off with your data? You, sir, are arguing from bad faith as your obvious mission is to promote “rust in all the places”.
        hot_gril 4y ago
        Our style guide says "almost never auto," but most people auto everything. They can make the linter replace auto with the actual type if it's really that big a deal. Explicit type wouldn't have avoided this bug.
        LaLaLand122 4y ago
        Arguably an explicit type would have made the bug a little bit more obvious. You basically expect, by default, this kind of string manipulation functions to return a std::string. Obviously in this specific case you can return a view, and that makes it more performant; but it's kind of unexpected and using auto leaves the surprise a bit more hidden. But sure, you can still make the error with expiclit types.
  - LaLaLand122 4y ago
    It's good that you can solve this with 100% of the team following 100% of the time the rules/guides. It's even better if your language has a way to express "the return value points to data from the input argument, so it's a compile error to pass a rvalue string to this function". The second we got a language able to do that, usable everywhere where C++ is, (yes, that one) the incapacity of C++ to express this became "a problem with C++". Our expectations have just increased. Surely it can be catched via static analysis if you suppose the common case that the return value is a function of the argument, and not pointing to some static global data. But you will get false positives when somebody does the uncommon case. There is a lack of expressiveness in C++ here.
    - hot_gril 4y ago
      The "oh shit" moment when we found that our database's indexes got mysteriously corrupted and we had no idea from where. What do we do, fire the entire team to get rid of whoever made the bug?
    - account42 4y ago
      But C++ can express that, with compiler extensions: https://godbolt.org/z/ohxaGzsEM https://godbolt.org/z/ohxaGzsEM
      - LaLaLand122 4y ago
        That's cool. Last I remember, the lifetime profile stuff was there, but there was still no way to add your own annotations. For some reason, I didn't hear too much about any of this, it was - clang is working on it - clang is working on it - clang is working on it - Visual Studio has it - clang is working on it - Silence gcc still has nothing, right?
        LaLaLand122 4y ago
        I have just taken a look... https://wg21.link/p1179 https://wg21.link/p1179 is actually still not there, right? I see some interesting stuff in https://discourse.llvm.org/t/rfc-lifetime-annotations-for-c/61377 https://discourse.llvm.org/t/rfc-lifetime-annotations-for-c/... from last year. But, in general... once Herb started the whole Lifetime safety profile thing, there seemed to be a lot of interest, but for the last few years things seems to have died? I think things are better with Visual Studio, but being on Linux... I may need to start developing for Linux from Visual Studio with WSL2 :-(
  - arka2147483647 4y ago
    All this talk of rvalues, auto, and string_view is PRECICELY the problem with cpp. There are so many details you need to keep track of, and eventually you make a mistake. Now, yes, i know what all of that does, and how they are supposed to be used, but it does not remove the cognitive load. Many languages have a substantially lower cognitive load when doing something trivial, such as ToLower().ToUpper(), etc.
    - opportune 4y ago
      Every systems-level language will have these sharp edges handled differently. Have you heard of borrow checkers? Many languages don’t have to concern programmers with rvalues or equivalents at all because they are garbage collected - should everything be garbage collected? Let’s not make this a language war, there has to be some programming language that does low-level memory operations without batteries included for some types of technologies. When I write code in C++ and I want something like garbage collection or ref counting I can reach for a shared_ptr. If you don’t want to concern yourself with types, values vs references, or manual memory management don’t choose C++. The default handling is sane if not necessarily intuitive. You shouldn’t create a ref or pseudo-ref (string_view) to data that is not on the heap and no longer allocated to the stack - seems sane. This problem could be easily caught by breaking function calls into separate lines and explicitly specifying the types at each step.
      - pjmlp 4y ago
        Many languages don’t have to concern programmers with rvalues or equivalents at all because they are garbage collected - should everything be garbage collected? From Xerox point of view, yes. Unfortunely they lost to the UNIX workstation market. Interlisp-D, Smalltalk and Mesa/Cedar.
        brobdingnagians 4y ago
        There might be a reason they lost. Believing that one size fits all is a sure way to alienate a lot of people who don't fit that size. Right tool for the right job and giving the freedom for people to solve their problems in the best way is a better way to win people over.

hot_gril 4y ago

Oh sorry, foo2 should be auto in this example (which becomes string_view). StripAsciiWhitespace takes a string_view here: https://github.com/abseil/abseil-cpp/blob/master/absl/strings/ascii.h#L225 https://github.com/abseil/abseil-cpp/blob/master/absl/string... The garbage comes from AsciiStrToUpper returning a new std::string which StripAsciiWhitespace takes as a string_view (implicit conversion). By the time you print foo2, the string is already freed.

opportune 4y ago
This is a classic misuse of rvalues so I’m not sure it’s a huge problem. I don’t think it’s a problem with C++. I probably work at the same place you do btw and I am pretty sure there are rules/guides about how to handle string_view lifetimes For those downvoting, please explain why you think string_view should take ownership of an rvalue string
- hot_gril 4y ago
  When you're writing a ton of web backend code dealing with strings all over the place, it's easy to forget to check whether something is accepting and returning a string or string_view. `auto foo2 = StripAsciiWhitespace(AsciiStrToUpper(foo))` doesn't say what's going on. I didn't downvote, btw. I don't do that in general.
  - opportune 4y ago
    Heh this is normally why I tell my new teammates to be careful about using auto in non-test code outside of well established patterns like iteration. Auto will bite everybody in the butt at some point!
    - iknowstuff 4y ago
      Classic C++
    - LaLaLand122 4y ago
      And yet "Almost Always Auto" is "Modern C++"...
      - UncleEntity 4y ago
        Your local style guide can’t override this? Just turn people loose on your codebase without supervision and be really surprised that the hackers make off with your data? You, sir, are arguing from bad faith as your obvious mission is to promote “rust in all the places”.
        hot_gril 4y ago
        Our style guide says "almost never auto," but most people auto everything. They can make the linter replace auto with the actual type if it's really that big a deal. Explicit type wouldn't have avoided this bug.
        LaLaLand122 4y ago
        Arguably an explicit type would have made the bug a little bit more obvious. You basically expect, by default, this kind of string manipulation functions to return a std::string. Obviously in this specific case you can return a view, and that makes it more performant; but it's kind of unexpected and using auto leaves the surprise a bit more hidden. But sure, you can still make the error with expiclit types.
- LaLaLand122 4y ago
  It's good that you can solve this with 100% of the team following 100% of the time the rules/guides. It's even better if your language has a way to express "the return value points to data from the input argument, so it's a compile error to pass a rvalue string to this function". The second we got a language able to do that, usable everywhere where C++ is, (yes, that one) the incapacity of C++ to express this became "a problem with C++". Our expectations have just increased. Surely it can be catched via static analysis if you suppose the common case that the return value is a function of the argument, and not pointing to some static global data. But you will get false positives when somebody does the uncommon case. There is a lack of expressiveness in C++ here.
  - hot_gril 4y ago
    The "oh shit" moment when we found that our database's indexes got mysteriously corrupted and we had no idea from where. What do we do, fire the entire team to get rid of whoever made the bug?
  - account42 4y ago
    But C++ can express that, with compiler extensions: https://godbolt.org/z/ohxaGzsEM https://godbolt.org/z/ohxaGzsEM
    - LaLaLand122 4y ago
      That's cool. Last I remember, the lifetime profile stuff was there, but there was still no way to add your own annotations. For some reason, I didn't hear too much about any of this, it was - clang is working on it - clang is working on it - clang is working on it - Visual Studio has it - clang is working on it - Silence gcc still has nothing, right?
      - LaLaLand122 4y ago
        I have just taken a look... https://wg21.link/p1179 https://wg21.link/p1179 is actually still not there, right? I see some interesting stuff in https://discourse.llvm.org/t/rfc-lifetime-annotations-for-c/61377 https://discourse.llvm.org/t/rfc-lifetime-annotations-for-c/... from last year. But, in general... once Herb started the whole Lifetime safety profile thing, there seemed to be a lot of interest, but for the last few years things seems to have died? I think things are better with Visual Studio, but being on Linux... I may need to start developing for Linux from Visual Studio with WSL2 :-(
- arka2147483647 4y ago
  All this talk of rvalues, auto, and string_view is PRECICELY the problem with cpp. There are so many details you need to keep track of, and eventually you make a mistake. Now, yes, i know what all of that does, and how they are supposed to be used, but it does not remove the cognitive load. Many languages have a substantially lower cognitive load when doing something trivial, such as ToLower().ToUpper(), etc.
  - opportune 4y ago
    Every systems-level language will have these sharp edges handled differently. Have you heard of borrow checkers? Many languages don’t have to concern programmers with rvalues or equivalents at all because they are garbage collected - should everything be garbage collected? Let’s not make this a language war, there has to be some programming language that does low-level memory operations without batteries included for some types of technologies. When I write code in C++ and I want something like garbage collection or ref counting I can reach for a shared_ptr. If you don’t want to concern yourself with types, values vs references, or manual memory management don’t choose C++. The default handling is sane if not necessarily intuitive. You shouldn’t create a ref or pseudo-ref (string_view) to data that is not on the heap and no longer allocated to the stack - seems sane. This problem could be easily caught by breaking function calls into separate lines and explicitly specifying the types at each step.
    - pjmlp 4y ago
      Many languages don’t have to concern programmers with rvalues or equivalents at all because they are garbage collected - should everything be garbage collected? From Xerox point of view, yes. Unfortunely they lost to the UNIX workstation market. Interlisp-D, Smalltalk and Mesa/Cedar.
      - brobdingnagians 4y ago
        There might be a reason they lost. Believing that one size fits all is a sure way to alienate a lot of people who don't fit that size. Right tool for the right job and giving the freedom for people to solve their problems in the best way is a better way to win people over.