On 23/11/2015 20:43, Rainer Weikusat wrote:
> 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.

OK, "unnecessary reimplementation" then. Reimplementing basic stuff is
wasteful on many levels.

>> 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.

Well, inside the guts of an allocator is exactly where direct pointer
usage is required for the needed performance and flexibility. But for a
list in a frontend GUI, not so much. It would be a waste of valuable
time and effort when there are easier and simpler alternatives. The
goal is to write a GUI, not mess around with list implementation details.

>> 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.

So this is pre-Standard C++ given the timeframe? It was particularly
bad around this time, and it took several releases of GCC3.x before the
bugs in libstdc++ were shaken out (so ~2004-5 when it became widely
available). Not that the C++98 standard library is without its warts,
but it's perfectly functional. With C++11, the library became properly
usable--direct initialisation of containers makes it vastly better.

If you came to me with a problem, and that required maps, lists etc. to
solve, I would nowadays automatically discount C. I'd look and C++ or
Python first. I'd have an implementation done and tested well before
I'd even got started on it in C--where I'd be obliged to create all the
low-level pieces before I even got started on the problem itself.
There's no advantage to using C in a situation like this--other than for
masochistic bragging rights--it doesn't do a better job, and it takes
longer, requires more effort and will be more likely to contain bugs.

std::vector<std::string> list{"foo", "bar", "baz"};

Just works. How much low-level C would be required to implement that?
Lots. Would it be worth the cost? Almost certainly not.


Regards,
Roger