Re: C and C++
On Sunday, 10 November 2013 21:09:26 UTC+2, Richard Damon wrote:
On 11/10/13, 12:29 PM, =D6=F6 Tiib wrote:
On Sunday, 10 November 2013 16:23:47 UTC+2, Dombo wrote:
In case of C# you have also the using/IDisposable construct, which
isn't as nice as RAII, but in many cases it is close enough.
Yes that was exactly what I said. The idioms that replace RAII (chains
of catches everywhere, finalizers and disposers) are painful to use for=
managing precious resources. The information that some object "manages"=
precious resources leaks outside and so the object has to be "managed"
differently by using code. No true encapsulation possible. How to
OOP then?
I an nor so sure I would call that an information "leak", in a language
without the ability to tell the compiler to automatically call an
objects destructor, I wouldn't call listing a requirement that the
object needs its "close" function called before the object goes away an
encapsulation "leakage", it is just part of the objects interface.
I was more about leaking that "interfacial property" up the whole cascade. =
Usage of such class as member turns usually the composite also into "must
close" kind.
It
does say that when designing said interface, the designer needs to think
if there is now, or in some point in the future a possible need for such
an routine, and if so provide it and "require" its call.
Yes. May be we need to manage a member that manages a member that may be
has a file open or network connection or something like that? Everything
"may happen" (perhaps besides bare bone strings and numbers) and so
everything may need manual life-time management. Dealt with it once and
the RAII of C++ feels suddenly so sweet a feature. ;)
If anything, it
is the objects that do NOT require a "close" call that have leaked
implementation details, as if the future that changes, you need to
review all usage of that class.
Ok but with mandatory manual life time management of most things
.... what is the major benefit above idiomatic OOP of C?:
#include <Thing.h>
int main()
{
Thing* thing = Thing_open(42);
if (thing == NULL)
perror("Error opening Thing");
else
{
Thing_trick1(thing);
Thing_trick2(thing);
Thing_close(thing);
}
return 0;
}
Yes, the automatic calling of the "close" function simplify a lot of
code, but some of the critics of C++ also point out that this
automatisity is also a big problem as it can hide significant amounts
of operations.
I just do not buy that argument. The idea of encapsulation is to
establish some borderline. If a class does travel to Moon and back to
fulfill some responsibility of it despite it does not have to then it
is crappy implementation. If it is clear that it has to travel to Moon
and back however then more verbose interface does not aid us any.
We need that done and so someone has to visit Moon.