Not everything is a nail...

Posted Jan 25, 2011 9:38 UTC (Tue) by paulj (subscriber, #341)
In reply to: Not everything is a nail... by daglwn
Parent article: Sobotka: Why GIMP is inadequate

You can do RAII in C just fine...

Not everything is a nail...

Posted Jan 25, 2011 16:06 UTC (Tue) by jrn (subscriber, #64214) [Link] (4 responses)

I suppose it depends what RAII means. But no, I am not aware of a simple way to, say, free memory on the heap when a pointer to it falls out of scope (especially when a "return" statement exits that scope).

Not everything is a nail...

Posted Jan 25, 2011 16:41 UTC (Tue) by etienne (guest, #25256) [Link] (1 responses)

Maybe you do not have the problem of freeing memory when a local structure goes out of scope in C (outside of kernel space), because in that case the local structure is declared in the stack and will be freed automatically...
Maybe the real problem is that your "autoptr" is not able to manage an object in the stack, but you need an "autoptr" because one method has such an argument.

Not everything is a nail...

Posted Jan 25, 2011 22:18 UTC (Tue) by daglwn (guest, #65432) [Link]

Will that local structure also close files for me when it goes out of scope? Or does that local structure free memory pointed to by members of that structure when it goes out of scope? Or does that local structure release a lock it holds when it goes out of scope?

RAII is about MUCH more than memory.

Not everything is a nail...

Posted Jan 26, 2011 12:32 UTC (Wed) by paulj (subscriber, #341) [Link] (1 responses)

For me RAII in the abstract is an object/resource-lifetime management strategy, such that creation and destruction of composite objects appear atomic wrt resources/objects held internally, as far as users of the object are concerned. Obviously it's good programming to try make objects atomic in this way when designing code.

C++ has implicit calls to constructors and destructors, which tie in to scoping. C doesn't have that, true, and requires explicit construction and destruction (you can still hide destruction behind refcounting, obv). It's often bad practice and/or a sign of a (quick)? hack when C code uses automatic allocating for non-trivial, composite objects.

Whether language support for implicit ctor/dtors tied with scoping is required for a practice to be called RAII, I don't know. I guess to a C++ person it does. Still, the general sentiment of RAII seems more widely applicable than C++.

Not everything is a nail...

Posted Jan 26, 2011 19:52 UTC (Wed) by daglwn (guest, #65432) [Link]

Implicit destruction (finalization, uninit or whatever you want to call it) seems to me integrally tied to the concept of RAII. Without it, one ends up having to cover all exit points of a scope with explicit calls to cleanup code. Either this means there are several such calls scattered around parts of the enclosing scope or there's a big ugly goto to a common piece of cleanup code. Neither is particularly attractive or maintainable.

This gets to be impossible if the exit points are not known statically. C++ exceptions are a classic example but since some seem to think the C++ exception model is broken, I will emphasize that the problem is NOT solved by eliminating exceptions. One still has to cover all exit points with cleanup code.

Perhaps a better term for this would have been "resource ownership is object lifetime."