:: Re: [DNG] Experiencing with GtkBuil…
Top Page
Delete this message
Reply to this message
Author: Rainer Weikusat
Date:  
To: dng
Subject: Re: [DNG] Experiencing with GtkBuilder
Roger Leigh <rleigh@???> writes:
> On 23/11/2015 13:50, Rainer Weikusat wrote:
>> Roger Leigh <rleigh@???> writes:
>>> On 23/11/2015 11:49, Nate Bargmann wrote:
>>>> * On 2015 23 Nov 00:53 -0600, aitor_czr wrote:
>>>>> In my opinion, using C with lists will be the most suitable.
>>>>
>>>> Have you looked at what glib provides? It is an underlying library of
>>>> GTK and seems to contain many such solutions.
>>>
>>> Using GLib for structures like linked lists (GList) etc. is a much
>>> better solution than reinventing them unnecessarily.
>>
>> I beg to differ here: Using a lot of complicated code in order to
>> accomplish something simple, ie, management of linked lists, may be
>> regarded as advantageous, eg, because it enables avoiding a (typically
>> negligible) amount of work or because it's more politically feasible but
>> $code doesn't become a 'better' solution for some $problem just because
>> it can be downloaded for free from the internet.
>
> This is true up to a point. Note the "unnecessarily" qualifier in
> what I wrote--sometimes there might be a justification for reinventing
> the wheel,


"The wheel" (leaving the issue that wheels are being 're-invented', ie,
new kinds of wheels are being developed all the time, aside) is a
technical device which has been in use without changes to the basic
design for a couple of thousands of years. In contrast to this, most
other human inventions, say, steam-powered locomotives, delay line
memory or CP/M, are very short-lived. This make it a particulary
unsuitable analogy here.

> 1) Use GLib
> 2) Use a linked list implementation from another library
> 3) Write your own
> 4) Use C++
> 5) Use another language
>
> As you say (1) isn't necessarily ideal, and this also potentially
> applies to (2) depending upon its quality of implementation and how
> well it matches your needs. Where I would disagree is that (3) has a
> "typically negligable" cost. A linked list is conceptually simple,
> and yes, not that much effort to write.


One thing I always liked about Jeff Bonwick's 'Slab Allocator' paper was
that he apparently didn't even think about implementing a generalized
library for handling doubly-linked list instead --- he just wrote the
code manipulating the link pointers as needed.

[...]

> If you take approach (4), and use a standard container type, the
> problem is solved immediately. "#include <list>", "std::list<mytype>
> mylist". Job done.


One of the reasons why I stopped using C++ around 2001/2 (A lesser
reason. The more important one was that it was neither a requirement nor
particularly helpful) was that I always regarded it as very nice
language with the millstone of an atrociously implemented standard
library around its neck while I came to realize that a certain Mr
Stroustroup seemed to regard is a rather atrocious language he could
only sell because of the wonderful library requiring it.