Like the video? Check out these C programming playlists with hundreds of videos! 🙂 C Programming Examples: kzread.info/head/PLA1FTfKBAEX6dPcQitk_7uL3OwDdjMn90 C Programming Tutorials: kzread.info/head/PLA1FTfKBAEX4hblYoH6mnq0zsie2w6Wif

@etmax1

2 ай бұрын

Is it perhaps that s1[] = "abcdef" results in the string being on the stack and s2* = "abcdef" has it defined in program memory space or as a const in heap space (depending on the compiler?) and being const in both cases is unmodifiable. Also you can do a cast of s1[] by saying (char *)s1++ and do the same as if it was declared originally as char * s1. There's also: s1[]= "hello"; foobar(void) { } where s1 isn't on the stack, instead on the heap. It would be interesting to check whether doing: char s2 * = "Hello"; would place the string in heap space or const space. I've just tried this and looked at what my compiler does with it and in the s1 case as expected I get: s1 char [6] 0x20000548 where we can see that s1 is an array pointer stored at address 0x20000548 (RAM) that has a length six and s2 char * 0x10002710 "Hello" is a char pointer pointing to a literal stored at 0x10002710 (ROM). So you can see we do know where it's stored, the only thing we don't know without checking is whether it's a const in RAM (heap space) or const in ROM both of which are non modifiable. BTW, because s2 is declared immediately after s1 the map file tells me that it is in RAM location 0x20000550

A little bit more in depth explanation: - In C string literals ( aka double quoted strings ) if not used as initializers for char arrays are staticilly allocated, that means they live in the .text / .rodata section and under most operating systems thats read only ( aka no self modifying code for you ;). - char s1[] and char *s2 are different types, s1 can be used in functions expecting a char* parameter because of some evil compiler backwards compatibility magic which automatically converts any function(s1) -> function(&s1[0]) - Both s1 and s2 in the example is stack allocated, but while s1 is an array of chars all values are also stored on the stack, while s2 is a char pointer and only the pointer variable is stack allocated the value it points to isnt. Its also quite interesting to look at the assembly your compiler generates and learn from that ;)

@bayyyi

4 ай бұрын

youtube ate my * characters, but i tink you get my point ;)

@psyience3213

4 ай бұрын

Exactly that's what i just commented above in the super popular, pedantic and yet wrong first comment

@bayyyi

4 ай бұрын

@@psyience3213 i missed it ;)

@user-sy2pe1dh3w

4 ай бұрын

It's not compatibility magic, it's called pointer decaying, you can't pass a whole array to you can't pass a whole array by value in c, instead you pass a pointer to the first element and the size of the array.

@guiorgy

4 ай бұрын

I suspected it was a pointer to globally static memory, makes sense it's read-only, otherwise every call to the fuction modifying that memody would get/produce different results. Thanks for the clarification.

char *s is precompiled in .text while char s[] is allocated in .data section so if you try to modify *s like s[0] = xxx, it will usually cause a sigseg since you're modifying .text section which is read only

@vladimironoprienko7177

3 ай бұрын

that makes things clearer. thanks!

@jansustar4565

2 ай бұрын

Isnt it always copied to the stack when a function is called? Unless main is sn exception. I guess i have to open up godbolt

@KhaledKimboo4

Ай бұрын

The Value of the pointer is stored in .text not the literal itself, .text would have a pointer value pointing to a region in memory (that region is not decided by your code rather by the os ) , his explanation is correct

@kevinquintana3085

Ай бұрын

Makes sense to me

