|
Well, not quite the same, a smart pointer/COM object/Objective C object the reference count directly controls object lifetime, but in the page cache the reference count controls whether the page is eligible for eviction. Similar basic principle, though.
|
# ? Aug 1, 2014 17:38 |
|
|
# ? Apr 27, 2024 16:08 |
|
pseudorandom name posted:Well, not quite the same, a smart pointer/COM object/Objective C object the reference count directly controls object lifetime, but in the page cache the reference count controls whether the page is eligible for eviction. Similar basic principle, though. Technically this isn't entirely true. In Objective-C, dealloc is only called synchronously* when the number of releases match the number of retains by convention - it's possible to cause releases on a background thread to trigger main thread deallocation. Doing so requires a slight tweak to reference counting, as you need to atomically observe a "is deallocating" bit. Deallocated (deallocating?) object resurrection is actually possible as well, though it's unconventional and very risky. * I assume this is the condition that needs to be met for "directly controls object lifetime" to be true EDIT: see the dealloc2main stuff in objc-internal.h Doctor w-rw-rw- fucked around with this message at 17:51 on Aug 1, 2014 |
# ? Aug 1, 2014 17:48 |
|
ohgodwhat posted:Googling his email address leads me to believe that all he does is go around and submit unwanted and bad patches without any sort of testing. I can't decide if it's an over enthusiastic ten year old or someone with a mental illness. And misunderstanding compiler options http://www.linuxquestions.org/quest...5770/page2.html E: or maybe he just doesn't get how computers work - could be either one
|
# ? Aug 1, 2014 18:08 |
|
I love C, but pointers are my worst enemy. I was writing a game engine with a 60 FPS main loop and it kept crashing badly. Couldn't figure out what the hell was happening until I realized that I kept declaring a pointer for the background music 60 times a second and never destroyed it. Another one was when I wrote a graphics editor in 6502 Assembly language. My Save and Load routines kept crashing the computer and I couldn't figure out what the hell was going on. Turns on B0 and 80 look very much alike in a lovely font. Once I updated the CMP #$80 to CMP #$B0, my software worked just fine.
|
# ? Aug 1, 2014 18:52 |
|
Munkeymon posted:And misunderstanding compiler options http://www.linuxquestions.org/quest...5770/page2.html We've all done -j128 for the hell of it one time or another. Don't act like you haven't.
|
# ? Aug 1, 2014 18:57 |
|
Volmarias posted:We've all done -j128 for the hell of it one time or another. Don't act like you haven't. If you use distcc it's totally reasonable.
|
# ? Aug 1, 2014 19:01 |
|
Volmarias posted:We've all done -j128 for the hell of it one time or another. Don't act like you haven't. Sure, but I at least have enough self awareness to know that I shouldn't be a kernel contributor just because I figured out how to compile a linux
|
# ? Aug 1, 2014 19:55 |
|
tango alpha delta posted:Another one was when I wrote a graphics editor in 6502 Assembly language. My Save and Load routines kept crashing the computer and I couldn't figure out what the hell was going on. Turns on B0 and 80 look very much alike in a lovely font. Once I updated the CMP #$80 to CMP #$B0, my software worked just fine.
|
# ? Aug 1, 2014 20:24 |
|
Munkeymon posted:Sure, but I at least have enough self awareness to know that I shouldn't be a kernel contributor just because I figured out how to compile a linux Someone in the linked threads on the mailing list accused this person of simply trying to get their name in the commit log, but it seems like given the patience being shown, that could've happened ages ago. So I'm not really sure what this person's motive is.
|
# ? Aug 1, 2014 20:59 |
|
mjau posted:Write hex in lowercase. Problem solved (native assemblers on the c64 wouldn't even let you use uppercase ) I was using a Machine Language monitor (yeah, I'm a masochist) which would only display mnemonics in upper case.
|
# ? Aug 1, 2014 21:24 |
|
Volmarias posted:We've all done -j128 for the hell of it one time or another. Don't act like you haven't.
|
# ? Aug 1, 2014 22:06 |
|
pokeyman posted:Someone in the linked threads on the mailing list accused this person of simply trying to get their name in the commit log, but it seems like given the patience being shown, that could've happened ages ago. So I'm not really sure what this person's motive is. I first got my name in the Linux commit log (CREDITS at that point, I believe) by writing a pile of comments. Maybe that would be a better route for him.
|
# ? Aug 1, 2014 22:31 |
Subjunctive posted:I first got my name in the Linux commit log (CREDITS at that point, I believe) by writing a pile of comments. Maybe that would be a better route for him. But this guy is only a Google search away for a perspective employer to see that he is a complete rear end
|
|
# ? Aug 1, 2014 22:35 |
|
fletcher posted:But this guy is only a Google search away for a perspective employer to see that he is a complete rear end Yeah, he shows questionable judgment. I don't think that's in dispute at this point.
|
# ? Aug 1, 2014 22:49 |
|
At this point I really doubt he even knows what programming is, regardless of best practices, paradigms, or even languages. Maybe a vague idea of "I type on keyboard => thing happen", or actually it seems more like "a thing exists. any thing at all in the world, i myself am not even aware of what it is or its existence => i have apparently succeeded in every single one of my fully undefined goals - cum laude, even!"
|
# ? Aug 2, 2014 05:02 |
|
From here it looks like the thought process is "I'll just ignore every piece of feedback except that which directly and obviously concerns the code", which of course entirely misses the point of, well, actually doing any of it.
|
# ? Aug 2, 2014 06:32 |
|
Volmarias posted:We've all done -j128 for the hell of it one time or another. Don't act like you haven't. I've done make -j a few times thinking that it meant something like "parallelize up to a reasonable limit", only when I did that with the kernel did I realize that it's not actually limited.
|
# ? Aug 2, 2014 11:56 |
|
code:
Mandor fucked around with this message at 11:36 on Aug 4, 2014 |
# ? Aug 4, 2014 11:31 |
|
Mandor posted:I especially like that one comment, it really ties the entire thing together. It's even worse when you realize it's there because someone copy-pasted the algorithm for Easter from somewhere else, without attributing the source, so you have a potential copyright violation there.
|
# ? Aug 4, 2014 11:38 |
|
Easter is a coding horror.Skuto posted:It's even worse when you realize it's there because someone copy-pasted the algorithm for Easter from somewhere else, without attributing the source, so you have a potential copyright violation there. This algorithm seems to be from 1877. It's probably public domain?? qntm fucked around with this message at 11:43 on Aug 4, 2014 |
# ? Aug 4, 2014 11:40 |
|
qntm posted:This algorithm seems to be from 1877. It's probably public domain?? That's why I wrote "potential". If there'd been a link to the origin, you'd have known instantly.
|
# ? Aug 4, 2014 12:05 |
|
It's also buggy, isn't it? http://en.wikipedia.org/wiki/Computus#mediaviewer/File:Easter_Distribution.png Easter can be on the 31st of March.
|
# ? Aug 4, 2014 12:14 |
|
One of my co-workers is looking for a new job after being with the company for a single year. He is in a particularly lovely team, however, and I can see why he's leaving. Case in point: His managers told him to stop using 'shared_ptr' and to remove all references of it from his code with the reasoning that 'shared_ptr causes memory leaks'. Yes, because raw pointers and heap allocations don't cause memory leaks. No, it's the shared_ptrs you see, they're the REAL memory leakers! Sometimes I think I must've been really lucky to get put in a team where my manager isn't a fossilised relic from the 80s.
|
# ? Aug 4, 2014 15:28 |
|
qntm posted:Easter is a coding horror. Copyright is about the expression, not the idea. If I write an implementation of the Easter algorithm today, the copyright clock starts today. (It's not such a trivial algorithm that there's only one way to express it, IMO.)
|
# ? Aug 4, 2014 15:41 |
|
To be fair, if you're writing new code instead of wrangling smart pointers into existing code, you probably shouldn't be using shared_ptr.
|
# ? Aug 4, 2014 15:54 |
|
Jabor posted:To be fair, if you're writing new code instead of wrangling smart pointers into existing code, you probably shouldn't be using shared_ptr. I hope there's an implicit "because unique_ptr" exists on your post, but there are still lots of places where shared_ptr is a good choice.
|
# ? Aug 4, 2014 16:03 |
|
seiken posted:I hope there's an implicit "because unique_ptr" exists on your post, but there are still lots of places where shared_ptr is a good choice. Shared, reference counted pointers and auto/unique pointers aren't even close to the same thing let alone they solve similar problems. I think there's some idea that using shared_ptr means "you don't understand your object lifetimes so you suck". Personally I'll take shared_ptr as a good working convenience over having to do the latter and getting it wrong. And so did everyone who designed reference counted languages, I guess. (My own code seems to mostly use it when multiple threads are involved, because gently caress dealing with lifetime issues and thread shutdown orders)
|
# ? Aug 4, 2014 16:13 |
|
Shared and reference counted pointers are the same thing. That's how shared_ptr works. Anyway, no, you really should use unique_ptr any time your objects are obviously a tree.
|
# ? Aug 4, 2014 16:18 |
|
PIGEOTO posted:One of my co-workers is looking for a new job after being with the company for a single year. He is in a particularly lovely team, however, and I can see why he's leaving. Case in point: His managers told him to stop using 'shared_ptr' and to remove all references of it from his code with the reasoning that 'shared_ptr causes memory leaks'. Given that this is all I know about your coworker, I'm betting he was using them instead of properly thinking properly about object lifetimes. Maybe he also did cause memory leaks. Having circular points-to-a relationships is a bit of a smell on its own, too.
|
# ? Aug 4, 2014 16:40 |
|
seiken posted:Shared and reference counted pointers are the same thing. That's how shared_ptr works. I should've said "shared/reference counted pointers" I guess but I really didn't think someone would manage to read the obviously wrong meaning in that sentence. quote:Anyway, no, you really should use unique_ptr any time your objects are obviously a tree. Not sure what the structure of your objects has to do with figuring out ownership semantics?
|
# ? Aug 4, 2014 16:41 |
|
Skuto posted:Not sure what the structure of your objects has to do with figuring out ownership semantics? If you have a tree, then each node has exactly one reference to it, so you don't need to count them. The lifetime is bounded by that of its parent, and the automatic cascade of destruction triggered by the root or subtree-root suffices. When it starts to be a tree-with-exceptions ("let's share this one case to save space...") is when you start taking nips out of your bourbon flask during compiles and randomly keying cars in the parking lot.
|
# ? Aug 4, 2014 16:49 |
|
Subjunctive posted:When it starts to be a tree-with-exceptions ("let's share this one case to save space...") is when you start taking nips out of your bourbon flask during compiles and randomly keying cars in the parking lot. It's called a DAG.
|
# ? Aug 4, 2014 17:02 |
|
Thanks. I was thinking of the case with multiple threads, where the structure of the objects is a bit disconnected from the multiple ownership issue, and you don't necessarily want to scope thread lifetimes to object lifetimes.
|
# ? Aug 4, 2014 17:03 |
|
Zopotantor posted:It's called a DAG. If you're lucky, it is.
|
# ? Aug 4, 2014 17:05 |
|
shrughes posted:Given that this is all I know about your coworker, I'm betting he was using them instead of properly thinking properly about object lifetimes. Maybe he also did cause memory leaks. Having circular points-to-a relationships is a bit of a smell on its own, too. A manager outlawing all use of shared_ptr or any other kind of smart pointer mechanism is pretty bad. Yeah you can use them badly, but that's no reason to never use them at all. I probably wasn't clear enough that *_ptr classes are things their team aren't allowed to use, in any situation, despite having the ability to, because I guess they can cause a circular leak if someone uses them improperly.
|
# ? Aug 4, 2014 17:18 |
|
He banned unique_ptr?
|
# ? Aug 4, 2014 17:24 |
|
Well, if you construct a unique_ptr from some other raw pointer, and keep around the the other pointer and delete it later, you might get a double delete, so clearly this technology is too dangerous for the likes of man
seiken fucked around with this message at 17:30 on Aug 4, 2014 |
# ? Aug 4, 2014 17:26 |
|
std::make_unique
|
# ? Aug 4, 2014 18:25 |
|
Not quite the horror of C pointers (which is kind of a horror in itself) but I've been doing some client work that involves importing Purchase Orders from a large online marketplace. Tucked away in the documentation is:quote:NOTE: We >strongly< suggest you append MM/DD/YYYY to all PO Numbers originating from our system because we cannot guarantee that they will be unique. Sure, no big. Why would you even want unique PO numbers anyway?
|
# ? Aug 4, 2014 18:28 |
|
|
# ? Apr 27, 2024 16:08 |
|
This "*_ptr is haaaard, man" stuff is why most C++ people need to use Rust instead
|
# ? Aug 4, 2014 18:41 |