C/C++ Does VS support string_view in C++?

[yungman]

Even if that claim was true (which I strongly doubt; modern std::string or similar implementations are highly optimized for performance while still maintaining easy and safe use), I can't help wondering what kind of program you plan to make where you think any performance difference between the two will be an issue?

I ask because run-time performance obviously does not matter one bit when you are just learning the basics, so if you are worried about speed you must be thinking of some usage situation and not about learning, right?

I read it on line to justify going into string_view.

I hope I don't offend you below:

I designed a lot of hardware, there are situations time is critical. That goes back to a lot of times I mentioned and people disagree here. I notice EVERY single piece of hardware/appliance, be it cars, tv, computers, printers...everything that using firmware and/or software are getting slower and slower while the speed of hardware and processors are getting faster. I blame it on software people taking for granted that hardware is fast, they they can be more fancy and don't worry about the speed. I just do NOT want to be one of them. I respect hardware people that bent over backwards, breaking their backs to squeeze out the last bit of speed just to be wasted and take for granted by others. Do you know how hard it is to squeeze the speed, generation of hardware engineer, pcb designers are forced out because they don't have the knowledge of microwave to do design? The bus system on the pcb is NOT just a trace, you have to worry about reflection, crosstalk and all that.

I know how to design these, I spent years studying calculus, ODE, PDE in order to study electromagnetic to design microwave hardware. I few sorry towards those that don't. Out of respect, I will NOT wasting the speed away no matter what. There is a lot of blood sweat and tears to this.

 

[Filip Larsen]

I designed a lot of hardware, there are situations time is critical.

Granted, on (small or special) embedded devices you may have limited resource and the programming environment may also be fairly limited (e.g. no heap and similar), but then I would think you would probably also be coding more in C than "full" C++ (and C-strings obviously makes sense to learn about if you want to code in C).

I would still venture the guess that you would be hard pressed to find an embedded device with accompanying SDK supporting full C++ but only in such a way that resource managed strings (like std::string or its replacement on that particular platform) are significantly slower than "unmanaged" raw string pointers. My point here is that if you have C++ you also have the means to encapsulate the complexities for handling raw string pointer in a class (whether they are null terminated or length based) without being forced to loose performance.

Also, if "string" processing performance is critical on an embedded CPU device, perhaps some of it should be handled by a DSP or a FPGA instead. For instance, at my work we do mostly C++ with a dash of OpenCL code that is deployed to data processing GPU's and special FPGA's. Managing buffers in that context is similar to C-string handling, but even so we have handy C++ classes to wrap all the lower-level stuff.

 

[jbunniii]

Even if that claim was true (which I strongly doubt; modern std::string or similar implementations are highly optimized for performance while still maintaining easy and safe use), I can't help wondering what kind of program you plan to make where you think any performance difference between the two will be an issue?

Agree strongly with this. Any modern compiler will have a highly optimized implementation of std::string and other standard library features. (Additionally, they have even-more-optimized specializations for small strings which require almost no overhead beyond the storage for the characters themselves.) It's a premature pessimization to assume otherwise, especially if it means trading the safety and convenience of std::string for the terribly error-prone and limited C string. The latter is hardly suitable for high performance without extra bookkeeping anyway. Even simple operations like determining the length of a C string (strlen) require iterating through the entire string to look for the terminating '\0'.

Moreover, @yungman, I strongly suspect that in most/all of the use cases for which you are considering std::string_view, you could achieve the equivalent by simply passing a std::string by reference instead of by copy. Can you show an example where you think this is not the case?

 

[Filip Larsen]

I notice std::string is much easier to use.

Indeed, and that ease of use goes directly into better code quality, more flexible code and higher coding speed (and more fun doing all that)

 

[Jarvis323]

I read it on line to justify going into string_view.

I hope I don't offend you below:

I designed a lot of hardware, there are situations time is critical. That goes back to a lot of times I mentioned and people disagree here. I notice EVERY single piece of hardware/appliance, be it cars, tv, computers, printers...everything that using firmware and/or software are getting slower and slower while the speed of hardware and processors are getting faster. I blame it on software people taking for granted that hardware is fast, they they can be more fancy and don't worry about the speed. I just do NOT want to be one of them. I respect hardware people that bent over backwards, breaking their backs to squeeze out the last bit of speed just to be wasted and take for granted by others. Do you know how hard it is to squeeze the speed, generation of hardware engineer, pcb designers are forced out because they don't have the knowledge of microwave to do design? The bus system on the pcb is NOT just a trace, you have to worry about reflection, crosstalk and all that.

I know how to design these, I spent years studying calculus, ODE, PDE in order to study electromagnetic to design microwave hardware. I few sorry towards those that don't. Out of respect, I will NOT wasting the speed away no matter what. There is a lot of blood sweat and tears to this.

The most important thing is to know what you're doing first. If you did have a use case where c-strings performed better than std::string, would it matter anyway if your code is wrong, crashes randomly, hangs, gives wrong results etc.

I suggest that you should first figure out what a c-string is and what an std::string is, how to use them, and then figure out in which cases one might be faster than the other, and by how much, by testing the performance.

It's always important to know what you are doing, both when it comes to programming logic, syntax, etc., and optimization.

 

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