Good video, but I like to also add that char msg[] ="hello"; is just shorthand for char msg[] ={'h', 'e', 'l', 'l', 'o', '\0'}; There are no such things as strings in C. Only char arrays or character arrays. And the address of first character of the char array is fixed , it is a constant pointer, &msg[0] and msg mean the same thing. And msg and msg + 0 is also the same , you can't change the base address of the array, it is suck in memory. It makes sense , lets say you had this : char s[]="car"; then decided to change it to s = "abcdefghijklmnopqrstuvwxyz123456789134566778889abcdefghijklmnopqrstuvwxyz" ; The compiler would have to find a large amount of memory for this new change in size. And there might not be enough memory for this new sudden change in size. Therefore a array's starting address being fixed is a good safeguard. Therefore the base address of any array in C is fixed, it is a constant. This applys to all arrays in C , for example: int a[]={1,2,3}; int b[={4,5,6}; you can't do this a= b; ////// same as a= &b[0] ; // because you are changing the starting or base address of the integer array called a . The address of a is fixed, and will remain fixed for the entire program. But I can do this , int *p = a; ///// int *p =&a[0]; then later I can change the int pointer to point to array b p = b; ////// because p is a pointer variable that can point to any variable or any array as long as it has the same data type , as the variable or array , that it is pointing, or refering to. Pointer variables can point to any variable of the same type. Again as I said earlier , char arrays or C-strings are character arrays only , there is no such thing as a string in C , they are not String objects like Java , or String objects like C++ or C# .

@PortfolioCourses

Жыл бұрын

Wow thanks so much for sharing all of this Rick! For anyone curious, some of this gets covered in other tutorials videos in the C programming tutorial playlist on this channel that cover strings, pointers, and arrays. And I get what you're saying regarding "C not really having strings", and I think you mostly clarified it at the end of your own comment. But just to be clear, it's inaccurate to say that "there are no such things as strings in C". In C there is no string *type* like some languages such as Java, but the language definitely has strings. In C the term "string" means a sequence of characters in memory ending with a null terminator, whether it's on the stack, the heap, or wherever the compiler being used stores a string literal. The official C standards make reference to strings and that's the term to use when referring to them: www.open-std.org/jtc1/sc22/wg14/www/projects#9899.

@Patrik6920

4 ай бұрын

...partly incorrect... Char *text="abcdef" is a pointer to a memory adress containing a string(a sequence of ints, ending with a string end integer Char Text[]="abcdef" is a pointer to a string object, still in a speciffic memory adress ofc, with the difference it also has an table with functions that can be performed on that memory adress... eg it is a STRING_OBJECT , (a table saying this object at this adress is a string and the listed functions can be performed on it, u can add or overwrite functions that can be performed on objects, usually a bad ide overwrite them, just extend if needed ) ...u can point at any memory adress and read it as a string..but its not a string object... eg the compiler has no ide what function is allowed to run on that memory adress... ex. Char Text[]="abcdef" print Text , (will print abcdef) Char *ptr_text=&Text *ptr_text=8 print ptr_text (will output the first charater after the string as a sequence of character until it reaches a end string int (out of bounds)... it will otput som part of memory as characters.

@atussentinel

4 ай бұрын

​@@Patrik6920 wdym by "Char Text[]="abcdef" is a pointer to a string object, ..., with the difference it also has an table with functions that can be performed on that memory adress... eg it is a STRING_OBJECT"? There is no such "string object" in ANSI C standard library. char text[] declares a char array, that's what it is. It's no way a "STRING_OBJECT" in C, neither a way to declare a "std::string" object in c++. The "table of functions" is even more ridiculous, C is not OOP native and there is no data structure having bound functions (methods). Explicitly adding function pointers to data structure is another story but it's neither something you can do with declaring only "char text[]". Everything in your original comment below the above line quote is hard to understand or difficult to follow. I'm guessing you are either mixing C with some other languages or regarding some custom/3rd-party string libraries as standard C.

@mytech6779

4 ай бұрын

Not an accurate statement. A C string is a null terminated array of characters. A true char array is just a sequence of bytes, it is not null terminated and will not work with routines that expect the terminating null unless you just get lucky and have put a null byte in the array. Like other arrays a true char array must have the length metadata tracked separate from the contained data.

@Patrik6920

4 ай бұрын

@@atussentinel when u create a string object thers functions that can be used on it, those functions is described (it isent some random data), when u compile a piece of code, and u try to use charachter functions on an int for example the compiler is going to realise it.. ...whats associatet with what int, char, float is described in a function table with that data type structure...

In case of embedded devices, and so I suppose in desktop application case also: char *s = "abcdef"; "abcdef" goes together with other constant variables to RO (Read Only) section of memory, that is a part of FLASH (CODE + RO). s pointer goes together with other non-constant global/static variables to RW (Read/Write) section of memory, that is a part of RAM (RW + ZI (Zero-Initialized)) (technically it placed in FLASH, but loads to RAM during initialization). char s[] = "abcdef"; "abcdef" goes to RW section ("s[]" goes nowhere, it kinda does not exist unlike "*s", that is specifically variable type to store address pointing to another location, because all address calls to "s[]" are stored in code commands and cannot be modified and it's the reason why you can't reassign "s[]" to another string later in the code). That's why if you want to save RAM space when using a lot of string arrays those are not gonna be modified, you must declare them "const char s[]" so their values could be placed in RO section (in this case it may look the same as "char *s", but there are still differences in compilation and how it processed by different functions like sizeof(), because array will have data type "char []" not a pointer type). This explains why you get that access error trying to modify value that is placed in RO section.

@CaptTerrific

4 ай бұрын

Which compiler or flags are you using for this? I'm not a professional C programmer, but I figured your first example would require a const declaration? I'm very likely missing something major, hoping you can help me :)

@JA-sv1gv

3 ай бұрын

I agree with all but the s[] part. It is a variable that refers to the starting address of the array and it should be observable in a map file with the associated size to it. Furthermore, there's a difference between initialization (compile-time) vs assignment (run-time). You can't re-initialize a variable but you can reassign a data at each element in s[] and ultimately change out the whole string even sizes during run-time.

Portfolio courses is without a doubt, the best c programming / computer science teacher !!

@PortfolioCourses

Жыл бұрын

Thank you for the very kind words Mefref. 😀

@mohammadahmedragab837

Жыл бұрын

I totally agree with you, it is the best C courses✨

@PortfolioCourses

Жыл бұрын

Thanks Mohammad! :-)

One is a string, initialised with abcdef and the other is a pointer to part of the program itself, 6 bytes representing abcdef. When I was writing embedded process control software a million years ago, the first version would be 6 bytes of RAM and the second would be a pointer in RAM pointing at a string of 6 bytes in ROM.

@tzwcard5936

3 ай бұрын

yeah that's what I also think so, that contents of s1 allocated in program stack while s2 allocated in .text (which is read only and cannot be modified without something like VirtualProtect() in windows)

@Hoffmatic

Ай бұрын

I’m still learning C and taking an Embedded systems class. I wrote a char * array when transmitting over UART because google said to, while my professor said to traverse over the array instead. When I asked him to help debug my code he was blow away that I used the more efficient method, and so was I lmao

This subscription reminder is the best I have seen so far. Totally non-obtrusive and non-annoying. I love it. *Klicks subscribe*

Extremely useful. Please make the same video with more examples and corner cases. You are very good teacher. You deserved to be paid.

Very good video, thanks to your calm, soothing voice and the low pace in which you explain everything step-by-step!

@PortfolioCourses

Жыл бұрын

I'm glad you enjoyed it! :-) And thank you very much for the positive feedback.

Great video. It's been a couple decades since I've done any C programming and I've forgotten some details like this since my programming focus has shifted considerably to functional programming, Python, and C++.

@PortfolioCourses

4 ай бұрын

I'm glad you enjoyed it! :-)

Excellent explanation! I just went through a string section in a C course I am taking and completely misunderstood the content. Even though I was able to stumble through a couple projects, I really did not understand what a "string literal" was and how it was different from a character array defined as char[]="some string". This cleared it up perfectly. You have a rare gift in instruction for the C language and I feel lucky to have found Porfolio Courses. Judging by the other comments, I hope you will continue this great work.

Litterally had the exact same question a week ago in my HPC-course! Many thanks 🙏🙏🙏

@PortfolioCourses

Жыл бұрын

You’re very welcome Grabriel! :-)

