Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Use string views instead of passing std:wstring by const&

giodicanio.com

Post reply on HN
Print view View original

21–30 of 55 posts

Re: Use string views instead of passing std:wstring by const&

#21

Post by masklinn »

theamk wrote: post #5
david2ndaccount wrote: post #3

Earlier quoted context omitted.

Pascal strings might be the only string design worse than C strings. C Strings at least let you take a zero copy substring of the tail. Pascal strings require a copy for any substring! Strings should be two machine words - length + pointer (aka what is commonly called a string view). This is no different than any other array view. Strings are not a special case.

x86 had 6 general-purpose working registers total. Using length + pointers would have caused a lot of extra spills.

“Sure your software crashes and your machines get owned, but at least they’re not-working very fast!”

Re: Use string views instead of passing std:wstring by const&

#22

Post by kstrauser »

Joker_vD wrote: post #14
david2ndaccount wrote: post #3

Earlier quoted context omitted.

Pascal strings might be the only string design worse than C strings. C Strings at least let you take a zero copy substring of the tail. Pascal strings require a copy for any substring! Strings should be two machine words - length + pointer (aka what is commonly called a string view). This is no different than any other array view. Strings are not a special case.

Yeah, I too feel that storing the array's length glued to the array's data is not that good of an idea, it should be stored next to the pointer to the array aka in the array view. But the thrall of having to pass around only a single pointer is quite a strong one.

Is there a reason for the string not to be a struct, so that you're still just passing around a pointer to that struct (or even just passing it by value)?

Re: Use string views instead of passing std:wstring by const&

#23

Post by kstrauser »

theamk wrote: post #4
delta_p_delta_x wrote: post #2

The zero-terminated string is by far C's worst design decision. It is single-handedly the cause for most performance, correctness, and security bugs, including many high-profile CVEs. I really do wish Pascal strings had caught on earlier and platform/kernel APIs used it, instead of an unqualified pointer-to-char that then hides an O(n) string traversal (by the platform) to find the null byte. There are then questions…

