reference-counting

问题 Take the below example: - (NSString *)pcen NS_RETURNS_RETAINED { return (__bridge_transfer NSString *)CFURLCreateStringByAddingPercentEscapes(NULL, (__bridge CFStringRef) self, NULL, (CFStringRef) @"!*'();:@&=+$,/?%#[]", kCFStringEncodingUTF8); } Is it correct to put the NS_RETURNS_RETAINED there? Another example: + (UIImage *)resizeImage:(UIImage *)img toSize:(CGSize)size NS_RETURNS_RETAINED { UIGraphicsBeginImageContextWithOptions(size, NO, 0.0); [img drawInRect:...]; UIImage *resizedImage

问题 I need a base class like TInterfacedObject but without reference counting (so a kind of TNonRefCountedInterfacedObject ). This actually is the nth time I need such a class and somehow I always end up writing (read: copy and pasting) my own again and again. I cannot believe that there is no "official" base class I can use. Is there a base class somewhere in the RTL implementing IInterface but without reference counting which I can derive my classes from? 回答1: In the unit Generics.Defaults

问题 In his Blog Herb Sutter writes [...] because incrementing the smart pointer reference count can usually be optimized to be the same as an ordinary increment in an optimized shared_ptr implementation — just an ordinary increment instruction, and no fences, in the generated code. However, the decrement must be an atomic decrement or equivalent, which generates special processor memory instructions that are more expensive in themselves, and that on top of that induce memory fence restrictions on

问题 I want to keep the smart behavior of std::shared_ptr . So is there a way to cast a shared void pointer to another type while without confusing the reference counting? I can't get the raw pointer and create a new shared pointer from it. 回答1: You can use the pointer casts from rob mayoff's answer; but be careful. It is easy to unintentionally trigger undefined behavior here: struct MyClass {}; void* rawPtr = new MyClass; shared_ptr<void> exampleVoid(rawPtr); // Undefined behavior; // calls

问题 The standard convention in the Python C-API is that functions do not steal references from input arguments (that are objects) return values and output arguments (that are objects) own a reference Most functions in the Python C-API follow this convention. However, there are some exceptions. I have come across the following: Functions that steal a reference from an input argument PyModule_AddObject Functions with return values or output arguments that borrow a reference PyErr_Occurred PyTuple

问题 I have the following code which uses both Rc and Box ; what is the difference between those? Which one is better? use std::rc::Rc; fn main() { let a = Box::new(1); let a1 = &a; let a2 = &a; let b = Rc::new(1); let b1 = b.clone(); let b2 = b.clone(); println!("{} {}", a1, a2); println!("{} {}", b1, b2); } playground link 回答1: Rc provides shared ownership so by default its contents can't be mutated, while Box provides exclusive ownership and thus mutation is allowed: use std::rc::Rc; fn main()

问题 I'm looking for an equivalent of LWARX and STWCX (as found on the PowerPC processors) or a way to implement similar functionality on the x86 platform. Also, where would be the best place to find out about such things (i.e. good articles/web sites/forums for lock/wait-free programing). Edit I think I might need to give more details as it is being assumed that I'm just looking for a CAS (compare and swap) operation. What I'm trying to do is implement a lock-free reference counting system with

问题 STL standard do not require from std::string to be refcounted. But in fact most of C++ implementations provide refcounted, copy-on-write strings, allowing you passing string by value as a primitive type. Also these implementations (at least g++) use atomic operations making these string lock-free and thread safe. Easy test shows copy-on-write semantics: #include <iostream> #include <string> using namespace std; void foo(string s) { cout<<(void*)s.c_str()<<endl; string ss=s; cout<<(void*)ss.c

问题 STL standard do not require from std::string to be refcounted. But in fact most of C++ implementations provide refcounted, copy-on-write strings, allowing you passing string by value as a primitive type. Also these implementations (at least g++) use atomic operations making these string lock-free and thread safe. Easy test shows copy-on-write semantics: #include <iostream> #include <string> using namespace std; void foo(string s) { cout<<(void*)s.c_str()<<endl; string ss=s; cout<<(void*)ss.c

问题 Is it a bad idea to use the dot notation to initialize retain properties to nil in my init methods? With any ordinary property like this: @property (nonatomic, retain) id foo; Say in my init method I set self.foo = nil . The synthesized method first releases or autoreleases foo (not exactly sure of the underlying impementation). Is foo guaranted to be nil before the first setter or getter call? Or would it point to random garbage unless I explicitly set foo = nil without the dot notation? 回答1