char* s2 = "hello", attempting to change string literal is undefined behavior so you don't know what will happen in run time.

@PortfolioCourses

9 ай бұрын

Yep! :-)

@Hardcore_Remixer

4 ай бұрын

As far as I have experimented, it gave a segfault. The teacher explained that in assembly it is placed in the .text section (which only has read permission) and the pointer just gets assigned the begining address of that string. Though, I haven't tried it on other architectures than x86.

@johnmcleodvii

4 ай бұрын

The definition of undefined means it is stupid to use even if it appears to work. Way back in the era of 8086 and 8088, there were compilers where this worked - sort of. This was before x86 had much in the way of process security. The gotcha is that that string literal would change for EVERY instance of the original string. I think it was an early Microsoft compiler, but it could have been some other compiler.

@Hardcore_Remixer

4 ай бұрын

@@johnmcleodvii Well, it actually makes sense that when you modify one of the instances of a string constant all of them will modify the same way because it is usually the same string constant being referenced by all of its instances in order to save memory.

@obinator9065

4 ай бұрын

I thought it would even give me a compiler error

the c++ compiler will forbid to declare char * s1 = "test"; because it is a convertion from const char * to char * which is forbidden.

Once again, a clear explanation on a tricky point. Thanks 🙏

@PortfolioCourses

10 ай бұрын

You're welcome, I'm glad you found the explanation clear! :-)

@CaptTerrific

4 ай бұрын

Don't you mean a tricky point...er? I'll see myself out

Yep, depends on your compiler. I've lived with this over the years I've been working with C on embedded systems. It's one reason why fixing your projects code development to a particular version of your compiler tool chain, AND the optimisations you use, is very important.

@earthwormscrawl

4 ай бұрын

It also depends on the execution environment. A segmentation fault requires a memory protection unit. When working with a flat physical memory, typical in embedded systems, the two approaches will behave identically.

You should be able to define in the linker in which segment the literal is stored and what attributes it have. In GCC __attribute__ ((section „.rwdata“)) would work as well.

@halitcetin5148

4 ай бұрын

Lets not to make the code compiler dependent.

Very clear and good information! Thanks !!

The compiler allows you to modify. It is the runtime protections that prevent it. If you tried it in DOS then it likely would likely work.

@PortfolioCourses

4 ай бұрын

The compiler may or may not allow you to modify it according to the C standard. In the C standard it's something called "undefined behaviour", there are other undefined behaviours. The compiler could produce code that allows you to modify the string literal, and that would still be a valid C program.

@dibblethwaite

4 ай бұрын

@@PortfolioCourses The language definition says that the behaviour is undefined in order that implementations may put the string in protected memory if such a thing exists on the target platform. The compiler typically needs to do nothing to either allow you to or prevent you from accessing the memory and as @okaro6595 says it is normally the operating system/hardware that blocks the access. It is also true that DOS compilers used to allow this sort of access back in the day since no protection mechanism existed in the hardware. So you may find that these things make sense to you once you understand the reasons that the standard declares the behaviour as undefined.

@PortfolioCourses

4 ай бұрын

@@dibblethwaite I appreciate and understand what you're saying, my only point is that because the language definition says that, compiler makers can ultimately do what they like, e.g. they could even put the data for string literals on the stack. Now of course practically, why would they? But again my only point is to state the fact that the language standard lists the behaviour as undefined, so we can't assume. Again though I do appreciate the discussion on underlying reasons "why".

When I'm building code with a new toolchain I am always looking at where that tool is putting my string literals (through the map file) just to make sure I understand what it's assumptions are. And these assumptions vary with optimisation options

Awesome stuff. Learned something new. Thank you

@PortfolioCourses

Жыл бұрын

You're welcome Amani, I'm glad to hear you learned something new! :-D

