Boost process and C

[extrudedaluminiu]

Hi,

Is there any group in the manner of the C++ Boost group that works on
the evolution of the C language? Or is there any group that performs an
equivalent function?

Thanks,
-vs

[CBFalconer]

jacob navia wrote:

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

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?

.... snip ...
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.

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 :

On 2006-04-30, jacob navia <ja***@jacob.remcomp.fr> wrote:

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.

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,

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?

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

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]

Ben Pfaff wrote:

jacob navia <ja***@jacob.remcomp.fr> writes:

Ben Pfaff a icrit :

we******@gmail.com writes:
You are saying you should throw out an entire language because you
don't like the way it handles strings?
It depends on your priorities. I wouldn't want to rewrite a Perl
program that does complex string processing in C. It's going to
get a lot longer and possibly harder to read (depending on how
much taste the Perl programmer had).
You mean then in substance:

"Since C strings are completely screwed up, do NOT try to change that,
but learn Perl".

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.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Richard Heathfield]

jacob navia said:

Robert Latest a écrit :

On 2006-04-29, jacob navia <ja***@jacob.remcomp.fr> wrote:

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

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[jacob navia]

Richard Heathfield a écrit :

jacob navia said:

Robert Latest a écrit :

On 2006-04-29, jacob navia <ja***@jacob.remcomp.fr> wrote:

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

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.

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.

[Chris Hills]

In article <sl**********************@localhost.localdomain> , Robert
Latest <bo*******@yahoo.com> writes

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!"
:-)
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Richard Heathfield]

jacob navia said:

Richard Heathfield a écrit :

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 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.

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.

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,
"++")?

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.

<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.

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.

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
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[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?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[jacob navia]

Richard Heathfield a écrit :

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?

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.

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?

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]

jacob navia <ja***@jacob.remcomp.fr> wrote:

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

[Richard Heathfield]

jacob navia said:

Richard Heathfield a écrit :

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?

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.

In other words, it would be an implementation extension rather than part of
the language - which is basically what happens now. Code that used it would
not be portable to computers that don't have that functionality.

<snip>

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.

Excuse me, but it is *not* an array. It is an instance of a struct type
containing an array.

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?

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);

?????????

The function calls in the second version remind the reader that something
more complicated than mere arithmetic is happening. At present, a
maintenance programmer is entitled to assume from a single glance that a =
b * c is merely an arithmetic operation, obviously of no consequence in his
bug hunt, whereas what you are proposing would mean that such an operation
could conceal an arbitrary number of side effects, and indeed may not even
have anything whatsoever to do with multiplication.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Flash Gordon]

jacob navia wrote:

Richard Heathfield a écrit :

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?

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!

If I write code depending on the |+ operator then I need it implemented
on all the systems I need it ported to. It does not matter to me whether
it is implemented as an MMX instruction or a function call. You don't
need operator overloading for that, you need it added to the base language.
The language is made extensible without adding any specific extension.

The reserved namespace and stating in the standard that extensions are
allowed does that. Hell, since |+ is currently an error you can add it
as an extension to your compiler if you want, as long as it produces a
diagnostic when invoked in standard conforming mode! No need for
operator overloading to allow you to do that.

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.

It's a structure containing an array.

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?

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);

?????????

Well, your suggestion here seems to have use * for addition... ;-)

Anyway, I would have done
SomeIntType_t a;
SomeIntType_t b = makeSomeTime(7);
SomeIntType_t c = makeSomeTime(6);

c = SomeTypeMult(b,c);

Unless the operation is very complex, in which case it might be worth
people knowing that rather than thinking, oh, that's just a multiplication.

Operator overloading may well be useful. So feel free to propose it to
the standard committee. However, that is not this group which discusses
the existing language.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

[Jordan Abel]

On 2006-05-02, jacob navia <ja***@jacob.remcomp.fr> wrote:

Richard Heathfield a écrit :

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?

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.

More likely you mean, use a new type with a real operator that does that
on computers that have MMX, and use operator overloading to implement
saturation arithmetic in software on computers that don't have it.

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.fr> writes:

Robert Latest a écrit :

On 2006-04-30, jacob navia <ja***@jacob.remcomp.fr> wrote:

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.

jacob, until you stop making these *absurd* claims about what you
think everyone else believes, you will not be taken seriously here.

The "regulars" do not believe, and have never stated, that "C should
be kept as dead as possible", or that "C++ is the best thing in the
world". In attempting to support this ridiculous claim, you have
quoted E. Robert Tisdale, a notorious troll who absolutely does not
represent the point of view of anyone else in this newsgroup.

Most of us believe that C is (in many ways) a good language as it is,
though there is certainly room for improvement. Many of us believe
that C++ or other languages might be more appropriate than C for some
tasks; that in no way implies that C is, or should be, a dead
language.

