int *p vs int* p Pointer Declarations | C Programming Tutorial
Вставка
- Опубліковано 17 сер 2022
- A discussion about the different ways to declare pointer variables in C, including how one approach could lead to confusion and bugs if we try to declare multiple pointer variables with a single statement. Source code: github.com/portfoliocourses/c.... Check out www.portfoliocourses.com to build a portfolio that will impress employers!
The comments suggesting declaring one variable per line as the better/ultimate solution are spot on, I've made this video covering the advantages of this style: ua-cam.com/video/cuRCEZpotHM/v-deo.html.
The videos on this channel are mostly targeted at beginners, such as students taking C Programming 101 courses, and I made this video in response to comments asking about the star when declaring multiple pointers... i.e. what is going on here, what does the star do, do we need more than one star, what way should we do it? For some reason the UA-cam algorithm decided to promote this video like wild over the last week... I'm genuinely shocked, in almost 3 years of doing this channel it's never done that before.
So if you're new to the channel, welcome aboard! The videos here do target beginners coming to UA-cam with "school exercise" type questions, so things like %d vs. %zu, how types can be different sizes depending on the machine/compiler, etc, aren't covered in every video (though there are videos covering topics that are generally beyond a typical C Programming 101 course, like sizeof(), size_t, pthreads, etc.). There are some really good channels covering C programming in more depth if you're looking for that (Low Level Programming, Jacob Sober, CodeVault). 🙂
If you do like these videos, check out these C programming playlists with hundreds of videos! 🙂
C Programming Examples: ua-cam.com/play/PLA1FTfKBAEX6dPcQitk_7uL3OwDdjMn90.html
C Programming Tutorials: ua-cam.com/play/PLA1FTfKBAEX4hblYoH6mnq0zsie2w6Wif.html
I've always considered this to be a failure of the language definition. An int is clearly a different data type than a pointer to an int, so the * should be part of the type, not the variable name. Therefore, I always use int* i;, and never do multiple variable decls on the same line.
This, precisely. Agree.
You need to call *p to dereference the pointer and access the int. So *p is an int. Now `int *p` makes more sense, doesn't it. At least it helps me understand how to think about it. I agree the language could have been better about this though
True, but at the same time p is an int*, so int* p makes the same amount of sense for that syntax
Same here, "int-pointer p" has always made more sense than "int pointer-p"
I am on the same team here.
Also, literally EVERY established coding standard disallows or at least discourages multiple variable declarations per line. Therefore, the problem shown in the video is accurate but shouldn't happen in the first place.
I guess the only reason why this has never been cleaned up are gazillions of lines of legacy code that used more than one variable declaration per line, happily mixing variables of the actual type and pointers to variables of the type in one line. You know, that kind of code that gives C a bad name... I will stick with my "type* variable_name" style, no matter what. It's like the toilet paper roll thing. There is only one correct way to put it on the holder, but some people still think it must be the other way around. 😂
As old (or, excuse me, mature) as C is, there's still no end of the mayhem you can create! Or, as my friend says: C is happy to let you put it into reverse at 60 MPH. Thanks for this clear and concise video.
C is probably becoming more relevant now than it has been the last 20 years simply because people are starting to come out of the OOP stupor they've been in. Rust and C. Use Rust for security centric applications and C elsewhere.
If c had a motto, it would be, “you know what you are doing, I hope”
@@kellyfrench The worst part about C is libc and all the inherently unsafe functions it provides. If we kept the same language but provided a safer and more fully featured standard library that came packaged with gcc or clang I'm sure people would not dislike C as much as they currently do.
Sure, those structs have the same size. Here's this one cast as that one. Have fun with the runtime error of the non-null terminated string!
Best comment I have heard to far, gave me a good laugh 😄
I have always preferred int* p, because when I first learned C, I would get confused between declaring a pointer to an integer and dereferencing a pointer. It was easier in my head to remember that int* is a pointer to an integer and *p is dereferencing a pointer. Nevertheless, I understand your point-of-view and neither notation bothers me anymore.
its kinda because authors of the language(s) meant that `int *p` means that you will use it as `*p`, same for `int p[...]` allowing for `p[...]` and other syntax constructions
I’m the opposite, because I think of it as *p is type int.
Think about this again. The dereferenced p is and int. So p is the pointer and *p is an int.
Therefore int *p makes perfect sense.
I still use this to this day and was backed up in it by a video from Brian Will. He suggests that we shouldn’t even think of int* as a “pointer to an integer” but rather as an “integer pointer type variable.” Viewing pointers as types helped me fully separate them in my mind from dereferencing operations when mutating data.
@@hansdampf2284but int* p also makes sense, because p is an int pointer. And you wouldn't make an int pointer and then always straight dereference it
I'm seeing a lot of comments in favor of "int* p" and I use to be in that camp because I thought that p was a variable of type pointer to an integer. The videos in this channel are great, but this particular video doesn't fully explain the why "int *p" is actually the "correct" way to write a pointer and why it's written that way. I, like most of the folks here in the comment section came from a higher level language first while you have to understand that C was created in a time when many people were still writing assembly and C was considered a high level language! Modern languages today have sophisticated type systems while C's "trust me bro" type system with all it's casting magic (a feature, not a bug) really just specifies width. You are expecting more from the type system than you really should.
When you declare a pointer, you should think of "int *p" as "if I dereference p, I'll get an int". The declaration offers a "hint" on how the variable should be invoked. The video showed one example of "int *p1, *p2;", but look at how arrays in C are written "int array[]", and not "int[] array" like they are written in Java. A language like Java that focuses on pass by reference, you really have that array is a variable of type int[]. In C, you are literally creating a contiguous chunk of memory on the stack, and the declaration offers a hint on how to access it.
This is a much more powerful way of thinking about it, because if you end up with some crazy pointer declaration, it's very easy to reason about it because you know you have an address until you fully use the hint. Obviously there are crazier examples than a handle, but instead of thinking of "int **p" as a pointer to a pointer to an int, you can think of it as "my variable p will be an address until I fully follow through with what the declaration says and use **p".
I've been using C for 40 years. I pretty much always use int *p.
I also close to never declare more than one variable at a time.
those of us who learned with k&r agree with you
I have ~5 years of c experience. I am starting to sometimes declare multiple stuff on one line. depending on how lazy I am, since I know what I'm doing (in my freetime project; so who cares how I'm programming XD)
I wonder if I ever get into the industry and how that evolves
Yes, exactly. It looks so wrong the other way.
@@phitc4242 It's a filthy habit. Ditch it before you're drawn to the wrong side.
I'm young, started with C++ 12yrs ago. Always taught to use int* p.
It makes way more sense, [type] [variable_name] right? So is pointer(*) the name of the variable, or apart of the type? (This is rhetorical btw)
It obviously doesn't rly matter, but I know Stroustrup is on side [type]* [name]
I’m a C++ programmer and it’s not a regular thing for me to need to define more than two raw pointers or references on the same line, so I always stick to int* and int&.
Further, I think it's more visually consistent in principle of separating type and label- it's of type int*, not int so it reasons that the asterisk should be next to the type
Why would you declare a reference?
@@NightMind0 I’m not sure I understand the question. One obvious use case is accepting parameters by reference.
Another is referencing a nested item to avoid the bother of having to keep accessing it every time. For example: if you have a struct called `items` that contains a vector and a string, you can do
const auto& [vec, str] = items;
You can now modify the nested items by modifying the reference variables ‘vec’ and ‘str’
// str = “hi”;
// items.str is now == “hi”
instead of having to call items.vec and items.str every time.
A third reason is to selectively choose one of two expensive objects. Suppose you have two large strings and you want to apply operations on the larger string of the two only:
const string& smaller = str1.size() > str2.size() ? str1 : str2;
You have effectively chosen a particular string and did so without copying anything.
There are many more uses but I don’t want to drag this comment out in case I misunderstood your question.
@@NightMind0 Why would you not? As part of function-parameters, or cause you want to access some nested members, or to reference a element newly inserted into a container.
@@ABaumstumpf OK, more specifically, why would you declare a reference from int? genuinely curious btw
Just a small remark on the use of printf("%d
", sizeof(some_type)): In most environments the type of sizeof() is not int so the %d conversion specifier raises an error or at least a warning. The correct conversion specifier is %zu. z for the type of sizeof() which is defined as size_t and u as we are dealing with an unsigned value.
Size uf
Thanks for this. As a beginner I would be tempted to use int* p1, p2 thinking that both p1 and p2 would be declared as pointers. Really appreciate this video. Oh, I have also done void main so I am watching that video next.
You're welcome Karim! :-) I'm glad you enjoyed it, and yes this is definitely a pitfall for new (and experienced) programmers.
@@PortfolioCourses The other point of confusion I had was when in a function declaration we write: int func(int *p1). This is NOT to be read "The integer value that p1 points to" because what is being passed is an address. Therefore, in declarations do NOT read *p1 as "the integer value that p1 points to." In calls to the function we write: func(p1) to pass an address. I hope what I have said is correct.
I think the answer might be that it's OK to say "both". Because yes p1 stores a memory address. But p1 stores the memory address of an int. So saying "the integer value that p1 points to" in the context of discussing the function, the parameter, and arguments, isn't necessarily wrong... I think it would depend on the context in which the words were used. It's possible to say "the integer value that p1 points to" and have it be correct, it would depend on how it's used... e.g... "the int variable 'a' is set to 5, and we are passing &a to func, and so we are passing the int value that p1 points to (by pointer) to the function". We might use the term "by reference" as well. As a side note, you may find this video interesting: ua-cam.com/video/RecxQUUEOn4/v-deo.html. And yes, when we call the function, we are passing an address (i.e. a pointer). :-)
@@karimshariff7379 Honestly, the best way to think of '*p1' is as just another name for an 'int' object, both in the declaration and any expression that uses it. If you define a function as
void doSomething( int *p1 )
{
/* do something interesting with *p1 */
}
void foo( void )
{
int x;
doSomething( &x );
}
then you have this relationship:
p1 == &x; // int * == int *
*p1 == x; // int == int
except that "*p1" isn't just the value of "x", it _designates the same object in memory_ as "x". The _expression_ "*p1" acts as a kinda-sorta alias for "x"; anywhere you use "*p1" in doSomething, you're actually using "x":
*p1 = some_value; // equivalent to x = some_value
printf( "%d
", *p1 ); // equivalent to printf( "%d
", x );
You probably don't spend any time thinking about how the subscript [] operator works, or how it's different between declarations and expressions; you just know that "int a[N]" declares an array and the expression "a[i]" refers to a specific object. Exact same thinking applies for the declaration "int *p1" and the expression "*p1".
Ive been doing embedded work for more than two decades. Some of it has been in safety critical systems. I've always used "int * p1" (space on either side of *). And I never declare multiple variables on one line. (C++ too.) I personally find the other two annoying to read.
Haha.. I've just heard "Don't be a coward, commit to one or the other".. but not sure why :P I do prefer the asterisk at the type however.
I also do this and it's just to remind me that the * is the actual data type, and the int is just what kind of pointer it is. Like an unsigned int is two keywords so should int *
Thanks for this quick video, I remember wondering this exact thing while learning.
I've always hated "int *p"; I've noticed that people get confused by it, especially if you need to make a pointer to a pointer (an "int**" type thing)
it's so much simpler and more understandable to think of p as a variable of the type "int*"
look up pointer syntax in Pascal - it is much easier and understandable, including later dereferences.
I am not a C or C++ programmer, but I am interested in these two languages . . . For some reason, just watching you go through this very basic declaration of pointers, non pointers, dereferencing pointers, etc. suddenly helped things click for me.
You didn't go through pointer arithmetic, obviously that was out of scope for your video but I've watched those, too and suddenly pointers make sense. Thank you for helping me put this all together.
* (pointer + 1) is the same as array[1], whatever operation you do works in units of typeof( * pointer). so like pointer-- will move the pointer to what would be the previous element in an array, like doing int * p = &array[i-1]
i had to do weird spacing cuz youtube thought i was trying to make my stuff bold
Wait till your ass gets into bitwise operations and the binary system
@@Nunya58294 I've been comfortable with bitwise operations since I was a kid but your comment did make me laugh. Thank you for that, I needed it today.
My approach is to not declare multiple variables in one line. Exactly because of that int * p1, p2; inconsistency. One line creates different types - bad.
My choice is
int* p1;
int* p2;
It is clear type, clear distinction and intellisense is guaranteed not to mess up in-place hints when parsing that.
That's why there are experts and there are noobs.
I’ve rationalised it like this when I was learning:
int *p means that by dereferencing p you get int type back
Int* p means variable p is of int* type, i.e. int pointer(which is not exactly the case but close enough)
That's not how the language works. When declaring variables, you specify the data type, then a list of variable names. Each variable may or may not be a pointer to the data type in question.
It actually is.
Also: int func(float) says that func(some float) will be of int type.
int (*func)(float) says the same but you have to dereference func first (which often is implicit - weird C).
int a[3] similarly says that a[...] is of type int.
That is the logic they used when designing C. We may not like it, but then the solution should be using a language that applies different notation, not working in the intersection of how it works and how we want it to work...
And those languages already exist. Java, Go, Haskell, Rust, etc. all exist and do not do it the weird C way. We should just use those then rather than pretending C/C++ were something they aren't.
I rarely declare local pointers and if I do, I usually put them on a separate line for better readability, anyway. There is no reason not to. I do see your point, but any half-decent linter will catch that ambiguity.
In my mind, pointers are a different type but a pointer can have a (sub) type. I usually tend to type void foo(int* bar, char* baz) as arguments, for instance. It really helps understanding both pointers and C in general, as the only two types a C program has is pointers and integers. And, on the extremely rare occasion you will need it, floating points - though 99% of the time fixed point just does a better job of decimals.
At the end of the day though, I write code in whatever fashion I get paid to write.
01:45 The one that makes more sense is the first: int *p
02:10 The clearest is the first one: int *p1
Thanks for the informative video.
I'm not a C programmer but I love your videos. This video made me subscribe to your channel. Keep up the good work!
Welcome aboard! :-)
non c programmer here. Always wondered that question. Thank you for clear explanation!
I tend to do "int* p" when declaring single variables, but "int *p, *p1" when declaring multiple.
I hope the day this backfires on you is the day you stop doing this.
I dislike multiple declarations, so I always make it explicit. It's not like our computers have such little memory that you need to keep your source code short :)
I also do int* p; As others have pointed out, the * is part of the type, not the variable name. Sadly K&R disagree with me on that point.
@@merseyviking Why do you dislike multiple declarations? I do multiple declarations not because of memory limitations (dunno why you'd ever think somebody would think that*) but rather for neatness and keeping the amount of unnecessary vertical space to a minimum by taking advantage of the miles of horizontal space. The problem of way too much vertical space usage is exacerbated in higher-level languages like Java, but I still try to be conservative with my C code so that somebody can gather most the information they need with as little movement as possible. Our computers have exponentially more memory, but us humans certainly do not.
* I do know that people would think that, but your comment sounds a bit condescending to me, like you're assuming this random internet person is very sure to keep each source and header file under 4KiB, and that they should stop doing that along with declaring multiple variables on one line.
@@NoahtheEpicGuy ah yes, the limited vertical space...
Putting them line by line makes makes a clear list with 3 columns type/name/value. There's no need for the need horizontal gymnastics to interpret it.
I usually allow single line declarations when the variables are closely related. E.g a matrix "float m00,m01,m10,m11" Or float x,y,z. But even then. You're better off with a struct.
Excellent video! Really loved the way you present these concepts! Subscribed.
You're welcome, I'm glad you enjoyed it! :-)
Always used star before name of pointer, recently in the latest Deitel C programming book, they suggested to use type* name_pointer, now with this video is very clear which notation to use.
p2 is an int-pointer, and p1 is a pointer that, when dereferenced, returns an int. They are the same thing in the end, but the way our brain reads code can influence how we write it.
Makes all the sense, the pointer * operator doesn't apply to the int keyword, but to the variable. This is why in "int *p1, p2;" only p1 is a pointer. Never thought about that. Man, you videos are very good, I'm clearing up a lot of doubts that I didn't even know I had.
I’m really happy to hear these videos are clearing up doubts for you. :-)
I never go for either
I've always preferred int * p since I don't consider the star to be part of the type only or the name only, but of both. It just looks cleaner to me.
If you need a pointer to a pointer... do you use int ** ptr or int * * ptr ?
@@PLATONU In cases like that I've used the non-seprated double stars since, just like a single star for a regular pointer, together the two stars form a type attribute
Thank you for this! You give a very good reason for adopting a particular coding Style.
Excelent video, you learn how to investigate such quirks, it is pricless knowledge.
600th like right here !
Great video, btw 👌
I always make variable names aligned on the same column for readability, whatever type is.
Because of that I always align asterisk to type name, because it is part of variable type, not its name.
I don't care what K&R were thinking doing such mess, I will do that my way for my own comfort and efficiency.
If somebody would read my code and make such mistake, it would not be my fault. My code is not intended for noobs.
I have no issues with the way how compiler works (I never declare multiple pointers in single declaration), or styles other coders use.
Good video. My suggestion is to expand your video to include typedefs. That will solve the confusion of type declarations. FYI: I worked on the AT&T Bell Labs team that wrote C and the Unix operating system. I was also involved in porting the C compiler to odd architectures including the 8086/80286 and Cray supercomputer. There is a lot of history behind some of the design choices we made for the language.
What I like from int *p is that you can think that the variable pointed by p is of type int. Or when you use *p in your code, you're using an integer.
Yes, but this "advantage" disappears as soon as you use struct pointers. Then you get e.g. car->doors even when _car_ is a pointer. And when you work with code that uses kind of an object oriented approach, you'll use struct pointers a lot...
@@minastaros can't you use (*car).doors ?
Section 6.7.6 in the c17 spec agrees, the * is part of the 'declarator'. Reading the * as part of the 'specifier' or type will fail in many non-trivial situations.
@@JonitoFischer Technically, you could (and are free to do so), but you shouldn't. The arrow operator has a _semantic_ meaning (=member of an "object"), and is immediately recognized by any reader as such. I assume there was a strong reason in the past why they have created it, and not only to spare the two key strokes... ;-)
Just saying, the position of the * is technically not important (and with *var you are even closer to the C habit in most code bases). But there are pointer operations that don't use an *, and with structs, "inheritance", polymorphism etc. it starts getting really powerful and interesting!
"[W]hen an operand of the same form as the declarator appears in an expression, it designates [an] object with the (...) type indicated by the declaration specifiers."
You can avoid this problem by using a typedef to give int* an alias, or if you are programming for windows use one of the pointer types defined by Microsoft in windows.h. Then you can ignore the asterisk since it is implied by the type definition. But you also need to remember that you're dealing with a pointer.
Thanks for comprehensive explanation. I've been reading C++ code over the years and this always confused me.
Late to the game, but I am sn advocate of cuddling the asterisk with the type and not declaring multiple variables of any type on a single logical line.
On many architectures, both 'int' and 'int*' are the same size.
C is a free format language, so whitespace between tokens is arbitrary and when not required to delimit multi character tokens and identifiers, optional.
I have been programing in C since 1981 and worked in compiler development for several years, so I am very set in my ways. I will continue to cuddle my asterisk with the type name because I believe it makes the code easier to read.
Really helpful and clear! THANK YOU! :)
I always use TAB; -- for example: int * p1; or char *p2; -- this way the variable names always line up so they are easier to read. Also, always one declaration per line.
chaotic neutral unless your IDE automatically lines up adjacent tabs to match horizontal position. I used to code this way but realized it's much better using tabs to indent and spaces to align, because then it won't change no matter what tab size somebody uses. chaotic evil would be using spaces to indent and tabs to align.
also, why does everybody say that only one declaration per line is better?
Very nice explanation!
Great explanation! In the embedded world I would argue that the "int * p3" decelerationis the most common. Although, in function declerations it would typically be "int const * p3"
Worth pointing out: Guidelines and best practices in many programming languages is that each variable should be declared separately. Thus, keeping the asterisk next to the type remains true. The issue that introduces confusion is declaring multiple variables in one statement. If you always follow best practice and declare variables separately, the opinion that the asterisk is part of the type makes sense.
I wonder why this guideline came to be... Wouldn't it just so happen that it's Cnile retardation like every other time?
The way I see it, writing
int *ptr;
signifies that, once you dereference the pointer, you get an int. With that in mind, I have no problem typing
int *p1, p2, *p3, p4;
since I would know very well that p1 and p3 are pointers (that point to an integer because their dereferenced type is int), while p2 and p4 are themselves integers.
The reason I use int* ptr was bc the thing you said made sense to me, but when I tried to initalize "dereferenced ptr of type int" it required a memory address instead.
@@nothing-lo8lh Hmm, fair point. I would get around that confusion by keeping the initialization separate from the type declaration, though that doesn't look good if I'm only declaring one variable
But then you start initializing it. And then you might think that int *p = 0; does the same as int *p; *p = 0. Which it doesn't.
i really love your videos , thank you for the great explanation , tho I have a question , which compiler and IDE do you use?
You’re welcome, I’m glad you love the videos! :-) In this video I am using Xcode on Mac OS as an IDE. In some other videos I use Visual Studio Code + the gcc compiler on the Mac Terminal.
Thanks for the info! This is definitely a trap that would get a lot of people new to C like me. I will be vigilant!
You're welcome Aquil! 😀
Oh the memories of writing C code on SSFD. We would write the code using whatever style was appropriate (white space, brace offsets, etc) and then promptly run it through a batch file process filter to remove all that so that the compilers would be 10 times faster not having to process all the white space used for readability. Oh, and all the fond memories of finding memory leaks. Those were the days! LOL
I only recently started learning c, but I have experience with Pascal. I think Pascal style pointers are much more clear, declared like this
P1: ^Integer; // P1 is pointer to integer
dereferenced like this
P1^ := 5; // P1 dereferenced assign 5
No ambiguity because dereferencing is postfix. But that's just my opinion.
It’s important to understand what can go wrong because you have to work with other people’s code. But just avoid multiple declarations and it because a style issue I don’t care about. This is the same whether you are writing c or c++.
I use p3 syntax because I use distinct syntax for declaring a pointer and de referencing them. This distinction makes the code look cleaner in my opinion.
int * p3 = NULL;
I also write my types from right to left because that's how they are best read and understood. For example:
char const * const argv[]
This is a constant pointer to a constant char. Where as this will often be written by most people as
const char* const argv[]
and they'd internalize it as "a const char pointer to a... const?" or something reading it from left to right.
You’re right, and I agree, but sadly most haven’t seen the light yet, if ever.
The reason why the most appropriate way to declare a pointer to int is int *p; is because the * is a unary operator, and unary operators bind more tightly to their operand which is why you put them together.
There has always been a convention in C that you put a single space around binary operations and no space between a unary operator and its operand. Some other unary operators would be ++ -- & sizeof etc etc.
Also you never imply precedence by spacing , hence never do A + B * C because visually when speed reading somebodys code you immediately assocciate the + first.
Great channel keep it up!
Thank you very much! :-D
The tokenization of C is straight forward. int*p1; Is also valid, the tokenizer looks for certain sequences that define identifiers, operators etc. such as a string of letters and numbers and _ starting with a letter or _. Any other character ends the token. white space is another way of ending a token. The grammar of C spells this out.
you're the best instructor!!!
Thank you for the kind feedback! :-)
The historical quirk about declaring pointer variables in a compound statement could reasonably be fixed in new C and C++ standard AST rules.
I prefer int *p, but the other version makes more sense when you realize that a reference to a pointer has to be coded as:
int* &p;
Very important observation.
Very clear explanation.
I'm glad you enjoyed it! 😀
int* makes more sense because p is not actually an integer but rather a memory reference that points to an integer value
The first way is definitely proper in my opinion .
But I do it the 2nd way because then I can do this :
void some_function( int* *fake_pass_by_reference ){ ... }
some_function( &( some_integer_pointer ) );
I do this on byte arrays that return bitmaps .
the very fact that `sizeof(int)` and `sizeof(int*)` have a different size (on a 64bit system) demonstrate to me that `int*` is a different type altogether, so grammatically it makes sense to me to keep it as such
I prefer the odd and seldomly used "int * p" because I can differentiate it from pointer dereferencing, which I write as "*p". Given that there is no correct notation and all of them have their pros and cons, you have to find a style that works for you and helps you do the things you do the most in the most efficient way.
So, I also don't declare multiple variables in a single statement precisely due to this issue. I usually try to contain it to simple counters when setting up _for_ loops.
It's not that much more work to have a single declaration per line. It usually pays off to type slightly more and then not having to debug the issues a misplaced * can cause, which can take minutes. Maybe that is different for you. I usually try to keep code debuggable and maintainable, instead of typing the least amount of characters, because I find that I usually only type code once (or a similarity low frequency), but then I have to step through the code many times whenever something changes (either new code or bugs).
as always great video
Thank you Robel, I'm glad you enjoyed it! :-)
What confused me for the longest was that the declaration of the pointer and the dereferencing of the pointer have the exact same syntax
The variable holding the address of PeeOne: *p1
The value stored at address PeeOne : *p1
While there are syntactic differences the "int *p;" style provides the foundation for "int *p[N];" being an array of pointers to int's; it is NOT a pointer to an array of int's...
The "decorations" are to be interpreted primarily with the variable's name leaving the data's ultimate type being the final step of parsing.
This same rule-of-thumb extends to everyone's favourite: function pointers.
As to "stacking" several declarations together, consider "for( char *pLft = str, *pRgt = str + len; pLft < pRgt; pLft++, pRgt-- )"
Two throwaway pointers whose scope is minimal.
That’s a very good point. :-)
Very informative video! Do you know of any reason why it was decidad that int* should not work for multiple variable declarations in the same line?
That’s a great question and I tried to figure out “why” before making this video, but there isn’t really a deep reason (that I could discover) beyond “they decided to make it work that way”. :-) That said I think this answer on stackoverflow provides some reasoning: stackoverflow.com/a/61861075. Basically variable declarations are split up into a “declaration specifiers” and “declarators”, where “static int” would be part of the declaration specifier portion but “a[10]” would be a declarator declaring an array with 10 elements. Now I don’t see why whether the variables being declared are pointers or not couldn’t be part of the “declaration specifier”. But I suspect they felt it belonged with the other declarators and so decided it would be specified there. The declarators seem focused on “structure” (pointer, array, function, etc.) so maybe that’s why they felt it fit there. But I’m just speculating, I’d love to know why. :-)
@@PortfolioCourses Oh I never thought about there being declaration specifiers and declarators, but it kind of makes sense. So writing int *p is basically a short form of int p[1] and in that sense it is quite obvious that it does not work for multiple declarations in the same line.
@@3NAS_N1 It's pretty similar the only thing is p[1] will be an array of 1 element and *p will be a pointer, and arrays and pointers can sometimes be used in place of the other but not always.
@@PortfolioCourses Oh yeah, you are right. I wrote my last response a little too quickly.
All of the discussion of pointers and the 'grammar' issues are clearly described. However, as a new coder, the term "dereferencing" is quite vague and potentially misunderstood. So instead of saying "dereferencing a pointer", I say "accessing the contents of the pointer", which explicitly describes the action of retrieving the value from the memory address pointed to by the pointer.
I definitely agree with the asterisk '*' being right next to the variable name instead of other places. It does seem to be easier to follow that over the other uses that could appear to be 'unclear' to ones reading it.
That was a good view and was helpful on that point.
Agreed! :-)
Yeah my logic why I do that way is because variable is a pointer not the type
Yep. Also, every textbook I’ve ever seen keeps the asterisk with the variable, never the type.
This makes sense, since the asterisk modifies the variable. The type stays the same. Personally, looking at it the other way around, saying that the asterisk modifies the type from a type to a pointer-to-a-type just seems silly and confusing.
It’s the behaviour of the variable that’s being modified - it’s become a pointer to a type instead of a value of a type. Therefore, the asterisk belongs with the variable that is being modified to become a pointer.
(Just don’t mention typedef’d opaque pointers… shhh!)
You are a noob. The variable name is not always next to the asterisk. Wait until you learn about constant or volatile pointers, my child.
Amazing, I used to thought with int* all following variables are pointer type.. thanks sir for making this video
int* p: pointer to an int
*p: p dereferenced
p * q: p times q
int&: reference to an int
&p: address of p
This is how I differentiate everything from each other
The way to read this is "int *p" means "let *p be an int". It's tempting to think of it as "p is a variable of type int* " but firstly that doesn't always work (as per the video), and secondly, if you want to declare a variable as "the address of an int", then the logical way to define this would be "&int p" i.e. "p is of type address-of-int". In fact, neither "int*" nor "&int" are valid type definitions; but "int *p" works accidentally (sometimes), as a consequence of the whitespace not always being significant in C.
great clarification, thanks
ur the best!! thank u !
You're welcome Mefref! :-D
I’ve always put the star nestled up against the variable name. I saw the other style used and made a mental note of it.
One day I’m hitting an issue and decide to see what happens if I put the star up against the type instead, wondering if there was a difference and to my shock it compiled and ran. When I moved the star back, it didn’t.
I thought for a long time there that there must be some difference thanks to that but I wasn’t quite sure what.
Then I went back and put the star where I normally would and decided to clean the build and recompile as fresh as possible.. and it worked.
Some weird broken cache was the cause of my woes and I just didn’t see it.
Now I’m paranoid and clean rebuild often.. I shouldn’t.. but once bitten twice shy lol
Best ways to mitigate this risk:
1. One declaration per line
2. Use a typedef to define, say, intptr.
IMHO, 'int* p' is more readable than 'int *p', in an eyeblink, especially on some occasions when people (rightly) justify definitions to vertically align variable names. In such cases, the * is much too far from the type, and the type is split into two parts, which is wrong.
The moment when we actually use the third one in our projects. And I think it's actually the most logical one, since all parts of the specification are separated by spaces, then why not this one. And it still reads "integer pointer p1". It's actually totally in place when you do also "int & ref1" - then you have all your specifications more standardized. And yes, we have "int * & some_var"
In the C language, both int* p and int *p have their advantages and disadvantages. Essentially, due to deficiencies in the type expression aspect of C language syntax design, neither of these two writing styles is perfect, and you can choose either one, as it is a matter of personal style.
However, in the case of C++ language, int* p is evidently the better practice, more in line with the design philosophy of C++. This becomes particularly apparent when writing generic codes.
This is a use case for typedefs, for example typedef int* intptr, although it can get messy if you try to be exhaustive;
WIN32 API be like
typedef unsigned int * * PPDWORD;
or whatever - and I like it that way
typedefs have no usecase and should've never existed
For how well I know C, I don't code very much. So while I can't agree with your statement absolutely, I want to thank you for introducing me to the idea of typedefs being "suspicious" by default - it was never more than a vague thought in my head up to this point.
A common-sense example I just found (and now agree with) from the Linux kernel style docs:
"u8/u16/u32 are perfectly fine typedefs... New types which are identical to standard C99 types [are not forbidden]... In general, a pointer, or a struct that has elements that can reasonably be directly accessed should **never** be a typedef." Lesson: obfuscated type information is bad.
Of course, a project's coding style should trump personal preference. You can imagine how disheartening it is to see someone pass a standard type (or worse, their own custom typedef) to a WIN32 API call. Argh, just use the type in the definition!
Anyway, if you _insist_ on declaring your own types, typedef beats #define for sure (probably why they put it in C to begin with).
Thanks for reading, friend.
Typedefs hide information; if whoever's using that variable needs to be aware of its pointer-ness in order to use it properly (they need to dereference or use a subscript on it), then _don't_ hide that information behind a typedef.
I once spent an afternoon chasing my tail because of a typedef that hid a pointer; I would rather have the eye-stabby version, at least it tells me what I need to know.
@@johnbode5528 When was this? 1993? Any IDE or code editor today will let you drill down to the typedef in about three mouse clicks maximum. And then there's always RTFM.
Shortly after I started to learn C I saw this way of declaration int* p1; and it confused me because I've first learned int *p2; which is clearer to me, and got even more confused when I saw that on function declarations too, but eventually I figured it out that they are the same. Now, I don't recall to have seen int * p3; but now I'm aware of it thanks to your straightforward and clean explanation.
Question, Is it a good practice to always (when possible) initialize your variables? Let's say NULL to pointers, 0 to int, etc.
Yes, it's a good practice. Generally it's nice if you initialize variables right when you declare them, but if you know you're going to initialize them soon after (e.g. after some other statements) that's going to be OK too.
Funny thing is, my experience was the opposite. having the star next to the name also acted as an intuitional block to what I thought pointers did.
It makes sence to think of the star as a part of the type itself, which makes sence, since "int*" is not the same as "int". The star modifies the type.
But it's an unfortunate circumstance that when declaring multiple variables on one line, it has a very un-intuitional syntax. You assume all the variables on the line have the same type as is written at the start, but that isn't the case when considering pointers. Even though the star is essentially meant to define the type, just like how "int" does, but you don't write "int" multiple times on one line.
So in my opinion, the way C handles the pointer-star on multi-var-single-line declarations is a bit jank in and of itself, and creates this unfortunate situation for developing a good intuition on pointers.
Also, I personally don't declare multiple vars on one line anyway.
@@Andrew90046zero As an extra complication this changes when you declare a typedef for the pointer type, for example like this:
_typedef int * intp;_
_intp p1, p2;_
Now both _p1_ and _p2_ are pointers. Similar confusion may arise with function types, eg. _int* (*swap_ptr(int*p)),_ ptr to arrays of ptrs etc, so I often found it clearer and less errorprone to use typedef for more complicated types. The simplest declarations like just a pointer to sth I don't bother with, but for the "something" itself I prefer to have them as typedefs unless they are just primitive types (like an int). The reason I don't bother with the pointer (*) is because I rarely if ever declare more than one variable per line, and if I need a second declaration I start a new declaration on the next line complete with the type information AND initialize it too.
Since modern C now allows declarations intermixed with statements the convenience of just declaring a bunch of variables on a single line at the top of the function is no longer relevant. Then it is better to declare each variable as late as possible and initialize it at the same time. That way the risk of using uninitialized vars (especially pointers!) is reduced or eliminated. You can also wait until the point where you have gathered enough information to initiate the variable to the correct/valid/desired value immediately.
int *p1; should be read as "dereferenced p1 is an int" .then confusion goes away . and also * remains just the dereference operator and not a separate spacial pointer declaration use case .
Probably one of the reasons Go uses var statements (as well as := type inference), like: var p1 *int
It's much more logical and less confusing.
Thx for your work.
👍
You're welcome! :-)
Declaring multiple variable in a single statement is less clear and readable than simply using a single statement to declare each variable. I personally would not recommend doing that.
You want to keep your code cryptic and unmaintainable so you can keep your position
Actually, the first time I saw int * p, it was what made me understand the problem.
That’s cool! Personally I wouldn’t ever recommend doing it that way in a “real program” as out of all three approaches that one is the most criticized by programmers for not making sense. :-)
@@PortfolioCourses Yeah, I totally agree with the point in your video ;)
Turns out it’s actually the best choice technically, but rarely chosen because the convention is to use one of the two deficient choices, so most don’t recognise it. Not an uncommon thing in software engineering, unfortunately.
I use it professionally and have done for decades and it’s never caused anyone a problem. Avoids the issues with int* x or int *x effectively.
While it's good to know what the syntax truly is and does, I would say "prevent bugs by not declaring multiple variables in the same statement" as it also keeps it simple when reading the code, doing initialization, etc.
I always thought it was a mistake that * binds to the right in a type declaration. If you typedef your int* then it makes more sense as a type. And multiple declarations on a line is just ugly.
This is very informative, Thank you. I am wondering, is there a GUI or IDE that will tell you exactly what a variable is, int vs int pointer so this confusion is not possible. Similarly it should give the types for all variables.
I'm sure there's a good reason for the compiler allowing to implicitly declare variables of different types in the same statement, but that's what I'd find confusing as a beginner.
The compiler (gcc) only applies the '*' to the variable name immediately following it in the declaration. The solution to this is: Only declare one variable at a time - anything else is sloppy, which programmers should avoid like the plague.
To avoid confusion
Right side is the value
Left side is the type of
Int *P means *P is the int which makes P as pointer
Int* P means P is the integer pointer
Hi sir
Is it possible to create a 2d or 2d array with single pointer dynamically if it is possible then why we need these many pointer like double pointer and triple pointer ( was there any disadvantages with using single pointer to all the array to create dynamically)... It's little bit confusing for beginners..can you pls help me
Thank you sir
We can use a "single pointer" instead of a "double pointer" (i.e. a pointer to a pointer). But what we will have in that case is more like a 1D array of data, we would need to access the data differently than array[row][column]. We would need to access the data in the array like they do in the first example on this page: www.geeksforgeeks.org/dynamically-allocate-2d-array-c/. :-)
This reply is likely too late to do any good, but ...
Yes, you can create a 2D array with a single pointer, but it must be a pointer _to an array_ . Example:
int (*arr)[C] = malloc( sizeof *arr * R );
allocates enough space for R instances (rows) of C-element arrays (columns) of 'int'. You index into the array like any 2D array:
arr[i][j] = some_value;
and when you're done, you only need a single call to "free":
free( arr );
The difference between this and something like
int **arr = malloc( sizeof *arr * R );
for ( size_t i = 0; i < R; i++ )
arr[i] = malloc( sizeof *arr[i] * C );
is that in the first method, all the rows are contiguous in memory, while in the second method they are not. Sometimes that matters. Also, in the second case, you must explicitly free each 'arr[i]' before freeing 'arr':
for ( size_t i = 0; i < R; i++ )
free( arr[i] );
free( arr );
The fact is, when declaring a pointer, such as
int *ptr;
we are really saying to the compiler that we wanna use a reference variable called ptr to point to a chunk of memory that has to be the size of an int. Or, in other words, the expression "int *ptr" really means: if you will dereference this pointer ptr that I am declaring, you should get something of type int. Basically, declaring a reference by immediately showing that you can dereference it. Isn't that brilliant? :D
Once this concept is clear, it will only become natural to put the star symbol (*) always close to the pointer's name, both when declaring it and when dereferencing it in expressions and statements.
Same goes for the ampersand symbol &, used to represent addresses in C and even variables passed by reference in C++ (which really are copies of the arguments' addresses passed to the functions, by the way, hence the use of the "address of" operator & in such contexts). I always find awkward to see these symbols adjacent to a type descriptor, rather than to the actual variable name.
Your pointer sizes being 8 indicates you are using a 64 bit system; compile and run that same code on a 32 bit system, and the size of your pointers will be 4, just like the size of the int type.
That's true, that gets "addressed" in other videos (pun intended). :-)
@@PortfolioCourses - what I was getting at is comparing “sizeof” values isn’t reliable for distinguishing a pointer from some other data type. This type of “exercise” could be misleading to those who don’t yet understand that principle.
@@stevebabiak6997 Yes, I figured that. 🙂 I made no claim that this is a general method that can be used to distinguish pointers from other types, I just used it as a method to illustrate they are different types than might be expected in this instance and on my machine/compiler. I've been teaching C programming for 20 years and there's something about showing the sizeof() different types (especially pointers) which makes things "click" for beginner students (there is no typeof() in standard C).
BFD! "int", "*", and "p1" are three distinct tokens. It doesn't matter to the scanner where the whitespace is, or if there is no whitespace at all.
Or you can just declare each variable at its own line. This way it's easier to change a type of a variable or comment it out completely.
This has been one of my pet peeves. I'm by no means a professional in cpp. But man the fact that it's a pointer is part of the type.
Interesting that there's a caveat with multiple declarations. But honestly I think they should all be marked as the same type, wtf.
Lastly I generally don't like multiple variables in one line and if I see them I get rid of them. I favour readability over being a smartass. I'll generally allow it if you need a lot of variables and the variables are somehow related. Like vectors x,y,z or matrices m00,m01,m10
Always used *p because it avoids errors and makes sense. One could argue that int pointer and int are different. Fine. But it makes the code less readable and error prone for the developer himself.
I declare each variable on its own line. What you show is a common error.
I noticed the wrong type was used for a printf of the size_t. You should use the zu format-specifier.
This always made perfect sense to me. the base type is int, and anything else binds only to the variable. If that feels uncomfortable to anyone they can always use a typedef.
Ugh please don't abuse typedef like that. To paraphrase Linus Torvalds, you generally shouldn't use typedef unless there is actually a reason for it. Like if you're using it for compatibility across platforms or to deliberately hide something. Typedefs are obfuscation by design.
@@Spoonbringer I agree, and my suggestion was by no means a recommendation - I ported software across Unix platforms in the '90s. I've seen and done things ... that poor preprocessor ... but only because I had to.
No, using a typedef to hide the way a language works just because you don't like the look of it is pretentious and asking for trouble.
I learned the * next to the variable name. It makes sense to me because later, you deference the variable, not the type.
Also, my reasoning is that I don't think of pointer as a type perse. Int is a type, the * is just a modifier to the variable. If you say pointer is a type, then int* and char* are pointers? They are, but more specifically, they are pointer to int and char types. Just my thoughts.. LOL if it doesn't make sense, disregard. My favorite language C. :-)
what code editor did you use
X Code
I want to do "int* p;" to indicate that the type is a pointer to an int, but I know that "int* p, p2;" is not creating two variables that both have the type of pointer to int (p is pointer to int, p2 is int)
So because of the C syntax, I force myself to write "int *p" so that "int *p, *p2" and "typedef struct { int val; } Foo, *pFoo;" is correct.
(though I don't use the second one I just do a normal pointer, but that is another case where this might become a problem)
I've always hated `int foo, bar` and have always gone with the more explicit `int foo; int bar` and now I have a reason
I am a sovereign programmer, I declare my pointers however I want to and I will not tolerate attempts to infringe on my right to write and commit footguns.