C needs a BOOST

[Eric Sosman]

Chris Thomasson wrote On 10/05/07 06:14,:

Humm... I will post an example LIFO linked collection API (e.g. stack) in a
day or two. We should be able to tear it apart into something usable... A
simple standardized API wrt this newsgroup could be beneficial. Well, any
question that deals with common/trivial collection abstractions can be
directed at the various implementations of this newsgroups standardized API.

There is only one requirement I would personally leverage against any
submission: The KISS principal should be the main goal... C is low-level,
therefore we should keep anything we create for this group bound to the land
of minimalism...

Any thoughts?

Perhaps it might be too ambitious to begin with
something as advanced as a stack. How about starting
with a lower-level data structure, just to get the
hang of designing API's that the C community at large
will find useful? How about a suite of functions to
manage an array of elements, for example?

struct ArrayHandle *
ArrayCreate(size_t count, size_t esize);

void
ArrayStore(struct ArrayHandle *handle,
size_t index, const void *pdata);

void
ArrayFetch(struct ArrayHandle *handle,
size_t index, void *pdata);

void
ArrayDestroy(struct ArrayHandle *handle);

Hmmm... Given the somewhat contentious tone of
the C discussion groups, even that might be too
controversial. It might be more prudent to begin
with an API for manipulating int values, like

int IntAdd(int x, int y);
int IntSubtract(int x, int y);
int IntMultiply(int x, int y);
int IntDivide(int x, int y);
int IntModulus(int x, int y);
_Bool IntLessThan(int x, int y);
_Bool IntLessThanOrEqual(int x, int y);
_Bool IntEqual(int x, int y);
_Bool IntGreaterThanOrEqual(int x, int y);
_Bool IntGreaterThan(int x, int y);
_Bool IntNotEqual(int x, int y);
int IntShiftLeft(int x, int bits);
int IntShiftRight(int x, int bits);
int IntAnd(int x, int y);
int IntInclusiveOr(int x, int y);
int IntExclusiveOr(int x, int y);
int IntUnaryMinus(int x);
int IntUnaryPlus(int x);
int IntComplement(int x);
long IntPromoteToLong(int x);
int LongDemoteToInt(long x);
int ShortPromoteToInt(short x);
short IntDemoteToShort(int x);
...

(For efficiency's sake, some of these functions might
also be implemented with masking macros.)

Comments?

 

[Douglas A. Gwyn]

bad analogy. In transistor count (ie. functionality) ICs are
getting bigger. Much bigger. That's one reason there are so few
CPU designs out there. Designing a modern IC is expensive.

It's not clear that that is a significant factor. The tools for
designing CPUs are much better also. There are still several
distinct CPU "designs" (by which I assume you mean ISAs), but
there is also no compelling reason to come up with a different
binary-incompatible design just for the sake of being different.
Being able to more or less painlessly replace existing older
parts is a significant economic advantage.

 

[Richard Heathfield]

Eric Sosman said:

Perhaps it might be too ambitious to begin with
something as advanced as a stack. How about starting
with a lower-level data structure, just to get the
hang of designing API's that the C community at large
will find useful? How about a suite of functions to
manage an array of elements, for example?

struct ArrayHandle *
ArrayCreate(size_t count, size_t esize);

Add parameters for maximum capacity (to prevent Denial of Memory attacks),
constructor (a pointer to a function that creates space for a new object
if necessary, and properly copies a provided object into it), destructor
(to take it down properly), and a comparator (to compare two objects
within the array). You might also want to add an iterator function
pointer, although you might prefer to provide an iterator-setting function
instead, since it is entirely possible that you might want to use
different functions for different purposes.

void
ArrayStore(struct ArrayHandle *handle,
size_t index, const void *pdata);

And another void * to allow ancillary data to be used in the copy, and
return an int which indicates whether the copy was successful.

void
ArrayFetch(struct ArrayHandle *handle,
size_t index, void *pdata);

How about returning a pointer to the object, to simplify the call?