The pointer in c[] is constant, but in *c it is a variable that can change value. But everybody know that.

great channel i'm planning to see your whole c++ course later 👍

@PortfolioCourses

Жыл бұрын

Thank you, I’m glad to hear that you’re enjoying the channel! :-)

2nd declares a pointer and makes it point at character constant {"abcd"} (which is type of "const char *" not char* (one most likely gets compiler warning about mixing both). And segfault wile executing.

Thanks bro. It helped me to clear confusion

@PortfolioCourses

6 ай бұрын

You’re welcome, I’m glad it helped clear confusion up for you! :-)

- I believe in some compilers, a string literal is a constant char array stored on the code segment of the memory. In the case of `char s1[] = "string";` the compiler copies string from code segment into a mutable array on the stack, and assigns to s1 the pointer to the first character of that array. In the case of `char *s2 = "string";` the compiler only assigns s2 the address of the first character of the string literal stored on code segment. The code segment is readonly, so we essentially have a pointer to something that is immutable. But ofcourse, for s2, we can change what we are pointing to. - I think, you should use %zu instead of %d, for printing the result of sizeof(). Otherwose compiler may emit a warning. Thanks for preparing these video seroes on C.

@PortfolioCourses

Жыл бұрын

Yes, you got it. In your original comment you said the compiler emits a warning and I wrote this in response: And that's funny, I get no warning with my compiler with %d and sizeof(), though the types are technically different so I can see how a compiler might do that (it might depend on the settings). You have since changed your comment to "*may* emit a warning", which is totally cool, but it made my response make less sense so I'm editing my comment too. ;-) Technically sizeof() returns size_t, maybe I'll make videos on sizeof() and size_t next, I haven't covered those yet. 🙂

@alib5503

Жыл бұрын

@@PortfolioCourses I guess you should add some flags to the default compilation command. Flags like `-Wall -Wextra`. These enable most (if not all) of warnings.

@PortfolioCourses

Жыл бұрын

@@alib5503 One day maybe I can make a video about compiler flags too, that's a good idea. I think the warning level someone would want to use would depend on what they're doing.

@alib5503

Жыл бұрын

@@PortfolioCourses Sorry about that! I didn't refresh the page. Yes, many warnings come with those flags included. And yeas, size_t is the output of size_t and functions like strlen(). I believe It is a typedefed to unsigned long long.

@PortfolioCourses

Жыл бұрын

@@alib5503 Oh no worries at all haha, I just wanted my comment to also make sense. 😛

Great video explanation! Let me know if I understood rightly. I can't change the string attributed to a pointer. But, if I attributed the pointer to a delcared string I am able to change the "pointer"? Like: char *ptr = str (declared before).

Great tutorial! Thank you so much for taking the time to make it.

@PortfolioCourses

6 ай бұрын

You’re welcome, I’m happy that you enjoyed it! :-)

Thank you for taking the time to make these very informative videos. For someone coming from a higher-level language, you get right to the point explaining things that you don't find in, say C# or Python. I have one question about this particular topic: When you "reassign" a const char* to a new string literal (I guess, "point it to a new one" would be more accurate), what happens to the old character data in the first string? As in your example: const char *s2 = "abcdef"; //then later, you reassign s2 to: s2 = "new string"; Does the "abcdef" just lay around somewhere, or does the compiler remove it from memory? Thanks!

@PortfolioCourses

Жыл бұрын

Great question! In this example, it must "lay around somewhere in memory". :-) If we had saved the memory address of the string (more specifically, the first character of the string) into a different pointer variable, we could then access that same string literal, when we set s2 to something else. So the compiler and C won't remove it from memory. Now, as a side note, I do wonder if a compiler would be smart enough to remove something like this from memory: const char *s2 = "abc"; s2 = "def"; Because in this case, *maybe* the compiler could tell "at compile time" that the string literal "abc" will never be used. So *maybe* a compiler could remove the string literal "abc" from memory when the program is compiled, knowing it will never be used. But I'm not sure if a compiler could do that, or if it would do that, I'm just speculating for fun. :-) Maybe I need to test this out and see what happens hahaha...

@PortfolioCourses

Жыл бұрын

So yeah... I did a little test right now. :-) And at least with gcc on my MacOS machine, there is no optimization like that... the string literal will stay in the compiled executable even if it is never used at all.

@mkd1964

Жыл бұрын

@@PortfolioCourses Wow, thanks for such a detailed answer! So that's interesting. I'm still very new to C so it makes me wonder why you would ever bother using strings in this manner. The only scenario I can think of would be to display something like on-screen instructions, field labels, or menu items. Stuff that will probably get used more than once, but not likely to change during the program.

@herohera3497

Жыл бұрын

@@mkd1964 hii u there...r u still studying

@mkd1964

Жыл бұрын

@@herohera3497 I'm not in school, if that's what you mean, but yes. I'm just learning C for no particular reason. I've always found it interesting and challenging and wanted to have a more thorough understanding of how it works.

The s2 remains stored in the binary of the program while s1 is stored as a copy on "the stack". Some operating systems will allow you to change bytes between executable code, like cc65-built code for Atari 8 Bit, Apple II and C64, while other, more secure operating systems will deny access to it. The same will happen in any other programming language (look up "self modifying code"). This may be one reason why the C standard is not specially forbidding modifying s2, but operating systems do.

