About the container library

[jacob navia]

What is important at thisbstage is not the efficiency of the individual
routines. What is important now is to discuss if this approach can lead
to a general container library in C that could be proposed as an example
to standardize later.

This post is intended to all people that believe that C can be used
as a general purpose programming language not only in embedded coffee
machines but also in high level machines. Please refrain from arguments
like

it will not run in my pet processor with 512 bytes RAM...

Thanks

 

[ld]

What is important at thisbstage is not the efficiency of the individual
routines. What is important now is to discuss if this approach can lead
to a general container library in C that could be proposed as an example
to standardize later.

This post is intended to all people that believe that C can be used
as a general purpose programming language not only in embedded coffee
machines but also in high level machines. Please refrain from arguments
like

Why to you use an OOP-like approach while you still expose the data
type and do not manage inheritance? You could be interested by OOC-S
which is doing basically what you are looking for.

http://ldeniau.web.cern.ch/ldeniau/oopc.html#OOC-S

Object Oriented C - Simplified release is an oversimplified version of
OOC-2.0 with about 300 sloc (ultra light!), which provides some very
simple coding guidelines and programming techniques to allow C
programmers to write object oriented program nearly as in Java. OOC-S
provides some object oriented features like class (i.e. TYPE and
INTERFACE), single inheritance of class, attribute access control,
java-like interface, interface default method implementation, multiple
inheritance of interfaces and ownership management (including
autorelease). OOC-S is not a framework and minimizes the use of macros
(one per class) and typedefs (none) and therefore requires some manual
coding (class initialization) and some care from the programmer.
Following OOC-S templates or examples with all compiler warning
options enabled should avoid most common mistakes and forgetting. One
can still build some macros on top of OOC-S to automatize some part of
the coding. OOC-S requires a C89 compiler. download [size=18kB].

Let me know if you are interested by OOC-S, I did it very quickly some
years ago for a project and I may have some (new) ideas to improve
it.

a+, ld.

 

[jacob navia]

ld a écrit :

Why to you use an OOP-like approach while you still expose the data
type and do not manage inheritance?

I dop not see what "OOP" approach is this. There is no object
oriented programming in this library, and of course there is no
inheritance.

> You could be interested by OOC-S
which is doing basically what you are looking for.

http://ldeniau.web.cern.ch/ldeniau/oopc.html#OOC-S

I am NOT looking for object oriented programming but
for a container library in C.

 

[ld]

ld a écrit :




I dop not see what "OOP" approach is this. There is no object
oriented programming in this library, and of course there is no
inheritance.

 > You could be interested by OOC-S



I am NOT looking for object oriented programming but
for a container library in C.

So why do you create a vtable?

Usually, vtable are used for polymorphic type-based behaviors like for
FILE or OOP-like data structure. If your list is monomorphic, then an
ADT and a normal interface exposure List_xxx() should be simpler. You
can even make it type safe by wrapping generic void* interface with
typed inlined functions. This is what I was doing a long time ago.

Cheers,

ld.

 

[Seebs]

What is important at thisbstage is not the efficiency of the individual
routines. What is important now is to discuss if this approach can lead
to a general container library in C that could be proposed as an example
to standardize later.

I believe that the answer is, in general, "no".

Your options are:

* A non-general container library which is efficient enough to be useful.
This is not worth standardizing because it is trivial.
* A general container library which is not efficient enough to be useful.
This is not worth standardizing because it is not useful.

This post is intended to all people that believe that C can be used
as a general purpose programming language not only in embedded coffee
machines but also in high level machines. Please refrain from arguments
like

it will not run in my pet processor with 512 bytes RAM...

The problem is, if you standardize a feature, the little embedded machines
may have to provide it too...

-s

 

[Seebs]

Why? They don't even have to provide printf or getchar!

You have a point; if this were a hosted-only feature, it might get some
more traction, but it still seems hugely top-heavy and very much unlike
the Spirit of C.

-s

 

[Seebs]

My own objection to the proposal is simply that there are a trillion
ways to do this, and any single way is going to meet with approval by
some and disapproval by most. A similar argument can be made against
providing C's existing string library (and such an argument may well
have been made at the time). We got one anyway. Whether this is a
Good Thing is a matter of opinion!

The big difference:

C's string library is one of essentially two ways to do it; you can either
use a length indicator or a sentinel. It's fairly lightweight and maps nicely
to a number of conventions and idioms, and there are chips out there that have
instructions which map nicely to it, as I recall.

The string library imposes an extremely minimal data structure, and there
was a compelling need for that data structure to exist -- C would be much
less useful without the ability to use string literals for messages!

The container library isn't something you'd run into while writing "hello,
world!". It's a fairly specialized application, and it's a field where there
is a very noticeable tradeoff between efficiency and generality. Furthermore,
it specifies a fairly complicated data structure -- MUCH more complicated
than any currently in use, and I think the relative lack of complicated and
yet specified data structures in C is intentional.

A C-like container library ought to specify the interface, not the
implementation... But in this case, interface and implementation are fairly
closely tied together. When I did my list library, I picked a naming
convention for functions, declared a single struct type with which user
types were supposed to be compatible, and left it at that. It only does
one thing (lists) rather than other kinds of containers, but it imposes
only a very small amount of structure on you.

In general, I guess, I view data structures as a matter for the programmer
to decide in individual cases; not something that should be encapsulated in
the language spec. The few cases where C has structures (e.g., struct tm)
have by no small coincidence also been sources of major pain for many users.

