Welcome back.
In the last lecture, you have learnt about bitts rooms and shrinks is lecture, you will understand
how they work together.
All right, let's get started.
Let's start by declaring a string variable that contains some single bite and multiple bite rooms like
this.
First of all, let me tell you that a string value is not an ordinary bitts less a street value is read
only by its slice, so I cannot change it like so.
As you can see, there are errors because strings are read only.
Of course, there is a solution I can convert a string value to a bite slice like so.
So that I can change the elements of the bitts license that let me print it.
As you can see, changing the bite size didn't change the original strength, but why?
It's because starting to bite conversion creates a new bite slice by copying the bite inside the syringe
so they don't share the same baking array.
That is why changing the bite size doesn't change the original string.
Let me show you the opposite of the conversion.
So this time I'm going to convert the bite slice into a string.
Do they share the same baking array now?
No, they still don't.
It's because the conversion creates a new string value by copying the bytes of the bytes to a new string
value.
So the S.R. variable contains the same string value, but it actually uses a different Badgingarra.
As you can see now, the string is different.
It is entirely a new string value.
The original one is gone, by the way.
It breaks the string, it prints some weird characters.
You'll understand why it does so in a minute.
So before going on, let me take the assignments back.
OK, so in summary, a string is an immutable BIID slice and you cannot change any of its elements.
However, you can convert it to a box less than you can change that new slice.
OK, now I'm going to print the bytes slice as hexadecimal numbers.
Since I created the byte slice from the estar variable, the BISLEY'S contains the same bytes as the
SDR variable.
Let me show you the length of the string and the bytes slice.
As you can see, the number of bites in the sink and the bite slice are equal is because the land function
counts the bites, it doesn't count the runes.
To count the actual rules, I need to use the room count in string function LACHSA.
You can also count the rooms inside the bisley's like so.
These two functions do the same thing.
They count the rooms most of the time there are more functions like these ones for the Sphinx and Bitts,
it's because you can think of the bytes, slices and strings are interchangeable values.
These mirrored functions are there to prevent you from converting a bite slice to a string or vice versa.
It's because converting them between each other may allocate new memory anyway.
So there are nine characters and 15 bytes in the string.
That's because the string also contains non English characters.
So some rooms inside the string, how?
Multiple bytes.
Now let me show you the bytes of the string one by one in a loop inside the loop here.
I'm going to print the current index and the byte at that index.
What will these print, what do you think, please pause the video and try to answer.
Interesting, isn't it, the indexes don't increase one by one, instead, it appears as if they increase
randomly.
Let me also change this to the UTF eight encoded version of the room here.
Remember, when you convert an integer, no go encodes it to UTF eight automatically, by the way,
Cuerpo here prints the given room.
As you can see, the second room is two bytes.
That's why the range loop jumps to the top index here.
Here, the Yangyang room is three bytes and the loop jumps from the seventh index to the stunt index
and so on.
This happens because the range loop jumps over the rules instead of the bytes in the string, and each
room may start at a different location in the string.
This happens because UTF eight encoding is a variable length encoding.
As you've seen before.
Each room may have a different number of bytes anyway, as I said, as string is a bytes less.
So you should be able to use it as a slice.
Right.
So let's talk about indexing and slicing a string.
For example, I can index the first rule laakso.
But can I index the second room?
As you can see, the first room is easily indexable because its length is one, but it's an ASCII character.
However, the second one is not indexable easily because it has two bytes here.
I only printed the first bite of the second one.
That is why it prints this nonsense symbol.
So how can I print the second room?
Well, I can put it into a new string value by slicing the string lachsa.
I slice it like this because the second room starts at the second bite of the string and it is consisting
of two bites.
Remember, slicing returns a value with the same type of the sliced value here.
It returns a string value because the sliced value is a string.
However, indexing a value returns the element type of the sliced value here.
It returns a bad value because the string is a bad slice anyway.
Now I can print the second run good.
The last room is for bytes long so I can slice the string for the last four bytes like so it prints
the emoji.
Cool.
As you can see, most emojis are multiple bytes.
So in summary, each room in a string can have a different number of bytes, so you can't easily index
a string that contains multiplied rooms in other programming languages, especially in a scripting language.
They do this automatically for you.
I mean, you can easily index characters, but you cannot do it with goal.
The main reason is efficiency.
Goal doesn't hide anything from you.
It allows you to control the encoding and decoding of the characters.
So you might ask, is there an easier way?
Yes, there is.
However, it's an inefficient form.
Let me show you.
You can convert the sink to Aroon Slice soap.
Of course, converting a street value to our own slice has a cost.
When I do so, go finds the rooms inside the string and packs them as rooms into the new room.
Slice one by one.
As you can see, go is an explicit language.
It doesn't allow you to hide the cost of something.
When the other developers or even you read the source code, they will be aware of that something costly
is going on here.
Anyway, why use a ruling class, it becomes very easy to calculate the length of the string.
It brings nine because there are nine elements or nine rooms inside the room slides now.
As you can see, this result is equal to our previous calculations here, indexing and slicing around
slice is also very easy.
For example, let me index the first rule.
And the second to let me also say for the first five characters.
As you can see, everything is correct, it seems like working with a ruling class is awesome.
So why don't we use it all the time?
Why gold doesn't always work with room slices and forces us to use bite slices and.
What is the catch?
Let me explain.
First, let me print the size of the room slice.
Remember, the room is an alias to interpret it, too, and it represents four bytes, for example,
this room has nine elements, so it occupies today six bytes in total, however, values a string.
Instead, it only uses 15 bytes.
This happens because UTF eight is a variable length encoding scheme.
So in UTF eight, each room can have different lengths.
So it's actually a pretty efficient encoding scheme.
This is why it's been used almost everywhere.
Another reason is why we don't use the rules all the time is that the Gold Standard Library and most
of the other libraries prefer to work with byte slices instead of room slices.
So let me summarize.
Let's take a look at this string value.
It's a Turkish word.
It means story.
There are four rooms in this string.
The first room has two bytes.
It is between the 08 and the first index.
The second room has a single bite.
It is at the second index, the third one has a single bite as well.
It is at the third index.
The classroom has two bites, like the first room.
It is between the fourth and the fifth index.
When you look at it from a bird's eye view like this, you can exactly see where the rooms start and
end.
However, in practice, while working with UTF and encoded strings, you cannot easily see where the
rooms start and stop because as you have Lawrence, UTF eight uses a variable length encoding so each
room can start and stop anywhere in the string value.
By the way, when you use a string, literal as in here, go in codes, the string value as UTF eight
automatically for you if your source code file has also been encoded in UTF eight.
So this string is no exception.
It's also been encoded in UTF eight.
I'm telling you this because a string value can be encoded with any type of encoding scheme.
So do not assume that Ristic value is UTF eight encoded only assume that string literals are UTF eight
encoded.
This means that you can store anything in a string value because it only contains bytes.
It's a bridezillas.
So in a string value you can even store an image as sounds or a music and so on.
I'm telling you this because do not assume that every string value is a valid UTF eight encoded string
value.
Anyway, that's all for now.
Thank you for watching.
Now you know the basics of bitts runes and strings.
See you in the next lecture by.