Until and unless you understand that, you will not be able to have any
kind of serious discussion here. At the very least, I suggest you
stop trying to tell us what *we* believe, and concentrate on telling
us what *you* believe (assuming it's topical).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

we******@gmail.com writes:

Ian Collins wrote:

Where would you draw the line on topicality?

My interpretation is [...] Potential improvements?

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

If you don't like the features of C, you can either:

(1) Do without, or

(2) Use some other language that provides those features, or

(3) Use a C compiler that implements those features as an extension
(thus tying your code to that specific implementation), or

(4) Push to have the new features added to the next revision of the C
standard, and then wait for the new standard to be published, and
then wait for implementations to support the new standard. If
you're *very* lucky, this might take as little as a decade.

If you think the standardization process is too slow, you can discuss
it in comp.std.c. If you know of an alternative other than the ones
I've mentioned (and they've *all* been mentioned here), feel free to
suggest it.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[CBFalconer]

jacob navia wrote:

Robert Latest a écrit :

.... snip ...

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

Lean and simple?

Assembler is even leaner and is much simpler.

Please post the source code to the last project you wrote in
assembler, and which ported unchanged to, say, an 8080, an 8051, an
8086, a 6800, a68000, an IBM 360/370, a PDP11, an HP3000. I trust
it ran to completion, and produced the same output on all systems
for the same input.

I won't insist on any more than the above selection. Note that I
even omitted a PIC and the Rabbit and the 6502. I will even let
you pick the (available) OS for each machine. However I do expect
more than a single 'halt' instruction.

--
"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/>

[CBFalconer]

we******@gmail.com wrote:

Ben Pfaff wrote:

.... snip ...

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.

The last time I took an (admittedly cursory) look at Bstrlib, I
found it cursed with non-portabilities and unwarrented assumptions,
not to mention an interminable API. This is a criticism very few
can make of the standard C string operations.

--
"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/>

[CBFalconer]

Richard Heathfield wrote:

.... snip ...
[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.

In fact, that is one portability test I try to apply to my code.
It has been known to rub ones nose in unwarranted assumptions.

--
"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/>

[Ben Pfaff]

we******@gmail.com writes:

Ben Pfaff wrote:

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.

I've never looked at Bstrlib, so I have no comments specifically
about it. But I believe that my statement holds in general.
--
Ben Pfaff
email: bl*@cs.stanford.edu
web: http://benpfaff.org

[Ian Collins]

Robert Latest wrote:

On 2006-04-30, jacob navia <ja***@jacob.remcomp.fr> wrote:

Third step - get people to use your shiny new standard container library.
Except that they won't, of course, because they will all just carry on
using whatever it is that they're using right now.

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?

I think the point was you don't have to, because it is part of the
language, the compiler vendor does this.

--
Ian Collins.

[Ian Collins]

Robert Latest wrote:

On 2006-04-29, jacob navia <ja***@jacob.remcomp.fr> wrote:

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?

Nothing that justifies adding it to C.

--
Ian Collins.

[Ian Collins]

we******@gmail.com wrote:

Ian Collins wrote:

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.

How and where?

--
Ian Collins.

[Mark McIntyre]

On Mon, 01 May 2006 23:40:44 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:

Keith Thompson a écrit :

comp.lang.c++ in effect tried a similar experiment some years ago. It
barely survived. As it drowned in a flood of discussions of
system-specific C++ programming, the regulars who wanted to talk about
the language itself drifted away.

But that's the point Keith.

The point is that you want the regulars to drift away? Stop taking
acid please.
We want to talk ABOUT THE LANGUAGE ITSELF.
indeed.
Not just the narrow definition of "The language as it was in 1989" or
"The language as specified in the C standard",
but that *is* the language.
but including discussions
like this discussion, that is the first in many years that touches
topics that go beyond
your idea is like creating a group specially to discuss the French
language, but insisting to also discuss Franglais, patois, lingala,
and all the other derivants of French.
Everything is frozen here, like in a museum.

You're quite wrong, but then I don't expect you to see this, since you
have a twisted and bizarre view of CLC. Please go away and play
somewhere else.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Mark McIntyre]

On Tue, 02 May 2006 14:06:50 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:

Yes, because in this polemic situation it is difficult to discuss
It is only polemic because you make inflammatory statements like this:
Everything is frozen here, like in a museum.
Neither you nor anyone else has any authority to tell me what I should do or not do.
And make false statements such as
Substantive discussions about software constructions, pro/cons of
specific ways of writing in C, or discussions about the language itself
and its direction, new proposals etc, are
"beyond the scope of this group".

The first three of these are entirely topical here and are frequently
discussed. The last is indeed offtopic, since its the subject of
comp.std.c.

I really do find it hard to see why you can't understand this. Perhaps
you ought to stop being so "gallic" and feeling insulted about it, and
try to listen to the advice you receive instead. Is it /really/ so
difficult to restrict your posts to topical material, and avoid
wandering off into discussions about how lcc's extensions work, or dos
assembly language or whatever?
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Mark McIntyre]