-s

 

[Tech07]

What is important at thisbstage is not the efficiency of the
individual routines. What is important now is to discuss if this
approach can lead to a general container library in C that could be
proposed as an example to standardize later.

I think it would be ignorant to try to do containers without an object model
and a well-defined (and sanctioned ) concept of genericity. You seem to
be asking: "Given only a hammer, how can we build skyscrapers?". You can't!

 

[Nick Keighley]

jacob navia wrote:

I think it would be ignorant to try to do containers without an object model

unsurprisingly, I disagree. Then are plenty of languages without an
"object model"
that manage to do creditable container classes.

The original Ada for instance. I'm not sure how much of an object
model
C++'s template based containers need.

and a well-defined (and sanctioned ) concept of genericity.

I'll agree the lack of "a well-defined concept of genericity" may
actually be C's
stumbling block for containers. (I don't know what you mean by
"santioned"
so I've elided it). I'd *love* there to be a linked list library in C,
I've spent way too much time debugging badly designed linked list
implementations
and my first thought on seeing C++'s containers was "wow I'll never
have to debug
a linked list again!"

You seem to
be asking: "Given only a hammer, how can we build skyscrapers?". You can't!

--
In a profession plagued by, "when all you have is a hammer, everything
looks like a nail," we get really excited when someone is able to come
along and prove that everything really *is* a nail if lambda is the
hammer.
B.R.Lewis (comp.lang.scheme)

 

[Tech07]

unsurprisingly, I disagree. Then are plenty of languages without an
"object model"
that manage to do creditable container classes.

The original Ada for instance. I'm not sure how much of an object
model
C++'s template based containers need.


I'll agree the lack of "a well-defined concept of genericity" may
actually be C's
stumbling block for containers. (I don't know what you mean by
"santioned"
so I've elided it). I'd *love* there to be a linked list library in C,
I've spent way too much time debugging badly designed linked list
implementations
and my first thought on seeing C++'s containers was "wow I'll never
have to debug
a linked list again!"

I don't like freitos. Do you like frtios? Do fritoes suck? I don't like em.

 

[Mark]

I believe that the answer is, in general, "no".

Your options are:

* A non-general container library which is efficient enough to be
useful. This is not worth standardizing because it is trivial.

In connection with this I have a question. You ever wrote that something
that is trivial to implement (for example, strdup() or asprintf()) are not
added to the Standard. How come that 'bool' which has a simple
implementation was standardized ? This not to start another flame, but to
try to understand the criteria of "triviality"

Thanks.

 

[Keith Thompson]

[A given kind of library] is not worth standardizing because
it is trivial.

In connection with this I have a question. You ever wrote that
something that is trivial to implement (for example, strdup() or
asprintf()) are not added to the Standard. How come that 'bool'
which has a simple implementation was standardized ?

Excellent question. Why indeed?

Perhaps because so many programmers have defined their own boolean
types and/or constants in inconsistent ways.

 

[Keith Thompson]

Seebs wrote:
[A given kind of library] is not worth standardizing because
it is trivial.

In connection with this I have a question. You ever wrote that
something that is trivial to implement (for example, strdup() or
asprintf()) are not added to the Standard. How come that 'bool'
which has a simple implementation was standardized ?

Excellent question. Why indeed?

Perhaps because so many programmers have defined their own boolean
types and/or constants in inconsistent ways.

The same reasoning can be applied to container libraries. So why
weren't they standardised?

You're not really surprised that the standard isn't 100% consistent,
are you?

 

[Seebs]

In connection with this I have a question. You ever wrote that something
that is trivial to implement (for example, strdup() or asprintf()) are not
added to the Standard. How come that 'bool' which has a simple
implementation was standardized ? This not to start another flame, but to
try to understand the criteria of "triviality"

Long story short, I'm not sure. In the case of bool, I think the issue
is that, while it's very easy to write AN implementation of bool, it's
very hard to write one without one of a number of flaws, unless you're
the implementor.

(e.g., if you just make your own bool, and do "bool x = 3", is x == true?)

-s

 

[Richard Bos]

Long story short, I'm not sure. In the case of bool, I think the issue
is that, while it's very easy to write AN implementation of bool, it's
very hard to write one without one of a number of flaws, unless you're
the implementor.

(e.g., if you just make your own bool, and do "bool x = 3", is x == true?)

More perniciously, what if bool x = 4?

Richard

 

[Tech07]

jacob navia wrote:

Whatever you wrote, "THE" container library. "Surely you jest".

What is important at thisbstage is not the efficiency of the
individual routines. What is important now is to discuss if this
approach can lead to a general container library in C that could be
proposed as an example to standardize later.

You sound like Hitler. Why is that?

This post is intended to all people that believe that C can be used
as a general purpose programming language not only in embedded coffee
machines but also in high level machines.

Ah! The master race!

 

[Tech07]

What is important at thisbstage

"ain't no stage", you're promoting your new language. That's great! ( I mean
I think it is! ). But. you wannn drag these old C programmer's into i? Why?
They just wanna die. I don't thing you owe anyone anything that has come
before you. That said, I don't think that I'd concede to you either, as I am
writing the best language of the time, on my death bed, and it doesn't
include your elementary views of strings.

 

[Nick Keighley]

jacob navia wrote:


You sound like Hitler. Why is that?

one of The Lost Nuremburg Speeches was devoted entierly to the
implementation of container libraries?