Boost process and C

[Richard Heathfield]

jacob navia said:

This lack of depth in the discussion provokes that most people stop
contributing and go away.

So why the constant high traffic?

C people will be seen as a conservative group

Only by silly people who can't understand the very, very, very simple idea
of discussing /THIS/ computery stuff in comp.this and /THAT/ computery
stuff in comp.that.

of old fashioned programmers that do not go beyond the linked list and
are so conservative that harmless changes like generic functions, or
even default arguments are seen as an heresy.

No, they're seen as being suitable for discussion elsewhere.

This group has no chart actually,

That is true on so many levels, and is possibly the most accurate statement
you've ever made.

and this narrowing of the scope of
this discussion group about the C programming language (something that
also involves the evolution of C) has no legal basis whatsoever.

This isn't a question of "legal basis". This is a question of keeping
important expertise around. The traffic is quite high enough as it is, and
it's already impossible for busy people to read every article in sufficient
detail to do it justice.

If we start accepting questions on raw I/O, directory parsing, menu design,
getting and setting file attributes, free memory, process catalogs,
threads, free disk space, maps, the current background colour, detecting
and updating the current printing device, tape drives, vectors, BIOS
information, baud rate retrieval, drive letters, connecting to a socket,
pixel-scraping, default arguments, pids, uids, gids, EBCDIC, file
timestamps, partitioned data sets, interrupt vectors, updating the system
date and time, inheritance, process forking, classes, event handling,
setting the current drive, ASCII, operator overloading, pipes, interfacing
with physical registers, try/catch exception handling, connecting to a
database, bitmap file formats, clearing the screen, the syntax of select
statements, the syntax of SELECT statements, polymorphism, floodfill, pie
charts, text prediction, daemons, device contexts, resource handles,
multimaps, inline assembly language, iostreams, readln, writeln, setting
environment variables, curses, ncurses, vncurses, and all the rest of it,
then it will be rather harder for the experts in straightforward portable C
programming to discover where that expertise can best be applied.
Eventually they'll stop bothering to try, and that expertise will be lost
to Usenet.

But the "regulars" have always won in discouraging people from any
in-depth discussion.

Not true. What we have done is ***encouraged*** that discussion to take
place elsewhere on Usenet, where there are plenty of newsgroups for the
purpose.

Maybe because they fear that C will lose some original "purity"

No. Duh. It's because - here, let me try this in words of one syllable.

I. S. O. C source is good to port. Code that is not I. S. O. C is hard to
port. These are two things to talk, not one thing to talk. We need a place
where we can talk C that is good to port. This is that place. We need a
place where we can talk not-I.S.O. C, sure, but there are more place than
this place. You can use those place if you want to talk not I. S. O. C but
this place is for I. S. O. C and that is what we all want to talk. If you
want to talk I. S. O. C this is a good place and if you want to talk not I.
S. O. C there are lots of place where you can talk that.

Get it yet?

or (probably more often) because they believe that C++
is the future and that C should be destroyed as anything capable of
evolving.

Oh, for heaven's sake, this is programming, not a religion. People find it
useful to have a newsgroup for discussing portable C programming. If you
find that useful too, great, stick around - you're welcome to join the
group but not to destroy it. If you don't find it useful to have a
newsgroup for discussing portable C programming, great, that's fine, go
elsewhere where there are lots of other newsgroups.

I hope I am wrong.

Always, it seems.

 

[Richard Bos]

Keith Thompson a écrit :

But that's the point Keith. We want to talk ABOUT THE LANGUAGE ITSELF.

No, the regulars do. _You_ want to talk about your own little toy.

Well, do it somewhere else. There _are_ lcc newsgroups; go there if you
want to discuss an embrace-and-extend lcc-based suite.

Richard

 

[jacob navia]

Richard Bos a écrit :

No, the regulars do. _You_ want to talk about your own little toy.

Well, do it somewhere else. There _are_ lcc newsgroups; go there if you
want to discuss an embrace-and-extend lcc-based suite.

Richard

It is useless to discuss with you Richard. I do not want to discuss lcc
specific issues. I want to discuss about improving C strings for
instance, about a container library etc.

