In C, you can use the strlen() function to determine the length of a string. The sizeof() operator does not give you the length of a string, but rather the size of the array that holds the string. So correct code would be something like this Char string[]="hello world!"; Char buffer[strlen(string)+1]; Most Rust have skill issues regarding on C and yet they talk about it because they want to pormote SAFETY FEATURE that expert C coder don't need - good for webdev and python programmer - hope you stay away from C because you really don't understand it

Sadly a little known fact. And only this 7 bit ASCII range is identical for many encodings such as many Windows codepages or even UTF-8 which makes them backwards compatible.

True. ASCII: 7 bit (128 chars) "Extended" ASCII: 8 bit (256 chars)

For historical reason the 8th bit was traditionally used in ascii as a parity bit as a rudimentary integrity check

To be more precise, it’s 127 characters in ascii plus the ‘\0’ Characters from 1 to 31 are control characters. Then the first real character is at 32, it’s the space. Character 126 is tilde. 127 is DEL.

@@lumberjackdreamer6267 they are 128 as 0 is included.

To be more clear, you have to try to write "portable" C with an additional zinger of handling data with more than ASCII or ISO-8859-1 encoding. If you are writing C for a known and targetted platform + OS, strings and paths really aren't that hard to manage.

Yeah, I'm glad that the rust community as a whole still respects and shows deference to C. It's not about one being better than the other, it's about different overall philosophies :)

Your computer is not a PDP-11, you are not "close to the metal" with C.

@@apestogetherstrong341 One of the computers was a PDP, and close to the metal is what I did - and still do, but not with a PDP. And C can hit the hardware addresses. Pretty close to the metal I would say.

@@apestogetherstrong341 I dunno, man. When a string is still a raw sequence of bytes and the pointer to it could be NULL, pointing to the zeroeth byte of the heap, or maybe it's already been free()ed (no good way to know) I'd say that's as close to metal as generally feasible. Of course, if you're running in some virtualized environment, the metal is isolated to some degree regardless of the language you used.

I'm not even sure why Rc was used in this case. A regular slice would do the trick, no copying and reference-counting involved. A better example would be if the original string wasn't 'static and went out-of-scope, while the reference-counted copy gets retained.

Very funny, thank you 👍

Thank you for watching :)

Great video btw! Thanks for the resource.

Wanted to point out the same, but then decided to look for it in the comments first. glad i was no the only one :)

Yeah that was super confusing when I initially started learning C.

@@alexwhitewood6480 tbh, C does a very good job to hide the differences through implicit lookups, but it fails in a few edgecases where it becomes really confusing. sizeof(char*) vs sizeof(char[]) being the most famous. example.

The issue is not with the string contents but with reference counting done by Rc, Rc updates its reference count in a thread-unsafe way, thus the need for Arc

@@belowdecent6494 I see! Totally makes sense now. Thank you for your answer.

Assuming someone hasn't already written it... then write it yourself. All you're asking for a thin wrapper around Vec and/or &u8, and Rust gives you the ability to write that abstraction and drop it in. You just gotta do it (or more likely, find it in the ecosystem)

The syntax you suggest doesn't make any sense in Rust terms and encapsulating it like that would incur an overhead. Just have different types for different strings. Someone has probably already made a library for it, which you probably wouldn't need anyway because utf8 is compatible with it.

Strings are immutable by default unless quantified by "mut". Same applies to other data types as well. Box doesn't have capacity information, i.e. not ideal for expansion. The difference between Box and &str is that Box is mutable and the owner, versus &str is immutable (you can mutate it as &mut str) and is borrowed not owned.

Nothing is mutable by default so to make it mutable you have to add the keyword mut. The capacity is used to allow resizing a string, otherwise it's just a slice, i.e. a view into another string. I suppose they thought it was cool to drop it because it saves 8 bytes, and it doesn't add a ton of complexity to the base string type. To work with an immutable string you really only need the length and pointer to the data anyway, though if they're going through all this trouble of defining multiple ways of dealing with strings they should've included a short string type that encodes the length in the first byte the way Pascal did it.

1. string slices in rust are _usually_ immutable (as in, most commonly you access a string slice through immutable reference "&str"). The mutable reference to a string slice "&mut str" is an extremely niche type to see in the wild, because there is very little you can actually do with it safely. 2. By capacity we mean the size of the allocation where the string slice is stored. In case of Box, the size of the allocation will be the same as the size of the string slice in bytes. In case of String, it may have extra memory at the end, so it doesn't have to reallocate every time the size of the string changes during modification. The String type is just Vec type (dynamically sized array), but wrapped in an API that preserves valid UTF-8 encoding in the stored bytes.

Main thing about Box is that it's an alternative to String, not &str. I.e. you want an _owned_ value, but don't want to present it as something you can/should modify and therefore don't need the capacity. If you didn't need an owned value, you should just use &str directly. This is why the video talked about Box not having the capacity inside of it.

> You initially said strings in rust are immutable. But later presented "&mut str" saying that it is mutable string, which allows in place transformations. He said its immutable by _default_

came here for this, I almost thought I was crazy for a sec there

​@@chronxdev It's also funny because it actually directly displays the reason for safe Rust code with the Option enum type and how that is only possible to extract when it actually has a value, which is what people refer to when they talk about the power of Rust's type system. And which is what you will use in most cases when not directly talking to C libraries.

