raii

问题 It is often heard that in C++ temporary objects get deconstructed at the end of the full-expression . A full-expression is defined to be an expression that isn't a sub-expression of some other expression. This sounds very similar to the notion of a statement to me. So my questions are: If I append a semi-colon to a full-expression , will it always be a statement ? Can one arrive at every full-expression by taking some statement with a semi-colon at the end, and removing that semi-colon? Can I

问题 It is often heard that in C++ temporary objects get deconstructed at the end of the full-expression . A full-expression is defined to be an expression that isn't a sub-expression of some other expression. This sounds very similar to the notion of a statement to me. So my questions are: If I append a semi-colon to a full-expression , will it always be a statement ? Can one arrive at every full-expression by taking some statement with a semi-colon at the end, and removing that semi-colon? Can I

问题 fn main() { let k = "fire"; drop(k); println!("{:?}", k); } Playground Why am I still able to use k after dropping it? Does drop not deref a reference automatically? If yes, then why? What does the implementation of Drop look like for &str ? 回答1: What happens when I call std::mem::drop with a reference The reference itself is dropped. a reference instead of an owned value A reference is a value. Why am I still able to use k after dropping it? Because immutable pointers implement Copy . You

问题 Regular goto in C++ respects object lifetime - that is using goto to jump out of a block will run the destructors for the appropriate local variables. start: NonTrivial object; if (again()) goto start; // will call object.~NonTrivial() Is the same true when using the Labels as Values extension? start: NonTrivial object; goto *(again() ? &&start : &&end); end: GCC happily accepts this code, but seems to ignore any effect goto might have on object 's lifetime. clang complains. Look for calls to

问题 My understanding is that when you kill a C++ application through Task Manager in Windows XP, the application is still "cleanly" destructed - i.e. the call stack will unwind and all the relevant object destructors will be invoked. Not sure if my understanding is wrong here. Is it possible to kill such an application immediately, without unwinding the stack? For example, the application may employ RAII patterns which will destroy or release resources when an object is destructed. If the

问题 Being primarily a C++ developer the absence of RAII (Resource Acquisition Is Initialization) in Java and .NET has always bothered me. The fact that the onus of cleaning up is moved from the class writer to its consumer (by means of try finally or .NET's using construct) seems to be markedly inferior. I see why in Java there is no support for RAII since all objects are located on the heap and the garbage collector inherently doesn't support deterministic destruction, but in .NET with the

问题 I've read What are non-lexical lifetimes?. With the non-lexical borrow checker, the following code compiles: fn main() { let mut scores = vec![1, 2, 3]; let score = &scores[0]; // borrows `scores`, but never used // its lifetime can end here scores.push(4); // borrows `scores` mutably, and succeeds } It seems reasonable in the case above, but when it comes to a mutex lock, we don't want it to be released prematurely. In the following code, I would like to lock a shared structure first and

问题 I have a class that represents a data stream, it basically reads or writes into a file, but first the data are being encrypted/decrypted and there is also an underlying codec object that handles the media being accessed. I'm trying to write this class in a RAII way and I'd like a clean, nice, usable design. What bothers me is that right now there is a lot of work being done in the constructor. Before the object's I/O routines can be safely used, first of all the codec needs to initialized

问题 I'm trying to design a class that needs to dynamically allocate some memory.. I had planned to allocate the memory it needs during construction, but how do I handle failed memory allocations? Should I throw an exception? I read somewhere that exceptions should only be used for "exceptional" cases, and running out of memory doesn't seem like an exceptional case to me.. Should I allocate memory in a separate initialization routine instead and check for failures and then destroy the class

问题 My code contains snippets like these: std::va_list ap; va_start(ap, msgfmt); snprintf_buf buf; const tchar * msg = buf.print_va_list(msgfmt, ap); va_end(ap); These are short and va_start() and va_end() are close together so they are not much of a problem. Exceptions from calls in between the two could be a problem (or not?). Simple test shows that calling va_start() from a function without ellipsis is not allowed. Is calling va_end() from a different function than va_start() was called from