On Tue, 02 May 2006 15:36:16 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:

C should be kept as dead as
possible.
Yup, its dead. You can move on now, nothing to see.Usenet is there to allow people interchange ideas, proposals, ways of
working, etc

indeed. So why don't you interchange some, instead of trying to force
everyone to agree with you? :-)

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Mark McIntyre]

On Tue, 02 May 2006 15:27:59 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:

Robert Latest a écrit :

What's so great about operator overloading?
It is a technique for defining new numeric types and new kinds of
operations for numeric types.

And? Whats so great about that?
This is not possible in standard C.

Yes. And?

Whats your point? That other environments have features that are
useful? Great. In that case will you please add the sys$system
routines to lcc immediately, they were handy features too, like
whenever I need to rewind a DEC tape or dismount a cluster member in
my 8800s.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Mark McIntyre]

On Tue, 02 May 2006 15:53:55 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:

Richard Heathfield a écrit :

jacob navia said:

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

He didn't ask what it is. He asked what's so great about it.

Consider that the MMX instruction set is around 10 years old now,

Can you point out where in my 80386 and in my 68000 the MMX
instructions are to be found? Please don't claim that these chips are
no longer used. How about in the IA-64 core or in the chip driving my
(and probably your) router? Or in my palmtop PC or DVD recorder?
and that we have yet to see a mapping of those operations into C.

perhaps because not all the world's a pentium?
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Mark McIntyre]

On 2 May 2006 06:37:47 -0700, in comp.lang.c , we******@gmail.com
wrote:

Ben Pfaff wrote:

jacob navia <ja***@jacob.remcomp.fr> writes:

> Ben Pfaff a icrit :
>> we******@gmail.com writes:
>>>You are saying you should throw out an entire language because you
>>>don't like the way it handles strings?
>> It depends on your priorities. I wouldn't want to rewrite a Perl
>> program that does complex string processing in C.
>
> You mean then in substance:
>
> "Since C strings are completely screwed up, do NOT try to change that,
> but learn Perl".

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.

Ben did not say that, you made it up to provoke a reaction. Please
don't do that, it detracts from the quality of your arguments and
causes people to apply hostile filters.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[regis]

Bill Pursell wrote:

Operator overloading is, IMHO, a really, really bad idea. I've only
been coding C for just under a year, and 11 months ago I was really
bent out of shape that I couldn't write:
struct foo A,B,C;
A = B + C;
but I'm really glad now that I can't, and I would hate to see operater
overloading be expanded in C. Operator overloading in C is the root
cause of a very large number of bugs already. How many bugs are a
result of "3+4" being different that "3.0 + 4.0"? Those bugs would
have been avoided had the programmer been required to type
"int_add(3,4)" or "float_add(3,4)". Now, I'm not arguing that the '+'
symbol be dropped for arithmetic on basic numeric types, but expanding
the language to allow '+' as an infix operator on user-defined structs
is just asking for trouble. The only gain is (arguably) cleaner code,
but quite frankly "A = foo_add(B,C)" is more informative than "A =
B+C" and less prone to error.

without operator overloading, how about just an infix notation
for 2-ary functions (with, e.g., functions evaluated left to right,
all with the same priority) ?

typedef struct Vect { double x, y; } Vect;

infix Vect Vect_Sub (Vect u, Vect v) {
return (Vect) { .x= u.x - v.x, .y= u.y - v.y };
}
infix Vect Vect_Scale (double lambda, Vect u) {
return (Vect) { .x= lambda*u.x, .y= lambda*u.y };
}
infix double Vect_Dot (Vect u, Vect v) {
return u.x * v.x + u.y * v.y;
}
int main (void) {
Vect u, v, w, p, q, r, s, t;
...
t= ((v Vect_Sub u) Vect_Dot (w Vect_Sub v))
Vect_Scale (p Vect_Sub q Vect_Sub r Vect_Sub s);
...
}

[CBFalconer]

Ian Collins wrote:

Robert Latest wrote:

On 2006-04-30, jacob navia <ja***@jacob.remcomp.fr> wrote:
.... snip ...

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?

I think the point was you don't have to, because it is part of the
language, the compiler vendor does this.

And, if you write the library in truly portable C, without any
silly extensions and/or entanglements, you just compile the library
module. All the compiler vendor need to do is meet the
specifications of the C standard.

Simple, huh?

--
"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/>

[Ian Collins]

CBFalconer wrote:

Ian Collins wrote:

Robert Latest wrote:

On 2006-04-30, jacob navia <ja***@jacob.remcomp.fr> wrote:

.... snip ...
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?

I think the point was you don't have to, because it is part of the
language, the compiler vendor does this.

