Programming thread

Does that only work with integers or can you use other data types? Also, how does it do classes? My searches aren't coming up with much.
Switch only supports the int types, tried compiling a quick test program with floats and it crashed and burned. Classes are presented as structs with single inheritance in the docs, no idea if it actually groups methods or not.
 
Switch only supports the int types, tried compiling a quick test program with floats and it crashed and burned. Classes are presented as structs with single inheritance in the docs, no idea if it actually groups methods or not.
How would methods work in something like C exactly? Is it like Python where self isn't a reserved word but just the de facto parameter used to access members of a class instance?
 
How would methods work in something like C exactly? Is it like Python where self isn't a reserved word but just the de facto parameter used to access members of a class instance?
What I've seen is usually just groups of similarly named functions and taking a pointer to the structure they operate on. C++ basically automates that to an implicit this argument. If Holy-C were continuing in that direction, I'd expect to be able to define functions as members of the class and access data with self or this. (Code tag fail, lmao)
 
  • Thunk-Provoking
Reactions: Belisarius Cawl
What I've seen is usually just groups of similarly named functions and taking a pointer to the structure they operate on.
One of the things I remember when learning R, which was in the context of RStudio, but could apply elsewhere, is that whenever you do this make sure the "similarly" part is in the front of the identifier so that any kind of completion functionality can work properly. I think that's how it usually works barring the sort of matching I've witnessed when using the fish shell.
 
It might be because I’m a huge Apple Chad, but I gotta admit that Swift has grown to be my favorite language of doing everything in when possible.

The standard library is huge, so much in fact that I never bother with 3rd party packages, but just write whatever functionality missing myself. It’s fast and memory safe using ARC instead of GC. And if you’re doing something that requires manual memory management, it allows you to do that fairly easy and the same goes for interacting with C/C++ as well.

On the other hand I’m also very passionate about making money, so everything for work is C# lmao!
 
How would methods work in something like C exactly? Is it like Python where self isn't a reserved word but just the de facto parameter used to access members of a class instance?
Methods work in C the same way they work in C++, it's just that C++ hides the implementation from you. There's a table of function pointers (vTable, in the jargon, this is how polymorphism is implemented), and the first parameter of each function is a "self" or "this" pointer to the object. GTK is (was?) a decent example of how objects and classes look in C.
 
Last edited:
Methods work in C the same way they work in C++, it's just that C++ hides the implementation from you. There's a table of function pointers (vTable, in the jargon, this is how polymorphism is implemented), and the first parameter of each function is a "self" or "this" pointer to the object. GTK is (was?) a decent example of how objects and classes look in C.
Notably unless they were explicitly declared virtual its handled more like a wildcard function. IE if you hold a pointer to something as BaseClass (even though its not) and then call a member function off of it you will call the BaseClass version of the function.

I was annoyed about that for years and then really disenchanted with the language when I figured out how that really worked. I guess its fine though I can still write C in it and pick and choose the C++ features when I actually want them.
 
Can someone please explain what cross site scripting is to a retard? I’m not a webshitter but I’m forced to use Swift this one time. Word2Vec is weird.
 
Last edited:
"Cross-site scripting" is when a website pulls scripts from other websites. Obviously, if those websites get hacked, the hacked scripts might do undesirable things.
no, that's a supply chain attack. xss is when the code that renders the HTML, whether client-side or server-side, doesn't properly sanitize the data it gets from the database when rendering the UI.

e.g. if you set your display name to "<script>functionThatSendsYourAuthenticationTokenToMaliciousServer()</script>" on a vulnerable site and someone visits any page containing your display name, their browser will actually RUN that javascript, in this case, send their user authentication token to a server that YOU control, giving you access to people's accounts, including admin accounts

a less harmful example is forcing users to automatically post something to that website, or change their profile picture, something like that

xss's are way less common on sites created in the last decade or so, with everyone using react or similar frameworks, which automatically sanitize everything

they used to be a lot more prevalent when everyone was using php (along with an entire class of other exploits very common with php code)
 
Last edited:
Can someone please explain what cross site scripting is to a retard? I’m not a webshitter but I’m forced to use Swift this one time. Word2Vec is weird.
From here:
Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page. For more details on the different types of XSS flaws, see: Types of Cross-Site Scripting.

Cross-Site Scripting (XSS) attacks occur when:

Data enters a Web application through an untrusted source, most frequently a web request.
The data is included in dynamic content that is sent to a web user without being validated for malicious content.

The malicious content sent to the web browser often takes the form of a segment of JavaScript, but may also include HTML, Flash, or any other type of code that the browser may execute. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data, like cookies or other session information, to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user’s machine under the guise of the vulnerable site.
A lot of XSS happens from bad input sanitization when displaying user-controlled data. For example, if xenforo didn't escape posts properly, this <script>alert(1)</script> (usually there's a bit more to it than that lol) would cause an alert in your browser. This is why you sometimes see text with stuff like &gt; instead of <. These escaped characters help browsers distinguish between text content and actual HTML tags.
 
