3 ms·

"Is C++ Doomed?" No. The FILE example is either bad, tired, lazy or shows lack of knowledge of the standard library. A better way of opening/closing the FILE w

"Is C++ Doomed?" No. The FILE example is either bad, tired, lazy or shows lack of knowledge of the standard library. A better way of opening/closing the FILE with RAII is right in the example [0] of unique_ptr at the wonderful cppreference.com: std::ofstream("demo.txt") << 'x'; // prepare the file to read { using unique_file_t = std::unique_ptr<std::FILE, decltype(&close_file)>; unique_file_t fp(std::fopen("demo.txt", "r"), &close_file); if (fp) std::cout << char(std::fgetc(fp.get())) << '\n'; } // `close_file()` called here (if `fp` is not null) I'm sorry, I'm not trying to be negative towards the author, but you need a better example than opening/closing FILE if you're going to make a compelling argument about the looming death of C++. [0] https://en.cppreference.com/w/cpp/memory/unique_ptr https://en.cppreference.com/w/cpp/memory/unique_ptr

nyanpasu64 5y ago
Using a function pointer as a unique_ptr's deleter type, and passing it in at runtime, makes the unique_ptr fat (two pointers large). To avoid this overhead, I prefer passing in a default-constructible type with an operator() deleter function, and not passing in a value into the unique_ptr constructor (https://github.com/nyanpasu64/qvgmsplit/blob/edcce6df391c15beb7d5db9c5d9275f853c87690/src/backend.cpp#L52-L63 https://github.com/nyanpasu64/qvgmsplit/blob/edcce6df391c15b...). A neat party trick is to use the decltype of a lambda (https://old.reddit.com/r/cpp/comments/rlvsq0/does_anybody_really_use_deleters/hpmg0k6/ https://old.reddit.com/r/cpp/comments/rlvsq0/does_anybody_re...).
CyberRabbi 5y ago
His point is that C code often calls into C++ code. This is always incorrect unless the C++ entry point is guaranteed not to throw an exception. This is especially bad since this is not automatically checked by default.
morelisp 5y ago
But this also shows a lot of warts that mean RAII isn't "really working", as in it isn't reducing the mental load of resource management as far as we'd like. - You've needed to manually specify the deleter. Why do I need to invent unique_file_t myself? The stdlib is failing to support idiomatic language use. - Probably most critically, fp can be null! If A is I, then I is A, yet here we are with a resource in-scope but not allocated! - You've had to manually add a scope to handle it, and (unlike e.g. Python with or Java try) there's nothing per se to indicate that's what the scope is for. SBRM is supposed to be interesting because of how often our scopes align with lifetimes naturally; manually adding a scope isn't too far from manually calling a destructor. Please don't respond with the reasons "why" it is this way; we all know. That also doesn't change that they are still major warts that undermine safe, clean C++.
- jcelerier 5y ago
  > - You've needed to manually specify the deleter. Why do I need to invent unique_file_t myself? The stdlib is failing to support idiomatic language use. But you're not supposed to use fopen / fclose at all, in unique_ptr or not, so the language shouldn't encourage you to use those. They are just often shown in unique_ptr, because when making examples to teach the language, it's a quick and easy way to showcase how to wrap any kind of pre-existing handles, not only memory, through the unique ownership semantics of unique_ptr; any other example would be platform specific (say, HWND on Win32, GL contexts or who knows what). Everyone knows fopen/fclose. Basically, that unique_ptr thing is just here to show that it's possible to quickly ease porting 45 million lines of C to C++ without having to change every fopen into an ifstream/ofstream.

nyanpasu64 5y ago

Using a function pointer as a unique_ptr's deleter type, and passing it in at runtime, makes the unique_ptr fat (two pointers large). To avoid this overhead, I prefer passing in a default-constructible type with an operator() deleter function, and not passing in a value into the unique_ptr constructor (https://github.com/nyanpasu64/qvgmsplit/blob/edcce6df391c15beb7d5db9c5d9275f853c87690/src/backend.cpp#L52-L63 https://github.com/nyanpasu64/qvgmsplit/blob/edcce6df391c15b...). A neat party trick is to use the decltype of a lambda (https://old.reddit.com/r/cpp/comments/rlvsq0/does_anybody_really_use_deleters/hpmg0k6/ https://old.reddit.com/r/cpp/comments/rlvsq0/does_anybody_re...).

CyberRabbi 5y ago

His point is that C code often calls into C++ code. This is always incorrect unless the C++ entry point is guaranteed not to throw an exception. This is especially bad since this is not automatically checked by default.

morelisp 5y ago

But this also shows a lot of warts that mean RAII isn't "really working", as in it isn't reducing the mental load of resource management as far as we'd like. - You've needed to manually specify the deleter. Why do I need to invent unique_file_t myself? The stdlib is failing to support idiomatic language use. - Probably most critically, fp can be null! If A is I, then I is A, yet here we are with a resource in-scope but not allocated! - You've had to manually add a scope to handle it, and (unlike e.g. Python with or Java try) there's nothing per se to indicate that's what the scope is for. SBRM is supposed to be interesting because of how often our scopes align with lifetimes naturally; manually adding a scope isn't too far from manually calling a destructor. Please don't respond with the reasons "why" it is this way; we all know. That also doesn't change that they are still major warts that undermine safe, clean C++.

jcelerier 5y ago
> - You've needed to manually specify the deleter. Why do I need to invent unique_file_t myself? The stdlib is failing to support idiomatic language use. But you're not supposed to use fopen / fclose at all, in unique_ptr or not, so the language shouldn't encourage you to use those. They are just often shown in unique_ptr, because when making examples to teach the language, it's a quick and easy way to showcase how to wrap any kind of pre-existing handles, not only memory, through the unique ownership semantics of unique_ptr; any other example would be platform specific (say, HWND on Win32, GL contexts or who knows what). Everyone knows fopen/fclose. Basically, that unique_ptr thing is just here to show that it's possible to quickly ease porting 45 million lines of C to C++ without having to change every fopen into an ifstream/ofstream.