Does VS support string_view in C++?

[yungman]

I really don't know enough about comparing strings with c-string which one is faster. Like I said, I don't think I have much of a choice at this point like I described in post 29. I know I should learn everything, but I just can't, I have to choose my path of using Gaddis for exercise. I actually used all std::strings before as it is much easier to use, I did learn the member functions and all that. But I have no choice but to change to c-string because of the book. You guys know C++, it's easy to say one way or the other.

Remember I am self study, even with all your help, it's still down to me reading the books. I already bought 5 or 6 books already, Only Gaddis is the simplest one and provide all the sample program to play with. I tried other books, I cannot deal with Ivor's book that at least have some programs. Lipman's book don't have exercise. What choice do I have at this point? I just have to bull through all the chapters and complete the Gaddis book. Then I can venture out to different things. I don't want to jump around. It's not as if I want to stuck with c-strings. Std::string is much easier to deal with for sure.

 

[Jarvis323]

You might want to take a pause and learn about memory. The issues you've had with c-strings have been mostly been due to a lack knowledge about this. With c-strings, you are working with memory addresses to stored values. Using higher level features you can get away with not understanding these things, but not using things like c-strings. You need to know where your c-string is (stack, heap, static) and when/how it gets destroyed. If you know these things, then you have no reason to ask us how to return a c-string.

https://www.google.com/amp/s/crafto...emory-in-c-the-stack-the-heap-and-static/amp/

 

[yungman]

FYI, I actually spend time on std::string the last two days. I was playing with and even added my own lines to this program from Ivor book to try to understand the string_view and the new way of writing constructor like MoreTrouble(string_view str = " There is more trouble...") : Trouble{str}{}. I have to translate this to line 19 and 20 so it's easier for me to read. I don't even know what you call this to try to look online how to write it. I literally have to guess, run and compare the result to confirm!

//Matching catch handler with exception
#include<iostream>
#include<string>
#include<string_view>
#include<cstring>
using namespace std;
class Trouble
{
private:
public:
    string message;
    Trouble(string_view str = " There is a problem")//12, 12,
        { message = str; }//30, 31, 19,
    virtual ~Trouble() = default;//Base classes must have virtual des.
    virtual string_view what() const { return message; }//
};
class MoreTrouble : public Trouble
{
public: MoreTrouble(string_view str = " Theres more trouble")//19, 19,
    : Trouble(str){}//11, 11, 25,
      ~MoreTrouble() { cout << " Destructor MoreTrouble.\n\n"; }
};
class BigTrouble : public MoreTrouble
{
public: BigTrouble(string_view str = " Really big trouble") //25,
    : MoreTrouble(str) {};//18, 32,
      ~BigTrouble() { cout << " Destructor BigTrouble.\n\n"; }
};
int main()
{    Trouble trouble;//11,
    MoreTrouble moreTrouble; //18,
    BigTrouble bigTrouble;//24,
    cout << trouble.message << "\n\n";
    cout <<moreTrouble.message << "\n\n";
    cout << bigTrouble.message << "\n\n";
    trouble.message = " change to New trouble";
    cout << trouble.message << "\n\n";
    cout << moreTrouble.message << "\n\n";
    cout << bigTrouble.message << "\n\n";
    moreTrouble.message = " change to New moreTrouble";
    cout << trouble.message << "\n\n";
    cout << moreTrouble.message << "\n\n";
    cout << bigTrouble.message << "\n\n";
    bigTrouble.message = " change to New bigTrouble";
    cout << trouble.message << "\n\n";
    cout << moreTrouble.message << "\n\n";
    cout << bigTrouble.message << "\n\n";
    for (int i = 0; i < 7; ++i)
    {    try
        {
            if (i == 3) throw trouble;//
            else if (i == 5) throw moreTrouble;//
            else if (i == 6) throw bigTrouble;        }
        catch (const BigTrouble& t) { cout << " BigTrouble obj caught: " <<
            t.what() << "\n\n"; }//
        catch (const MoreTrouble& t) { cout << " MoreTrouble obj caught: " <<//
            t.what() << "\n\n"; }//
        catch (const Trouble& t) { cout << " Trouble obj caught: " <<//
            t.what() << "\n\n"; }//
        cout << " End of for loop(after catch blocks), i = " << i << "\n\n";
    }
}