🥳Wow!! Thanks a lot sir!! This is massive for me..

@PortfolioCourses

Жыл бұрын

You’re welcome! :-)

@jess-inspired

Жыл бұрын

Hello sir, can I link this video on my channel to refer my viewers here for better understanding?😊

This is so helpful thank you honestly

@PortfolioCourses

Жыл бұрын

You’re very welcome Mahmoud! :-)

I wish i could have watched this video back in 1998. Really well-explained!

Very good explanation, Thank you

@PortfolioCourses

Жыл бұрын

You’re very welcome Chetan! :-)

Hey appreciate the content man , what editor do you use and i would like to know how you effortlessly jump out of autocompleted brackets. Do you use arrow keys or is there a keyboard shortcut?

@PortfolioCourses

9 күн бұрын

In this video I'm using Xcode on a Mac. I just use the arrow keys, nothing special in this video. :-)

Brilliant explanation thank you so much😘

@PortfolioCourses

Жыл бұрын

You’re very welcome, I’m glad you enjoyed it! :-)

Good video. Subscribed. Cheers

in which playlist these types of videos you have? where you discuss these types of generic problems??

I did C and later C++ for over a decade and was pretty close to giving up programming. Writing business software, I was so frustrated by the tedium of C and C++. Keeping .h files in sync with .cpp files, managing pointers, and my biggest frustration: dealing with strings. It's just so tedious in C and C++. Fortunately, right around that time, C# showed up and strings were as easy to work with as any other data type. Memory management became a distant memory and no more header files. I don't miss that stuff at all.

@C2H6Cd

4 ай бұрын

Try Rust too (no GC), it’s kinda cool and deals with tedious and dangerous memory management (also multithreading) issues by design. Of course it has a “dark side” (unsafe code) but at least tries to deal with such stuff in a clear way. My problem with C/C++ is that it allows shooting yourself easily in the foot (as Stroustrup said) and even proud of it… Idk why it’s OK to be openly dangerous after decades, we are not in the 1980s anymore.

what Editor or IDE do you use ? Looks neat and very simplified, i wanna give it a try too.

@PortfolioCourses

3 ай бұрын

Xcode on MacOS

good video. very well done.

Awesome video, help me a lot... New sub!

@PortfolioCourses

Жыл бұрын

Thank you Almir, I’m glad the video helped you out, and welcome aboard! :-)

i know this but they you describ, just perfect!👍

The pointer variant reminds me of a linked list. Where you don’t know where it’s allocated except for the first node.

Theoretically if this pointer to a string literal would be in a function that gets called multiple times the pointer could always be the same. In the output the string literal itself would probably be defined before the function as a "constant" and the pointer would always be to that constant.

i didn't get how s1 is passed as a pointer to printf? it's passed as a value no?

Thank you for making this video sir🙂

@PortfolioCourses

Жыл бұрын

You're very welcome! :-)

It's more about the OS and modern security features than the compiler, I should think. Run the same code on an old enough system or even most modern microcontrollers and it might well let you change a literal. The compiler could technically put string literals somewhere else if they wanted to but that'd increase memory usage of your program in some cases. Generally, the text segment (which includes executable code and literals) get marked read only in a way that's either enforced by the OS or the CPU depending on the system. That allows those segments to be shared between processes running the same executable on systems with virtual memory and memory protection. It also prevents certain types of security exploits. Coupled with Execute Disable (XD) on the writable segments of the process's virtual memory and it becomes easier to crash a program with bad code but much harder for attackers to exploit.

@PortfolioCourses

3 ай бұрын

Thanks for leaving this comment, it's a well put version of a point a few others have made. I agree with what you're saying overall, a string literal being placed somewhere like the stack for example would fall under the "nasal demons" category of "highly unusual.... but legal" C compiler behaviour: www.catb.org/jargon/html/N/nasal-demons.html.

great vid, but I think "new string" should be 11 long including the terminator?

Would have been interesting to run the code through the GodBolt compiler explorer, I think you’d spot some additional changes in the code generated by the compiler(s).

Hi, what keyboard do you have? the sound is very satisfying.

@PortfolioCourses

Жыл бұрын

I have an Apple keyboard, I think it's called a "magic" keyboard officially. 🙂

5:55 So, char *argv1[] and char **argv2 differs, right? argv1 is a pointer that points to constant pointers. argv2 is a pointer which points to another pointer.. and i can use pointer arithmetic in this situation.( like **argv2++; ) Is that correct?

@PortfolioCourses

Жыл бұрын

Yes, they differ. char *argv1[] would be an array of pointers to chars. char **argv2 would be a pointer to a pointer to a char, and yes you could use pointer arithmetic in this situation. :-)

And can I create a string literal that uses special characters, like in char *s2="%s: %.2lf %.3lf ","something",M_PI,sqrt(2.0); ? Or is it too advanced for C compiler and I need to use some function like sprintf()?

@mikechappell4156

4 ай бұрын

