|
tyrelhill posted:// TODO: Autogenerated stub. I never bother to delete those in my personal projects. It's an annoyance to interrupt what I'm doing to do so, and by the time I remember I might want to clean them up there's too many and I don't care. I'd probably put more care into it if it was code I was writing professionally though.
|
#
?
Mar 3, 2015 16:46
|
|
|
|
| # ? Jun 7, 2024 14:32 |
|
|
Dicky B posted:At the top of an uncommented cmake file which defines macros for generating a bunch of cpp files from a directory of xml inputs
|
|
#
?
Mar 3, 2015 16:50
|
|
|
LeftistMuslimObama posted:I'd probably put more care into it if it was code I was writing professionally though. Probably! e: maybe consider getting some practice refactoring/cleaning code now, as it's a skill like any other
|
|
#
?
Mar 3, 2015 17:28
|
|
|
Bonfire Lit posted:that's a perfectly good comment for the top of a cmake file though
|
|
#
?
Mar 3, 2015 17:56
|
|
|
Bonfire Lit posted:that's a perfectly good comment for the top of a cmake file though Only if you are a scrub and can't figure out cmake. 
|
|
#
?
Mar 3, 2015 18:10
|
|
|
JawnV6 posted:Probably! Oh, I do it all the time in irl code. It's just stuff that I'm handing in for school that's just being run through an autograder anyway I just can't make myself give a gently caress about good comments and removing IDE-generated stuff. The instructor's not gonna look at my source, so why worry about it?
|
|
#
?
Mar 3, 2015 18:45
|
|
|
Are auto graders mostly problem free for you? When I was a tutor/grader I wished we'd had auto graders just so I could have something to start with instead of compiling and running every project individually, but the few times I was in a class with one, it seemed like 1 out of 4 submissions would break the drat grader.
|
|
#
?
Mar 3, 2015 18:48
|
|
|
ratbert90 posted:Only if you are a scrub and can't figure out cmake. No you see that's what *nix users like to call a "hash bang", which instructs the program loader what binary and options should be used to evaluate the rest of the file. That one is RFC standard code for "cmake".
|
|
#
?
Mar 3, 2015 19:09
|
|
|
carry on then posted:Are auto graders mostly problem free for you? When I was a tutor/grader I wished we'd had auto graders just so I could have something to start with instead of compiling and running every project individually, but the few times I was in a class with one, it seemed like 1 out of 4 submissions would break the drat grader. Well, functionally they seem to work fine, though they seem to cause the instructors to grade for really arbitrary bullshit that I disagree with. Practically everyone in the class got knocked down 20% on the first project because we didn't call free() before ending the program, despite the fact that the program's flow is basically: 1-Malloc variable 2-Do a bunch of poo poo with that variable 3-Program ends In such a case, the call to free() is extraneous, and nothing in the project description stated that they would be checking for it. Regardless, that's what they put in the autograder and when people protested they basically said "that's what we decided and that's what's in the grader, tough dice". One of the upsides, though, is that they release an early version of the autograder about 3 days before the due date that has 70% of the tests they'll run in it. It lets us confirm our code at least mostly works and is headed in the right direction. The horror is, like I said, them frequently grading us on things they don't mention in the lecture or the project descriptions because they feel that something is the correct practice. If it's the correct practice, teach it to us first!
|
|
#
?
Mar 3, 2015 20:06
|
|
|
Bonfire Lit posted:that's a perfectly good comment for the top of a cmake file though I haven't been using cmake all that long, but it's so so so much better than writing makefiles by hand.
|
|
#
?
Mar 3, 2015 20:53
|
|
|
LeftistMuslimObama posted:The horror is, like I said, them frequently grading us on things they don't mention I liked to think of this as early practice for working with clients.
|
|
#
?
Mar 3, 2015 21:10
|
|
|
Your code not calling free() is like kinda like not putting your name on your exam because the teacher saw you take it.
|
|
#
?
Mar 4, 2015 02:13
|
|
|
LeftistMuslimObama posted:Well, functionally they seem to work fine, though they seem to cause the instructors to grade for really arbitrary bullshit that I disagree with. You should still call free.
|
|
#
?
Mar 4, 2015 02:33
|
|
|
nm
|
|
#
?
Mar 4, 2015 02:58
|
|
|
evensevenone posted:Your code not calling free() is like kinda like not putting your name on your exam because the teacher saw you take it. That's strange, because our textbook explicitly says it's not necessary right before an exit() because the os will reclaim all the memory you've been allocated anyway and there's no risk of memory leak because your program is done executing. I'm open to that being wrong, it's just frustrating to read one thing and then get dinged for it on my grade.
|
|
#
?
Mar 4, 2015 03:46
|
|
|
LeftistMuslimObama posted:That's strange, because our textbook explicitly says it's not necessary right before an exit() because the os will reclaim all the memory you've been allocated anyway and there's no risk of memory leak because your program is done executing. I'm open to that being wrong, it's just frustrating to read one thing and then get dinged for it on my grade. If you're uncertain about what they want, get them to tell you. Don't leave your grade to chance if you can help it.
|
|
#
?
Mar 4, 2015 04:02
|
|
|
I think it's fair to expect that, if the textbook says something isn't needed, it won't be needed in an assignment.
|
|
#
?
Mar 4, 2015 04:09
|
|
|
So the problem with not calling free() for a class assignment is that ostensibly they are trying to teach you a general programming concept. You are correct that an OS can, and often does, manage memory the way that you're talking about. There are other situations you might be programming in in the future where that does not hold true, though, and so it's generally a good idea to learn responsible memory management habits. If you're not getting this info from your textbook or your prof prior to the assignment, though, then that's real lovely. You should probably write that in your review of the course when it finishes. ErIog fucked around with this message at 04:15 on Mar 4, 2015 |
|
#
?
Mar 4, 2015 04:13
|
|
|
Explicitly freeing memory immediately before exiting is actively detrimental and is how you get applications that grind your HD for ten minutes when you ask them to exit, but school assignments are generally not actually about writing the most appropriate solution to the given problem. Outside of the most trivial things, correct memory management that doesn't explicitly free everything on exit tends to be more complex than freeing everything, and school assignments are usually trivial problems that are trying to teach you how to do less trivial things.
Plorkyeran fucked around with this message at 04:38 on Mar 4, 2015 |
|
#
?
Mar 4, 2015 04:35
|
|
|
ErIog posted:So the problem with not calling free() for a class assignment is that ostensibly they are trying to teach you a general programming concept. You are correct that an OS can, and often does, manage memory the way that you're talking about. There are other situations you might be programming in in the future where that does not hold true, though, and so it's generally a good idea to learn responsible memory management habits. I definitely plan on mentioning it in my review of the course. It's fair to expect us to do "pro forma " stuff like that, just not if you teach us the opposite or we have no way of knowing other than reading the instructor's mind. I said as much to him I person, but he just kinda ran away. Actually he literally just said he was sorry I was upset and booked it out of the room. It's kinda a downside of being a 6'4" weightlifter in an industry that is mostly small, introverted people. They tend to take feedback from me as aggression no matter how nice I am about it. He didn't actually explain their reasoning for the grade until the next day via email.
|
|
#
?
Mar 4, 2015 04:51
|
|
|
LeftistMuslimObama posted:That's strange, because our textbook explicitly says it's not necessary right before an exit() because the os will reclaim all the memory you've been allocated anyway and there's no risk of memory leak because your program is done executing. I'm open to that being wrong, it's just frustrating to read one thing and then get dinged for it on my grade. Call free() before exiting - it makes it easier for debuggers like Valgrind to find real memory leaks. It's not like free() is expensive. By the way (and now I'm getting a bit off-topic), this is one reason why I think it is a bad idea to base course grades on every bit of coursework, as it inhibits the use of assignments as pedagogical tools. One of the best ways to learn is to do something with the expectation that you'll get minor things wrong, then be told what is wrong (like this free() thing), why, how to fix it, and then have to do it and hand it back in. If an assignment is going to be used for grading you have to be much more clear about expectations, and you cannot use resubmissions as a pedagogical tool. Well, you can, but you lose a good bit of the already meagre information content contained in a grade.
|
|
#
?
Mar 4, 2015 08:09
|
|
|
Athas posted:Call free() before exiting - it makes it easier for debuggers like Valgrind to find real memory leaks. It's not like free() is expensive. Uhhhh this is laughably wrong. There's no magic flag to make malloc leave the free blocks list in disarray; book-keeping will be done. You might even be forcing useless memory pages to be swapped back into RAM just to get freed. Not to mention destructors for many languages like C++, Swift, etc rearranging the deck chairs right before the process sinks below the waves. All modern operating systems completely reclaim all memory when a process dies, along with local locks, file handles, etc.
|
|
#
?
Mar 4, 2015 08:32
|
|
|
Seriously you should be calling free() unless you explicitly have a reason not to. Plorky's example is basically an edge case for a student assignment. If the material didn't mention that you have to free memory you malloc, then that's a fuckup. If it's a situation where 1/10 of the people who didn't free the memory actually knew the OS would do it for them, then the autograder is honestly correct. The cleverest programmer in a codebase is the one defensively coding for everyone else.
|
|
#
?
Mar 4, 2015 08:34
|
|
|
Ender.uNF posted:Uhhhh this is laughably wrong. Au contraire, one who is laughably wrong. You don't ensure that your lifecycles are complete to avoid leaking beyond the termination of the app(*), but so that you don't have false positives when analyzing for real leaks. To say nothing of leaving traps for future refactoring. (*) not all operating systems are that advanced especially in embedded context, you can leak past process termination when in the kernel, and not all program resources are necessarily cleared up at shutdown. SysV shared memory is an example of the lattermost.
|
|
#
?
Mar 4, 2015 08:41
|
|
|
Ender.uNF posted:Uhhhh this is laughably wrong. There's no magic flag to make malloc leave the free blocks list in disarray; book-keeping will be done. You might even be forcing useless memory pages to be swapped back into RAM just to get freed. Not to mention destructors for many languages like C++, Swift, etc rearranging the deck chairs right before the process sinks below the waves. If the destructor does something nontrivial (like flushing a buffer), that's even more reason to make sure it gets run! And yeah, book-keeping will be done, but come on, the amount of memory that's going to be touched is fairly minor. Note that free() doesn't zero the deallocated blocks or anything like that. Is shutdown really on your critical path? Is it worth sacrificing ease of debuggability for? I don't have any hard data, but I suspect that memory leaks in C programs are a more common problem than slow shutdowns. If shutdown is on the critical path, roll your own slab allocator and seriously consider what you are doing with your life.
|
|
#
?
Mar 4, 2015 08:54
|
|
|
Subjunctive posted:Au contraire, one who is laughably wrong. You don't ensure that your lifecycles are complete to avoid leaking beyond the termination of the app(*), but so that you don't have false positives when analyzing for real leaks. To say nothing of leaving traps for future refactoring. I thought shared memory was tracked through ref-counted fds in the kernel, which are closed when the process is destroyed?
|
|
#
?
Mar 4, 2015 09:12
|
|
|
Suspicious Dish posted:I thought shared memory was tracked through ref-counted fds in the kernel, which are closed when the process is destroyed? Not necessarily, which is why ipcrm exists.
|
|
#
?
Mar 4, 2015 09:15
|
|
|
Oh jesus, that old SysV garbage. I didn't realize that Linux implemented that, much less POSIX specifying it
|
|
#
?
Mar 4, 2015 09:17
|
|
|
All of the IPC primitives (SysV and POSIX) will outlast a process.
|
|
#
?
Mar 4, 2015 09:43
|
|
|
What I'm getting here is that it's wrong of the lecturer to act like there's a firm right way in either direction, since it seems we can't even agree on it in here.
|
|
#
?
Mar 4, 2015 17:36
|
|
|
Unless it is important for some reason not to, always free. If it's important not to free for some reason, and you're sure it's safe, you can omit it, but you're unlikely to actually encounter such a case in your career.
|
|
#
?
Mar 4, 2015 17:38
|
|
|
LeftistMuslimObama posted:Practically everyone in the class got knocked down 20% on the first project because we didn't call free() before ending the program, So the program should definitely not leak memory between jobs/iterations if it's capable of processing multiple inputs, that's just indefensible. As for whether the program should free all dynamically allocated memory prior to a clean exit is more of a matter of style and/or circumstance, and you'll come across both in practice. Usually I try to write programs (that intend to terminate) so that they can run iteratively if provided with multiple inputs, even if I'm only providing a single input in the common case. As a consequence, I'll end up calling free on data structures allocated for each iteration, which usually results in all memory being opportunistically freed on clean exit. That's good style. Conversely, if freeing all one-off dynamic allocations on clean exit is cumbersome or requires significant amount of additional code, I wouldn't worry about it as it has little practical benefit. You're right, you don't have to call free and the OS will reclaim the memory anyways. The best reason to explicitly aim to free all dynamically allocated memory is, as others have mentioned, so that leak checkers like valgrind complain less, making it easier to find true memory leaks. However, keep in mind that there's plenty of ways for your program to terminate abnormally (bail out on error, getting signaled, forked children, etc.) in which it wouldn't make sense to free all outstanding memory allocations. In some cases, like signal handlers and while executing forked children, it may not even be safe to do so. In the abnormal case I generally try to invoke the simplest method of termination possible, including default signal handlers, or calling the GNU error/error_at_line functions which I've come to like on GNU systems. It's also true that you may, in some circumstances, be dealing with resources that the OS doesn't automatically deallocate for you, in which case you do have to take care to deallocate them in exceptional pathways wherever possible. Sometimes that might not even be safe, and the safest option is to leak resources, but that's a decision that has to be made after a solid analysis of the circumstances. But that's not a problem with malloced userspace memory on modern Unix systems, and so it's simply not worth doing that analysis. The situation is different when writing library code, or kernel code, or writing code for MMU-less systems running tiny OSes, but all of those are completely out of scope for this project. ExcessBLarg! fucked around with this message at 18:02 on Mar 4, 2015 |
|
#
?
Mar 4, 2015 17:48
|
|
|
LeftistMuslimObama posted:What I'm getting here is that it's wrong of the lecturer to act like there's a firm right way in either direction, since it seems we can't even agree on it in here. Occasionally you'll come across a lecturer that went back to academia after 10+ years in the trenches. Those are the ones worth paying attention to. ExcessBLarg! fucked around with this message at 18:08 on Mar 4, 2015 |
|
#
?
Mar 4, 2015 17:56
|
|
|
ExcessBLarg! posted:
If only  . This guy just finished the first year of his Master's in India and transferred here. I don't think he's even completed a course at this school yet.
|
|
#
?
Mar 4, 2015 18:11
|
|
|
LeftistMuslimObama posted:If only
|
|
#
?
Mar 4, 2015 18:13
|
|
|
LeftistMuslimObama posted:It's kinda a downside of being a 6'4" weightlifter in an industry that is mostly small, introverted people. They tend to take feedback from me as aggression no matter how nice I am about it. Take a class/lecture from Dawson Engler.
|
|
#
?
Mar 4, 2015 18:18
|
|
|
Subjunctive posted:Au contraire, one who is laughably wrong. You don't ensure that your lifecycles are complete to avoid leaking beyond the termination of the app(*), but so that you don't have false positives when analyzing for real leaks. To say nothing of leaving traps for future refactoring. Apparently experts disagree! Who knew?  To be clear: I am saying that free() is not zero cost and I am assuming a full featured OS; embedded has many of its own rules. If using a C-based language, I would absolutely write it to be correct in calling free(), running destructors, etc for the reason you described. I just wouldn't rely on that for correctness. If the computer randomly reboots or I just abort I should be able to recover gracefully with minimal or no data loss. Athas posted:If the destructor does something nontrivial (like flushing a buffer), that's even more reason to make sure it gets run! And yeah, book-keeping will be done, but come on, the amount of memory that's going to be touched is fairly minor. Note that free() doesn't zero the deallocated blocks or anything like that. Uh huh. What happens when the computer loses power? Or the OS crashes? Or your process crashes? Or the user kills it? What happens to your precious destructors then? You should write things atomically, use FS and/or DB transactions if available, and persist undo information between launches so your process is resilient against failure. LeftistMuslimObama posted:What I'm getting here is that it's wrong of the lecturer to act like there's a firm right way in either direction, since it seems we can't even agree on it in here. Isn't that almost every post in this thread?
|
|
#
?
Mar 4, 2015 18:31
|
|
|
I would interpret the "leave freeing memory to the OS when you are quitting anyway" advice (which is good advice) as "call TerminateProcess() instead of unwinding all your stacks". You should still ensure that you clean up resources as your objects get destroyed and in your main() function, you simply do not have to do it all if you are really existing - tell the OS to kill the process and that's the end. But any code that just leaves memory dangling without explicitly going "Kill me, OS" I would consider highly suspect. Code is not only a tool of telling the machine what to do, it is a textual representation of ideas and if the ideas are imbalanced in resource management then comprehending the code will just make everyone feel queasy.
|
|
#
?
Mar 4, 2015 20:46
|
|
|
It's also just bad from a reuse/maintainability perspective. If you don't write (or at least plan) the code that frees memory when you write the code the allocates it, you are never going to be able to write it and get it right later on. So if you're writing code that you never plan to use again or adapt, I guess knock yourself out.
|
|
#
?
Mar 5, 2015 03:40
|
|
|
|
| # ? Jun 7, 2024 14:32 |
|
|
Plorkyeran posted:Explicitly freeing memory immediately before exiting is actively detrimental and is how you get applications that grind your HD for ten minutes when you ask them to exit
|
|
#
?
Mar 5, 2015 03:57
|
|