And, if you write the library in truly portable C, without any
silly extensions and/or entanglements, you just compile the library
module. All the compiler vendor need to do is meet the
specifications of the C standard.

I think the point of the original paragraph has been lost, the reason to
have a standard library is to remove the need for everyone to roll their
own and get newcomers producing useful applications faster. Sure there
are those of us with our own tried and trusted solutions, but that
doesn't help the newcomers.

The same thing happened with C++, before the standard there were many
incompatible commercial and private libraries, now most of these have
been replaced with standard implementations.

It's a win win situation, you can still use your own if you choose.

--
Ian Collins.

[websnarf]

CBFalconer wrote:

we******@gmail.com wrote:

Ben Pfaff wrote: ... snip ...

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.

The last time I took an (admittedly cursory) look at Bstrlib, I
found it cursed with non-portabilities

You perhaps would like to name one?
[...] and unwarrented assumptions,
Such as?
not to mention an interminable API.
It is not necessary to learn or use the entire API to use it
effectively. If it seems large you can blame the current crop of users
who have motivated all the extensions from its original base functions.
In each case I could not make a strong enough case to avoid each
functions' inclusion. You appear to be the only person obsessed with
this non-issue.
[...] This is a criticism very few can make of the standard C string operations.

The C standard says that whether or not "string literals" are writable
is platform specific. It doesn't even specify what wchar_t contains
-- for example, the WATCOM compiler supports the old UCS-2 in its 16
bit compilers, and UTF-32 in its 32 bit compilers (while not
implementing a properly functioning setlocale function). So much for
portability. Bstrlib is *designed* for portability (including semantic
behavior irrespective of platform).

Every C string function which writes makes the one unwarranted
assumption that it cannot make -- i.e., that the size of the buffer
that holds the destination will be large enough for whatever operation
it is doing. fgets() makes the assumption that the input stream is in
text mode, or that it doesn't read a '\0' or that you just don't care
about that case. Nearly every string function *assumes* that the
parameters are non-aliasing (that's worse than just an unwarranted
assumption -- its just degenerate in terms of functionality). It is
*assumed* that you don't make interleaved calls strtok on different
strings. And of course, the format of C strings *assumes* that '\0'
will never be considered part of a string's content -- this assumption
ends up permeating all system string APIs, for any platform that uses C
as its main implementation language.

In terms of API size, Bstrlib is about 80 base C functions (which
includes the stream API functions) and 18 macros (there are 22 "bonus"
functions for doing MIME parsing and other miscellaneous utilities, and
there is a C++ API). The string.h file for one of my compilers has
about 57 extern functions. Then we need to add
(f|s|v|vs|sn|vsn|vf|)printf, (f|)puts, (f|)gets, (s|)scanf, ato(f|i|l),
strto(d|l), which is 19 all by itself. Add in the wide characters and
you'll nearly double that count. Bstrlib is not drammatically more
"interminable" than the standard C library.

And you just can't compare the size of the APIs to judge how easy it is
to use or understand. To know all of the undefined scenarios of the C
library functions, you have to do a function by function examination of
the standard. With Bstrlib, all you have to do is make sure each
parameter is well defined, you don't abuse the write protection, and
don't destroy a value if you use an alias of it later. So the effort
to understand each function is Bstrlib is far lower. The functions in
Bstrlib also tend, on average, to do a lot more per function -- so your
investment in understanding has a higher payoff. And the thing is open
source, so there is never any ambiguity about any Bstrlib function that
you cannot authoritatively figure out on your own.

So I don't know what you last looked at, because you are just plain
wrong.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[websnarf]

Keith Thompson wrote:

we******@gmail.com writes:

Ian Collins wrote:

Where would you draw the line on topicality?
My interpretation is [...] Potential improvements?
To which the familliar refrain is "if you don't like the features of C,
use some other language".

If you don't like the features of C, you can either:

(1) Do without, or

(2) Use some other language that provides those features, or

(3) Use a C compiler that implements those features as an extension
(thus tying your code to that specific implementation), or

(4) Push to have the new features added to the next revision of the C
standard, and then wait for the new standard to be published, and
then wait for implementations to support the new standard. If
you're *very* lucky, this might take as little as a decade.

If you think the standardization process is too slow, you can discuss
it in comp.std.c.

Its not just slow -- its *WRONG*. They add things that shouldn't be
added, and they rarely remove things, even things where there simply is
no question that they need to be removed.
[...] If you know of an alternative other than the ones
I've mentioned (and they've *all* been mentioned here), feel free to
suggest it.

How about doing what the GMP authors did, what Hans Boehm did with his
Boehm garbage collector, and what I've done in my own priviate
libraries (a self debuging heap with sub-heaps with fast mass-free
capabilities, coroutines, etc.)? Just *do it* and shake your head at
the standards committee who are of no help. (Then there is the Walter
Bright/Jacob Navia solution -- but I don't have the energy to build my
own compiler.)

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[P.J. Plauger]