The only character you cannot embed in a traditional string is '\0' because it usually acts as a terminator. You might be able to include it, but C generally uses '\0' terminated strings in arguments. You could create a library that stores the length of a string in the first byte instead of using a terminator, but that forces a limit on the length of a your string and you'd need an entire library of functions to deal with them since stdio and stdlib both assume nul terminated strings. I think the C compiler can handle some simple math using direct constants but it can't evaluate functions. The compiler doesn't evaluate *printf arguments, the stdio library is responsible for that. You'd want to use sprintf for that if you wanted that evaluated.

Best C tutorial!!!

@PortfolioCourses

Жыл бұрын

Thank you very much for the positive feedback Eden! :-)

Perfectly explained, thank you!

@PortfolioCourses

Жыл бұрын

You’re welcome! :-D

Why when u printed the s2 ,it gave you an abcdef instead of the address of index 0 ,since s2 is a pointer?

@PortfolioCourses

Жыл бұрын

Great question! Because I used %s, printf output the string, if I had used %p it would have output the address stored in the pointer instead. :-)

@edward3105

Жыл бұрын

@@PortfolioCourses Ohh I wasn't paying attention,u are right!

@PortfolioCourses

Жыл бұрын

Cool glad it’s sorted out for you. :-)

char *s2 ="abcd" ; // gets `warning: ISO C++ forbids converting a string constant to ‘char*’ [-Wwrite-strings]` char const *s2 ="abcd" ; // does not get a warning, using g++ 13.2 -std=c++17 And there in lies the true answer.

The example with char *str = "abcd"; str[0] = 'k'; compiles and changes the first index of the string in microsoft compiler, is that normal ?

@PortfolioCourses

Жыл бұрын

Great question Avetik! :-) Modifying a string literal has “undefined behaviour” officially, this means it *could* work but it’s definitely not guaranteed to work. So it’s “normal” but it’s not something that you should count on always working.

What to do if you want to change the string literal on purpose? I suppose you use char * s1 then reassign s1 to your hearts content?

@PortfolioCourses

Жыл бұрын

Great question Angelo! :-) I would copy the string pointed to by s1 into a char array using strcpy(), and then yes you can modify it to your hearts content after that.

What is editor that you use? Thanks in advance!

@JefreySobreira

2 ай бұрын

Looks like Xcode

this was worth a sub

@PortfolioCourses

Жыл бұрын

I'm glad you liked the video, and welcome aboard! 😀

Oh man. Where is the comparison of the assembly generated by the compiler? :(

amazing my dude

@PortfolioCourses

Жыл бұрын

Thank you Albin! :-)

This is why I always write my pointer decls as "char* s2" rather than "char *s2". The "pointerness" is part of the type, not the variable. And writing it my way makes it more obvious.

@PortfolioCourses

4 ай бұрын

I've usually done it as char **s2 because that's the standard code bases I've worked on have used, but I completely get what you're saying, char** s2 does make it clearer that it's "a pointer to a char" in that sense.

@PortfolioCourses

4 ай бұрын

Using stars in KZread comments messed up what I was saying and then when I fixed it, it still bolded it. I'll have to read up on how to actually do a star in a comment. :-)

@remcogreve7982

4 ай бұрын

I think c declarations are supposed to mimic how they are used. That is why. I don’t like it either. Most modern language designers seem to prefer the old Pascal way of declaring. I like that much more.

for example: char* ptr="Hello"; ptr="Bye"; what does happen to "Hello"? Is the memory where it was stored freed? Or do I get memory leak someway if I continue to assign different values to ptr? Thank you.

@PortfolioCourses

9 ай бұрын

Assuming the compiler doesn't optimize it away, "Hello" will be somewhere in memory. We wouldn't really call it a leak because it's not dynamically allocated memory that we are expected to free(). But it would sort of be like a memory leak in the sense that we have data in memory we aren't using. :-)

@JosephMwema

4 ай бұрын

Thank you for asking that Question. It has helped me to understand something in his answer.

you should use zu format specifier for sizeof as it returns size_t type

@PortfolioCourses

Жыл бұрын

For the size of numbers we are dealing with in these simple examples %d will work fine. If we're going to use size_t values for larger numbers, like allocating massive blocks of memory for example, we would want to use %zu (though even with %zu, there are portability issues you can run into with some older compilers...). For anyone curious about learning more check out these tutorials: size_t type explained: kzread.info/dash/bejne/oHZ-17KYpdGYYLA.html sizeof operator: kzread.info/dash/bejne/ZKuCxZNuaZWciJc.html

I want to get into C as an alternative to rust, but I've never broken through the basics yet. Do things that *read* strings implicitly deal with the differences between pointer and literal strings? Rust burned me with all that by having more string/string adjacent variants than I can count on two hands, and explicitly requiring the exact variant every time.

@mgancarzjr

2 ай бұрын

It's going to depend on the function that deals with them. Some functions will read one char (1 byte) at a time until they reach a '0' character, and some will read a specified amount of bytes whose value you have to supply. Be very careful of both. For example, let's say you overwrite the final character of your char array. It's still a valid array, but a function expecting a '0' character will keep reading OR WRITING directly into memory until it hits a '0' if you pass it the starting address of your array.

0:38 Note: a string literal is not guaranteed to have a closing null character! If you write char s[6] = "abcdef"; there will not be a null terminator.

@kosiak10851

3 ай бұрын

"abcdef" has null terminator, it is just not assigned in because of lack of space

