4 ms·
My first advisor would write code like this: std::vector<float*> myVec; myVec.resize(1024); for (int i = 0; i < 1024; ++i) myVec[i] = new float(0);
by thechao 3y ago
My first advisor would write code like this:
std::vector<float*> myVec;
myVec.resize(1024);
for (int i = 0; i < 1024; ++i) myVec[i] = new float(0);
There were no `delete`s or `free`s anywhere in the codebase. I asked him what he was thinking and his response was: (1) it's not a server, and I know there's enough room on the computer; and, (2) the OS will free all of the memory for me, anyways.
- Tommstein 3y agoThere's also the old story about how memory leaks on missiles don't matter as long as you're leaking slow enough to not run out of memory before they explode.
- thechao 3y agoI worked with a guy — he's long deceased — whose doctoral dissertation was for missile guidance systems back in the 60s. The title was something like "supersonic ballistic landing trajectories for light civilian aircraft"; since, obviously, he couldn't publish it as "... for ICBMs".
- arghnoname 3y agoHe was probably right. When I write small, short-lived programs I mind my memory because it's a muscle I need to retain and I don't want to pick up bad habits. For an academic writing a one-off program just to get something done, all manner of bad practice is if not desirable, at least acceptable.
- knallfrosch 3y agoMy economics-studying roommate had an optimization problem that required a lot of RAM. He had 32 GB (that was >10 years ago). His program crashed with an out of memory exception. He was rich enough to simply upgrade his system to 64 GB. To my CS eyes, this sounded weird. Turns out he was initializing arrays manually instead of in a loop, so the compiler didn't recognize possible optimizations in the program. I changed his program and it ran twice as fast in half the memory. But he had already fixed his problem without 2 years of studying CS. Software is about solving problems. Professors in particular have exams, staff, their own work, student requests, external mail and international collaboration to worry about. I bet that once the program stops working, he'll make a student fix the problem within 3 weeks. That's a fine approach and way better than learning C++ yourself.
- arghnoname 3y agoIt's a good example and I think it generalizes. For instance, I'm capable of some minor repairs for appliances, but if some problem seems to be contained in the PCB and I can just replace it for $50 (or whatever) I'll just do that. I don't own an oscilloscope and only barely know how to use it--so yes, I'm sure I've spent $50 when I could have just desoldered some 25 cent part, but it's far more costly for me to learn how to diagnose and fix these sorts of problems than to just buy my way out. I learned how to do one profession to a high standard and maybe aspects of some others to a lesser standard, but it's just smart to be mindful of how we want to spend our limited skill-development budget.
- jcul 3y agoThat is true, but then if you need to debug some memory usage or a memory leak, you have to wade through all the valgrind false positives due to people not bothering to clean up at the end of the program.
- vidarh 3y agoAbout 24 years ago I built a webmail service based on C++ cgi's. FastCGI existed, but that required perfect memory management. CGI let us do what your instructor did, and on one hand it saved us from dealing with leaks at all, and on the other it reduced the performance overhead of going for CGIs - much faster to deallocate the whole heap in one go. We'd manually deallocate particularly big allocations, but otherwise we knew the process would die within fractions of a second anyway, so the increased memory use was fairly limited. We served a couple of million users with that using servers with a combined capacity lower than my current desktop.
- actionfromafar 3y agoC++ with CGI is weirdly like a fast PHP with the same teardown/clean slate property.
- vidarh 3y agoIt got surprisingly fast actually. We also did things like statically link it which drove the overhead of restarting down further (when the dynamic linker is a measurable proportion of your total execution time....), and I really liked knowing we had a fully clean slate on every request. I mostly do Ruby these days, and the one thing I strongly dislike is the horribly slow startup...