I liked this gauss bell meme.
>>108476537what is gc?
>>108476565Garbage collection>>108476537Well it just feels good starting a C++ web server and watching the memory indicator on lxqt panel not change by a single pixel.
>>108476537Nocoder, why can't you judt read through your code and see where it's alocating memory and where it's releasing it and see if everything matches up?
>>108476664It can be done but different objects may have diferente lifetimes, for some kind of programs it's a waste of time.
>>108476537Garbage collection is great in most use cases yes.
>>108476725Me on the left.
>>108476537I'm not that experienced I've only done a few simple programs, but even using C you are often relying on external libraries which handle memory management right? I have done in the things I've made at least. How often do you actually have total control over every byte of memory? Of course when using external libraries you can at least go an look at them and see exactly how they handle it, but who would bother unless there is an issue?
>>108476730I don't even use git lmao I just make the program work and if it don't work I fix it. Why would I want to see the older version that I already improved? If I tried to improve something and failed then I still need to improve more for it to be useful anyway.
>>108476537
>>108476730me too. no collaborators, no branches
>>108476537Believing in a 3 state bell curve is ironically peak midwit, there will be opposing views in the inbetween and some more on the extremes
>>108476806It's for when you fuck something up in the future and forget what it was doing.
I remember this one from some government software where they hardcoded a progress bar.
>>108476537They hated him, for the told them the truth.
>>108476537I think that for a very efficient section of a program (that runs a lot), having manual control is great. I don't think it's ideal for large projects.But I am not a very experienced coder.
Any faggot that thinks he's better than GC in 2026 doesn't know how to program.
>>108476725>svn commit -m ""
>>108480254Agree
>>108476725When things go sideways I git diff stuff out into patches, make a new branch, git apply, then commit and push that. Trying to get too clever with git commands will just blow up your repo.
>>108476537>>108478096The GC vs manual memory management debate is asking the wrong question.It should be heap or nor heap. My answer is that the heap is for operations on strings or documents (xml/html/json etc) not for your core program objects which should be managed in an arena. >But my core program object *is* a DOMAnd that's why people hate using your software.
>>108477626The other day a coworker showed me how they hardcoded overloaded functions in C++ for our internal printf for logging. A sane person would use a variadic template type. When ever these people need more parameters they go into the class, copy-paste the last one (currently 17 parameters IIRC) and add another polymorphic parameter.
>>108476806rollback
>>108476537MASMNASMFASMSASM
>>108476725Nice. Very nice. Parsimonious, even, but I have a yet, more elegant solution, sir.gitadd() { git add "$1" git status}gitpush() { git commit -m "$1" git push}
gitadd() { git add "$1" git status}gitpush() { git commit -m "$1" git push}
So many outdated memes, I use AI period.
>>108476664Because there are times where it's so complicated, you'd deserve a Field medal for doing it.Think about AAA games, they use textures, and a texture needs to be loaded into memory (VRAM, but not going to be too specific). But there are too many texture to possibly fit into memory, so they load textures progressively as the objects using them pop up on your screen.This is easy to manage, as soon as no object uses a texture (this is called reference counting), the texture can be removed from memory.The issue, is that if you load many objects at once, e.g at a level change, you'll get a long loading time. You'll see a loading screen, or whatever pixel soup unreal engine likes to serve.To fix this, they prefetch textures before you actually need them. That already requires a fair bit of logic to determine in advance which textures you'll need.Then, they don't drop the textures as soon as they're no longer needed, instead they wait some time before removing them. This is because you may just go back to a previous area that would require the textures again.In theory, it's possible to find where exactly it's safe to remove a texture from memory, but in practice, it's nearly impossible. That's why we let algorithm and heuristics decide when to load/drop textures in memory.The same applies to all complex software. Even ones written in languages with 'manual memory management', like blender, krita, autocad. The scene you work with is just too big to fit in memory, and it's impossible for the devs to know in advance what can be discarded from memory at which point, so they use some sort of GC to do it.
>>108476806>i'm unemployed
>>108476537my iq is 154 and I don't >just use gcjust use gc
>>108480355variadic templates are just a hard filter of c++.I know great c++ devs that have no ideas of what they're doing when they work with variadic templates. They recently discovered that template<T> void(T val) could mean int val, int &val, int &&val etc..So I don't expect them to know about std::forward, if they can even use std::move then it's already great
>>108481442use case for textures?
>>108480340>arena>look at malloc/similar>it's an arena allocator>mfw
>>108481467They're called Tensor™ now
>>108476565gaming controller