void
ArrayDestroy(struct ArrayHandle *handle);

** rather than * please, so that the function can set the pointer to NULL
after taking down the object.

Hmmm... Given the somewhat contentious tone of
the C discussion groups, even that might be too
controversial. It might be more prudent to begin
with an API for manipulating int values, like

int IntAdd(int x, int y);
int IntSubtract(int x, int y);
int IntMultiply(int x, int y);
int IntDivide(int x, int y);
int IntModulus(int x, int y);

Add a mechanism to each of these for dealing with overflow, division by
zero, etc.

_Bool IntLessThan(int x, int y);
_Bool IntLessThanOrEqual(int x, int y);
_Bool IntEqual(int x, int y);
_Bool IntGreaterThanOrEqual(int x, int y);
_Bool IntGreaterThan(int x, int y);
_Bool IntNotEqual(int x, int y);

Why not int? No sense in alienating our 2 to 3% of Turbo C users...

int IntShiftLeft(int x, int bits);
int IntShiftRight(int x, int bits);
int IntAnd(int x, int y);
int IntInclusiveOr(int x, int y);
int IntExclusiveOr(int x, int y);
int IntUnaryMinus(int x);
int IntUnaryPlus(int x);
int IntComplement(int x);

Again, you need mechanisms to deal with invalid inputs.

long IntPromoteToLong(int x);
int LongDemoteToInt(long x);
int ShortPromoteToInt(short x);
short IntDemoteToShort(int x);

Same here (for the demotions, at least).

...

(For efficiency's sake, some of these functions might
also be implemented with masking macros.)

Comments?

Yes, I think those would be a good idea too.

 

[Douglas A. Gwyn]

Why calculating the gamma function is deemed worth of
standardization and not a common place routine like the handling of
a single linked list?

Because enough users want to have a gamma function ready to use,
and implementing it correctly is non-trivial. Unlike linked-list
handling, which is trivial to do in-line in C code.

You say:
"... unless, perhaps, you don't know how to design it well enough
for reuse".
This attitude is unwarranted Mr Gwyn.

But you just told us that you think each project necessarily has
its own implementation of such a library.

 

[jacob navia]

[snip nonsense]

You can't contribute anything to this discussion, then, you
try to destroy it.

 

[Walter Roberson]

Hmmm... Given the somewhat contentious tone of
the C discussion groups, even that might be too
controversial. It might be more prudent to begin
with an API for manipulating int values, like

int IntAdd(int x, int y);
int IntSubtract(int x, int y);
int IntMultiply(int x, int y);
int IntDivide(int x, int y);

If we're going to design an API around such things, we should have
provision for detecting underflow and overflow; we also need to
consider what layer we would want potential "saturate on overflow"
to be handled.

int IntShiftLeft(int x, int bits);
int IntShiftRight(int x, int bits);

Unless you wish to handle negative bit counts, the bits
parameter should be unsigned.

int IntUnaryPlus(int x);

Behaviour on -0 ?

 

[Walter Roberson]

[snip nonsense]

You can't contribute anything to this discussion, then, you
try to destroy it.

It wasn't nonsense -- it was merely the equivilent of
"stretching exercises" before getting down to the hard work.

 

[Francine.Neary]

Chris Thomasson wrote On 10/05/07 06:14,:






Perhaps it might be too ambitious to begin with
something as advanced as a stack. How about starting
with a lower-level data structure, just to get the
hang of designing API's that the C community at large
will find useful? How about a suite of functions to
manage an array of elements, for example?

struct ArrayHandle *
ArrayCreate(size_t count, size_t esize);

void
ArrayStore(struct ArrayHandle *handle,
size_t index, const void *pdata);

void
ArrayFetch(struct ArrayHandle *handle,
size_t index, void *pdata);

void
ArrayDestroy(struct ArrayHandle *handle);

Hmmm... Given the somewhat contentious tone of
the C discussion groups, even that might be too
controversial. It might be more prudent to begin
with an API for manipulating int values, like

