raii

This is about wrapping the exception handling logic in some sort of class. While writing c++ code, many time we need to catch many type/variants of exception depending on what client throw. This lead us to write similar types of code(many times) in catch() clause. In below sample example, I have written the function(), which can throw exception in the many possible form. I wanted to know is it possible to write/wrap such logic in the form of class so that end user would have to write similar types of code at once place?. Does it make any sense or it has any meaning? #include<vector> #include

Bjarne Stroustrup writes in his C++ Style and Technique FAQ , emphasis mine: Because C++ supports an alternative that is almost always better : The "resource acquisition is initialization" technique (TC++PL3 section 14.4). The basic idea is to represent a resource by a local object, so that the local object's destructor will release the resource. That way, the programmer cannot forget to release the resource. For example: class File_handle { FILE* p; public: File_handle(const char* n, const char* a) { p = fopen(n,a); if (p==0) throw Open_error(errno); } File_handle(FILE* pp) { p = pp; if (p==0

In C#, if I want to deterministically clean up non-managed resources, I can use the "using" keyword. But for multiple dependent objects, this ends up nesting further and further: using (FileStream fs = new FileStream("c:\file.txt", FileMode.Open)) { using (BufferedStream bs = new BufferedStream(fs)) { using (StreamReader sr = new StreamReader(bs)) { // use sr, and have everything cleaned up when done. } } } In C++, I'm used to being able to use destructors to do it like this: { FileStream fs("c:\file.txt", FileMode.Open); BufferedStream bs(fs); StreamReader sr(bs); // use sr, and have

What is the advantage in de-allocating memory in reverse order to variables? Consider this example: Type1 Object1; Type2 Object2(Object1); Suppose that Object2 uses some internal resources of Object1 and is valid as long as Object1 is valid. For example, Object2 s destructor accesses Object1 's internal resource. If it weren't for the guarantee of reverse order of destruction, this would lead to problems. It's not just about deallocating memory, it's about symmetry in a broader sense. Each time you create an object you are creating a new context to work in. You "push" into these contexts as

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 allowed or not? Basically, I am curious if it is possible to use the SBRM/RAII idiom for these calls,

I'm implementing an object that owns several resources created from C libraries through FFI. In order to clean up what's already been done if the constructor panics, I'm wrapping each resource in its own struct and implementing Drop for them. However, when it comes to dropping the object itself, I cannot guarantee that resources will be dropped in a safe order because Rust doesn't define the order that a struct's fields are dropped. Normally, you would solve this by making it so the object doesn't own the resources but rather borrows them (so that the resources may borrow each other). In