Hi Daniel, I would just like to mention a few things... CoreBase officially supports both GNUstep and GNU runtimes, so it is important that we do not break that. Additionally, clang/llvm and GCC are supported. A configure test will be required for objc_release/_retain/_autoreleaseReturnValue, and we need to make sure GCC and the GNU runtime are still working. Ideally, we also need tests added to the test suite.
Are these two functions only supposed to work when ARC is available? Or can they be used with GCC/GNU-runtime and manual ref. counting? If they have to work with GCC and manual ref. count, I assume CFBridgingRelease would be a no-op when the object is a CF-type and a ref. decrement when it is a objc object. Does that sound about right? I had some time to think about this a little today, so I think I understand what the purpose of these functions and how to implement them. I won't have a chance to even look at it until Monday, though. And even then, I will need to learn how to use git (which completely ignorant about). Stefan On Thu, Jun 1, 2017 at 9:46 PM, Daniel Ferreira (theiostream) < bnm...@gmail.com> wrote: > On Thu, Jun 1, 2017 at 2:29 PM, David Chisnall <thera...@sucs.org> wrote: > > On 1 Jun 2017, at 17:49, Daniel Ferreira (theiostream) <bnm...@gmail.com> > wrote: > > It absolutely should *NOT* decrement the reference count but not > deallocate the object if it reaches zero! > > Makes perfect sense. I think deep in my subconscious I meant > "reduce-refcount-to-zero-but-do-not-deallocate" as an autorelease > (we're releasing! and deallocating later! Although we are certainly > not playing with the refcount yet). Anyway, I'll leave this matter to > psychology and move on to implementing these functions on CoreBase. > > Thank you for the explanation! :) >
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