I have been working on this many hours a day, it's not as if I don't try. It's just a lot of things to learn. At this point, I feel my head is spinning.

 

[yungman]

You might want to take a pause and learn about memory. The issues you've had with c-strings have been mostly been due to a lack knowledge about this. With c-strings, you are working with memory addresses to stored values. Using higher level features you can get away with not understanding these things, but not using things like c-strings. You need to know where your c-string is (stack, heap, static) and when/how it gets destroyed. If you know these things, then you have no reason to ask us how to return a c-string.

https://www.google.com/amp/s/crafto...emory-in-c-the-stack-the-heap-and-static/amp/

Actually I deleted my last response to you. Yes, I spent over a day studying c-string. The thing that I understand now is c-string does not have a type like int, char etc. So I cannot return a c-string in a function. Yes, there's a lot of limitation using c-string more codes need to copy and all. std::string is just a lot easier to use. In fact I used std::string until like 3 months ago and had to switch to c-string because of Gaddis that time.

Thanks

 

[Jarvis323]

Actually I deleted my last response to you. Yes, I spent over a day studying c-string. The thing that I understand now is c-string does not have a type like int, char etc. So I cannot return a c-string in a function. Yes, there's a lot of limitation using c-string more codes need to copy and all. std::string is just a lot easier to use. In fact I used std::string until like 3 months ago and had to switch to c-string because of Gaddis that time.

Thanks

Also, std::string is really, basically, just a c-string coupled with a variable that tracks its size, and some operators to do things like deep copy.

If you really wanted to return a c-string that is on the stack, one way to pull it off, would be to make a struct that manages it and can make deep copies in the operator= and copy constructor, etc. Something like this

struct cstringWrapper {
    size_t size;
    char * cstring;
    cstringWrapper & operator=()...
    cstringWrapper( const cstringWrapper & other) ...
};

Then, you can return it by value, and it will automatically deep copy the stored data for you. But this is basically what an std::string is. It's just a c-string that is managed by a class.

The other thing you can do is use smart pointers, like std::unique_ptr/std::shared_ptr. These are pointers to stuff on the heap, that are automatically freed, so you don't have to worry about deleting it yourself. They are kind of like C++'s (sort of) answer to have something like reference counting and automatic memory management.

https://web.stanford.edu/class/archive/cs/cs106l/cs106l.1184/lectures/lecture15/15_RAII.pdf

std::string_view is new, and I've not even heard of it until now. But std::string is already really fast. Unless you are doing a whole lot of certain types of string operations (like millions or billions of them), then you are probably not going to save any noticeable amount of time. And using raw c-strings or string_view is not a solution to returning a local string (that is on the stack).

People will tell you, they can't stress it enough, premature optimization is bad. It's fine if you want to maximize performance, but starting blindly with c-string optimizations is not the way to go. That is most often going to be one of the last things worth trying, if at all. It usually won't make any noticeable difference. Donald Knuth made a big deal about it, saying,

“The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.”

https://stackify.com/premature-optimization-evil/

And Knuth is the one that wrote some of the most famous books on efficient algorithms. He invented analysis of algorithms, and our concept of time complexity. He wrote all of his books using assembly language to implement the examples. He is not the one you can complain about when you find your software is slow.

If you learn about data structures and algorithms and time complexity, one thing you'll realize is that the algorithm is the most important thing. You can spend days trying to optimize the strings, maybe using c-strings, or std::strings. Maybe sometimes you end up finding std::string is sort of faster, maybe sometimes string_view or c-string saves some time, probably maybe a few microseconds. But a change to the algorithm can make a huge difference. You can write your program in a high performance language like C++, using the GPU, and multi-threading even, and you can spend years micro-optimizing. But someone might just use a more clever algorithm, or wiser choice of data structures, even implemented in a slower language like python, and beat your algorithm like a rabbit vs a turtle in a race. I've seen this happen so many times.

 

[Vanadium 50]

But std::string is already really fast. Unless you are doing a whole lot of certain types of string operations (like millions or billions of them), then you are probably not going to save any noticeable amount of time.

This.

And that Knuth fellow seems pretty clever.

The only other things I would say would be:

• I would be surprised if the time difference betyween C and STL strings was any more than the time difference from using "<<" as opposed to printf.
• "This works better for embedded processors" is not a good argument if you are not writing for embedded processors.
• Speed is no substitute for correctness. Getting a wrong answer faster is not really a benefit.