int *p vs int* p Pointer Declarations | C Programming Tutorial

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!

[@PortfolioCourses]

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: kzbin.info/www/bejne/maa1dHiQpdSnfq8. 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 KZbin 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 KZbin 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: kzbin.info/aero/PLA1FTfKBAEX6dPcQitk_7uL3OwDdjMn90 C Programming Tutorials: kzbin.info/aero/PLA1FTfKBAEX4hblYoH6mnq0zsie2w6Wif

[@TheBunzinator]

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.

[@higgins007]

This, precisely. Agree.

[@RahulYadav-hq2yy]

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

[@dominiccasts]

True, but at the same time p is an int*, so int* p makes the same amount of sense for that syntax

[@CybAtSteam]

Same here, "int-pointer p" has always made more sense than "int pointer-p"

[@Colaholiker]

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. 😂

[@bewingbewing]

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.

[@Valerius123]

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.

[@kellyfrench]

If c had a motto, it would be, “you know what you are doing, I hope”

[@Valerius123]

@@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.

[@zecuse]

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!

[@TotoMacFrame]

Best comment I have heard to far, gave me a good laugh 😄

[@danielsass4134]

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.

[@CYXXYC]

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

[@yiyuzhou3453]

I’m the opposite, because I think of it as *p is type int.

[@hansdampf2284]

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.

[@HaydenLikeHey]

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.

[@antonhelsgaun]

​@@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

[@cccmmm1234]

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.

[@Flavio-ar]

those of us who learned with k&r agree with you

[@phitc4242]

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

[@InfiniteQuest86]

Yes, exactly. It looks so wrong the other way.

[@cccmmm1234]

@@phitc4242 It's a filthy habit. Ditch it before you're drawn to the wrong side.

[@virno69420]

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]

[@UsernameUsername0000]

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&.

[@tanmang42]

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

[@NightMind0]

Why would you declare a reference?

[@UsernameUsername0000]

@@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.

[@ABaumstumpf]

@@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.

[@NightMind0]

@@ABaumstumpf OK, more specifically, why would you declare a reference from int? genuinely curious btw

[@adruzgatsby]

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".

[@karimshariff7379]

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.

[@PortfolioCourses]

You're welcome Karim! :-) I'm glad you enjoyed it, and yes this is definitely a pitfall for new (and experienced) programmers.

[@karimshariff7379]

@@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.

[@PortfolioCourses]

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: kzbin.info/www/bejne/iJbGqYSLiqqCpJY. And yes, when we call the function, we are passing an address (i.e. a pointer). :-)

[@johnbode5528]

@@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".

[@MrGeorge1896]

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.

[@clrkgmii]

Size uf

[@marccygnus]

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.

[@tubeincompetence]

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.

[@greatnate29]

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 *

[@aurinator]

Thanks for this quick video, I remember wondering this exact thing while learning.

[@samjohnson5044]

Thank you for this! You give a very good reason for adopting a particular coding Style.

[@TechyAyush]

Excellent video! Really loved the way you present these concepts! Subscribed.

[@PortfolioCourses]

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

[@ProtossOP]

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)

[@TrueThanny]

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.

[@divVerent]

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.

[@markmidwest7092]

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.

[@Scotty-vs4lf]

* (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

[@Nunya58294]

Wait till your ass gets into bitwise operations and the binary system

[@markmidwest7092]

@@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.

[@AK-vx4dy]

Excelent video, you learn how to investigate such quirks, it is pricless knowledge.

[@hstrinzel]

Really helpful and clear! THANK YOU! :)

[@HasanShokri]

I'm not a C programmer but I love your videos. This video made me subscribe to your channel. Keep up the good work!

[@PortfolioCourses]

Welcome aboard! :-)

[@lamaspacos]

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.

[@johnphamlore8073]

Very nice explanation!

[@guilhermecampos8313]

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.

[@PortfolioCourses]

I’m really happy to hear these videos are clearing up doubts for you. :-)

[@kensclark]

I tend to do "int* p" when declaring single variables, but "int *p, *p1" when declaring multiple.

[@manyirons]

I hope the day this backfires on you is the day you stop doing this.

[@merseyviking]

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.

[@NoahtheEpicGuy]

@@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.

[@shinobuoshino5066]

@@NoahtheEpicGuy ah yes, the limited vertical space...

[@Cyberfoxxy]

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.

[@kongolandwalker]

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.

[@gregorymorse8423]

That's why there are experts and there are noobs.

[@ChaseAlberti]

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"

[@nameless5724]

Very clear explanation.