No matter how many times I say this, you will always answer with ironic
answers like "your little toy" etc.

You can go on if you wish. I will go on posting here. Neither you nor
anyone else has any authority to tell me what I should do or not do.

jacob

 

[Richard Heathfield]

jacob navia said:

I want to discuss about improving C strings for
instance, about a container library etc.

Nobody is stopping you. Why not get on with it? For example: what containers
do you think a standard C container library should make available? What
should the APIs look like? And how will you persuade people to use the new
library instead of whatever they are using right now?

I have asked these questions before. You seem reluctant to pursue them.

You can go on if you wish. I will go on posting here. Neither you nor
anyone else has any authority to tell me what I should do or not do.

That's right. You are free to throw your reputation down the tubes, and
nobody here can stop you, try as they might.

 

[jacob navia]

Richard Heathfield a écrit :

jacob navia said:




Nobody is stopping you. Why not get on with it? For example: what containers
do you think a standard C container library should make available?

What we should agree is a common interface for all containers, and
prescribe a few minimal ones.

A common interface means that all containers have the same method (i.e.
function name, arguments) for accessing it, adding to it, deleteing from
it, etc.

This allows the user to switch easily from one container (say a list) to
another (say a table) without too much rewriting of code.

The minimum set for containers would be:

Lists
Flexible arrays
Hashtables

What should the APIs look like?

We have the common verbs like Create, Add, Delete, Find, etc. The same
verbs should be used in all of them, if possible and if it makes sense.

I have several months ago proposed an interface for containers where we
use extensible function tables. In this manner we would keep the
interface flexible enough.

The first slot of a container would be a pointer to a table of functions
that would implement the different actions to be done in the container.
The creation function would fill that table.

The usage would be:

list->FnTable->Add(list,"Item");

In this way, the user could change specific parts of the API at run time
to fit his/her needs ("subclassing") easily.

And how will you persuade people to use the new
library instead of whatever they are using right now?

If this library is accepted by the standards comitee it would be added
to the language.

I have asked these questions before. You seem reluctant to pursue them.

Yes, because in this polemic situation it is difficult to discuss
matters with the necessary objectivity. I am not saying I know all the
answers and this is quite difficult. It is made even more difficult if
there is an hostile atmosphere around.

 

[Robert Latest]

We had this discussion already. I started yet another discussion about
the need for a portable standard container library several times and the
answers were:

[ quotes of clc regulars saying that such a library is
unnecessary snipped ... ]

And everyone accepted those things in silence. Nobody complained.

Which you failed to take as a pretty strong hint to the fact that
the regulars might be right, and you might be wrong.

The standards comitee doesn't even accept simple data structures like
strings. Lists, flexible arrays, stacks, queues, etc etc must be done
over and over, and are kept OUTSIDE the standard library.

Why?

Why not? This way the language itself is kept lean and simple,
and those that need more complex stuff can choose from a host of
good libraries that do what they want. GLib comes to mind as an
example.

I repeat that such an attitude towards data structures means that indeed
C is the past and C++ the dreaded future.

And who cares? Why the fuzz? Why are you wasting your time in a
Usenet group about a soon-to-be-dead language anyway?

robert

 

[Robert Latest]

Until they have to port it to a new environment. Then they will see how
easy is to port the libc. Basically you do not port it.

And the STL is easier to port?

robert

 

[Robert Latest]

Operator overloading is a well known technique, no need to swallow
all C++ to get it. Thank you

What's so great about operator overloading?

robert

 

[websnarf]

Where would you draw the line on topicality?

My interpretation is

Off topic:

Platform specific issues.
Product specific issues.

On topic:

The current language and its use.

This contradicts both of the two Off topic categories that you cite.

Potential improvements?

To which the familliar refrain is "if you don't like the features of C,
use some other language".

 

[CBFalconer]

Richard Heathfield a écrit :
.... snip ...
.... snip ...

The minimum set for containers would be:

Lists
Flexible arrays
Hashtables


