With a bit of fiddeling you can use every kind of bracket to basically make function calls in c++
Here are the links to the snippets, all compile and run
Rust: https://godbolt.org/z/bM3d7bG14
You must log in or register to comment.
cpp and their operator overloads are also insane. It makes understanding cpp code impossible. A “+” could actually do something completely different or have insane side-effects. Truly superior language for spreading confusion.
Operator overloads is something that sounds like a good idea until you experience them firsthand. Just properly name your functions for fuck’s sake.
Operator overloading is awesome in a functional language. Haskell allows for a lot of creative stuff with operators, but since they can’t have side effects, must conform to predictable types, and have specific requirements they are somewhat understandable. Idris is also very ergonomic when it comes to operators.
C++ allowing a library to override the
+operator withsystem("rm -rf /")is a lot less awesome.Every time I use a language that doesn’t have operator overloading I wish I was using C++. It’s absolutely maddening to have to read and write things like “end.subtract(start)”.
Like all of the footguns in C++, it’s only a problem if the codebase uses it wrong. When used correctly (i.e. only when behaviours mimic built-in types, and without side effects), it helps makes code more readable
Don’t do what numpy does, which is to define * for two arrays. Without learning the library, you wouldn’t know whether this performs element-wise multiplication, matrix multiplication, dot product or cross product. Worse yet, it behaves differently to Python’s built-in * for lists (which is also bad), which concatenates N copies of the list
Clearly you’ve never had to read code like
entity.position = vector_algebra::vector2_add(entity.position, vector_algebra::vector2_scale(entity.velocity, dt));I prefer Java style:
entity.position = entity.position.add(entity.velocity.scale(dt));Not hard to read.
Honestly, I’m glad to have them, it can make a number of things simpler. For instance, a program I wrote had a number of duration fields that had to be stored in XML files and updated every once in a while. It was something that had to occur very often in the code: add a value to the duration, set that value in the XML data, and save the XML file. So I created a class that stored the date/time value and a pointer the XML element (it could be assumed that nothing else would be changing the value in the XML file and if it did, then that change should be overwritten) and overloaded the
+=operator (among others), so then all I needed was to create theDurationFieldobject, and then I could godurationFieldX += time2 - time1for instance. I could abstract all the logic away and make it very clear and easy to write. Could I have made it so that I have to todurationFieldX.add(time2 - time1)? Of course I could have. But IMO that variant is less neat and less readable.I’ll jump on your unpopular side. With a decent IDE you should be able to point/click and decode what any operator is doing in any context. If I have two vectors, or quaternions, and I want to operate on them, why should I be forced to pass them to a standard function instead of clearly seeing what I’m doing. If you can’t be bothered to know the types of your variables in a strongly typed language… IDK.
When I was an intern, I was tasked with writing a file converter for 3D geometry files. There was an official cpp library to read the source files, so I was using that to read the data, restructure and transform it as needed, then write it to the output file format. Near the end, I was having a problem where I was SURE that my math was correct for the transform coordinates, but the resulting file would load in the viewer with all the correct looking pieces but all in the wrong locations. The senior guy there helped me debug it since I wasn’t super familiar with cpp at the time, and we found that the library I was using had overloaded the multiply (*) operator specifically for the objects I was using it on, and it was actually multiplying and saving the result directly to the first variable used in the multiplication. I assume it was done for memory efficiency or something, but I had no idea it would behave that way, so I was accidentally changing the values of variables I didn’t intend to.
Example: I was doing something a = b * c, which caused the value of b to be changed (to b * c). Which screwed things up when I needed the original value of b later.
This is the type of shit that haunts me. Imagine overloading “>>” for piping and hiding threading behind that. The idea was to create an async pipe, but nowhere are you aware of async or threading or whatever was chosen. You look at the code and think “of it’s like piping to stdout” or whatever, only to find out that the method immediately returns.
Tracking down what the hell is happening with code that has such hidden side effects is a nightmare.
Are you still in the C++ world?
That is WILD lol. No, after that, I did a bunch of backend server apps for a few years mostly in C#, and then I got put onto some web app stuff after that. For better or worse. I do enjoy it and appreciate the abstraction, and I have found that I do love frontend dev a lot, but I do sometimes miss the lower level languages haha.
I talked to a frontender recently who said they had less pleasure writing frontend, because AI could make it look as good as they wanted in a fraction of the time. Has AI changed anything for you?
I was “encouraged” to use AI at work for frontend and while it output functional stuff, lifting the hood on the how, terrified me. 😅
Yeah, in my experience, it’s very hit or miss with frontend code architecture (I primarily work with React). And I am very particular about keeping code clean and maintainable, so that can be a challenge sometimes for sure. It’s not bad for smaller one-off tasks, but I still do a majority of my larger tasks by hand because I typically already know what I need and how to do it correctly.
Omg I have the best idea but I’m not writing any C++ so someone else will have to do it.
Overload + to work as - in either some super rare condition or randomly with a very low chance
Ship it
People have made
NULLto be a random number on a specific day. As a goodbye present :D
Yeah it’s like a knife, wildly superior to cut stuff up in the kitchen, but you can also like stick it in your eye (but why?).
Funny that you put rust as the “uses parenthesis for function calls”. When in rust you can use any bracket for macro invocations:
let v1 = vec!(1,2,3); let v2 = vec![1,2,3]; let v3 = vec!{1,2,3};These are valid and have the exact same meaning.
To be fair, with Rust macros anything goes. There was an example where someone demoed descriping rust structs and enums nested as xml with a macro to parse it.
That’s inside the macro though. Whatever you parse inside the macro is defined by the creator of the macro. The macro invocation itself is defined by the rust language.
Rust allows you to use any bracket because it doesn’t know what the macro is supposed to do.
Some macros work like functions:
println!("Hello world");Some macros work like array declarations:
let v = vec![1,2,3];And some macros work like a code scope:
select!{ a => myfunc(), b => my_other_func() }Since rust doesn’t know what your macro does, it just lets the user choose whatever the user sees more fitting for that specific macro invocation.
I always enjoy this one: https://crates.io/crates/inline-python
Apparently, Python’s syntax is almost entirely a subset of Rust’s syntax + a few keywords, so even though you have to pass valid Rust tokens into a macro, that’s good enough to write Python with just a few quirks.
That’s always funny to me. In a language that’s so particular about different syntax features, they let macros of all things have a little bit of arbitrariness.
Yeah, I always wonder, if it was an intentional decision or just some first draft that stayed in.
Because I do think, it’s kind of smart. Some macros make sense to call with either
()or{}, depending on if you pass a code snippet that’s multi-line or not.
So, you could come up with a complicated syntax to define which bracket types are acceptable, or you could just not bother. 🙃
Ehh, who needs functions anyways, you got one big one and thats your whole codebase.
Look at poor Haskell sobbing in the corner now.
I have honestly never seen parentheses called “round brackets” before. It totally makes sense, I have no idea why it’s not used more often.
“round brackets” sounds pretty hilarious
Weird opinion: I like square brackets, angle brackets are neat, curly braces range from neat to ok.
But I just don’t like the look of parentheses compared to the others. They especially look ugly and clunky when you need a bunch of them in a row, in a way that’s not true for the others.
I can’t think of a reason why I feel this way apart from the fact they tend to be very clunky in math too. They’re also the ugliest one when handwritten despite being the arguably simplest shape.
All that said it annoys me how parentheses are the most used bracket type in programming.
Only one of those is a function, get it right. () Call functions <> Specialize Templates, can be used to do compile time calls to things that behave like functions. [] Accesses elements {} Calls constructors, aka functions that do the initial setup.
Overloading these to do something else gets you in the naughty corner.
Edit: the implementation of the {} fuckery is no great. Just save the sum instead of all numbers.
No time for arguments, pipelines go brrrr
I haven’t kept up to date with C++ development in the last 16 years, I only recognize the first two of those four.
Yeah sameish, normal and template?
I asked the other day in another thread about hating on C++ what makes C++ so bad and never got an answer.
(best-syntax? '(lisp clojure)) ;; => trueYou can do most if not all of this in Perl if you’re twisted enough. Some hoop jumping may be required*, but I can think of ways to do something that looks like each of these.
*: The braces are especially tricky if warnings are turned on. I’d probably abuse the deprecated multidimensional syntax and
tiea hash to the actual function.