[@PortfolioCourses]

I'm glad you enjoyed it! 😀

[@Misteribel]

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.

[@soyitiel]

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.

[@PLATONU]

If you need a pointer to a pointer... do you use int ** ptr or int * * ptr ?

[@soyitiel]

@@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

[@pvjewel]

non c programmer here. Always wondered that question. Thank you for clear explanation!

[@nicreven]

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*"

[@mojeimja]

look up pointer syntax in Pascal - it is much easier and understandable, including later dereferences.

[@OriginalJetForMe]

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.

[@johnhanley2431]

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.

[@vvpChannel3112]

Amazing, I used to thought with int* all following variables are pointer type.. thanks sir for making this video

[@bikerinside_learn]

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.

[@ghos7bear]

Thanks for comprehensive explanation. I've been reading C++ code over the years and this always confused me.

[@emreoral3473]

great clarification, thanks

[@wertigon]

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.

[@zagaro5513]

Great channel keep it up!

[@PortfolioCourses]

Thank you very much! :-D

[@semihaturkoglu]

you're the best instructor!!!

[@PortfolioCourses]

Thank you for the kind feedback! :-)

[@JonitoFischer]

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.

[@minastaros]

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...

[@JonitoFischer]

@@minastaros can't you use (*car).doors ?

[@armedcannon]

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.

[@minastaros]

@@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!

[@armedcannon]

"[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."

[@semibiotic]

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.

[@el_calorie2867]

600th like right here ! Great video, btw 👌

[@Nyarkfunky]

Thx for your work. 👍

[@PortfolioCourses]

You're welcome! :-)

[@khalilebdelli6199]

i really love your videos , thank you for the great explanation , tho I have a question , which compiler and IDE do you use?

[@PortfolioCourses]

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.

[@ሰውመሆን]

as always great video

[@PortfolioCourses]

Thank you Robel, I'm glad you enjoyed it! :-)

[@enigmatico6209]

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.

[@mefrefgiweuhef4808]

ur the best!! thank u !

[@PortfolioCourses]

You're welcome Mefref! :-D

[@insu_na]

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

[@michaelelkin9542]

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.

[@sitting_nut]

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 .

[@aquilhall262]

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!

[@PortfolioCourses]

You're welcome Aquil! 😀

[@filker0]

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.

[@3NAS_N1]

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?

[@PortfolioCourses]

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. :-)

[@3NAS_N1]

@@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.

[@PortfolioCourses]

@@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.

[@3NAS_N1]

@@PortfolioCourses Oh yeah, you are right. I wrote my last response a little too quickly.

[@sergiogiacomosammartano7623]

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.

[@ncmathsadist]

I declare each variable on its own line. What you show is a common error.

[@Valerius123]

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.

[@meowsqueak]

You’re right, and I agree, but sadly most haven’t seen the light yet, if ever.

[@oscargraveland]

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

[@GeorgeStaplin-tx6dc]

I noticed the wrong type was used for a printf of the size_t. You should use the zu format-specifier.

[@rretro2042]

int* makes more sense because p is not actually an integer but rather a memory reference that points to an integer value

[@Allen-by6ci]

great video

[@lellyparker]

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.

[@dronihack]

You want to keep your code cryptic and unmaintainable so you can keep your position

[@MotorBorg]

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.

[@mc4ndr3]

The historical quirk about declaring pointer variables in a compound statement could reasonably be fixed in new C and C++ standard AST rules.

[@ramakrishna4092]

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

[@PortfolioCourses]

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/. :-)

[@johnbode5528]

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 );

[@turdwarbler]

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.

[@kiss-liava]

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"

[@KANJICODER]

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 .

[@salomonchambi]

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.

[@PortfolioCourses]

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.

[@Andrew90046zero]

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.

[@benhetland576]

@@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.

[@DmitryKandiner]

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.

[@karlostj4683]

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.

[@m4rt_]

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)

[@gnarfgnarf4004]

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;

[@gnarfgnarf4004]

Very important observation.

[@MarcoAurelio-sv2tk]

I think we shouldn't mix (in this case) pointer to an int and int. It might be confusing for the person that is reading the code. I personally like more the int *ptr notation, but in the end, the compiler doesn't care because it ignores the whitespaces

[@Cyberfoxxy]

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

[@rustycherkas8229]

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.

[@PortfolioCourses]

That’s a very good point. :-)

[@KyleHarrisonRedacted]

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

[@bismajoyosumarto1237]

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.

[@nothing-lo8lh]

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.

[@bismajoyosumarto1237]

@@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