Great content

@PortfolioCourses

Жыл бұрын

Thank you very much! :-D

Why isn't the type of the string literal const in the first place? why doesn't it make you cast away the const to assign it to a non-const pointer?

When you re-assign the pointer to a new string literal, how can you be sure that the previous one was deallocated? Or it goes to some kind of pool and never gets deallocated?

@PortfolioCourses

3 ай бұрын

String literals don’t really get deallocated. Where they are in memory ultimately depends on the compiler, but the compiled program has segments like the data segment where we may expect to see the string literals stored: en.m.wikipedia.org/wiki/Object_file

@mgancarzjr

2 ай бұрын

You can test this yourself with g++ in Linux or in WSL. g++ -S input.cpp It will generate an assembly-language file input.s

In x86 you often got string literals placed in CODE segment not in DATA. On microcontrollers you almost certainly got string literals placed in ROM. So there're pretty obvious reasons why you can't modify them.

if we use string literal to initialize char array like , char s1[] = "abcd"; Does it mean we use both stack memory and memory that stores string literal ?

@PortfolioCourses

Жыл бұрын

Great question! :-) We shouldn't really do this because 'char s1' will declare a char-type variable on the stack called s1. It can store a char. But "abcd" is a string literal. We can't assign a string literal to a char variable (successfully). We would want to have: char *s1 = "abcd"; instead. In this case, s1 is now a type "pointer to a char" variable, and it exists on the stack. It will store the memory address of the first char in the string literal "abcd". Where exactly string literals are stored in-memory is up to the compiler, we don't know whether they are on the stack or somewhere else (e.g. there is a portion of memory set aside for the program source code itself).

@akatsuki947

Жыл бұрын

@@PortfolioCourses ooh it was my typo i wanted to type s1 [] = "abcd" instead and thank you you still answered what you already clearly explained in the video 😂 my fault .

@PortfolioCourses

Жыл бұрын

@@akatsuki947 Oh haha no worries, I thought maybe that was a typo. 🙂

The compiler I used 25 years ago wouldn't complain about s2[0].

How come s2 is printing the whole string instead of printing the first character since it's only pointing to the first character

@PortfolioCourses

11 ай бұрын

Great question! :-) When we pass a pointer to a char to printf and we use %s as the placeholder, printf will just keep printing characters from that position in memory onwards until it encounters a null terminator character.

@PortfolioCourses Does this apply to c++ as well?

@epiendless1128

3 ай бұрын

I just tried in Visual Studio c++. It literally wouldn't accept char *s="string". Flagged it as an error before I got as far as compiling. I had to make it _const_ char *s="string". Then it wouldn't accept s[3]='o', because it knew s[] was a constant. So this c++ IDE won't even let you make the error.

@mgancarzjr

2 ай бұрын

It should compile if you use const_cast: const string *s1 = "hello"; char *s2 = const_cast(s1); s2[0] = 'a'; Will still result in a segmentation fault at runtime though.

sir can you help me with how can I read name initials from a column in an array?

@PortfolioCourses

Жыл бұрын

I'm not sure I understand the problem exactly Wallace. There are a number of videos on this channel covering 2D arrays that might help, like this one for example: kzread.info/dash/bejne/jImEyLmzhM-2kqg.html. :-)

It pretty new with C++, but i always get confused with pointer and adresses. Can't a pointer only point to an adress? How can it be pointed to a String? Normally i have to add a & before everything.

@PortfolioCourses

4 ай бұрын

It can be "pointed to" the first character in the string, i.e. the pointer variable can store the memory address of the first character in a string. And at that point we can say "it points to a string".

This somewhat reminds me to assembly

I'm assuming all string literals used in the source code are stored globally. When you use a pointer to a string literal, it gives you a pointer to that global memory, and since next time the current function gets called the same memory pointer will be used, the memory must remain constant, otherwise the next call to the function will produce different results. Using a character array copies that memory to the stack, so you can modify your copy as much as you want.

@salsamancer

4 ай бұрын

It depends on the linker. Usually string literals will actually be in the read-only text segment with the assembly.

while taking char str1[]="abcde" and char* str2="abcde", why does sizeof(str1) outputs 6 and sizeof(str2) outputs 8, shouldn't the size of both strings be same?

@PortfolioCourses

Жыл бұрын

Great question! :-) The strlen() function will give us the length of a string, but the sizeof() operator will give us the size in bytes. So if str1 is a char array that stores 6 chars (abcde + null terminator \0) and each char is one byte, that is 6 bytes total. If str2 is *really* storing a pointer to a char (the first char in the string), then it's really storing a memory address, which is 8 bytes on my system/compiler. sizeof(char *) should give us the same result back because it's giving us the size in bytes to store a pointer to a char. The video explains sizeof() more, you might find it interesting: kzread.info/dash/bejne/ZKuCxZNuaZWciJc.html. :-)

@atussentinel

4 ай бұрын

When you call sizeof() the content doesn't matter, only the type matters. so "sizeof(str1)" is equal to "sizeof(char[6])", which is 6. The size 6 is figured out by the compiler at compile-time. then "sizeof(str2)" is equal to "sizeof(char*)", which is 8 on a 64-bit system.

So char* s2 is read only even if you don't specify it with const?

