A container library for the C language

[BGB / cr88192]

Richard Kettlewell a écrit :

I will write a stream container, and that function will be
there. For the time being, note that getline is NOT part
of the specification.

note that name clashes like this risk causing bad results on Linux.

namely, even if not explicitly exported, there is a risk it could end up
being called by another library expecting the *other* getline (if both
libraries happen to be in use at the same time).

this sort of thing is not as likely to happen with DLL's on Windows (unless
the same client DLL tries to link against both DLL's with clashing export
names, and gets confused).


my typical strategy is to give all toplevel names prefixes to identify the
particular library (and often subsystem), such as to somewhat reduce the
risk of accidental name clashes.

MYLIB_MySubSys_MyName //typical for functions
mylib_mysubsys_myname //typical for global variables or data
(sometimes myname may be hungarian...), typically I prefer to avoid global
variables though.

and similar...


I may use an OpenGL-like convention for names which are part of the public
API, mostly becuase this allows shorter names (although at a statistically
increased risk of name clashes, for example, if 2 different libraries end up
using the same naming conventions and name prefix...). (I then use the prior
convention mostly for library-internal and project-internal names).

or such...

 

[Malcolm McLean]

nonsense. Many of my functions accept and return lists but no way most
of them.

Data comes in lists, almost always. The typical model comes in lists
of list

(List of firms, for each firm a list of sites, for each site a list of
departments, for each department a list of employees, for each
employee a list of remunerations and deductions, for each remuneration
and deduction finally a scalar).

Most functions operate on data.

I'm not saying that never ever do you have a graph or a tree, or that
you'll never need to write a function like sin() that operates on a
scalar. I'm talkign about the general case.

 

[Ben Bacarisse]

Data comes in lists, almost always. The typical model comes in lists
of list

(List of firms, for each firm a list of sites, for each site a list of
departments, for each department a list of employees, for each
employee a list of remunerations and deductions, for each remuneration
and deduction finally a scalar).

The remark in parentheses describes one or more associative arrays
("maps" to some). There is no natural lists structure involved despite
the fact that you put the word "list" in there lots of times!

I agree that lists are common (I would not be prepared to go much
further) but your example undermines your argument.

<snip>

 

[Malcolm McLean]

The remark in parentheses describes one or more associative arrays
("maps" to some).  There is no natural lists structure involved despite
the fact that you put the word "list" in there lots of times!

You're right of course. A list has an order, but, like a shopping
list, it is often purely arbitrary (it's easier to represent a list of
groceries in an order, one item per line, than to write them at random
all over a sheet of paper).
There is a case for a language in which it's easier to pass
collections than lists, to make this distinction more obvious.

 

[wolfgang.riedel]

On Jul 2, 12:37 pm, Nick Keighley <[email protected]>
wrote:

(List of firms, for each firm a list of sites, for each site a list of
departments, for each department a list of employees, for each
employee a list of remunerations and deductions, for each remuneration
and deduction finally a scalar).

I too think, there are many uses of/for lists (and of course have
written and used
some), but your example cries for a relational database (OT. here) -
it has all
drawbacks of an hierarchical database like IMS without any of its
advantages.

Wolfgang

 

[Ed]

as someone on comp.lang.schem once said

"
Yes, in the same sense that a shoe is a form of aircraft carrier.
"

which is pretty much the relationship between templates and C macros

I "get it", but not sure we are on the same page (and I think there is
only minor distinction). Do expound your point for posterity. Be very
explicit. Before you begin though, please give the context of where
templates and macros reside: that would be like a picture worth a
thousand words.

 

[Ed]

Old man getting tired, huh. I understand: the union and companies used
you. I understand.

I'll apply ruthless snipping here as you are becoming tedious

Oh! Maybe I don't (understand!).

I've no idea what that means.

So, do you have a retirement plan?

<snip REPETITION>

I do it naturally, not just because they taught me in school: "tell them
once, tell them, then tell them again". Ever heard that?

[...] Those who
value simple elegance over ultra-generality. Those who want to
understand the code of the libraries they use.

STL code is widely available.

So it heroin.

I think you have a bit of NIH syndrome.

I see. I'm "sick", because I DON'T do drugs. "okie dokie".

Those who have the capability to

more NIH.

Have you heard the term "pusher"?

I can build linked lists but why bother when there is a high

