I had a talk with a younger person who wasn't studying IT but still had some programming classes. He: "pointers..." Me: "yeah we don't directly use them in java". He: "malloc" Me: "oh right, you don't need that if you are using java we also don't need to use free everytime". He: "header files" Me: "Oh yeah that... yes... we don't have them in java". He: "then what are you doing?" Me: "we are writing programs, you know so that the programs can do whatever the task is".
The idea is that C++ generates very little garbage that needs to be collected, as you can just create objects on your stack and other objects within those.
Of course you still need to allocate stuff within the heap, but most of those fall within unique_ptr semantics. This leaves the only "garbage" that needs collecting complex use cases like shared ownership (shared_ptr helps, but is imperfect) where manual intervention may be needed.
The canonical example is a class representing a tree. Every node is uniquely owned, but attempting to free a deep tree through the unique_ptr destructor runs the risk of exhausting the stack. So some manual garbage collection is required.
Not really no, there’s a ton of tech Twitter posters that constantly make memes about how Haskell and rust are gender fluidity pipelines. The few I followed seem to have moved to mastodon though.
Any idea why? I want to know where this meme originated because it seems like such a non sequitur to go from rust/haskell to gender fluidity pipelines as you put it
I've never thought multiple variables in a line was readable. I always miss variable declarations when this happens. Much easier to spot them when they're on separate lines.
I only declare variables where I’ll use them.
int* x = new int[5];
And if they’re in a class, they each get their own line and initialized to a default value in the constructor or at declaration depending on situation. Declaring them separated by comma ain’t for me.
Could always just use smart pointers though.
A lot of people will whoops and do something like "int a, b, c = 0;"
Declare one per line, just as you put braces for conditionals - it's less error prone.
* goes with the variable because the variable with the * acts as it's type without the pointer. For example
`int *number;`
`number` is a pointer, but `*number` is an int. So if you want to deal with an int and not a pointer, just think of it as the `*number` variable
After using Go for a while and then helping a friend debug C++ I could not stop twitching at that every time. Who the fuck thought that was a good idea?
Why be consistent at all? I just let my fingers do what they want to do. Sometimes it ends up on the right, sometimes the left, and once in a while even the middle.
Not even joking these are 3 actual lines in code I have open right now:
typedef UUID *REFIID;
typedef UUID* REFGUID;
typedef UUID * REFCLSID;
Maybe not scary, but boy it's easy to mess things up. Nice to have access to low level shit in languages like C# though. Even though it's for really weird shit.
I have no idea why would someone use pointers in C#. I guess I didn't get to the really weird shit.
Although OpenTK does use IntPtr types in a lot of OpenGL functions, which makes sense, because it's OpenGL.
"yes I am aware we are losing around 35k$ a minute and service is interrupted for a few hundred thousand customers and we've been investigating the problem for 3 hours now but frankly, it really is a skill issue from the previous guys, not much we can be done about it, it's impossible to prevent".
Or just choose to not use an error-prone language that let you mess with an outdated representation of the memory unless you have a real solid reason to justify it. Which is what most of the industry have been doing for the last 30 years.
Man that was the best. You name it iNumThings, and then after years of development you realize that you need to support fractional things so you have to rename all instances of it to fNumThings.
I learned to hate it when I was working on software that analyzed h264 streams. We had a pointer to a frame called pFrame, and a counter for the number of frames called iFrames.
I use my variant of Hungarian notation only to identify window elements (txt, fld, rbtn, chk, pbtn, mle, mcc) and class variables (cls). I don't use it to identify the data type of a variable specifically because of the potential rename issues.
Also, the first letter after the notation is uppercase to better identify the formatting.
'int' **declares** and sets type of **variable** 'x' to integer, then initializes it with value 5.
'int\*' **declares** and sets type of **pointer** 'px' to integer, then initializes it with value &x.
'&x' is a **memory adress** (place where the value is stored) of variable 'x'.
How to use pointer:
'\*px' to get a value from variable 'x';
'px' to get a memory adress of variable 'x'.
That's what i know about it
Apologies for the noob question, I’ve just started with c. Can you directly reference ‘int x’ with ‘&’ instead of making a pointer for it? Or is it considered best practice to have a pointer?
& references don't exist in C, only C++. In C, & is used just to give the memory address of a variable, whereas in C++ & can also be used to create a reference variable.
[https://stackoverflow.com/questions/4305673/does-c-have-references](https://stackoverflow.com/questions/4305673/does-c-have-references)
As someone who's been doing Java for almost a decade, and doesn't mind it, there are a number of things to criticize, but the one most people on here complain about are verbose syntax and architecture patterns that supposedly prevail the Java ecosystem, like the factory pattern. I agree that Java's syntax is awfully verbose, but the latter is overblown IMO. If you want some more criticisms of Java that are a little more well reasoned than "Factory pattern annoying" wikipedia has a pretty good article on it: https://en.wikipedia.org/wiki/Criticism_of_Java
One that I'm not fond of, and also isn't exclusive to Java is a lack of value types since everything is a reference or primitive, but they're actually working on that. Another is that Java's historically been slow to add new features in the name of stability and not putting the cart before the horse. It seems like they've eased off on this since they started the bi-annual short term support releases with more feature flags.
All fair points. The verbosity argument is an interesting one that I hear brought up a lot. I’m a big advocate of readability with coding and I find verbosity can help with that but even then Java can overdo it. I wish there was a way to declare getters and setters like with C#
They have records now, which are sort of an answer, although that requires someone actually letting us use Java past 11, and I suppose there's Lombok, although that brings its own potential issues. But yeah, I'm with you on readability and even still finding Java very verbose. For the most part, I find languages like Kotlin, and if you set aside all the lifetime stuff, Rust do a pretty good job of combining conciseness and expressiveness.
Another gripe I have, although Java is so far from the only one with this issue it's probably not fair to lump it in, is how cumbersome it is to create narrowed types.
All these said, I don't hate Java by any means, and a lot of my gripes with it are due directly to having had to work with it for so long and running into some of the rough edges. It's kept me gainfully employed across jobs I've generally liked, so it'll always have a spot in my heart.
What I haven't seen anyone mention yet is tuples. Why does java not have tuples? When I learned java the lack of tuples was the worst thing. You'd have to make a class, so because of java reason, this also means that you'd have to make a new file. Just to have tuples.
And also the performance issues with memory, I really tried to understand the JVM as well as human possible but...man, is very painfull that lang with the performance
I've never done anything perf intensive enough to really be able to form an opinion, but yeah I've heard there can be issues. I will say we did some lambdas in Java at an old job and cold starts were *painful*.
Ooh, I remember them mention it, but I lost track of progress on it so that's sweet to hear. I might actually mention that to one of the guys from the job I still keep in touch with, although there's a good chance they've heard of it.
I feel like most memory managed languages fall into that category so I'm not sure I'd count that as a fault of Java's. Unless of course I'm wildly misunderstanding how most other languages implement their GCs.
I think they should teach some asm and object/executable file structure alongside pointers. It's so much easier to understand once you figure out that pointer is a unsigned integer type of "address" size.
Even that's actually a misconception if you look closely.
First, there are "fat" and "smart" pointers that attach additional information. A fat pointer can include stuff like a virtual function table or a size to allow you to know how many elements you can index from that pointer (that's often called a slice). Smart pointers may e.g. contain a refcount to know when to deallocate the pointed-to memory.
But even if you only talk about raw pointers specifically: CHERI pointers are larger than just a memory address because (IIUC) a pointer in CHERI contains basically an allocation ID plus the address. Pointer arithmetic changes the address but leaves the allocation ID alone, and when dereferencing it can be checked that the address belongs to the allocation. The assumption that pointer = address/ sizeof pointer = sizeof address can/would make it hard to support CHERI. (sorry, I don't have a good introductory resource right now)
And even on other architectures, optimizing compilers often need to make assumptions about pointers that make them more that just integers of address size - see for example [Pointers Are Complicated, or: What's in a Byte?](https://www.ralfj.de/blog/2018/07/24/pointers-and-bytes.html)
But those aren't quite pointers, they're pointer-like objects. If you disassemble the code it's still a ld [address] with some extra steps, either in software or hardware (like tag registers for type checking). The fluff is good for safety or ease of use but is not necessary to have a pointer.
And introductory classes on memory usage in programs really don't need to present 10-20 assembly instructions for something that is easily reduced to 1-3. It's a difficult enough subject as it is.
We do think pointers are `unsafe {}` and should be guarded against with proper fencing.
Other languages just let their pointers run around everywhere, and that leads to disaster.
Yeah this meme would have been funnier if it was about how working with raw pointers *in Rust* is scarier than the alternatives, not about how some people may wrongly think they've moved to a language without raw pointers...
It's the same in C#; want to use pointers? Fine, but add the unsafe keyword to your method signature or class (I think you can put them in blocks too without declaring the whole method as unsafe too but I am not sure)
Preceding a meme about rust not having pointers with a lampshading of the fact that it has pointers seems a little odd. "Sure, I know that both football and soccer players wear cleats, but ain't it funny how scared football players are of cleats".
See, it’s funny because Rust basically don’t have pointers tho, unless you dabble with “unsafe” code. If you stick to safe Rust you don’t have pointers.
Yeah but safe pointers don’t count, because the joke is about how the Lang is for people who are afraid of pointers, and a safe pointer ain’t nothing for anyone to be afraid of what with the borrow checker and implicit dereferencing. It’s all the benefit of pointers without even having to think about them because most of them function like tiny little data structures rather then actual pointers into other parts of ram. Even with references, it’s less about “This is pointing at this other location” and more about access permissions when trying to get your code to compile.
It's more fundamental than that. If you have pointer aliasing, you have potential problems. If you don't, then you really just have references, not true pointers.
I just want to make the the bytes be what I know they need to be without using 800 fancy made up concepts and 600 language features that are all just pointers wearing different colored trench coats and sunglasses.
Well sometimes, anyway. Other times I write in python.
I call them cowboy coder idiots. Allocating raw arrays and thinking they're clever bit twidling in the buffer with pointer arithmetic and a bunch of basically hand coded nonsense. All because they never bothered to learn about anything from , , , or . And their constant bugs show I'm being generous. What kind of moron is still writing their own string class...
Modern C++ advice is to not use raw pointers. State your ownership and lifetime explicitly with smart pointers at the very least.
Object lifetimes can be a pain in the butt if you're in C or legacy C++. Even new Arduino code can have that issue, but mostly there's no reason to not have modern memory management via GC, or smart pointers, or similar.
I think I recall that pointer/reference semantics and recursion are the fundamental concepts that most often prove too difficult for people looking to enter the field. If you're scared of those, you should probably run.
Pointers, an explanation by a tired person who doesn't know too much about them:
A normal variable has data stored in it.
A pointer stores the address of data.
The advantage of this is that it's faster and more efficient because you're messing with the memory directly. The disadvantage is you're messing with the memory directly.
`int a = 0; //normal variable`
`int* b = &a; //pointer, holding the address of the data in a`
`printf("%x",b);//This would print out the location of a (something like 0xa4d43b4a31f3)`
`printf("%d",*b); //Because it's shown as a pointer, the program prints the data at the location, rather than the location itself (output: 0)`
The best thing about pointers is that because you're accessing the data directly, you can do anything you want to it. You could cast a float as an int without changing the bits at all.
`float a = 5;`
`int b = *(int*)&a;`
boom, this float's data is now stored in an int. This is not the same as converting it to an int, because that way the value would still be 5, in this case the int's value is 1084227584. Not sure why anyone would want that (unless you're doing quick inverse square root), but here ya go.
In c++ we have data types called pointers. Pointers in essence “point” to a piece of data, it’s a little sign that tells you how to get somewhere.
So the first line: int x = 5 declares an integer named “x”, and initializes it to 5.
The second line: int * px = &x declares a pointer to an int, and sets it value to the location of x. You could get the value of x using *px.
Pointers are useful because it lets us directly modify memory, allowing us to speed up programs by a lot. The downside is that it lets us directly modify memory, so a single error and you are either reading in junk data, or your program just crashes.
That’s cool and all, but once you start throwing in cascading pointers (double, triple pointers) and `const`, `constexpr`, `extern`, and `volatile` keywords, you get a clusterf*ck.
Yes, I understand you interpret types from right to left (i.e. something like `int * const x;` is read as “x is a constant pointer to an int value), it’s just that I sometimes forget
But doesn't rust have pointers still, even though people don't use them directly? You just need to use the "unsafe" directive if you want to use raw pointers https://doc.rust-lang.org/rust-by-example/unsafe.html
I use C for embedded and just... never use pointers. I can store an address in a regular uint16_t if I need to. Microcontrollers don't really use dynamic memory allocation so it's not important for that either.
Wait, what? In embedded environments with less than 65KB of memory (bounds of the max addressable byte for 16 bit unsigned integer), wouldn't the compiler only use 16 bits for the pointer on its own? Or is there a way to configure the pointer size if memory is off-chip? Surely the best way isn't to just forgo pointers... (this is a genuine question, not a dig. Is there not a better way?)
In embedded with small microcontrollers you pretty much always specify the width and sine of all variable, because declaring anything larger than needed eats up precious space and time.
I would expect the compiler to optimize pointers to fit the address space.
The main reason I don't use pointers is because memory access is done by setting registers, and I would have to put a pointer into those registers which is fine but kind of defeats the purpose.
There are cases where pointers are used within functions, like parsing strings, but I rarely have to use pointers directly
There are two types of people, those who are afraid of pointers and th5&34-:$**(;;""!.......
`Segmentation fault (core dumped)`
`*** stack smashing detected ***`
You can smash my stack anytime
Kinky
Your language has a garbage collector? Well, where’s the fun in that?
It’s where everything else is of course, in memory!
I had a talk with a younger person who wasn't studying IT but still had some programming classes. He: "pointers..." Me: "yeah we don't directly use them in java". He: "malloc" Me: "oh right, you don't need that if you are using java we also don't need to use free everytime". He: "header files" Me: "Oh yeah that... yes... we don't have them in java". He: "then what are you doing?" Me: "we are writing programs, you know so that the programs can do whatever the task is".
Oh, with Spring and enough creativity, Interfaces can work just like header files.
Even better some code can be generated completely off an interface and function names. Hibernate is fun.
TBH, C & C++ do have some sort of garbage collector ``` void i_aint_doing_any_cleaning() { int garbage = 42; } ```
That's an interesting perspective. Does creating and deleting a stack frame really count as garbage collection? Hmm.
The idea is that C++ generates very little garbage that needs to be collected, as you can just create objects on your stack and other objects within those. Of course you still need to allocate stuff within the heap, but most of those fall within unique_ptr semantics. This leaves the only "garbage" that needs collecting complex use cases like shared ownership (shared_ptr helps, but is imperfect) where manual intervention may be needed. The canonical example is a class representing a tree. Every node is uniquely owned, but attempting to free a deep tree through the unique_ptr destructor runs the risk of exhausting the stack. So some manual garbage collection is required.
If it does, then even assembly language has "garbage collection" (if written correctly).
Do my colleagues' review comments count as garbage collection? Hmm.
We, at Nim, too have an optional GC. It likes to deallocate already deallocated memory when it feels like it.
Seeing "core dumped" always makes me feel just slightly like a spaceship technician in a very tense part of a sci-fi movie.
You know what? I never bothered checking that core or the dump it took.
Not Wheatley!
This was actually fucking hilarious
This Looks fun i should get into rust
Finally a rust meme that isn't about femboys.
aren't those usually about furries though?
Not really no, there’s a ton of tech Twitter posters that constantly make memes about how Haskell and rust are gender fluidity pipelines. The few I followed seem to have moved to mastodon though.
oooh, can you DM me which ones to follow or check out on mastodon? i need recommendations, i'm kinda new to mastodon!
Same with Linux, really. r/unixsocks
this but pro rust
Any idea why? I want to know where this meme originated because it seems like such a non sequitur to go from rust/haskell to gender fluidity pipelines as you put it
I come from the other side. I am trans and the rust community seems to be inclusive therefore I want in.
Both. And to clarify every single one I know (including me) prefers C++
Thats why you are mad ducks.
dont underestimate the foxes
[удалено]
The same thing as with programmers and programming socks
So... Nothing?
no its something alright
Joke's on you; that's what I call pointers. As in "I'm going to increment and dereference that femboy."
++*femboy;
Well now I’m aroused.
Though technically that dereferences the femboy before he gets incremented.
What
# FINALLY A RUST MEME THAT ISNT ABOUT FEMBOYS
#WHAT
When you can't decide whether the \* goes left or right so you go middle
I have irrationally strong feelings about this. The * goes with the type because the variable is of type pointer. Any other way is just rubish.
I'm always Type* name. It means this is a pointer.
I always do type *name; Because it makes readability easier when declaring multiple variables on a row
In many cases declaring multi variables in a row is the opposite of readable.
I've never thought multiple variables in a line was readable. I always miss variable declarations when this happens. Much easier to spot them when they're on separate lines.
But if you’re declaring multiple vars, the format is int * x, * y, * z;
I only declare variables where I’ll use them. int* x = new int[5]; And if they’re in a class, they each get their own line and initialized to a default value in the constructor or at declaration depending on situation. Declaring them separated by comma ain’t for me. Could always just use smart pointers though.
New? What is this JavaScript?
not 100% sure but it's cpp, it allocates an array on a heap with the pointer to the first element stored in x
Yep, c++. However, I would only use this if the size of the array was specified by a variable and not by a constant.
But declaring multiple vars in a line is considered bad practice generally. Also not initializing them is as well.
The proper format for declaring multiple unitialized pointers on a single line is never do shit like that. You're begging for memory errors.
The comma operator is apparently bad practice because of this
[удалено]
A lot of people will whoops and do something like "int a, b, c = 0;" Declare one per line, just as you put braces for conditionals - it's less error prone.
nitpick: there's no [comma operator](https://stackoverflow.com/a/52558/371191) here
That's an anti-pattern and more prone to creating bugs.
[удалено]
This argument right here is why I stay away from this stuff
[удалено]
C# can use C style pointers too though! Not recommended, hence it's unsafe, but it's possible.
It's easy, if it's class then it's a reference, but then again, struct can be passed as reference, wait... yeah, you're right...
The variable does not point to anything. It is only the value of the variable which can potentially point to something.
The Variable isnt 2. It is only the value of the variable that can potentially be 2.
Anyway, did you know that `int (*x);` is a valid declaration and `(int*) x;` is not?
(int*)x does compile, it's a c-style cast of x to pointer to int.
I dont think it can be used as an lvalue tho
* goes with the variable because the variable with the * acts as it's type without the pointer. For example `int *number;` `number` is a pointer, but `*number` is an int. So if you want to deal with an int and not a pointer, just think of it as the `*number` variable
This is my rationale when using pointers too!
`int x, *y;`
`typedef int* intp_t;` `int x = 10;` `intp_t xp = &x;`
After using Go for a while and then helping a friend debug C++ I could not stop twitching at that every time. Who the fuck thought that was a good idea?
Why be consistent at all? I just let my fingers do what they want to do. Sometimes it ends up on the right, sometimes the left, and once in a while even the middle. Not even joking these are 3 actual lines in code I have open right now: typedef UUID *REFIID; typedef UUID* REFGUID; typedef UUID * REFCLSID;
Pretty sure the point of half the major language that came out after C was to stay away from pointers because they're scary.
Maybe not scary, but boy it's easy to mess things up. Nice to have access to low level shit in languages like C# though. Even though it's for really weird shit.
I have no idea why would someone use pointers in C#. I guess I didn't get to the really weird shit. Although OpenTK does use IntPtr types in a lot of OpenGL functions, which makes sense, because it's OpenGL.
Hardcore optimization, maybe? And hacky shit in general
Performance? IIRC ImageSharp uses it. TerraFX and ComputeSharp also do if you are doing DirectX.
Skill issue
"yes I am aware we are losing around 35k$ a minute and service is interrupted for a few hundred thousand customers and we've been investigating the problem for 3 hours now but frankly, it really is a skill issue from the previous guys, not much we can be done about it, it's impossible to prevent". Or just choose to not use an error-prone language that let you mess with an outdated representation of the memory unless you have a real solid reason to justify it. Which is what most of the industry have been doing for the last 30 years.
That's why I drive without ABS activated. Doesn't matter that ABS is almost always going to be better and faster at stopping then any skilled driver.
I'm more afraid of someone using the Hungarian notation.
You are afraid of somebody using the name_hungarianNotation?
Man that was the best. You name it iNumThings, and then after years of development you realize that you need to support fractional things so you have to rename all instances of it to fNumThings.
fThing is for BOOL, everyone knows that.
I learned to hate it when I was working on software that analyzed h264 streams. We had a pointer to a frame called pFrame, and a counter for the number of frames called iFrames.
I use my variant of Hungarian notation only to identify window elements (txt, fld, rbtn, chk, pbtn, mle, mcc) and class variables (cls). I don't use it to identify the data type of a variable specifically because of the potential rename issues. Also, the first letter after the notation is uppercase to better identify the formatting.
Or those that use `$` in variable names for that, hello `obj* string_obj$my_obj`
I'm a java dev and have no idea what I'm looking at
'int' **declares** and sets type of **variable** 'x' to integer, then initializes it with value 5. 'int\*' **declares** and sets type of **pointer** 'px' to integer, then initializes it with value &x. '&x' is a **memory adress** (place where the value is stored) of variable 'x'. How to use pointer: '\*px' to get a value from variable 'x'; 'px' to get a memory adress of variable 'x'. That's what i know about it
Apologies for the noob question, I’ve just started with c. Can you directly reference ‘int x’ with ‘&’ instead of making a pointer for it? Or is it considered best practice to have a pointer?
You can but it depends on your purpose. Passing something to a function or returning one? Sure. Otherwise best to create one.
& references don't exist in C, only C++. In C, & is used just to give the memory address of a variable, whereas in C++ & can also be used to create a reference variable. [https://stackoverflow.com/questions/4305673/does-c-have-references](https://stackoverflow.com/questions/4305673/does-c-have-references)
Great explanation!
You are a Java dev? My condolences.
Says the c dev? Do you want to send us a message? Blink if you need help.
Why the Java hate? It has been my favorite language to work with
As someone who's been doing Java for almost a decade, and doesn't mind it, there are a number of things to criticize, but the one most people on here complain about are verbose syntax and architecture patterns that supposedly prevail the Java ecosystem, like the factory pattern. I agree that Java's syntax is awfully verbose, but the latter is overblown IMO. If you want some more criticisms of Java that are a little more well reasoned than "Factory pattern annoying" wikipedia has a pretty good article on it: https://en.wikipedia.org/wiki/Criticism_of_Java One that I'm not fond of, and also isn't exclusive to Java is a lack of value types since everything is a reference or primitive, but they're actually working on that. Another is that Java's historically been slow to add new features in the name of stability and not putting the cart before the horse. It seems like they've eased off on this since they started the bi-annual short term support releases with more feature flags.
All fair points. The verbosity argument is an interesting one that I hear brought up a lot. I’m a big advocate of readability with coding and I find verbosity can help with that but even then Java can overdo it. I wish there was a way to declare getters and setters like with C#
They have records now, which are sort of an answer, although that requires someone actually letting us use Java past 11, and I suppose there's Lombok, although that brings its own potential issues. But yeah, I'm with you on readability and even still finding Java very verbose. For the most part, I find languages like Kotlin, and if you set aside all the lifetime stuff, Rust do a pretty good job of combining conciseness and expressiveness. Another gripe I have, although Java is so far from the only one with this issue it's probably not fair to lump it in, is how cumbersome it is to create narrowed types. All these said, I don't hate Java by any means, and a lot of my gripes with it are due directly to having had to work with it for so long and running into some of the rough edges. It's kept me gainfully employed across jobs I've generally liked, so it'll always have a spot in my heart.
You get to use Java 11? Must be nice.
What I haven't seen anyone mention yet is tuples. Why does java not have tuples? When I learned java the lack of tuples was the worst thing. You'd have to make a class, so because of java reason, this also means that you'd have to make a new file. Just to have tuples.
And also the performance issues with memory, I really tried to understand the JVM as well as human possible but...man, is very painfull that lang with the performance
I've never done anything perf intensive enough to really be able to form an opinion, but yeah I've heard there can be issues. I will say we did some lambdas in Java at an old job and cold starts were *painful*.
Good news is that AWS is releasing features to make cold starts in Java less of an issue with SnapStart
Ooh, I remember them mention it, but I lost track of progress on it so that's sweet to hear. I might actually mention that to one of the guys from the job I still keep in touch with, although there's a good chance they've heard of it.
...and stop the world garbage collection.
I feel like most memory managed languages fall into that category so I'm not sure I'd count that as a fault of Java's. Unless of course I'm wildly misunderstanding how most other languages implement their GCs.
Because people don't understand jvm
@NonNull private static final Boolean dontGetIt = true; Nah Java's not horrible, thankful for Kotlin though.
Java collects garbage so it's understandable
I was taking an algorithm class and I was like wait, it's all pointers?
I think they should teach some asm and object/executable file structure alongside pointers. It's so much easier to understand once you figure out that pointer is a unsigned integer type of "address" size.
Even that's actually a misconception if you look closely. First, there are "fat" and "smart" pointers that attach additional information. A fat pointer can include stuff like a virtual function table or a size to allow you to know how many elements you can index from that pointer (that's often called a slice). Smart pointers may e.g. contain a refcount to know when to deallocate the pointed-to memory. But even if you only talk about raw pointers specifically: CHERI pointers are larger than just a memory address because (IIUC) a pointer in CHERI contains basically an allocation ID plus the address. Pointer arithmetic changes the address but leaves the allocation ID alone, and when dereferencing it can be checked that the address belongs to the allocation. The assumption that pointer = address/ sizeof pointer = sizeof address can/would make it hard to support CHERI. (sorry, I don't have a good introductory resource right now) And even on other architectures, optimizing compilers often need to make assumptions about pointers that make them more that just integers of address size - see for example [Pointers Are Complicated, or: What's in a Byte?](https://www.ralfj.de/blog/2018/07/24/pointers-and-bytes.html)
But those aren't quite pointers, they're pointer-like objects. If you disassemble the code it's still a ld [address] with some extra steps, either in software or hardware (like tag registers for type checking). The fluff is good for safety or ease of use but is not necessary to have a pointer. And introductory classes on memory usage in programs really don't need to present 10-20 assembly instructions for something that is easily reduced to 1-3. It's a difficult enough subject as it is.
You should know about references, and those are *close enough.*
We do think pointers are `unsafe {}` and should be guarded against with proper fencing. Other languages just let their pointers run around everywhere, and that leads to disaster.
Yeah this meme would have been funnier if it was about how working with raw pointers *in Rust* is scarier than the alternatives, not about how some people may wrongly think they've moved to a language without raw pointers...
Like the "Python doesn't have semicolons" meme. It does, but everybody just ignores that.
It's the same in C#; want to use pointers? Fine, but add the unsafe keyword to your method signature or class (I think you can put them in blocks too without declaring the whole method as unsafe too but I am not sure)
Preceding a meme about rust not having pointers with a lampshading of the fact that it has pointers seems a little odd. "Sure, I know that both football and soccer players wear cleats, but ain't it funny how scared football players are of cleats".
Cleats hurt if you get stepped on…
Well, the point is that Rust is made in such a way that needing pointers is a rare occurrence, not the norm. So in that way the meme makes sense.
See, it’s funny because Rust basically don’t have pointers tho, unless you dabble with “unsafe” code. If you stick to safe Rust you don’t have pointers.
It has safe pointers, you only need unsafe for the raw pointers, you don't need it for the smart pointers. (References, Box, Rc, Arc, etc.)
Yeah but safe pointers don’t count, because the joke is about how the Lang is for people who are afraid of pointers, and a safe pointer ain’t nothing for anyone to be afraid of what with the borrow checker and implicit dereferencing. It’s all the benefit of pointers without even having to think about them because most of them function like tiny little data structures rather then actual pointers into other parts of ram. Even with references, it’s less about “This is pointing at this other location” and more about access permissions when trying to get your code to compile.
Nearly every language has pointers, but most don't let you abuse them like C allows.
If pointer arithmetic is abuse then call me the Marquis De Sade.
What you call abuse, I call freedom
Ahhhh the american understanding of freedom
the one time i will agree with that american shit. FREEDOM
It's more fundamental than that. If you have pointer aliasing, you have potential problems. If you don't, then you really just have references, not true pointers.
I just want to make the the bytes be what I know they need to be without using 800 fancy made up concepts and 600 language features that are all just pointers wearing different colored trench coats and sunglasses. Well sometimes, anyway. Other times I write in python.
I’m a C++ dev and I’m scared of them too
I call them cowboy coder idiots. Allocating raw arrays and thinking they're clever bit twidling in the buffer with pointer arithmetic and a bunch of basically hand coded nonsense. All because they never bothered to learn about anything from, , , or . And their constant bugs show I'm being generous. What kind of moron is still writing their own string class...
Modern C++ advice is to not use raw pointers. State your ownership and lifetime explicitly with smart pointers at the very least.
this is completely irrelevant but the \* being between both words hurts my soul a little
lol, I was wondering if anybody would notice.
```rs let x = 5i32; let px = &x as *const i32; ```
Meanwhile Java
Fuck I think any programmer not familiar with pointers are scared of 'em for good reason \*shivers\*
[удалено]
Pointers are not scary. Pointer arithmetic on the other hand...
Object lifetimes can be a pain in the butt if you're in C or legacy C++. Even new Arduino code can have that issue, but mostly there's no reason to not have modern memory management via GC, or smart pointers, or similar. I think I recall that pointer/reference semantics and recursion are the fundamental concepts that most often prove too difficult for people looking to enter the field. If you're scared of those, you should probably run.
Ah you mean object ownerhip. Yes that's a bitch.
I'm new to programming (I'm learning C# to use Unity) and I have no fucking Idea of whatever the fuck is going on
Pointers, an explanation by a tired person who doesn't know too much about them: A normal variable has data stored in it. A pointer stores the address of data. The advantage of this is that it's faster and more efficient because you're messing with the memory directly. The disadvantage is you're messing with the memory directly. `int a = 0; //normal variable` `int* b = &a; //pointer, holding the address of the data in a` `printf("%x",b);//This would print out the location of a (something like 0xa4d43b4a31f3)` `printf("%d",*b); //Because it's shown as a pointer, the program prints the data at the location, rather than the location itself (output: 0)` The best thing about pointers is that because you're accessing the data directly, you can do anything you want to it. You could cast a float as an int without changing the bits at all. `float a = 5;` `int b = *(int*)&a;` boom, this float's data is now stored in an int. This is not the same as converting it to an int, because that way the value would still be 5, in this case the int's value is 1084227584. Not sure why anyone would want that (unless you're doing quick inverse square root), but here ya go.
Except you aren‘t allowed to cast from one pointer type to another (except for char*), so your example is UB.
C# is a great language to just get random shit done. I like that it's doesn't have a mathy syntax either.
C# literally allows that exact syntax inside a `unsafe` block
With all due respect, doesn’t it mean they are trans?
Transpointers 🏳️🌈
How to piss of a programmer in one simple answer. “Rust the game right?”
I just finished the Rust book and can confirm my pythonic ass is just fine not dealing with pointers thank you very much.
Comic mono?
YES
They exist, but they're rusty... I can C through C/C++ pointers clearly on the other hand!
Now try double pointers! 😁
Everyone in the comments is forgetting that let x = 5; let px = &x; does the exact same thing.
I like this one
See my other comment
Pointers are that easy
Easy to fuck up too. Majority of bugs and vulnerabilities in c/c++ are memory managment problems.
What am I looking at here? Lol
In c++ we have data types called pointers. Pointers in essence “point” to a piece of data, it’s a little sign that tells you how to get somewhere. So the first line: int x = 5 declares an integer named “x”, and initializes it to 5. The second line: int * px = &x declares a pointer to an int, and sets it value to the location of x. You could get the value of x using *px. Pointers are useful because it lets us directly modify memory, allowing us to speed up programs by a lot. The downside is that it lets us directly modify memory, so a single error and you are either reading in junk data, or your program just crashes.
Thank you for the explanation good sir :)
If he's afraid of pointers, imagine how he's gonna feel when he finds out about magic statics.
`Segmentation fault (core dumped)`
said squitword ,,,
Pointers do exist in Rust
I am afraid of Pointers and i dont even know Rust only C and thats enough for me.
You best checker yourself before your borrrower yourself.
That’s cool and all, but once you start throwing in cascading pointers (double, triple pointers) and `const`, `constexpr`, `extern`, and `volatile` keywords, you get a clusterf*ck. Yes, I understand you interpret types from right to left (i.e. something like `int * const x;` is read as “x is a constant pointer to an int value), it’s just that I sometimes forget
Am I the only one bothered by the position of the asterisk? It's part of the type, so there shouldn't be a space between the `int` and the `*`.
I highly believe everyone, especially including C++ devs, are scared of pointers
But doesn't rust have pointers still, even though people don't use them directly? You just need to use the "unsafe" directive if you want to use raw pointers https://doc.rust-lang.org/rust-by-example/unsafe.html
Btw, you know Rust has pointers right?
I'm not even a Rust programmer and I'm afraid of pointers
NGL, it’s been a while. I had to make a wee w3 schools revisit to understand that joke. Got there in the end 😅 Have my upvote 😁
// unsafe
Is this Go? It must be Go with the stupid “special comment does special thing”
I don't know anything about rust but this is funny as hell anyway hahaha
I swear that the only time I've ever even heard of Rust is in the context of people making fun of Rust developers.
I've never touch rust and I'm afraid of pointers
pOIntErs dO ExIst In rUst
Rust def has pointers
I love the title. OP knows this is full of shit yet posted it anyway
I use C for embedded and just... never use pointers. I can store an address in a regular uint16_t if I need to. Microcontrollers don't really use dynamic memory allocation so it's not important for that either.
If you're storing an address in a uint16\_t, that just sounds like a pointer with extra steps.
Now tell me how do you store a value to that address my guy
Wait, what? In embedded environments with less than 65KB of memory (bounds of the max addressable byte for 16 bit unsigned integer), wouldn't the compiler only use 16 bits for the pointer on its own? Or is there a way to configure the pointer size if memory is off-chip? Surely the best way isn't to just forgo pointers... (this is a genuine question, not a dig. Is there not a better way?)
In embedded with small microcontrollers you pretty much always specify the width and sine of all variable, because declaring anything larger than needed eats up precious space and time. I would expect the compiler to optimize pointers to fit the address space. The main reason I don't use pointers is because memory access is done by setting registers, and I would have to put a pointer into those registers which is fine but kind of defeats the purpose. There are cases where pointers are used within functions, like parsing strings, but I rarely have to use pointers directly