In CUDA, the corresponding malloc cannot return the pointer to the allocated memory as runtime CUDA functions all return error codes instead. So the only way to “return” the pointer then without a return statement is to have a pointer given to that function by address, which means that you’ll have a pointer-to-pointer among its arguments.
I’m not entirely sure what you mean by memory isolation here, but the basic idea is that if you have a pointer to something then you know where it is located in memory and you can write in it, that’s the whole idea of passing by address in C.
Now pointers themselves are merely variables. Yes they have a special meaning, they “point” to something and you can dereference them with the * operator, but at the end of the day they’re still variables. They have a physical existence in memory or CPU registers, and their content is simply the address to which you want to point. Once you accept this, then the idea of the address of a pointer (ie the location of the variable you’re calling “pointer”, and not the address it contains) is not strange anymore and you can perfectly have a pointer-to-pointer in order to, among other things, pass pointers by address.
In C if I give you a pointer to a memory address, you can totally overwrite what is in that memory address, even write a new struct in there. So you’re getting a “real” writable memory address. You could even write a different type of structs and break the program. You could tweak specific bytes.
In languages like Java or C# you aren’t given a reference to the memory address but a reference to the object. You can only write to the object using it’s own interface (methods) but you can’t say “I’m going to totally overwrite this memory address with a new object”.
If you receive an object in a parameter, let’s say a “Person person” object and you do something like “person = new Person();” you didn’t really overwrite the memory address. The original person reference that was passed in the parameter is still intact. You can only modify it with something like “person.setName(…)”.
So, with real pointers you can do more stuff, but higher level languages don’t want you to do that because it breaks some of their principles for what “good programming” is. In this case they are protecting encapsulation. You shouldn’t be able to mess around with the memory contents of objects directly, only through their interfaces. Encapsulation is safer because objects should expose how to operate them safely via their interfaces.
So that you can have an array of strings. It’s useful to remember that in C arrays and pointers are exactly the same thing, just syntax sugar for however you want to look at it. There are a few exceptions where this isn’t true however:
Argument of the & operator
Argument of sizeof
C11 has alignof which decay is a no-no
When it’s a string literal of char[] or wide literal of wchar_t[], so like char str[] = "yo mama";
But int** is just an array of int*, which likewise int* can just be an array of int. In the picture here, we have int** anya that is an array of int* with a size of 1, int* anya that is an array of int with a size of 1, and then of course our int there being pointed to by int* anya.
I guess this is beating a dead horse but you can have pointers to pointers for 2D arrays.
The first pointer tells you which coulm you’re on. The second pointer tells you which is the first object of each column. That way you can iterate the columns without loosing a reference to the current column you’re standing on.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.
Wait we can have pointers to other pointers? Wouldn’t that be redundant?
In CUDA, the corresponding
malloccannot return the pointer to the allocated memory as runtime CUDA functions all return error codes instead. So the only way to “return” the pointer then without a return statement is to have a pointer given to that function by address, which means that you’ll have a pointer-to-pointer among its arguments.Man, this is the type of interaction I used to love on Reddit, but haven’t seen in ages.
So it’s sort of like “proxying” through pointers to enforce memory isolation?
I’m not entirely sure what you mean by memory isolation here, but the basic idea is that if you have a pointer to something then you know where it is located in memory and you can write in it, that’s the whole idea of passing by address in C.
Now pointers themselves are merely variables. Yes they have a special meaning, they “point” to something and you can dereference them with the
*operator, but at the end of the day they’re still variables. They have a physical existence in memory or CPU registers, and their content is simply the address to which you want to point. Once you accept this, then the idea of the address of a pointer (ie the location of the variable you’re calling “pointer”, and not the address it contains) is not strange anymore and you can perfectly have a pointer-to-pointer in order to, among other things, pass pointers by address.Wait stop, so in other languages like C#, when you pass a variable into a function “by reference” is that just passing the pointer to the variable?
Have I been baited into using pointers my whole life?
Yes passing “by reference” is essentially the same as “by pointer” but with some syntactical sugar to make it easier to work with.
In C# it is different.
In C if I give you a pointer to a memory address, you can totally overwrite what is in that memory address, even write a new struct in there. So you’re getting a “real” writable memory address. You could even write a different type of structs and break the program. You could tweak specific bytes.
In languages like Java or C# you aren’t given a reference to the memory address but a reference to the object. You can only write to the object using it’s own interface (methods) but you can’t say “I’m going to totally overwrite this memory address with a new object”.
If you receive an object in a parameter, let’s say a “Person person” object and you do something like “person = new Person();” you didn’t really overwrite the memory address. The original person reference that was passed in the parameter is still intact. You can only modify it with something like “person.setName(…)”.
So, with real pointers you can do more stuff, but higher level languages don’t want you to do that because it breaks some of their principles for what “good programming” is. In this case they are protecting encapsulation. You shouldn’t be able to mess around with the memory contents of objects directly, only through their interfaces. Encapsulation is safer because objects should expose how to operate them safely via their interfaces.
char**So that you can have an array of strings. It’s useful to remember that in C arrays and pointers are exactly the same thing, just syntax sugar for however you want to look at it. There are a few exceptions where this isn’t true however:
&operatorsizeofalignofwhich decay is a no-nochar[]or wide literal ofwchar_t[], so likechar str[] = "yo mama";But
int**is just an array ofint*, which likewiseint*can just be an array ofint. In the picture here, we haveint** anyathat is an array ofint*with a size of 1,int* anyathat is an array ofintwith a size of 1, and then of course ourintthere being pointed to byint* anya.I guess this is beating a dead horse but you can have pointers to pointers for 2D arrays.
The first pointer tells you which coulm you’re on. The second pointer tells you which is the first object of each column. That way you can iterate the columns without loosing a reference to the current column you’re standing on.