"there is a high": surely beyond anything "this" "(paltry)" life can give
(as if it was a fault of the "life" abstraction).

quality generalised implementaion available.

I don't do drugs and I am not your target market.

Do you write every line
of code yourself?
Yes.

Do you write the compiler?

I just want to do the front end (I have no interest in back-end compiler
stuff: NONE).

Do you design your own language?

It sorta crept up on me, yeah.

Why are you posting here then?

Oh, 'scuze me. Answer: I didn't know it was a clique. Is it? Do tell,
"young" man.

[...] Standards are those things that are
one-size-fits-all things and one-size-fits-all is fantasy (or
politics).

no. If civil engineers thought like you every nut and bolt would be
hand forged.

Oh, I must have pissed you off for you to attack me "personally" (don't
worry about it, I'm not offended or hurt).

standards are for everyone.

You are warring! Dude, chill! I am not the enemy (am I, to you?). I seek
nothing from anyone.

I only see so far because I stand on the
shoulders of giants.

And lil ol me learning assembly to reimplement everything right, gets
your dander up? You WANT to retire, but NO PENSION. Right? I understand.
(Because I know you can't code yourself out of a paper bag).

I do. They waste time by reinventing square wheels.

They butt their head against your "monument". It's a sad think that your
kids do to cemeteries. (You have had kids?).

The re-implement
linked lists on every project. Badly.

You sound like a teacher-wannabe. Do publish your essential linked list
and propel yoursel into teaching hall of fame.

me too


you seem to be one of 'em

What? Do teach me then oh great teacher.

whatever

Deal with it: I am not you.

this is because C does very little for you.

So you are admitting it's in adequacy?

C's functionality is
duplicated in many other languages. Try porting Python or Common Lisp
or smalltalk to another language or pardigm.

I didn't suggest porting to another paradigm. How "old" are you, again?
That was a childish remark. (And you wanna be a teacher? Pfft. Ain't
gonna happen.)

than those other languages?

That you have privy to you mean?

<snip>

You are quite the snippy one when enraged, huh. ("bring it": JK).

could you give an examples?
Yes.

What would I google for?

No. Sounds like "bobbing for apples".

this directly contrdicts my experience

No offense, it's going to outlive everyone, not just you and me.

you have come up with nothing.

Says who? You? Pfft.

and I don't see it.

NP: I am apparently older than you (that sucks way big time!). (That in
itself makes me wanna saddle up the harley (Yamaha) and ... explore (?)).
Do you C?

 

[Nick Keighley]

Malcolm uses the term "list" as follows
***

A "list" means

1: Fred
2: Jim
3: Bert
4: Harry
5: Fred

95% or so of your data will be lists. Whether they are stored as
arrays, linked lists, or in more exotic structures is an implentation
detail. Huge numbers of functions inherently operate on lists.

***

which I think is quite reasonable despite its apparent disagreement
with computer science. I'm quite happy to use the term "list" in the
"shopping list" sense. People who start talking about RDMSs and maps
are missing the point.


and all of firm, site, department, employee etc etc are *not* lists.

The remark in parentheses describes one or more associative arrays
("maps" to some).

list in the shopping list sense

 There is no natural lists structure involved despite
the fact that you put the word "list" in there lots of times!

I agree that lists are common (I would not be prepared to go much
further) but your example undermines your argument.

<snip>

but this is pointless as neither of us is willing to go and get any
metrics.

 

[Malcolm McLean]

but this is pointless as neither of us is willing to go and get any
metrics.

The point is that lists are extremely common, so any container library
has got to make it easy to build lists, pass lists, and to build
functions that interoperate between them.

 

[Ben Bacarisse]

Malcolm uses the term "list" as follows
***
***

[Its proabably better to use another quote character when re-quoting
someone else's text or adding context as I think you are doing.]

which I think is quite reasonable despite its apparent disagreement
with computer science. I'm quite happy to use the term "list" in the
"shopping list" sense. People who start talking about RDMSs and maps
are missing the point.

Yes, "list" is a reasonable term for a list like a shopping list. How
does this appear to be in disagreement with CS? I never talked about
relational databases and my comment about maps made explicit reference
to another example.

and all of firm, site, department, employee etc etc are *not* lists.


list in the shopping list sense

I don't understand what either this or the last remark is getting at. I
think, but I am not sure, that you are agreeing with me that the example
is not about lists is any natural sense.

<snip>

but this is pointless as neither of us is willing to go and get any
metrics.

I don't agree that the discussion is pointless without data. The
discussion reveals the participant's opinions and these can be
interesting in themselves. If you want hard data for your discussions,
Usenet will seem a barren place!

 

[Nick Keighley]

Malcolm uses the term "list" as follows
***
***

[Its proabably better to use another quote character when re-quoting
someone else's text or adding context as I think you are doing.]

I was adding context. I was being lazy.

Yes, "list" is a reasonable term for a list like a shopping list.  How
does this appear to be in disagreement with CS?

I think some peopel see the term "list" and think "linked list". I use
it to mean something like "ordered container" and I don't care how
it's implemented. (obviously at some point I have to care).

 I never talked about
relational databases and my comment about maps made explicit reference
to another example.

someone else did. This reply is probably a bit overly ambitiously
portmanteau. I'm trying to repond to about three people in a single
post.

On the maps I perhaps misunderstood you.

I don't understand what either this or the last remark is getting at.

he's saying his program has lots of "lists" of things like employees.
I agree. I don't really see what map adds.

 I
think, but I am not sure, that you are agreeing with me that the example
is not about lists is any natural sense.

no I'm not. I'm refuting his contension that most of the data in a
program is a list.

I don't agree that the discussion is pointless without data.  The
discussion reveals the participant's opinions and these can be
interesting in themselves.  

yes, up to a point. But if peopel are using terms like "many" and
"most" sooner or later you're going to need some numbers.

If you want hard data for your discussions,
Usenet will seem a barren place!

I can't sign off yet I have to refute someone who is posting nonsense
on the internet.

 

[Ben Bacarisse]

he's saying his program has lots of "lists" of things like employees.
I agree. I don't really see what map adds.

My disagreement was a small one: a description of the form "for every X
there is a Y and for every Y there is a Z..." suggests that a map of
some sort is the correct data structure, rather than lists of lists. Of
course, if all the program ever wants to do is enumerate the data then a
nested list of lists will do, but this is not a common situation.
Alternatively, if access to the data is not solely via the X -> Y -> Z
mapping, then a database may well be called for.

I am neutral on the point of whether you think of the data in a map (or
database) as being a list or not. It is certainly "a collection" but I
prefer not to call it a list because a list has an ordering that should
matter to the programmer (it is all it has!) but a map is a collection
whose enumeration order is either arbitrary (like in a hash table) or
intrinsically useful (like in a balance tree).

<snip>

 

[Malcolm McLean]

I am neutral on the point of whether you think of the data in a map (or
database) as being a list or not.  It is certainly "a collection" but I
prefer not to call it a list because a list has an ordering that should
matter to the programmer (it is all it has!)  but a map is a collection
whose enumeration order is either arbitrary (like in a hash table) or
intrinsically useful (like in a balance tree).

Thinking about this,

I suppose that a lot of data comes in intrinsically unordered
collections (eg employees), but ordering is in fact necessary because
the index is used internally by the program as a key, or is
conventional - such as sorting employees alphabetically by surname.

 

[Ian Collins]

The point is that lists are extremely common, so any container library
has got to make it easy to build lists, pass lists, and to build
functions that interoperate between them.

Any container library is constrained by the programming language it is
written in. The lack of support for generics in C may be the principal
reason a ubiquitous C container library hasn't appeared. There isn't an
obvious solution.

 

[jacob navia]

Ian Collins a écrit :

Any container library is constrained by the programming language it is
written in.
Yes.

The lack of support for generics in C may be the principal
reason a ubiquitous C container library hasn't appeared. There isn't an
obvious solution.

Not an obvious solution but a practical one. I have proposed here (and
documented in the library documentation) a simple C program that will
use a generic templateand adapt it to a specific data type. This is a
pre-processor solution, but it is very easy to implement and works like
a charm.

jacob

 

[Malcolm McLean]

Any container library is constrained by the programming language it is
written in.  The lack of support for generics in C may be the principal
reason a ubiquitous C container library hasn't appeared.  There isn't an
obvious solution.

The C way is to treat the objects as series of arbitrary bits, then
use function pointers to extract the useful information.

This has several disavantages; often the objects are pointers, in
which case memcpy() is called inefficiently to move simple pointers
about internally within the container, often the functions required
are tricky to document, and awkward to write, there's no clean way of
destroying embedded allocated data in the objects.