Hi All,

The backend, in a way, already handles lists. All I need to do is
extract the code and put it in a struct. This 'reinventing of the
wheel' will avoid having to content ourselves with what libraries
offer whatever that may be. With netman, the goal was to avoid as many
dependencies as possible: using huge libraries defies that purpose.

Edward

On 23/11/2015, Roger Leigh <rleigh@???> wrote:
> 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
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>