<we******@gmail.com> wrote in message
news:11**********************@j33g2000cwa.googlegr oups.com...

[...] If you know of an alternative other than the ones
I've mentioned (and they've *all* been mentioned here), feel free to
suggest it.

How about doing what the GMP authors did, what Hans Boehm did with his
Boehm garbage collector, and what I've done in my own priviate
libraries (a self debuging heap with sub-heaps with fast mass-free
capabilities, coroutines, etc.)? Just *do it* and shake your head at
the standards committee who are of no help. (Then there is the Walter
Bright/Jacob Navia solution -- but I don't have the energy to build my
own compiler.)

For once we are in agreement. Standardization works best when it
*codifies existing practice*. Absent existing practice, standards
committees indulge in speculative invention. Even if that invention
is done well it may not have much of a market.

So if you think you know how to evolve C, *just do it*. Build a
following and your bright new addition will be an obvious candidate
for a future DR, or revision of the C Standard. And meanwhile you
don't have to wait a decade for those stodgy old, uh, committee
members to do the obvious.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

[Robert Latest]

On 2006-05-02, Keith Thompson <ks***@mib.org> wrote:

If you don't like the features of C, you can either:

[ suggestions (1) through (4) snipped ]

(5) Write a compiler that supports the needed features,
preferably for a popular platform with a wide user
base such as Windows, and make it available for free.

If people like the language extensions, they will become popular
quickly and make it into other implementations as well, thus
creating what is known as a "de facto standard". No need to wait
for an ISO committee.

robert

[RSoIsCaIrLiIoA]

On Tue, 02 May 2006 -0400, CBFalconer <cb********@yahoo.com> wrote:

jacob navia wrote:

Robert Latest a écrit :... snip ...

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

Lean and simple?

Assembler is even leaner and is much simpler.

Please post the source code to the last project you wrote in
assembler, and which ported unchanged to, say, an 8080, an 8051, an
8086, a 6800, a68000, an IBM 360/370, a PDP11, an HP3000. I trust
it ran to completion, and produced the same output on all systems
for the same input.

"Please post the source code to the last project you wrote in"
some portable C code more complex than
"#include <stdio.h>
int main(void){printf("Hello World\n"); return 0;}"
I won't insist on any more than the above selection. Note that I
even omitted a PIC and the Rabbit and the 6502. I will even let
you pick the (available) OS for each machine. However I do expect
more than a single 'halt' instruction.

[CBFalconer]

we******@gmail.com wrote:

CBFalconer wrote:

.... snip ...

The last time I took an (admittedly cursory) look at Bstrlib, I
found it cursed with non-portabilities

You perhaps would like to name one?

I took another 2 minute look, and was immediately struck by the use
of int for sizes, rather than size_t. This limits reliably
available string length to 32767. I did find an explanation and
justification for this. Conceded, such a size is probably adequate
for most usage, but the restriction is not present in standard C
strings.

--
"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/>

[websnarf]

P.J. Plauger wrote:

<we******@gmail.com> wrote in message

[...] If you know of an alternative other than the ones
I've mentioned (and they've *all* been mentioned here), feel free to
suggest it.
How about doing what the GMP authors did, what Hans Boehm did with his
Boehm garbage collector, and what I've done in my own priviate
libraries (a self debuging heap with sub-heaps with fast mass-free
capabilities, coroutines, etc.)? Just *do it* and shake your head at
the standards committee who are of no help. (Then there is the Walter
Bright/Jacob Navia solution -- but I don't have the energy to build my
own compiler.)

For once we are in agreement. Standardization works best when it
*codifies existing practice*.

Ooooh! You mean like TR 24731? Are you sure that you are codifying
actual existing practice?
[...] Absent existing practice, standards
committees indulge in speculative invention.
You mean like complex numbers (but specifically excluding Gaussian
integers)?
[...] Even if that invention
is done well it may not have much of a market.

So if you think you know how to evolve C, *just do it*. Build a
following and your bright new addition will be an obvious candidate
for a future DR, or revision of the C Standard.
You know, debugging heaps have been around for ever (speaking of
*market*). strlcat, strlcpy, and strtok_r have been around for some
time (certainly from well before 1999), and have had plenty of pickup
in certain environments. The C standard didn't pick them up, why would
they pick up any other useful, successful extension? I don't buy your
claim, because its not consistent with observed reality.

You might also like to observe the efforts of Bjarne Stroustrup, Guido
van Rostum and Roberto Ierusalimschy. These people have garnered a
significant market following that has gone completely unnoticed by the
Standards committee.
[...] And meanwhile you
don't have to wait a decade for those stodgy old, uh, committee
members to do the obvious.

As I posted elsewhere, I am thinking more of the word "flawed" than old
or stodgy.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[websnarf]

CBFalconer wrote:

we******@gmail.com wrote:

CBFalconer wrote: ... snip ...

The last time I took an (admittedly cursory) look at Bstrlib, I
found it cursed with non-portabilities

You perhaps would like to name one?

I took another 2 minute look, and was immediately struck by the use
of int for sizes, rather than size_t. This limits reliably
available string length to 32767.

Using size_t is also not any more *portable* than using int. Any lack
of portability is merely a reflection of the lack of the intrinsic
non-portability of the language itself. size_t can only reliably
contain values as high as 65535 -- so you are saying this difference in
limits (between 32k and 64k) embodies a significant universe of string
manipulation to warrant a claim against Bstrlib's portability?
[...] I did find an explanation and
justification for this. Conceded, such a size is probably adequate
for most usage, but the restriction is not present in standard C
strings.

Your going to need to conceed on more grounds than that. There is a
reason many UNIX systems tried to add a ssize_t type, and why TR 24731
has added rsize_t to their extension. (As a side note, I strongly
suspect the Microsoft, in fact, added this whole rsize_t thing to TR
24731 when they realized that Bstrlib, or things like it, actually has
far better real world safety because its use of ints for string
lengths.) Using a long would be incorrect since there are some systems
where a long value can exceed a size_t value (and thus lead to falsely
sized mallocs.) There is also the matter of trying to codify read-only
and constant strings and detecting errors efficiently (negative lengths
fit the bill.) Using ints is the best choice because at worst its
giving up things (super-long strings) that nobody cares about, it
allows in an efficient way for all desirable encoding scenarios, and it
avoids any wrap around anomolies causing under-allocations. If I tried
to use size_t I would give up a significant amount of safety and design
features (or else I would have to put more entries into the header,
making it less efficient).

Hundreds of people have downloaded Bstrlib and seriously looked at it
already. I've gotten plenty of feedback over its lifetime which has
lead to its evolution (so its not like it hasn't already had
significant review). You, of all people, are not going find any
serious flaw in it by perusing it for 2 minutes.

"Cursed with non-portabilities" indeed ...

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Keith Thompson]

we******@gmail.com writes:

CBFalconer wrote:

we******@gmail.com wrote:

> CBFalconer wrote: ... snip ...

>> The last time I took an (admittedly cursory) look at Bstrlib, I
>> found it cursed with non-portabilities
>
> You perhaps would like to name one?

I took another 2 minute look, and was immediately struck by the use
of int for sizes, rather than size_t. This limits reliably
available string length to 32767.

Using size_t is also not any more *portable* than using int. Any lack
of portability is merely a reflection of the lack of the intrinsic
non-portability of the language itself. size_t can only reliably
contain values as high as 65535 -- so you are saying this difference in
limits (between 32k and 64k) embodies a significant universe of string
manipulation to warrant a claim against Bstrlib's portability?

Yes.

I can't speak for Chuck, but size_t can reliably contain the size of
any object that the system can create. That's what it's for. If the
maximum value of size_t is 65535, then the system isn't going to be
able to create objects bigger than 65535 bytes.

It's entirely possible to have a conforming implementation in which
int is 16 bits, but size_t is 32 bits. On such a system, using int to
represents sizes needlessly sacrifices the ability to handle objects
bigger than 32767 bytes. For that matter, it's conceivable (but
unlikely) that size_t could be smaller than int.

[...] Hundreds of people have downloaded Bstrlib and seriously looked at it
already. I've gotten plenty of feedback over its lifetime which has
lead to its evolution (so its not like it hasn't already had
significant review). You, of all people, are not going find any
serious flaw in it by perusing it for 2 minutes.

"Cursed with non-portabilities" indeed ...

