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, but that shouldn't be the norm. The options here are likely
limited to:

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. But... this is code which needs
writing, testing, debugging and then maintaining and which is not the
core purpose of your program. You need to reinvent this before you can
even get to the meat of the problem you are trying to solve. This is
wasted and unnecessary effort, spent on something which is boring and
counterproductive--it's just low-level infrastructure. If it was just
about one linked list, it might not be such a problem, but as you
continue with the application, you'll need some other container,
structure and/or algorithm which you'll /also/ need to reimplement, and
again over and over until you've eventually got your own GLib
equivalent. A limited language like C results in this wheel reinvention
due to its inherent lack of generality. If you can reuse an existing
tested and functional implementation, that's for the best. It's a
disservice to recommend pointless wheel reinvention--most C programs
suffer from it to some extent, but that's not in any way an endorement
of the practice. So I would say "use GLib GList if the cost of doing so
is less than the cost of reimplementing it yourself". And if the cost
is greater, then reconsider the use of C before anything else.

If you take approach (4), and use a standard container type, the problem
is solved immediately. "#include <list>", "std::list<mytype> mylist".
Job done. On to the next problem. This would be my recommendedation
over wasting time and effort working around the limitations of C. Your
goal is to write an application: just write it without being diverted
down unproductive tracks which aren't needed to achive that goal. Using
a linked list is not the goal, it's a trivial detail. If your goal is
to write the whole thing in C, that's fine, but do so understanding that
it's going to take a lot more time and effort, and the likelihood of
bugs creeping in will be much higher.

If you use (5), e.g. Python, Perl or some other language with native
lists/arrays, this becomes a non-issue--you just use the standard type
for that language.


Regards,
Roger