On 23/11/2015 20:43, Rainer Weikusat wrote:
Roger Leigh <rle...@codelibre.net> writes:
On 23/11/2015 13:50, Rainer Weikusat wrote:
Roger Leigh <rle...@codelibre.net> 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
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