We have the common verbs like Create, Add, Delete, Find, etc. The
same verbs should be used in all of them, if possible and if it
makes sense.

For some time there has been a solid and flexible hashtable
implementation available, under GPL. I wrote it, in purely
standard C, thus it is portable anywhere. I have heard no
bug-reports (after a very early one to do with a minor memory leak,
fixed). It is, and has been, freely accessible to all. You have
permission to use it, under the GPL of course.

<http://cbfalconer.home.att.net/download/hashlib.zip>

Incidentally, the API was developed via some discussions on this
very newsgroup. The system uses no wierd special provisions, such
as garbage collection, overloading, etc. It also imposes no
restrictions as to the kinds of data manipulated. At the same time
the code is fully re-entrant.

While I have to admit to some bias, I consider it a good example of
a C library module. Unlike lcc-win32, the source code is out there
and available for all to peruse and criticize.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[jacob navia]

Robert Latest a écrit :

What's so great about operator overloading?

robert

It is a technique for defining new numeric types and new kinds of
operations for numeric types.

This is not possible in standard C.

 

[Chris Hills]

And who cares? Why the fuzz? Why are you wasting your time in a
Usenet group about a soon-to-be-dead language anyway?

robert

Years ago one of my lecturers said:

"COBOL is Dead..... we have buried it EVERY year for the last 20 years!"

 

[jacob navia]

Robert Latest a écrit :

We had this discussion already. I started yet another discussion about
the need for a portable standard container library several times and the
answers were:

[ quotes of clc regulars saying that such a library is
unnecessary snipped ... ]

And everyone accepted those things in silence. Nobody complained.

Which you failed to take as a pretty strong hint to the fact that
the regulars might be right, and you might be wrong.

Of course the "regulars" are right. C should be kept as dead as
possible. This is of course RIGHT since you say that C++ is the best
thing in the world. There is no point in dveloping C. C++ has done it
already.

That's YOUR point of view, I disagree.

Why not? This way the language itself is kept lean and simple,

Lean and simple?

Assembler is even leaner and is much simpler.

and those that need more complex stuff can choose from a host of
good libraries that do what they want. GLib comes to mind as an
example.

Yes, that is precisely the point: " a HOST of good libraries" all of
them incompatible with each other and none part of a standard. The same
argument could be used in C++ AGAINST the STL, that you advocate in
another message.

Why is that good for C++ but not good for C?

And who cares?

I do

Why the fuzz?

Because I do not want that to happen.

Why are you wasting your time in a Usenet group about a soon-to-be-dead
language anyway?

The same reasons than you probably.
Usenet is there to allow people interchange ideas, proposals, ways of
working, etc

 

[websnarf]

No. I mean that some string operations can be expressed shorter
and with more clarity in Perl than in C. No new string library will change
this.

That's a pretty wishy washy premise on which to base an implied
disapproval of Bstrlib. Let me just guess that you haven't really
seriously taken a look at it.

Bstrlib + PCRE is virtually functionally equal to Perl. And of course,
since its C, it can support reference based sub-strings, and users have
compile time type safety assistance. If you use the C++ interface
(CBStrings) you will have comparable syntactical brevity to Perl.

If you want to actually change the C language to improve its
string support, as you seem to want, that's completely separate.
But your changes to C won't affect my software for 10 years or
more, because that's at least how long it'll take for them to get
into the standard (assuming they ever do) and then make it into
a wide range of real-world implementations.

Yes, but this criticism applies, at the very least, to the entire C99
standard as well; which is apparently not off topic in this news group.
Except that more likely, there is *no* amount of time that you will be
able to wait to be able to assume C99 compliance in most available C
compilers.

 

[Richard Heathfield]

jacob navia said:

Robert Latest a écrit :

It is a technique for defining new numeric types and new kinds of
operations for numeric types.

This is not possible in standard C.

He didn't ask what it is. He asked what's so great about it. The ability to
define new numeric types is of limited utility. It's good for bignums and
rationals, maybe for complex numbers and quaternions too, but that's about
it, really.

 

[jacob navia]

Richard Heathfield a écrit :

jacob navia said:




