raii

C++ Arrays and make_unique

由 落花浮王杯 提交于 2019-12-03 12:01:06
问题 As a follow up to this post I wonder how its implementation of make_unique plays with allocating function-temporary buffer arrays such as in the following code. f() { auto buf = new int[n]; // temporary buffer // use buf ... delete [] buf; } Can this be replaced with some call to make_unique and will the [] -version of delete be used then? 回答1: Here is another solution (in addition to Mike's): #include <type_traits> #include <utility> #include <memory> template <class T, class ...Args>

Managing objective-C objects with c++ std::unique_ptr<> or std::shared_ptr<>

由 。_饼干妹妹 提交于 2019-12-03 09:50:19
问题 Objective-C can be mixed with c++ to some extent and can be called to each other. But Objective-C objects still are more or less manually managed, and RAII idiom is entirely absent from the language. I wonder if it is possible to manage the lifetimes of Objective-C objects with c++ smart pointers. Specially now that both boost scoped_ptr and shared_ptr have been added to the C++11 standard 回答1: But Objective-C objects still are more or less manually managed, and RAII idiom is entirely absent

How to encapsulate a C API into RAII C++ classes?

由 穿精又带淫゛_ 提交于 2019-12-03 08:24:29
Given a C API to a library controlling sessions that owns items, what is the best design to encapsulate the C API into RAII C++ classes? The C API looks like: HANDLE OpenSession(STRING sessionID); void CloseSession(HANDLE hSession); HANDLE OpenItem(HANDLE hSession, STRING itemID); void CloseItem(HANDLE hItem); Plus other functions that are useful for one of these types (Session, or Item) and map directly to C++ member functions of the relevant object. But they are not needed here. My main interest is in the construction and destruction of these objects, using RAII to manage a correct opening

custom RAII C++ implementation for scoped mutex locks

由 你离开我真会死。 提交于 2019-12-03 08:21:56
问题 I cannot use boost or the latest std::thread library. The way to go is to create a custom implementation of a scoped mutex. In a few words when a class instance is create a mutex locks. Upon class destruction the mutex is unlocked. Any implementation available? I don't want to re-invent the wheel. I need to use pthreads. resource acquisition is initialization == “RAII” 回答1: Note This is an old answer. C++11 contains better helpers that are more platform independent: std::lock_guard std::mutex

Is shared ownership of objects a sign of bad design?

由 谁说胖子不能爱 提交于 2019-12-03 06:04:15
Background : When reading Dr. Stroustrup's papers and FAQs, I notice some strong "opinions" and great advices from legendary CS scientist and programmer. One of them is about shared_ptr in C++0x. He starts explaining about shared_ptr and how it represents shared ownership of the pointed object. At the last line, he says and I quote : . A shared_ptr represents shared ownership but shared ownership isn't my ideal: It is better if an object has a definite owner and a definite, predictable lifespan. My Question : To what extent does RAII substitute other design patterns like Garbage Collection? I

C++ RAII not working?

由 試著忘記壹切 提交于 2019-12-03 05:37:32
I'm just getting started with RAII in C++ and set up a little test case. Either my code is deeply confused, or RAII is not working! (I guess it is the former). If I run: #include <exception> #include <iostream> class A { public: A(int i) { i_ = i; std::cout << "A " << i_ << " constructed" << std::endl; } ~A() { std::cout << "A " << i_ << " destructed" << std::endl; } private: int i_; }; int main(void) { A a1(1); A a2(2); throw std::exception(); return 0; } with the exception commented out I get: A 1 constructed A 2 constructed A 2 destructed A 1 destructed as expected, but with the exception I

Why garbage collection when RAII is available?

由 你。 提交于 2019-12-03 05:26:18
问题 I hear talks of C++14 introducing a garbage collector in the C++ standard library itself. What is the rationale behind this feature? Isn't this the reason that RAII exists in C++? How will the presence of standard library garbage collector affect the RAII semantic? How does it matter to me(the programmer) or the way in which I write C++ programs? 回答1: Garbage collection and RAII are useful in different contexts. The presence of GC should not affect your use of RAII. Since RAII is well-known,

C++ Arrays and make_unique

由 徘徊边缘 提交于 2019-12-03 02:26:45
As a follow up to this post I wonder how its implementation of make_unique plays with allocating function-temporary buffer arrays such as in the following code. f() { auto buf = new int[n]; // temporary buffer // use buf ... delete [] buf; } Can this be replaced with some call to make_unique and will the [] -version of delete be used then? Here is another solution (in addition to Mike's): #include <type_traits> #include <utility> #include <memory> template <class T, class ...Args> typename std::enable_if < !std::is_array<T>::value, std::unique_ptr<T> >::type make_unique(Args&& ...args) {

RAII vs. exceptions

由 六眼飞鱼酱① 提交于 2019-12-03 01:50:51
问题 The more we use RAII in C++, the more we find ourselves with destructors that do non-trivial deallocation. Now, deallocation (finalization, however you want to call it) can fail, in which case exceptions are really the only way to let anybody upstairs know of our deallocation problem. But then again, throwing-destructors are a bad idea because of the possibility of exceptions being thrown during stack unwinding. std::uncaught_exception() lets you know when that happens, but not much more, so

Destructors not called when native (C++) exception propagates to CLR component

由 风流意气都作罢 提交于 2019-12-03 01:13:33
We have a large body of native C++ code, compliled into DLLs. Then we have a couple of dlls containing C++/CLI proxy code to wrap the C++ interfaces. On top of that we have C# code calling into the C++/CLI wrappers. Standard stuff, so far. But we have a lot of cases where native C++ exceptions are allowed to propagate to the .Net world and we rely on .Net's ability to wrap these as System.Exception objects and for the most part this works fine. However we have been finding that destructors of objects in scope at the point of the throw are not being invoked when the exception propagates! After
订阅 raii