91–100 of 248 posts
Earlier quoted context omitted.
"Smart pointers go brr" It's not really random, but it's quite hard to follow.
It shouldn't be. std::unique_ptr is very clear. (std::shared_ptr should be used only when absolutely required and should be kept under close watch the whole time.)
Should I be alarmed?
Earlier quoted context omitted.
You’re missing the point. The two are alike in that something significant is happening that you as the programmer did not explicitly tell it to do. The specific mechanism really isn’t an important distinction here.
If you write a destructor then you know exactly under what circumstances in C++ code it will be used (this is one of the major features of the language). This specific mechanism is extremely important.
Earlier quoted context omitted.
Deferred actions are not explicit at the exit points. That's quite implicit. You can no longer reason about a local piece of code; you now have to know its lexical nesting up to top level to see if it's inside a guard block that might trigger hidden behavior.
I wondered about this. Say I have a block, at the end of which I free a bunch of memory. I also have a bunch of other exit points within the block (mostly for catastrophic errors, say). Would a deferred free only apply to the outer scope? Because if so, I really don't see the point at all.
In its current form, this is really stupid, because of something like this: guard { for (int i = 0; i Now the compiler has to: 1. implement some side of capture/closure mechanism to keep all the 'i's to the end of the guard block 2. do dynamic allocation to store the closures so they can be executed at the end did the scope 1 seems like too much work for such a feature, and 2 is a massive no. Implicit dynamic allocat…
I got the impression that the proposal still has some aspects of the design that are open for discussion, including whether it should be static or dynamic, and whether it should capture the variables by value or by reference. (These are discussed in pages 13-16)
Earlier quoted context omitted.
> One of the key interest of C compared to more recent languages is that everything is explicit. There's nothing implicit about defer.
Deferred actions are not explicit at the exit points. That's quite implicit. You can no longer reason about a local piece of code; you now have to know its lexical nesting up to top level to see if it's inside a guard block that might trigger hidden behavior.
#define DEFER_START(scope_name) void * scope_name = &&scope_name##_end;
#define DEFER(scope_name, iter_name, func) void * iter_name = scope_name; { \
scope_name = &&iter_name ##_exe; \
if (0) { iter_name##_exe: {func} goto *iter_name; } }
#define DEFER_END(scope_name) scope_name##_start: goto *scope_name; scope_name##_end: {}
#define DEFER_EXE(scope_name) goto scope_name##_start;
...
{
DEFER_START(scope);
void * p = malloc(4);
if (!p) DEFER_EXE(scope);
DEFER(scope, free_p, { printf("freep\n"); free(p); });
void * q = malloc(40);
if (!q) DEFER_EXE(scope);
DEFER(scope, free_q, { printf("freeq\n"); free(q); });
DEFER_END(scope);
}
In its current form, this is really stupid, because of something like this: guard { for (int i = 0; i Now the compiler has to: 1. implement some side of capture/closure mechanism to keep all the 'i's to the end of the guard block 2. do dynamic allocation to store the closures so they can be executed at the end did the scope 1 seems like too much work for such a feature, and 2 is a massive no. Implicit dynamic allocat…
I suspect it will come with some really big caveats. For instance what you wrote shouldn't compile, because i's storage duration doesn't extend to the end of the guard block. If you write guard { int i; for (i=0; i I would expect foo(n) to be called n times. That is, variables won't be captured, it would work literally as if you wrote "foo(i)" n times at the end of the guard block. It's a footgun, but everything in C…
Re: Should object values be captured? The results from 387 responses (to a Twitter poll) show a 2:1 preference for the value being read at the time the deferred statements are executed (66.9%) rather than when the defer statement encountered(33.1%). Since both options - by value and by reference - may be viewed as reasonable or desirable, neither should be a default. Instead, they both should be using a special synta…
Why not have `defer free(p)` capture at deferral execution time, and `defer free(capture(p))` capture at statement execution time?
Despite being convenient,I have the feeling that it might be a bad idea. One of the key interest of C compared to more recent languages is that everything is explicit. With a finger you can follow the code as it runs and know exactly what is going on and when exactly. At the opposite, there is c++ that does a lot of things automagically. And it is often hard to understand why you suddenly get a segfault out of blue,…
A possible explicit solution I can think of is to introduce a new function attribute that gives the name of their ‘cleanup’ function (so that the compiler would know fopen needs a fclose, for example) and a compiler that uses these attributes to issue a warning if a function has a path that calls a function and doesn’t either call its cleanup function or returns its result.
I don’t know whether that would cover all bases, though.
Despite being convenient,I have the feeling that it might be a bad idea. One of the key interest of C compared to more recent languages is that everything is explicit. With a finger you can follow the code as it runs and know exactly what is going on and when exactly. At the opposite, there is c++ that does a lot of things automagically. And it is often hard to understand why you suddenly get a segfault out of blue,…
That said, it's still debatable if it's useful, given that you can achieve the same thing with the
struct some_resource resource;
do {
resource = allocate(...);
if (!resource) break;
} while(0);
if (resource) dispose(resource);