int IntAdd(int x, int y);
int IntSubtract(int x, int y);
int IntMultiply(int x, int y);
int IntDivide(int x, int y);
int IntModulus(int x, int y);
_Bool IntLessThan(int x, int y);
_Bool IntLessThanOrEqual(int x, int y);
_Bool IntEqual(int x, int y);
_Bool IntGreaterThanOrEqual(int x, int y);
_Bool IntGreaterThan(int x, int y);
_Bool IntNotEqual(int x, int y);
int IntShiftLeft(int x, int bits);
int IntShiftRight(int x, int bits);
int IntAnd(int x, int y);
int IntInclusiveOr(int x, int y);
int IntExclusiveOr(int x, int y);
int IntUnaryMinus(int x);
int IntUnaryPlus(int x);
int IntComplement(int x);
long IntPromoteToLong(int x);
int LongDemoteToInt(long x);
int ShortPromoteToInt(short x);
short IntDemoteToShort(int x);
...

(For efficiency's sake, some of these functions might
also be implemented with masking macros.)

Comments?

Wouldn't it be a good idea to reduce the risk of conflicting with an
existing implementation of these valuable functions by working in a
clc "namespace"? E.g. clc_IntAdd() etc.

You could also add some useful constants that users of the integer
library might need to refer to: CLC_INT_ZERO, CLC_INT_ONE and
CLC_INT_FORTY_TWO, for example.

 

[Wojtek Lerch]

Just out of curiosity, who were you responding to? My newsreader displays
posts sorted by time, not as a tree.

 

[jacob navia]

Just out of curiosity, who were you responding to? My newsreader
displays posts sorted by time, not as a tree.

[snip nonsense]

You can't contribute anything to this discussion, then, you
try to destroy it.


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

To Sossman and Heathfield that post nonsense with no
other motive than to laugh about any proposal to do
something here.

 

[Douglas A. Gwyn]

Actually then, you say it is better not to develop anything new in C.

That's not what I said. I said that *much* new development ought
to be done in higher-level languages. (In fact, it often is.)

That means that the potential benefit of new facilities for such
applications is diminished.

I would like that you claify this of course. Did I understand you
correctly?

I doubt that you did.

My opinion, based on considerable experience in this area, is that
C remains the best choice for much "systems implementation" work,
but that it is more cost-effective to use other, higher-level
languages for many "applications".

I happen to prefer C for my own one-person development projects,
but then I am especially proficient in it. For larger projects,
if C is selected then much attention/supervision will be needed
to ensure that appropriate disciplines are imposed upon its use,
in order to meet goals of reliability and maintainability. There
are other languages where less effort is needed for that purpose.
Also, C is designed to give the programmer considerable control
over details, to the extent that it *requires* the programmer to
be concerned over details. Again, there are other languages
where this is less of a burden.

It is (in my opinion) a mistake to try to push C (in any variant)
as a general solution for all programming problems. It's a
good choice for the systems programming that it was designed for,
although it still has deficiencies even for that. I would rather
the time spent discussing directions for C concentrate more on
remedies for its remaining deficiencies for systems work than on
trying to support applications where there are better choices.

 

[Douglas A. Gwyn]

C can still be a good choice for many new projects.

Sure, and I haven't said otherwise. I use it myself.

I maintain that C is not a good choice for most "modern" major
applications. However, if you already have access to a good
C programming support environment (libraries, disciplines) then
that could influence the decision. Also, C still has an edge
over any of the alternatives when it comes to breadth of
portability.

 

[Douglas A. Gwyn]

The fact that C99 is already to big and requires YEARS to be implemented
correctly (unlike C90 which is much simplier)

C99 didn't *require* years to implement. In fact, there was at least
one C99 front end (from Edison) not very long after C99 was published.

The bulk of the additions to C99 were in the library functionality.
The additional library facilities add no appreciable complexity, just
more work for somebody (Dinkumware, perhaps?). The added data types
don't much complicate the compiler, although some platforms have to
come up with additional run-time arithmetic support. The main
complication is <tgmath.h>, which generally is non-trivial to add to
a C90 compiler. VLAs could also require a bit of extra work.