First common 32 bit system was Win 95, which required 4MB of RAM (not GB!). The 4-byte prefix would be considered extremely wasteful in those times - maybe not for a single string, but anytime when there is a list of strings involved, such as constants list. (As a point of reference, Turbo Pascal's default strings still had 1-byte length field). Plus, C-style strings allow a lot of optimizations - if you have a mutab…

> First common 32 bit system was Win 95

We're just going to ignore Amigas, and any Unix workstations?

Re: Use string views instead of passing std:wstring by const&

#24

Post by quotemstr »

It's usually the case that the more strident someone is in a blog post decrying innovation, the more wrong he is. The current article is no exception.

It's possible to define your own string_view workalike that has a c_str() and binds to whatever is stringlike can has a c_str. It's a few hundred lines of code. You don't have to live with the double indirection.

Re: Use string views instead of passing std:wstring by const&

#25

Post by delta_p_delta_x »

dh2022 wrote: post #19
delta_p_delta_x wrote: post #15

Earlier quoted context omitted.

> zero copy and zero allocations This is a red herring, because when you actually read the strings out, you still need to iterate through the length for each string—zero copy, zero allocation, but linear complexity. > query file size, allocate buffer once, read it into the buffer, drop some NULL's into strategic positions, maybe shuffle some bytes around for that rare escape case, and you have a whole bunch of C stri…

I think the concern was conserving memory ( which was scarce back then) and not iterating through each substring.

I am very sceptical about that. Much safer and cleaner languages like ML and Lisp were contemporary to C, and were equally developed on memory-scarce hardware.

Re: Use string views instead of passing std:wstring by const&

#26

Post by tczMUFlmoNk »

kstrauser wrote: post #22
Joker_vD wrote: post #14

Earlier quoted context omitted.

Yeah, I too feel that storing the array's length glued to the array's data is not that good of an idea, it should be stored next to the pointer to the array aka in the array view. But the thrall of having to pass around only a single pointer is quite a strong one.

Is there a reason for the string not to be a struct, so that you're still just passing around a pointer to that struct (or even just passing it by value)?

I might guess that GP is referring not to interface ergonomics (for which a struct is a perfectly satisfactory solution, as you describe), but to implementation efficiency. A pointer is one word. A slice / string view is two words: a length and a pointer. A pointer to a slice is one word, but requires an additional indirection. I personally agree that slices are probably the best all-around choice, but taking double the memory (and incurring double the register pressure, etc.) is a trade-off that's fair to mention.

Re: Use string views instead of passing std:wstring by const&

#27

Post by Panzerschrek »

System APIs requiring passing a null-terminated string are also painful to use from other languages, where strings are not null-terminated by default. They basically require taking a copy of a string and adding a null-terminator before performing a call.

Re: Use string views instead of passing std:wstring by const&

#28

Post by Surac »

I work on embedded computers with mostly around 64K RAM using C99. Any form of alloc is forbidden. So I implemented a string lib that works with what is called here as views. I hold length and contend in preallocated arrays. Each string has exactly 127 characters and is also zero-terminated to fulfill C-API needs, and my tables can hold between 16 and 64 strings depending on the project. There is even a safety zero at index 127 enforced in any operation. This system allows for fast, non-copy workflow, and ownership is always obvious; a string is not owned. I even have different "arenas" for different parts of the system that can clear independently. I use this approach also in a desktop context, albeit scaled up in length and number. This combines view, zero delimiter, ownership, and arena-like management altogether.

Re: Use string views instead of passing std:wstring by const&

#29

Post by dev-ns8 »

theamk wrote: post #4
delta_p_delta_x wrote: post #2

The zero-terminated string is by far C's worst design decision. It is single-handedly the cause for most performance, correctness, and security bugs, including many high-profile CVEs. I really do wish Pascal strings had caught on earlier and platform/kernel APIs used it, instead of an unqualified pointer-to-char that then hides an O(n) string traversal (by the platform) to find the null byte. There are then questions…

First common 32 bit system was Win 95, which required 4MB of RAM (not GB!). The 4-byte prefix would be considered extremely wasteful in those times - maybe not for a single string, but anytime when there is a list of strings involved, such as constants list. (As a point of reference, Turbo Pascal's default strings still had 1-byte length field). Plus, C-style strings allow a lot of optimizations - if you have a mutab…

Besides my DA/Algo classes in College, I've never used C seriously. And you know, it's semantics like this that really make me go WTF lol....

From strtok man page... "The first time that strtok() is called, str should be specified; subsequent calls, wishing to obtain further tokens from the same string, should pass a null pointer instead."

Really?? a null pointer.. This is valid code:

  char str[] = "C is fucking weird, ok? I said it, sue me.";
  char *result = strtok(str, ",");
  char *res = strtok(NULL, ",");
Why is that ok?

Re: Use string views instead of passing std:wstring by const&

#30

Post by kelnos »

dev-ns8 wrote: post #29
theamk wrote: post #4

Earlier quoted context omitted.

First common 32 bit system was Win 95, which required 4MB of RAM (not GB!). The 4-byte prefix would be considered extremely wasteful in those times - maybe not for a single string, but anytime when there is a list of strings involved, such as constants list. (As a point of reference, Turbo Pascal's default strings still had 1-byte length field). Plus, C-style strings allow a lot of optimizations - if you have a mutab…

Besides my DA/Algo classes in College, I've never used C seriously. And you know, it's semantics like this that really make me go WTF lol.... From strtok man page... "The first time that strtok() is called, str should be specified; subsequent calls, wishing to obtain further tokens from the same string, should pass a null pointer instead." Really?? a null pointer.. This is valid code: char str[] = "C is fucking weird…

You have to understand the context, and the time period. Memory and CPU cycles were precious. All computers being 24/7 networked wasn't a thing, so security wasn't much of a concern. API design tended to reflect that.
Post reply on HN