[@__christopher__]

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.

[@FredrikHistherRasch]

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.

[@shinobuoshino5066]

I wonder why this guideline came to be... Wouldn't it just so happen that it's Cnile retardation like every other time?

[@georgH]

Actually, the first time I saw int * p, it was what made me understand the problem.

[@PortfolioCourses]

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. :-)

[@georgH]

@@PortfolioCourses Yeah, I totally agree with the point in your video ;)

[@meowsqueak]

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.

[@UnlikelyToRemember]

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.

[@NoahtheEpicGuy]

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?

[@bertiesmith3021]

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++.

[@FSEAirboss]

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

[@reynaldomesmo]

Can we use (int *) p1, p2, p3... to declare multiple pointers?

[@user-to1lb6dj6g]

no, but You can define a pointer-to-int type: typedef int* pint; and use it like this: pint p1, p2, p3;

[@codewizard58]

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.

[@cleightthejw2202]

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.

[@PortfolioCourses]

Agreed! :-)

[@realdragon]

Yeah my logic why I do that way is because variable is a pointer not the type

[@simontillson482]

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!)

[@gregorymorse8423]

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.

[@ChiefExecutiveIntern5691]

My take as a C++ programmer is definitely that the * pointer annotation should be included with the type and not the name, just like the & reference symbol, const, or any other type modifiers. It's part of the variable's type, and not part of its name, as the pointer variable can be used and referenced without it. Any peculiarities or inconsistencies when declaring multiple variables on a single line is just a good reason not to declare multiple variables on a single line. And how often do you really need to initialize multiple variables of the same type with the same value?

[@B1gLupu]

Is this the same in C++? Would int* p1, p2; declare a pointer and an int in C++ too?

[@PortfolioCourses]

Yes

[@jarekmyszko3332]

It is the same, but in c++ we do not declare multiple variables in a single line and int* varName=VALUE; is a prefered way of variable declaration and initialization. The reason for this is that int* is a whole type in itself and the other way of declaration tends to be confusing with templates and horizontal alignment formatters. Multiple variable declaration is not used due to variables not being initialized which is tragedii as an error by most modern compilers.

[@deslomator]

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.

[@yoops66]

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.

[@RichardNeill01]

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.

[@davidgillies620]

This is a use case for typedefs, for example typedef int* intptr, although it can get messy if you try to be exhaustive;

[@narfharder]

WIN32 API be like typedef unsigned int * * PPDWORD; or whatever - and I like it that way

[@shinobuoshino5066]

typedefs have no usecase and should've never existed

[@narfharder]

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.

[@johnbode5528]

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.

[@davidgillies620]

@@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.

[@chernobylfx2379]

When declaring I do type* and when dereferending *ptr so the "star" position also shows the intent kinda. It would look really weird to me to dereference like int x = * ptr; actually lol but its all about style

[@meowsqueak]

I’ve used a space on both sides for years, professionally: “int * var”, and it’s never caused any confusion. I don’t think it’s confusing AT ALL. Same for &. It might be rarer but why do you think it’s confusing?

[@Roxve]

the compilers simply ignores spaces you are excepted to put the * before the var name but since the compiler ignores spaces int* p = int *p = int * p = int*p however this becomes a problem when doing some stuff sush as declaring multiple variables as your brain thinks the type just does that int* p, p2 (p is pointer p2 isn't) you are supposed to do int *p, *p2 and it just looks like int*p,*p2 in the compilers pov

[@KayOScode]

I honestly don’t think it matters where you put the star. I’ve always put it next to the type, because I consider the pointer to be part of the type, not the variable. I am ok with the inconsistency of having to attach it to the variable when you declare multiple in one line, but in general, I declare one variable per line

[@xTriplexS]

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

[@BryanChance]

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. :-)

[@_sudipidus_]

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

[@SillyOrb]

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).

[@feakhelek1]

At first it seems natural to put the * with the int since int* seems to indicate a pointer to an integer. After considering the behavior though it seems to me to make more sense to think of the * as a Unary Operator and putting it in front of the variable name reinforces that it is not part of the data type. I say that it is not part of the data type since at declaration the second variable declared is simply an int showing that the * has not been applied to it. A Unary Operator would only apply to the variable immediately following so in my mind it is easier to consider it an operator modifying the variable rather than the data type.

[@gregorymorse8423]

Wait until we teach the guy who made this vid about constant pointers to constant ints. const int *const a; Maybe its volatile too for good measure. His mind will be blown!

[@n00blamer]

you're so cool you have heard of volatile, might even know what it is for wow