Do you have any figures on the number of people who have looked at it
briefly, rejected it because it's too complex, and not bothered to
mention it to you? I'm not saying there are a lot of such people
(obviously I don't have any such figures myself), but I don't think
you can exclude the possibility that it's a common thing.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Walter Banks]

we******@gmail.com wrote:

So if you think you know how to evolve C, *just do it*. Build a
following and your bright new addition will be an obvious candidate
for a future DR, or revision of the C Standard.
You know, debugging heaps have been around for ever (speaking of
*market*). strlcat, strlcpy, and strtok_r have been around for some
time (certainly from well before 1999), and have had plenty of pickup
in certain environments. The C standard didn't pick them up, why would
they pick up any other useful, successful extension? I don't buy your
claim, because its not consistent with observed reality.

TR18037 codifies embedded standalone practices of many different
compiler companies.
You might also like to observe the efforts of Bjarne Stroustrup . . .
These people have garnered a
significant market following that has gone completely unnoticed by the
Standards committee.

I guess that why Bjarne Stroustrup attends some of the standards meetings.

My point is the process may be long at times but it is a collection of
checks and balances that achieves broad input from a wide range of
sources. A single driven individual can start the process but cannot
force the outcome. It is more than the WG14 committee that needs
to be convinced of the merits of changes.

The TR's have become a kind of standards beta test and with broad
instead of limited use ideas can change.

Walter..

[REH]

Ben C wrote:

In C, builtin types are passed around by value and space for them
doesn't need to be allocated or freed.

Um, the same is true for C++.

REH

[websnarf]

Keith Thompson wrote:

we******@gmail.com writes:

CBFalconer wrote:

we******@gmail.com wrote:
> CBFalconer wrote:
... snip ...
>> The last time I took an (admittedly cursory) look at Bstrlib, I
>> found it cursed with non-portabilities
>
> You perhaps would like to name one?

I took another 2 minute look, and was immediately struck by the use
of int for sizes, rather than size_t. This limits reliably
available string length to 32767.
Using size_t is also not any more *portable* than using int. Any lack
of portability is merely a reflection of the lack of the intrinsic
non-portability of the language itself. size_t can only reliably
contain values as high as 65535 -- so you are saying this difference in
limits (between 32k and 64k) embodies a significant universe of string
manipulation to warrant a claim against Bstrlib's portability?

Yes.

I can't speak for Chuck, but size_t can reliably contain the size of
any object that the system can create. That's what it's for. If the
maximum value of size_t is 65535, then the system isn't going to be
able to create objects bigger than 65535 bytes.

It's entirely possible to have a conforming implementation in which
int is 16 bits, but size_t is 32 bits. On such a system, using int to
represents sizes needlessly sacrifices the ability to handle objects
bigger than 32767 bytes. For that matter, it's conceivable (but
unlikely) that size_t could be smaller than int.

None of this speaks of the portability complaint CBF was claiming to
make. Its also an extremely marginal complaint that ignores the
tremendous benefit of this design choice, as I've already thoroughly
explained.
[...]

Hundreds of people have downloaded Bstrlib and seriously looked at it
already. I've gotten plenty of feedback over its lifetime which has
lead to its evolution (so its not like it hasn't already had
significant review). You, of all people, are not going find any
serious flaw in it by perusing it for 2 minutes.

"Cursed with non-portabilities" indeed ...
Do you have any figures on the number of people who have looked at it
briefly, rejected it because it's too complex, and not bothered to
mention it to you? [...]

How do you suppose I would obtain such figures? I instead count the
actual feedback, and from that feedback count the number of people who
complained of portability problems (none) hidden assumptions (none) and
interminable API (none -- well even less than none, since people keep
asking me to add things into it.)

I also roughly count the number of people who have included Bstrlib in
their project but for some reason don't tell me about this fact (just
using google). While some of them may be being irresponsible and just
using the library without looking at the source at all -- I highly
doubt that that represents the majority, or that I can find even a
significant percentage of all such people this way.

Its not like a language standard where the audience is obvious
(compiler vendors) and so if you wanted to know if the standard was
rejected, you could just count up the number of people who upgraded
their compiler, but didn't implement the standard, say.
[...] I'm not saying there are a lot of such people (obviously I don't have any such
figures myself),
You can look in the sourceforge project page; the number of downloads
is not a secret.

There have, in fact, been thousands of downloads, but clearly a
significant number of them are probably just people getting the latest
version -- so I'm just estimating. There are a lot of "first day of
release" downloads of my library, indicating I have repeat customers
(about a hundred within the first few days of any new release) who are
very interested in keeping up to date with the latest version. But at
the same time, there are many more conservative people with on going
projects who I can see from their sources are using old versions of the
library.
[...] but I don't think
you can exclude the possibility that it's a common thing.

That's true, but I have received enough feedback to suggest that this
library has survived quite a thorough amount of auditting. Some
bugs have been caught, and the design has been improved because of it.

For the average source file in any environment, you are lucky if you
can get *one* person to review it. Bstrlib has clearly far exceeded
that.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[jacob navia]

we******@gmail.com a écrit :
[snip]

None of this speaks of the portability complaint CBF was claiming to
make. Its also an extremely marginal complaint that ignores the
tremendous benefit of this design choice, as I've already thoroughly
explained.

Look, I have used size_t for my string library, and a "flags" field for
annotating info like "read only", etc. Your method looks much more
interesting since it avoids an extra field an saves 32 bits per string.

True, I would have an upper limit of 2GB for strings but I think that
will be enough... Anyway having a 2GB limit or a 4GB limit is not so
different. You will have to have a limit *anyway*

Besides, if all Chuck has to say about your library is that "it should
have been a size_t" well... it is not a big problem. You are lucky that
he is not complaining that it doesn't run in a 486 :-)

jacob

[Ben C]

On 2006-05-03, REH <sp******@stny.rr.com> wrote:

Ben C wrote:

In C, builtin types are passed around by value and space for them
doesn't need to be allocated or freed.

Um, the same is true for C++.

Yes of course, I never intended to imply that it wasn't.