💪💪💪path buff yo

Hell yeah brother 💪💪💪💪💪

Yooo buff that path 💪🏽💪🏽💪🏽

There's another one: ’a

That's not a typo 💪💪💪

I think synchronization is necessary for the reference counting, not for the string content.

When encoding UTF8, you may need to pad the codepoint with leading 0 bits. This is because UTF8 only stores 7-bit, 11-bit, 16-bit, or 21-bit codepoints. Overlong sequences arise when you pad the codepoint more than necessary.

More information is on Wikipedia. wikipedia.org/wiki/UTF-8#Overlong_encodings

If say, you are trying to sanitize a Windows filename, then you would want to filter out backslashes. In correctly formed UTF8, you could just remove all 0x5C bytes. Overlong backslashes could skip this check, and get converted to regular backslashes when converting to UTF16 (Windows filename).

@@awesome_aiden ah thanks 👍 hope I don't have to worry these kinds of char encoding issues anytime soon or ever lol seems like a headache and a half 😅

1 - Yes it comes with an overhead. But in general those things will be negligible. It really depends on the size of the string and how exactly it is implemented. For example many languages (C++ and Rust included) make the class quite a bit bigger - in the range of 24-32 bytes. That holds the pointer to the data, how long it is, and how much storage is reserved. So yes a very short string takes significantly more memory. 2 - Yes and no. In C you can NOT just add a character to a "string" cause a "char*" used for storing strings does not have the information of either how long it is or how much memory it has. If you do not create your own struct for that then you are doing hundreds of times more work just to add a single character. Say your string is "C string is fast" and you now want to append "er!" to finish the sentence. These are the steps you need to do: linearly search for the end of the string - and you already did way more arithmetic calculation than needed in C++/Rust. Then reallocate the string, then append "er!\0". In C++ you also most of the time have small-string-optimisation so strings shorter than 22 character are stored directly in the class without any dynamic memory involved. 3 - kinda, but you are missing some critical information and the memory-layout is bad. 4 - not really. UTF8 is a character-encoding and that has absolutely no impact on performance directly as long as you do not use the extended features. Btw C is not ACII either - it can be UTF16 (which factually is slower and more memory intensive), or even EBCDIC - so all your string-manipulations would be wrong. 5 - sure. And you just need to make sure that the underlying string is never rellocated. It would be a lot more convincing if you gave some better C-examples and not ideas that come from fresh students. C does have some major advantages but you havent touched on any of them.

@@ABaumstumpf i am still learning c so please do forgive me, so i wanted to reply to few of your points. 3. How is the memory layout of my struct bad? 4. I haven't worked with UTF-8 directly but i know that there are this things called "codepoints" and stuff which are to be handled by the code logic, so won't the UTF-8 implementation of a string function be a bit more slow because of handling all that code logic? which is fine if you're using UTF-8 strings but what if you're just using ASCII characters, won't that extra logic slow down the code a bit? and the last "unlisted" point, umm can you give some c-examples and stuff? i am quite new to C, just over a year and i still have alot of stuff to learn.

@@RallyGuy There is no problem with you just learning C - but then a video about Rust is the wrong place for such questions as those are unlikely to even get the C-code correct (if not making it intentionally bad). As for the layout: You want your fixed-size member first as that allows for allocating the entire object in 1 contiguous block of memory. This is a bit more advanced C than you would ever see in this type of video here and not something you need to know when starting with C in general, but just doing 1 malloc instead of 2 will be faster and having it in a single block of memory means that accessing the data effectively only goes through 1 indirection instead of 2. So both creation and usage of the string would be faster. "which are to be handled by the code logic" only if you are using code that needs to deal with them. The encoding has absolutely no influence on how you decide on dealing with the data. UTF8 is a superset of ASCII meaning in C you can have your "normal" Char-string and either treat it as ASCII, Latin8 or UTF8. That is up to you. If you then want to get the correct string-length and you are treating it as UTF8 then it becomes slightly more computationally intense cause you are doing more work, but you are also getting more functionality for that as just treating it as ASCII would give you the wrong result. That is a very easy to make beginner error that i have seen a couple of times with tracing. People want to write out what their program is doing but also make it look pretty so they use the bordering-symbols to print a table. And then they suddenly notice that they get misallignments and wrong formatting at best, or memory-corruption and crashes at worst cause they did not account for those symbols being more than 1 byte. If you know that you are dealing with ASCII then you would just handle the string byte-by-byte and you would have no extra overhead either. As for examples - my C is a bit rusty after doing just C++ for many years now. And sadly the last few courses i had seen were basically horrible where they started with the most archaic version of C written in a horrible error-prone style. C is a relatively old language as it was created in the 1970s, and standardised in 89. But since then the language has evolved and gotten some nice additions. In general learning-by-doing and getting some instruction-series on UKposts works, or if you can a course at your local university.

@@ABaumstumpf thanks alot!

@@RallyGuy and just cause it popped up in my recommendations: ukposts.info/have/v-deo/iaBynI5knql5rqc.html ACCU has a lot of nice videos about specific topics in relation to C and C++

that's just cursed.

A bad UTF-8 parser could do something wrong if given this input, but that has nothing to do with the string itself, or even with C for that matter. this is not a good example.

@@U20E0 Thanks!!

Yeah my bad