Last edited:
The compiler is too restrictive of what you are allowed to do with the language, because it needs statically-managed lifetimes for the borrow checker
Good C and C++ programmers are already mentally managing allocation lifetimes, it requires constant attention if you want correct software. If you are finding lifetimes in Rust challenging, it is indicative that you aren't properly considering the lifetimes of your heap allocations in C or C++.
The value of rust is that it allows you to alleviate the cognitive burden associated with managing the lifetimes of allocated data, which also means you can almost fully learn it without that knowledge, but then when it pops up, you are forced to notate references to that data in a specific way. In all other languages, this is optional, it may display a warning, and then it manifests as the worst kind of bug, or is solved with an inefficient solution such as garbage collection and instead results in a memory leak.
In rust, it is a compile time check with a hard error rather than a warning to force the consideration of the allocation's lifetime on the programmer and to force an explicit notated extension of the bounds of that lifetime beyond the scope-bound ownership defaults.
This is the "restrictiveness" and "friction" that gets mentioned over and over again in relation to learning rust. If you were already considering these things in your software which if you are writing in a compiled systems language you should be, this a very easy action to do and the benefit is you know when a change violates that boundary immediately rather than years later through an obscure bug report that is hard to reproduce and trace back to the offending code. If you have spent years working on software written in C++, you know just how fantastic this really is and how much time and effort this saves.
Take a look at: https://rust-unofficial.github.io/too-many-lists/

Someone wrote a book about how to implement linked lists in Rust. I rest my case.
This book is a tool to learn the ownership, borrowing and lifetime rules in the context of a familiar data structure, it isn't to show you how you are supposed to write a linked list and shouldn't be used as an example for how you should implement one. Unfortunately, troons can't help themselves and put their gay retard opinions about why linked lists are so hecking bad.
I wrote one for NiggerLisp last year and I didn't mention it because I didn't think it was that notable of a data structure to implement in rust. I still don't think it is, the parse tree is way more interesting.
Anything that doesn't fit neatly in their gay little paradigm suddenly gets labeled as unsafe, hated vehemently, and quickly shouted down en masse as a cardinal sin of a shitty programmer. They always think they know better.
Ironically, it is the tranny that has the most binary and extreme opinions in all domains of life, the things they state in their faggot blogposts are not reality, it is just their stupid opinion and should only be observed from a distance. I didn't think tranny blogposts did so much damage, I wrongly assumed that people extract the interesting parts and discard the retardation. That doesn't mean there isn't some wisdom behind some things that the tranny themselves don't understand. For them it's a cult, it makes up their whole narcissistic identity, so of course violations of the sanctity of memory safety are hated. It's unhinged.
I'm honestly half tempted to look into Rust properly just to write a "Rust for C/C++ programmers" that's actually tolerable...
I learned it to shit on it in online discussions to own the shills with my superior C and C++ skills, and it pains me to like it and use it for most things despite the poisonous faggotry surrounding it online. I find myself embarrassed whenever some gay shit happens with rust because it is treated as a monolithic entity that contains everything to do with it ever including people who just use it because it's good. It would be so much easier to switch to something else and avoid the online faggotry entirely, but I don't because it's that good on its own.
If you want some help with that book/guide/whatever, I'd gladly contribute.
 
If you have spent years working on software written in C++, you know just how fantastic this really is and how much time and effort this saves.
Or, if you have actually spent years working on software in C or C++, you know how to manage lifetimes better than the borrow checker. It's a tool that relies on many simplifying assumptions that get forced on you as constraints. Hence why you basically can't write a doubly-linked data structure in Rust without using "unsafe." A good way to think about the Rust borrow checker is that it is a sort of compile-time garbage collector. Like every static compile-time tool, it needs everything it operates on to be fully determined at compile time.

Doubly-linked lists are a notoriously hard problem for GCs (definitely not solvable at compile time), so the borrow checker bans them and the community of Rust shills screams "they aren't that useful anyway" (intrusive doubly-linked lists are one of the most common structures in OS kernels and are very helpful for certain types of async code).

Unlike you might be thinking, I have no problem getting the compile-time GC to accept my code. It is extremely easy to do if you just avoid doing anything clever with data structures. However, the cleverness that you have to wrap in "unsafe" does help your performance, and things like intrusive doubly-linked lists are not, in fact, unsafe in any way. They just can't be GC-ed at compile time.

No offense, but the people I have met who shill the borrow checker the hardest are the ones who either have comparatively little experience with either C or C++ and aren't good at dealing with manual memory management. They get on their high horse about how easy it should be to get your code to compile (exactly as you did) if you are an experienced C programmer. However, if you are an experienced C programmer, you understand that the approach you are forced to use is not the best one.

Experienced C programmers I know who like Rust like it because you can make a generic B-tree without a garbage collector and without C++. In other words, they like that it's more expressive than C but also not C++. The borrow checker is a side thing.
 
Last edited:
Is it because the references are cyclical?
Fundamentally, it's because there's nothing in the code that guarantees that there's no dangling cycle of objects. For most GCs, back pointers aren't a problem but linked lists that become a cycle sort of are a problem. Rust has a more extreme version of this problem because it forces ownership to be a DAG (making anything with a back pointer a problem) to do this statically.

Edit: I misspoke - it's more restrictive than a DAG. Rust ownership has to be a tree.
 
Last edited:
Fundamentally, it's because there's nothing in the code that guarantees that there's no dangling cycle of objects. For most GCs, back pointers aren't a problem but linked lists that become a cycle sort of are a problem. Rust has a more extreme version of this problem because it forces ownership to be a DAG (making anything with a back pointer a problem) to do this statically.
I think my first exposure to DAGs was in high school or maybe a bit after when I learned about topological sorting. It really is great to learn about an arcane mathematical topic that actually has a bunch of applications and is used behind the scenes all the time:
Screenshot 2025-02-08 at 21-20-59 Topological sorting - Wikipedia.png
 
Back