The rate at which C99 conformance is being attained by GCC could be
explained by a combination of low customer demand (C90 being adequate
for most C programmers) and relative lack of interest by implementors.

 

[Douglas A. Gwyn]

(C99 broke the portability dream, ...

Only in that using its new features precludes easy porting to a
C90 environment. Since it is nearly a pure extension of C90
(with the exception of implicit int, which most programmers
seem happy to have removed), porting C90 code to C99 environments
is generally not a problem. Indeed, such forward compatibility
was the main constraint when revising the C standard. Stability
at this level is important for the industry.

 

[Douglas A. Gwyn]

_Bool IntGreaterThanOrEqual(int x, int y);
Comments?

Please don't continue the API design discussion in comp.std.c.
Once you have settled on something, it might be within the
charter of comp.std.c to suggest that it be standardized,
but until then it really is outside the charter of comp.std.c.

 

[Richard Heathfield]

jacob navia said:

To Sossman and Heathfield that post nonsense with no
other motive than to laugh about any proposal to do
something here.

Mr Navia: my reply was entirely serious. If you find it amusing, that's up
to you, but it was not intended so.

Just out of curiosity: are all Frenchmen so wilfully ignorant as to drop
honorifics from names (as you habitually do), or is it just you giving
your countrymen a bad name?

 

[Douglas A. Gwyn]

Did you know that C++ had slowly evolved from C?
"C with objects" was very small.
Then, it became C++ as new features were added.

Well, that's not entirely accurate. Bjarne started out with
"C with classes", which I used to distribute as a freebie with
the BRL Unix System V emulation before C++ replaced it. "C
with classes" was implemented as a preprocessor selected by the
"cc" driver whenever "#class" had been detected in the source
code by the C preprocessor phase. The early "C++"
implementations were based on a similar architecture (the
"cfront" preprocessor).

Similarly C evolved continuously from B...

C didn't evolve continuously from B. C was inspired by B, but
had a new design and implementation of its own. C did evolve,
of course.

 

[André Gillibert]

no you didn't.
Why do you say things like this!

He didn't for the post in which he said that he didn't.
In other words, he kindly accepted my criticisim about exclamation marks
and adopted a good style.

 

[jxh]

It's simply huge, very complex, and causes linking issues.
It's also quite weak without function overloading support with complex
resolution rules.
Classes support, with constructors and destructors, also greatly help to
the functionality of C++ templates.

I think it is rather myopic to dismiss the potential usefulness
without
at least trying. The weaknesses and limited usefulness of C macros
has
not dampered attempts to use them for generic programming in C. Why
not
provide the generic programmers better tools? Adding template support
wouldn't even break backward compatibility (except for the creation of
new keywords, probably at least "template" and "typename").

As I am proposing C templates, there are no objects and function
overloading. Function and struct name expansion occurs from explicit
instantiation of the templated function or struct.

However, even without supporting the notion of C++ methods, adding the
notions of constructor and destructor to C structs would be
tremendously
useful (at the very least, it would provide an easy to use alternative
to using a "goto" to the end of the function to do common cleanup).
Note that this is not advocating object oriented programming, since I
am not proposing methods or inheritance.

I believe I read an article about Bjarne Stroustroup where he
mentioned
that if he had introduced templates earlier, he would have de-
emphasized
the use of inheritance as a mechanism for code reuse in his C++
material.

-- James

 

[André Gillibert]

Only in that using its new features precludes easy porting to a
C90 environment.

Yes, that was my point.
When writing pure C90 code, you get the good feeling that it'll be easily
ported everywhere.
That's one of the reasons that explain why C99 has been adopted very
slowly.

Since it is nearly a pure extension of C90
(with the exception of implicit int, which most programmers
seem happy to have removed),

And size_t which can be larger than unsigned long or ptrdiff_t which can
be larger than long.

Otherwise, there're no big incompatibilities.