Johannes Sixt <j...@kdbg.org> writes:
> Am 30.08.2016 um 19:52 schrieb Johannes Schindelin:
>> Right, but that is exactly what I wanted to avoid, because it is rather
>> inelegant to strdup() strings just so that we do not have to record what
>> to free() and what not to free().
> Please, excuse, but when I have to choose what is more "elegant":
> 1. strdup() sometimes so that I can later free() always
> 2. use sequencer_entrust()
> I would choose 1. at all times.
Let's not bring elegance or aesthetics in. It is like asking if
garbage collected systems are elegant. I do not think it is a valid
question. GC is a good pragmatic compromise after (1) declaring
that keeping track of allocation is too cumbersome and programmers'
time is better spent elsewhere, and (2) making sure hiccups caused
by GC can be minimized to keep the latency down to acceptable
levels. There are good compromises and bad ones.
Does the proposed entrust() thing qualify as a good pragmatic
compromise like GC does?
> Particularly in this case: parsing options does not sound like a
> major drain of resources, neither CPU- nor memory-wise.
If entrust() does not have any CPU- or memory-cost, then comparing
it with having to strdup() sometimes might be a useful comparison.
But the entrust() thing has the allocation cost in order to track of
what needs to be done at runtime, and just like strdup() needs to be
done on things that are being borrowed, entrust() needs to be
avoided on things that are being borrowed (and the caller needs to
be sure not to entrust() the same piece of memory twice), so it does
not reduce the cost on programmers' and readers' mental burden--the
programmer always has to know which piece of memory is borrowed and
which are owned by the subsystem.