@PortfolioCourses

Жыл бұрын

I'm not sure I 100% understand the question, but yes s2 can be read even if you don't specify it with const. Using const will help to make sure we don't try to write to the the string literal that s2 is pointing to though.

MSVC used to allow modifying string literals but then disallowed it. The road to compiler completion can be a long one.

@PortfolioCourses

4 ай бұрын

Thank you for sharing that. :-)

you are the best dude

@PortfolioCourses

Жыл бұрын

Aw thank you very much! :-)

I'm watching and following along. You declare that the following creates a character array. char s1[]="abcdef"; As per your description, it appears that you are forcing the string to break up into an array filled with individual characters. An array of 6 individual characters: ("a","b","c","d","e","f") I may be misunderstanding this, but that is how it comes across. Is this not what is happening?

Just as a fun fact, I'm almost sure that if in C++ you pass a constant string to a char*, the compiles optimizes and allocates for you.

what's the ide ??

So I get that they are different but why are they different? They seem like they should do exactly the same thing to me.

4:29 if it gives a runtime error as opposed to being stopped by the compiler, than doesn't that mean that the compiler does allow it? It just gives a seg fault when u run it...

@PortfolioCourses

Жыл бұрын

The compiler allows the code to compile because it conforms to the C language standard. But the compiler doesn't allow us to modify the string literal at runtime... theoretically, the compiler could support this and compile the code in such a way that we are allowed to modify the string literal, because the C language standard only says that the behaviour is "undefined".

@bsykesbeats4013

Жыл бұрын

@@PortfolioCourses ahhh makes sense thank you

@PortfolioCourses

Жыл бұрын

@@bsykesbeats4013 You're welcome! 🙂

@mikechappell4156

4 ай бұрын

@@PortfolioCourses It's not the compiler throwing the error, it's basically the OS. IIRC, protected mode prohibits self modifying code, and if it's in the code segment, it's code, even if it is just data. I think real mode used to allow it. I don't think modern processors even support real mode. Self modifying code was common on 8-bit machines.

@PortfolioCourses

4 ай бұрын

@@mikechappell4156 That's true and a great point to make. Though what I said in the reply was that the compiler "doesn't allow us to modify the string literal at runtime", and that's also true. The compiler compiles the code in such a way that we can't modify the string literal. But the compiler could compile the code in such a way that we could modify the string literal, and it would still be compliant with the C standard because the behaviour is undefined.

great video

@PortfolioCourses

Жыл бұрын

Thank you Timo! :-)

If the code compiles, hasn't the compiler just allowed you to write the memory location? If I'm not mistaken, it's the runtime that gives you the error.

@PortfolioCourses

4 ай бұрын

Because it’s undefined behaviour, a compiler creator can do whatever they like. They could have it produce code that allows you to write or not write to the string literal. The error is going to occur at runtime, and in practice the compiler designer is going to almost certainly just let the architecture dictate the behaviour. But because it’s undefined behaviour in the C standard, it’s ultimately up to the compiler, and we shouldn’t make an assumption about what will happen (unless we are ok with our program being less portable).

@tetsi0815

4 ай бұрын

@@PortfolioCourses Maybe I just misunderstood what you're trying to say at 4:03. The compiler literally just compiled your code and you were allowed to run it. Then on runtime you got the error when you tried to write to memory location s2[0]. And it's not that the compiler (in that specific situation) could not see that you're trying to modify a string literal.

@PortfolioCourses

4 ай бұрын

Yeah, the compiler did compile the code, but the C standard says it’s undefined behaviour to write to string literals, so other compilers could (more theoretically speaking) handle writing to string literals as they like, and they would still be valid standard compliant C compilers. That’s my only point really. Virtually all resources online describe undefined behaviours as things that are up the compiler because that’s a simple and accurate way to put it. There’s definitely more to the story as to why something is made undefined behaviour to begin with and how compilers will handle things in practice.

"Gojo satoru" The string will end with '\o' after u? And, are white space and '\o' treated same while scanning?

@PortfolioCourses

Жыл бұрын

The string will end with the null terminator \0, after u, yes. I'm not sure what you mean by "scanning", do you mean using scanf and similar functions? :-)

@prabhu_0377

Жыл бұрын

@@PortfolioCourses yes,using scanf function to read the input.

@prabhu_0377

Жыл бұрын

@@PortfolioCourses Thanks for answering.

did you know you can use s2 like char array also?

What programming font do you use?

@PortfolioCourses

3 ай бұрын

I think XCode uses some kind of Helvetica font.

@mc-ciro

3 ай бұрын

@@PortfolioCourses thanks

you could use de-assembler

Good video. White theme burning my eyes though 😁

Thank you

@PortfolioCourses

Жыл бұрын

You're welcome! :-)

How does this program call? I need this!

@PortfolioCourses

Жыл бұрын

Sorry I'm not sure what you're asking Maksim. The code in this video is available here: github.com/portfoliocourses/c-example-code/blob/main/char_array_vs_string_literal_pointer.c. :-)

Ty I got my first divine because of you

@PortfolioCourses

Жыл бұрын

You're welcome Marilyn! :-) Is a "divine" a type of grade, like getting an A? I've never heard the word used like that before. Congratulations! :-D