4 ms·

if anyone is curious - http://hg.pidgin.im/pidgin/main/file/eb0eb02fce71/libpurple/value.c http://hg.pidgin.im/pidgin/main/file/eb0eb02fce71/libpurple/... tbh

if anyone is curious - http://hg.pidgin.im/pidgin/main/file/eb0eb02fce71/libpurple/value.c http://hg.pidgin.im/pidgin/main/file/eb0eb02fce71/libpurple/... tbh that's the first time i've seen something quite like that. i am not sure this is so common a pattern (usually, imho, you can be more explicit and have a struct that associates a known callback type with named, typed values).

jerf 14y ago
No, I wouldn't expect it is "common", but it definitely shows up. libpurple doesn't use it because it does its own thing, but glib has library support for it: http://developer.gnome.org/gobject/stable/chapter-signal.html#closure http://developer.gnome.org/gobject/stable/chapter-signal.htm... Although a straight-up Google search for "g_closure_invoke" is amusing. I did add the "as long as you can get the memory management right on it" for a reason... page after page after page of "segmentation fault in g_closure_invoke" stack traces....
- asveikau 14y ago
  I'm not sure why "getting the memory management right" is the hard part, or why it's any more or less hard than general C programming practice. For example a closure object with a reference count that releases references on its contained objects when destroyed seems like a perfectly workable pattern. (I'd be surprised if that's not how the glib closures are supposed to work, knowing that glib like many general-purpose C libraries is pretty big on reference counting.) NSInvocation in objc comes to mind, where IIRC the closure-like object can hold a reference to its arguments, though it's been years since I've used that...
  - pi18n 14y ago
    I think if you have objects and a reference-counting GC already this problem is pretty easy, but I assume the C programmers don't want that for performance or portability or some other reason. NSInvocation has a signature of the variable types of the method it represents, so it can retain the object ones without trying to retain plain integers. Modern Obj-C uses blocks to make closures, which the compiler changes into structs holding all the variables referenced. It knows the types of these as well, so it writes code to retain any object types and releases them as it is released. They haven't got a cycle collector in the runtime, so programmers still make mistakes by accidentally making strong cyclic references. Assuming the reference-counting GC, it's not hard, but you can still make mistakes.
    - asveikau 14y ago
      > I think if you have objects and a reference-counting GC already this problem is pretty easy, but I assume the C programmers don't want that for performance or portability or some other reason. Uh. Every large C code base I've worked with has had this in some form, usually fairly pervasively. I've mentioned glib as a library that exercises this heavily. In the Windows world this would also include COM. Kernel mode stuff on various platforms tends to do a lot of refcounting as well. Note that "reference counted object" is just a fancy word for "struct with an integer" - I feel like your phrases like "if you have objects" and "GC" strikes me as confusing this with other features in other languages, a sign that we're not entirely talking about the same thing. Edit after more time spent away from it: I guess to restate the original comment, what I was trying to say is that to an experienced C programmer closures don't make anything "more hard" - it's just the same memory allocation strategies that you'll be dealing with anyway, and there are already well understood solutions (such as having one of your struct fields be a reference count).
      - pi18n 14y ago
        I understand. I think you are right that it wouldn't make things more hard, I misunderstood that as implying that people wouldn't make memory mistakes under those conditions. So I was writing that one would require a GC to eliminate those kinds of mistakes. I agree with you, reference counting is not something that would confuse an experienced programmer, but you do have to be aware of what's happening with your objects.

jerf 14y ago

No, I wouldn't expect it is "common", but it definitely shows up. libpurple doesn't use it because it does its own thing, but glib has library support for it: http://developer.gnome.org/gobject/stable/chapter-signal.html#closure http://developer.gnome.org/gobject/stable/chapter-signal.htm... Although a straight-up Google search for "g_closure_invoke" is amusing. I did add the "as long as you can get the memory management right on it" for a reason... page after page after page of "segmentation fault in g_closure_invoke" stack traces....

asveikau 14y ago
I'm not sure why "getting the memory management right" is the hard part, or why it's any more or less hard than general C programming practice. For example a closure object with a reference count that releases references on its contained objects when destroyed seems like a perfectly workable pattern. (I'd be surprised if that's not how the glib closures are supposed to work, knowing that glib like many general-purpose C libraries is pretty big on reference counting.) NSInvocation in objc comes to mind, where IIRC the closure-like object can hold a reference to its arguments, though it's been years since I've used that...
- pi18n 14y ago
  I think if you have objects and a reference-counting GC already this problem is pretty easy, but I assume the C programmers don't want that for performance or portability or some other reason. NSInvocation has a signature of the variable types of the method it represents, so it can retain the object ones without trying to retain plain integers. Modern Obj-C uses blocks to make closures, which the compiler changes into structs holding all the variables referenced. It knows the types of these as well, so it writes code to retain any object types and releases them as it is released. They haven't got a cycle collector in the runtime, so programmers still make mistakes by accidentally making strong cyclic references. Assuming the reference-counting GC, it's not hard, but you can still make mistakes.
  - asveikau 14y ago
    > I think if you have objects and a reference-counting GC already this problem is pretty easy, but I assume the C programmers don't want that for performance or portability or some other reason. Uh. Every large C code base I've worked with has had this in some form, usually fairly pervasively. I've mentioned glib as a library that exercises this heavily. In the Windows world this would also include COM. Kernel mode stuff on various platforms tends to do a lot of refcounting as well. Note that "reference counted object" is just a fancy word for "struct with an integer" - I feel like your phrases like "if you have objects" and "GC" strikes me as confusing this with other features in other languages, a sign that we're not entirely talking about the same thing. Edit after more time spent away from it: I guess to restate the original comment, what I was trying to say is that to an experienced C programmer closures don't make anything "more hard" - it's just the same memory allocation strategies that you'll be dealing with anyway, and there are already well understood solutions (such as having one of your struct fields be a reference count).
    - pi18n 14y ago
      I understand. I think you are right that it wouldn't make things more hard, I misunderstood that as implying that people wouldn't make memory mistakes under those conditions. So I was writing that one would require a GC to eliminate those kinds of mistakes. I agree with you, reference counting is not something that would confuse an experienced programmer, but you do have to be aware of what's happening with your objects.