programming reactions

So basically you were unbelievably shit at manual memory management and should really be using a garbage collected language because you don't know what the fuck you're doing.

It's incredibly easy anon. I don't see how you fuck it up.

>>58934628
>i don't understand how someone can screw up at managing memory while i can do it fine in my fizzbuzz, UGH

>>58934665
If you 'placed the free function' somewhere you're clearly way off.

Malloc is not a good management system.

File: smugjak.png (129KB, 724x611px) Image search: [Google]

129KB, 724x611px

>the face /g/ makes when someone feels the need to congratulate themselves so desperately they post on an anonymous image board fishing for compliments

>>58935171
>that face when someone is so entitled he has to post his face
You are nothing but a virgin neckbeard.

File: 1479232378905.jpg (150KB, 600x450px) Image search: [Google]

150KB, 600x450px

>>58934571
>the face when you think not freeing dynamically allocated resources is a compile time error

File: 1480892488609.jpg (76KB, 640x854px) Image search: [Google]

76KB, 640x854px

>>58934571

File: what.jpg (7KB, 261x188px) Image search: [Google]

7KB, 261x188px

>>58934571
>tfw my code segfaulted when run normally, but worked fine when I ran it with valgrind and gdb, with no leaks, nothing.

I still didn't find the error. Oh well, I lost the source anyway, so who cares.

File: beyond-babby.jpg (16KB, 480x360px) Image search: [Google]

16KB, 480x360px

>>58935976
>I lost the source anyway

>>58935976
Sounds like UB to me, just needed to run a bunch of times with gdb and/or valgrind.

File: GuP.jpg (25KB, 480x360px) Image search: [Google]

25KB, 480x360px

>taking over project
>all comments in mix of Cyrillic and broken English
>some variables names too

File: normal reaction.png (87KB, 255x245px) Image search: [Google]

87KB, 255x245px

>>58936022
Well, it was broken, so I didn't upload it to GitHub or whatever, and it was lost when I nuked my disk.

>>58936023
I ran it like 50 times on valgrind before I gave up. It was a game, and running it on valgrind made it slow down so much it was unplayable. My computer at the time was a Pentium D also, so there's that.

>>58935547
This

>>58934571

no compiler would refuse to compile a memory leak

File: Babys first Warp travel.gif (2MB, 200x174px) Image search: [Google]

2MB, 200x174px

>code compiles flawlessly
>application passes acceptance tests on sample data run without any issue
>put application in real use

>>58934571
>code compiles without an error
how is that an achievement when you're debugging a memory leak?

>>58935976
printf debugging is probably the only thing that could save you there.
Unless you like looking at core dumps.

>>58936022
kek

>>58934628
t. python "programmer"

>mfw it works perfectly the first time
>mfw this is the only programming feel I have, the rest is shit
>mfw I have no face

>>58935547
retweet

>>58935976
I found that when run through the debugger my variables were initialized to 0 and null. When ran without debugger they were not. Caused frustration tracking down an error with a union used to hold memory addresses and integers as the debugger set the integers to 0 but live running allowed them to be junk data because 64 bit non initialized. Also, don't program high.

>after enabling a dozen type system extensions, you convince GHC that your code is valid
>realize it's probably a GHC bug and your program shouldn't be accepted

>>58937806

Your compiler should warning you about using variables before they were initialized. If your program compiles with warnings, it is probably incorrect.

File: 060.png (80KB, 500x475px) Image search: [Google]

80KB, 500x475px

>the face you make when valgrind tells you your "fix" is fucking atrocious and made everything worse