The point I was making was that operator overloading doesn't mix so
easily with things that might need to be allocated and freed manually--
i.e. objects of user-defined types. You start needing constructors and
destructors, which C++ (but not C) has.

[Ben C]

On 2006-05-03, we******@gmail.com <we******@gmail.com> wrote:

CBFalconer wrote:

we******@gmail.com wrote:

> CBFalconer wrote: ... snip ...

>> The last time I took an (admittedly cursory) look at Bstrlib, I
>> found it cursed with non-portabilities
>
> You perhaps would like to name one?

I took another 2 minute look, and was immediately struck by the use
of int for sizes, rather than size_t. This limits reliably
available string length to 32767.
[snip]
[...] I did find an explanation and
justification for this. Conceded, such a size is probably adequate
for most usage, but the restriction is not present in standard C
strings.

Your going to need to conceed on more grounds than that. There is a
reason many UNIX systems tried to add a ssize_t type, and why TR 24731
has added rsize_t to their extension. (As a side note, I strongly
suspect the Microsoft, in fact, added this whole rsize_t thing to TR
24731 when they realized that Bstrlib, or things like it, actually has
far better real world safety because its use of ints for string
lengths.) Using a long would be incorrect since there are some systems
where a long value can exceed a size_t value (and thus lead to falsely
sized mallocs.) There is also the matter of trying to codify
read-only and constant strings and detecting errors efficiently
(negative lengths fit the bill.) Using ints is the best choice
because at worst its giving up things (super-long strings) that nobody
cares about,
I think it's fair to expect the possibility of super-long strings in a
general-purpose string library.
it allows in an efficient way for all desirable encoding scenarios,
and it avoids any wrap around anomolies causing under-allocations.
What anomalies? Are these a consequence of using signed long, or
size_t?
If I tried to use size_t I would give up a significant amount of
safety and design features (or else I would have to put more entries
into the header, making it less efficient).

If you only need a single "special" marker value (for which you were
perhaps using -1), you could consider using ~(size_t) 0.

Things will go wrong for at most one possible string length, but that's
more than can be said for using int.

But whatever the difference in efficiency, surely correctness and safety
first, efficiency second has to be the rule for a general-purpose
library?

[REH]

"Ben C" <sp******@spam.eggs> wrote in message
news:sl*********************@bowser.marioworld...

On 2006-05-03, REH <sp******@stny.rr.com> wrote:

Ben C wrote:

In C, builtin types are passed around by value and space for them
doesn't need to be allocated or freed.

Um, the same is true for C++.

Yes of course, I never intended to imply that it wasn't.

The point I was making was that operator overloading doesn't mix so
easily with things that might need to be allocated and freed manually--
i.e. objects of user-defined types. You start needing constructors and
destructors, which C++ (but not C) has.

Why? And why do you think objects of user-defined types have to be
"allocated and freed manually"?

struct foo {
int x, y;
};

foo operator+ (const foo& a, const foo& b)
// for it you are of the "I hate references" camp: foo operator+ (foo a,
foo b)
{
const foo z = {a.x + b.x, a.y + b.y};
return z;
}

foo x = {1, 2};
foo y = {3, 4};
foo z = x + y;

simplistic, but no constructors.

REH

[Rod Pemberton]

"Richard Heathfield" <in*****@invalid.invalid> wrote in message
news:0O********************@bt.com...

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.

His reputation is far better than yours. Noone has ever heard of you. And
if they did once learn of you, they sure don't remember you... The same
can be said of Keith Thompson, Martin Ambuhl, Chuck Falconer, etc...
Everyone knows about LCC-Win32 and Jacob Navia.

Rod Pemberton

[Ian Collins]

Rod Pemberton wrote:

"Richard Heathfield" <in*****@invalid.invalid> wrote in message
news:0O********************@bt.com...

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

His reputation is far better than yours. Noone has ever heard of you. And
if they did once learn of you, they sure don't remember you... The same
can be said of Keith Thompson, Martin Ambuhl, Chuck Falconer, etc...
Everyone knows about LCC-Win32 and Jacob Navia.

That kind of assumes everyone uses windows....

--
Ian Collins.

[Rod Pemberton]

"Ian Collins" <ia******@hotmail.com> wrote in message
news:4b*************@individual.net...

Rod Pemberton wrote:

"Richard Heathfield" <in*****@invalid.invalid> wrote in message
news:0O********************@bt.com...

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

His reputation is far better than yours. Noone has ever heard of you. And if they did once learn of you, they sure don't remember you... The same can be said of Keith Thompson, Martin Ambuhl, Chuck Falconer, etc...
Everyone knows about LCC-Win32 and Jacob Navia.

That kind of assumes everyone uses windows....

Untrue, I learned of it when programming on Stratus Continuum's in PL/1...
In fact, I doubt anyone knows the original authors names to LCC either...
Rod Pemberton