He didn't ask what it is. He asked what's so great about it. The ability to
define new numeric types is of limited utility. It's good for bignums and
rationals, maybe for complex numbers and quaternions too, but that's about
it, really.

A)

Consider that the MMX instruction set is around 10 years old now, and
that we have yet to see a mapping of those operations into C.

A "clamped" add is when you have

unsigned char a,b=200,c=200;

a = b+c;
// now a is 255, no wrap around. Value of addition
// clamped to highest possible value.

Since we can't redefine the operators in C, we would have to go to the
function call syntax (c=clamped_add(a,b)) what makes any using of
existing code impossible.

lcc-win32 provides bignums, qfloats, and other types of numbers easily
with this feature.

This feature could be used in other contexts, for instance in the
implementation of the fixed point features now added to a TR, without
making any new API or incompatible keywords...

B)

This feature is useful when applied to special forms of arrays. Suppose:
typedef struct _String {
size_t length;
char *data;
} String;

If you want to maintain the natural syntax

String s;
....

s[2] = 'e';

it is good to be able to overload the [].

C) Lcc-win32 implements complex numbers using this feature because that
way users can REPLACE the default implementation with their
implementation that could be better suited to their needs. This feature
allows users to replace parts of the library at will.

 

[Richard Heathfield]

jacob navia said:

Richard Heathfield a écrit :

What we should agree is a common interface for all containers, and
prescribe a few minimal ones.

Getting that agreement is a good 99.99% of the problem.

A common interface means that all containers have the same method (i.e.
function name, arguments) for accessing it, adding to it, deleteing from
it, etc.

See below.

This allows the user to switch easily from one container (say a list) to
another (say a table) without too much rewriting of code.

The minimum set for containers would be:

Lists
Flexible arrays
Hashtables

Presumably you would view a string as a slightly specialised form of
flexible array.

What about DAGs? Shouldn't they get a look-in? Lots of people want trees,
you know.

We have the common verbs like Create, Add, Delete, Find, etc. The same
verbs should be used in all of them, if possible and if it makes sense.

The names are important, it's true, but the parameter lists are of rather
more concern, are they not? And, of course, the return types.

I have several months ago proposed an interface for containers where we
use extensible function tables. In this manner we would keep the
interface flexible enough.

These sound a lot like vtables to me. Yes, we could indeed change C into
C++. But wouldn't it be much quicker and less effort just to call strcat(c,
"++")?

If this library is accepted by the standards comitee it would be added
to the language.

<shrug type="stuff in the C language that I never bother to use">
restrict
// comments
VLAs
complex numbers
flexible array members
compound literals
static qualifiers in parameter array declarations
type-generic math macros
long long int
designated initialisers
extended integer types
block scopes for selection and iteration
variable argument macros
vscanf
trailing commas in enums
%lf in printf
inline functions
snprintf
boolean type
empty macro args
_Pragma
VA_COPY
</shrug>
.......and no doubt much, much more.

Chuck the new containers onto the list - unless you can demonstrate some
real world advantage of the new container library that will persuade a
large proportion of the C community to abandon the stuff they:

* are already using;
* are already familiar with;
* have already ported to all the places they feel necessary.

An Oracle programmer (a very good one, I hasten to add) once told me of a
chap who came to his place of work in the early 1990s, attempting to
persuade them to convert from C to C++. The poor chap spent an hour or so
presenting an object-oriented database methodology to the Oracle guys. He'd
obviously worked very hard on it. As he was winding up his presentation and
heading rapidly towards "are there any questions?", he suddenly noticed
that just about everybody in the room was regarding him with utter
astonishment. He panicked, and said "What's the matter? Have I got
something wrong?" Came the reply, "No, no, maybe one or two bits could be
improved here or there... it's broadly okay though... but - we did all this
*years* ago! And you want us to write it *again*?"

I don't know whether the experience made him a wiser man, but he was
certainly better-informed.

I see no benefit to changing working code to use these hypothetical new
container libraries. If it ain't broke, don't fix it.

For new code - sure, why not, provided you can persuade people that the new
libs actually work properly, and are widely available. Six and a half years
on from the introduction of C99, I still can't use its new features because
they still aren't sufficiently widely available that I can send source code
to a complete stranger whom I know only to have an implementation claiming
to support "ANSI C"[1], and be able to *guarantee* that his implementation
will be able to understand C99 features.

Yes, because in this polemic situation it is difficult to discuss
matters with the necessary objectivity. I am not saying I know all the
answers and this is quite difficult. It is made even more difficult if
there is an hostile atmosphere around.

There would be less hostility, I suspect, if you didn't keep dumping lcc
extensions into your replies as if they were somehow magically topical
here.



[1] Please remember that the introduction of C99 did not magically change
the documentation of all existing implementations. The documentation for
Turbo C 2.01 still claims that it is an ANSI C compiler, even though ANSI C
has moved on and Turbo C 2.01 has not. It is not unreasonable for people to
expect to be able to compile ANSI C programs in Turbo C 2.01.

 

[Richard Heathfield]

jacob navia said:

A)

Consider that the MMX instruction set is around 10 years old now, and
that we have yet to see a mapping of those operations into C.

Consider that many computers don't /have/ the MMX instruction set. What
possible use could C mappings of MMX instructions be to a mainframe
programmer?

B)

This feature is useful when applied to special forms of arrays. Suppose:
typedef struct _String {
size_t length;
char *data;
} String;

If you want to maintain the natural syntax

String s;
...

s[2] = 'e';

it is good to be able to overload the [].

That's arguable. Some might consider it good. Others might consider it
unnecessarily confusing. [] suggests that s is an array, which it clearly
is not.

C) This feature
allows users to replace parts of the library at will.

Making the code harder to read, harder to understand, and harder to
maintain. If people aren't even going to /use/ the library, why bother
writing it?

 

[jacob navia]

Richard Heathfield a écrit :

jacob navia said:




Consider that many computers don't /have/ the MMX instruction set. What
possible use could C mappings of MMX instructions be to a mainframe
programmer?

Exactly. That is why you would use operator overloading in computers
that have the MMX instruction set (PCs) and not use any operator
overloading for those operations in computers that do NOT have that feature.

Compare this solution with other solutions where the language would add
a special |+ operation (or similar) to the language itself.

All implementations would have to use it.

The advantage of operator overloading here is PRECISELY that you do it
where it is needed and nowhere else!

The language is made extensible without adding any specific extension.

B)

This feature is useful when applied to special forms of arrays. Suppose:
typedef struct _String {
size_t length;
char *data;
} String;

If you want to maintain the natural syntax

String s;
...

s[2] = 'e';

it is good to be able to overload the [].

That's arguable. Some might consider it good. Others might consider it
unnecessarily confusing. [] suggests that s is an array, which it clearly
is not.

Excuse me, it IS an array, but indexed with an size_t offset from the
beginning that is all.

Making the code harder to read, harder to understand, and harder to
maintain. If people aren't even going to /use/ the library, why bother
writing it?

Why is this:

SomeIntType_t a,b=7,c=6;
a = b*c;

more *difficult* to read than

SomeIntType_t a,b,c;

intToSomeIntType(&b,7);
intToSomeIntType(&c,6);
SomeIntType_Add(&c,b,a);

?????????

 

[Richard Bos]

Richard Heathfield a écrit :

jacob navia said:

B)

This feature is useful when applied to special forms of arrays. Suppose:
typedef struct _String {
size_t length;
char *data;
} String;

If you want to maintain the natural syntax

String s;
...

s[2] = 'e';

it is good to be able to overload the [].

That's arguable. Some might consider it good. Others might consider it
unnecessarily confusing. [] suggests that s is an array, which it clearly
is not.

Excuse me, it IS an array, but indexed with an size_t offset from the
beginning that is all.

No, it is not. It is a struct.

s[2]='e' means that *(s+2) must now == 'e'. Is that true for your
struct? If so, how do I get a pointer to its first member? Is offsetof
not broken?

If you consider a feature which demands all those questions "natural",
you must live in the centre of a big city, and think milk comes from a
factory.

Richard