Boost process and C

[Keith Thompson]

Keith Thompson a écrit :

Are you suggesting that the C standard should be changed so that
strings are no longer terminated by '\0'?

Yes. If we have the length as a size_t we do not need to start
scanning memory at each access to get the length of the string, what
is GREATLY inefficient and has been pointed out as inefficient since
decades!!!!!

There are dozens of
standard library functions that use this representation, and it's
central to the semantics of string literals.

lcc-win32 proposed replacing
strcmp --> Strcmp
strcat --> Strcat

where the arguments are the same but in THOSE kind of strings.

Similarly, the compiler when it sees:

String s = "This is a string";

would make an array of characters and prepend the length instead of
adding a terminating zero.

Conceivably you could add a new string representation *in addition to*
the existing one.
Yes.

You would then be permanently stuck with two
distinct and incompatible ways of representing strings. (Breaking
nearly all existing code is not an option.)

Yes, new code would use Strcmp, old would use strcmp.

I have tried porting code that uses heavily strings in the old
representation to the new one and it is relatively easy to do.

Of course, it's easy enough to implement this kind of thing in a
library using purely standard C; perhaps that's why there isn't much
enthusiasm for adding it to the language.

No. The problem is that you want to keep:

String s;
...

s[23] = 'b';

and not forcing people to use:

strindex(s,23)

strindexassign(s,23,'c');

or similar nonsense.

I don't recall every saying I "want to keep" any such thing.

C does not currently support operator overloading. Your String type
could be implemented in standard C, but it would require using
additional function calls. In a hypothetical C-like language that
*does* support operator overloading, a new String type could be
implemented more conveniently.

I do not necessarily oppose either adding operator overloading to a
future C standard, or implementing it as an extension in an existing C
compiler. I've used languages that support operator overloading, and
I've found it very convenient at times. (It's also prone to abuse.)

On the other hand, operator overloading is really nothing more than
syntactic sugar; there's nothing you can do with it that you can't do
without it (though perhaps much more verbosely).

A string library implemented in standard C would be a good topic for
discussion in this newsgroup. A string library that depends on
extensions provided by a single compiler would be a good topic for a
newsgroup that deals with that copmiler. Advocacy of changes to the C
language belongs in comp.std.c. You've complained that your
suggestions haven't been well received there; that doesn't seem to
have stopped you from talking about them here.

Get this through your head. I do not oppose your ideas. Some of them
are undoubtedly worth considering. I am sick and tired of your
attitude and your insistence on discussing them in a form where they
are off-topic.

Basically it implements all functions of the C library using the new
Strings. The syntax is almost the same:
Strcmp --> strcmp
Strcat --> Strcat

etc

Using operator overloading operators like

if (! s) {
}

have their usual meanings.

I asked for a pointer to the documentation. Is there any? If not,
it's not worth my time to consider it.

[...]

Maybe. I would not say that it is wrong. But the insistence for using
gcc with the -pedantic etc options that is getting recommended here
goes with the attitude of negating C99 in this bgroup.

Have you tried "gcc -pedantic -std=c99"? I use it routinely.

I remember the
discussion about the FAQ we had, where I was flamed because I insisted
on upgrading the FAQ to C99.

I don't remember that.

[...]

I am not imposing anything to anyone. I have explained with a lot of
arguments why I am doing this or that. Nobody is forced to use
lcc-win32 but I think that arguing and convincing people still is
possible, and is still the oenly way to publish your own ideas.

You are imposing extensions that are specific to lcc-win32 on this
newsgroup. You are imposing your advocacy of changes to the standard
on a newsgroup that discusses the language *as it currently exists*,
after being told repeatedly that such discussions would be more
appropriate in comp.std.c.

 

[Richard Bos]

It is a pity. Most people in this forum, for instance, that I thought
it would be suchg a group, refuse to discuss about any evolution
and seem nostalgic of some mythical past: they endorse the C89
standard (full 17 years ago) and will start getting VERY upset
if any improvement is proposed. Most of them think, as one of them
said:

"C++ is the future, we are just waiting that C programmers die out."

Tisdale is a known idiot, and you are a known liar.

_This group_ discusses ISO C. It does not discuss any of the gazillions
extensions to it that are out there. In particular it does not discuss
toy compiler suites crufted together by someone who hasn't even read the
Standard properly. It is understandable that this gets up your tits, but
you'll just have to learn to live with being marginal.

Richard

 

[Richard Bos]

You appear unable of understanding the simple fact that "all this" is
optional in C++ as well.

s/optional/an abomination/.

Operator overloading... yeurgh. What does random_struct_x *=
random_union_y + random_integer_z; _do_ in the first place?
References... yikes! When I want my object to change behind my back
without me even being aware of it, I'll use first-generation FORTRAN and
change the value of 3, thank you very much.
STL... bah. When I want to use a linked list, I want to use _this_
linked list which is tailored to _this_ application, not some Extruded
Datatype Product which may be "good enough" for most applications and
has precisely the wrong properties for mine.

C is simple, clean and efficient. Let's keep it that way.

Richard

 

[Spoon]

Well, there is also no group for discussing the *practice*
of C programming,

If your OS conforms to POSIX, then you can discuss it in
comp.unix.programmer

If your OS is Linux, then also try comp.os.linux.development.apps

the implementation of C compilers/libraries,

You can discuss this in comp.compilers and on the GCC mailing list.

common C compilers and their extensions,

You can discuss this in your platform's group, e.g. comp.unix.programmer
and comp.os.linux.development.apps

algorithms in C or C variants either.

comp.unix.programmer, comp.os.linux.development.apps, comp.programming

Paul, could you stop sounding like you have no clue about Usenet?
(I know it's not the case.)

 

[Ben C]

[...]

The problem with ultra FAT languages like C++ is their incredible
complexity!

Constructors and destructors?

Who needs them?

YOU, because you needs operator overloading, that requires constuctors
to define the operators to overload and destructors to undefine them.

Not at all. Operator overloading is (or can be) nothing more than
syntactic sugar, allowing an operator symbol to be used as a function
name.

This is true, but you do need to predefine what's I suppose a template
for the prototype of the function it's syntactic sugar for. Probably:

struct T operator+(struct T a, struct T b);
struct T operator=(struct T a);

For something like struct Complex this would be fine, but for a large or
complex T, or one which is subject to some specialized kind of
memory-management, you might not choose to define your functions like
this, but more likely like this:

void operator+(struct T *result,
const struct T* a, const struct T *b);

With operator overloading supported in the language you lose the ability
to distinguish... until you put that ability back by letting you
redefine constructors and destructors, and adding references to the
language.

There no necessary connection to constructors and destructors. (The
1983 version of Ada had operator overloading but did not directly
support object orientation.)

I'm not familiar with Ada, but I think the key point is whether the
language has explicit or implicit memory management.

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

The easiest way to "bolt on" operator overloading is to stick with C's
current system in which values of variables of user-defined types are
entire instances that are implicitly "memcpy"d.

But often C programmers implement their own reference-counting systems,
garbage collectors, specialized allocators, etc., and manage pointers to
objects using functions into these explicit memory managers. How do you
fit this under the very strict interface of overloaded operators? The
same way you fit anything under a strict interface-- with callbacks,
i.e. "constructors". Suddenly you're reinventing C++.

In languages with automatic memory management in which the values of
variables are consistently references to automatically allocated and
de-allocated objects, user-defined types already behave a lot more like
builtin types, and so operator overloading fits in much more easily.

I believe that, theoretically, a form of operator overloading could be
added to C without bringing in any of the other baggage of C++.

You are right, it could, but it would be of limited utility. The most
common use I've ever found for operator overloading is for matrix
arithmetic, where the matrices are potentially very large, or may be
stored in unusual ways (storing two triangular matrices in one square
array is common for example). For this the code that adds and multiplies
the matrices has to be dovetailed in with the code that knows how to
allocate, deallocate, and find the data. You need a similar level of
automation for both kinds of activity for operator overloading to be
really useful.

 

[Ben C]

Ben C a écrit :


Since there are no constructors neither copy constructors in C the
optimization is muc h simpler than in C++.

True, we need the references, what is a good improvement anyway.

Not at all! In C the fact that variables always "refer" directly to
values (and so we use pointers explicitly) is a good, consistent system.

References in C++ are a necessary evil introduced in the first place, as
far as I can see, to support operator overloading.

I disagree here by the way with the advice of the C++ FAQ (which IIRC
says "use references where you can, pointers where you have to").

[snip

I am certain that the conservative option just puts brakes to the
development of the language

I agree. You need brakes.

Having said that I'm all for trying these things out in projects like
lcc-win32.

In the case of C, whenever I think about something "why didn't they do
it this way instead?", I invariably come to realize eventually that they
knew what they were doing and did it the right way in the first place.
It's well-designed. I'm not saying take it for granted, but don't assume
it's /easy/ to improve it.

 

[Michael Mair]

Most users of C want a compact and efficient language. Many have
complained that they don't want all the "new" features in C99 hence the
reason why 7 years on there have been very few implementations of 99

I can't understand why people want to add a lot of C++ features to C. If
you really need those features use C++

IMO, a feasible way to go are _additional_ libraries not belonging to
the standard library as such but standardised and respected by further
language development nonetheless. I do not know if and how to
subdivide into packages giving enough freedom to the user or how to
make enough people agree on one API (in a more civilised way than a
cudgel with nails driven through) but I think that enough people
will migrate to the standardised container or standardised better
string libraries -- if these are well-tested and widely available.
The cost of porting to the next version of your library of choice or
another platform where this library is not available or does not
work as expected due to non-portable assumptions probably will even
bring new versions of existing software to use these libraries.

New language features are a completely different things.
I have seen some useful suggestions from Paul Hsieh, Jacob Navia, and
others which at least give ideas what to discuss or at least what to
provide a standardised/uniform way for to handle language extensions
in these directions -- this is IMO within the role of the committee
and certainly more useful than just ignoring such suggestions.
I am not sure whether I like the idea of a plethora of TRs describing
how to extend C in this direction or that but this at least provides
a way for the language to grow in an orderly way. If every compiler
provider builds his or her own baroque structures on top of C, then
this does nothing to improve portability and may be worse in the long
run.
In this way, much as people could choose from a library selection,
they could choose from extensions with standardised semantics and
say "We need basic C plus the list, set, and graph containers plus
the extension for coroutines" or whatever.

The library part of this suggestion is harmless enough and I really
think it could be beneficial in the long run.
The standardised extension part is something that should be discussed
in earnest. Maybe it would be even a good idea to review C99 under
this point of view: "_Complex, _Bool -> extension", "designated
initializers, VLAs, variable macro argument lists, compound literals,
inline -> base language", "tgmath, fenv, iso646, -> library extension",
.... I did not think much about this, so a debate about this on-the-fly
classification list is not helpful just now.

And yes, maybe a third newsgroup, comp.whatever.c.something, may be
in order as a place for the community to produce input for such
things.


Cheers
Michael

 

[Richard Bos]

Richard Bos a écrit :

int128 operator*=(int128 a,int128 b);

Well that should multiply a*b and assign the result to a, returning a,
I suppose. What is so weird about that?

That's not overloading. In a real C compiler, those would be int_128t's,
a normal integer type, and the normal C arithmetic operations would
apply to them.

Now answer my actual question: if you have objects of several random
types, how, except by digging deep into YASTL, do you know how
operations are overloaded for this particular combination?

References precisely do NOT change at all. They always point to the same
object! It is NOW That pointers can be changed behind your back to point
to something else. References avoid that!

Learn to read.

Functions which take a reference can change _my_ object behind my back,
and the only way I'd know about it is if I dug up the prototype. You
cannot tell from a single call. With pointers, the difference is always
clear. To illustrate:

With or without references, you know that
function1(*object);
might well change object, because it takes a pointer.
Without references, you can rest assured that
function2(object);
will never change object, because it does not take a pointer.
_With_ references, though, you always have to assume that
function3(object);
could change object, because you just cannot tell from that call whether
it takes a normal parameter or a reference.

References in the lcc-win32 implementation are exactly equivalent to
pointers with two restrictions:
1) they can't be NULL
2) They are assigned immediately after their definition and point always
to the same object.
3) When using them, they are always immediately dereferenced.

Three restrictions. And bright red uniforms. But those are not
references as it is generally understood. They're also mostly useless. I
cannot imagine wanting such a type when I already have normal pointers.
OTOH, they're also - being toothless - not harmful, the way a real
reference is.

For enlightenment on what is generally meant by "reference" in
programming, see the C++ Standard.

Well, then GO ON USING _that_ list tailored to _that_ application.

So I do - but if my implementation had to come with a shitload of
baggage, and I would have to understand all that shitload just to read
other people's code - instead of just understanding _that_ code - it
would make that implementation a chore to use.

Other people that recognize that a single linked list will be always a
single linked list

....are idiots, much as the people who recognise that an apple will
always be an apple (and happily bite an unripe one).

Nobody is changing that, as I have stressed over and over.

Yet you want to add three metric tonnes of baggage to this language. How
is that simple, clean and efficient?

We need length prefixed strings,

....like we need a hole in the head.

Richard

 

[CBFalconer]

.... snip ...

In this way, much as people could choose from a library selection,
they could choose from extensions with standardised semantics and
say "We need basic C plus the list, set, and graph containers plus
the extension for coroutines" or whatever.

Many things are already available from various participants here.
In my case you can find at least strlcpy, ggets, hashlib library
modules on:

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

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

Tisdale is a known idiot, and you are a known liar.

_This group_ discusses ISO C. It does not discuss any of the gazillions
extensions to it that are out there. In particular it does not discuss
toy compiler suites crufted together by someone who hasn't even read the
Standard properly. It is understandable that this gets up your tits, but
you'll just have to learn to live with being marginal.

Richard

I wrote:

"... start getting VERY upset if any improvement is proposed".

You wrote:

"Liar, marginal, haven't read the standard properly..."



jacob

 

[Keith Thompson]

If your OS conforms to POSIX, then you can discuss it in
comp.unix.programmer

If your OS is Linux, then also try comp.os.linux.development.apps


You can discuss this in comp.compilers and on the GCC mailing list.


You can discuss this in your platform's group,
e.g. comp.unix.programmer and comp.os.linux.development.apps


comp.unix.programmer, comp.os.linux.development.apps, comp.programming

Paul, could you stop sounding like you have no clue about Usenet?
(I know it's not the case.)

And if you want a newsgroup that discusses C programming without
limiting itself to the ISO standard, you can always advocate the
creation of such a newsgroup. I suggest that comp.programming.c would
be a good name for it. The procedures for creating a new newsgroup
are well documented. Or you can create your own alt.* group; they're
much easier to create, but they don't necessarily propagate as well.

You should decide just what the scope of the new newsgroup should be.
Don't be surprised if a lot of the people who agree with you that
comp.lang.c's scope is too narrow are unable to come to an agreement
on what the scope of this new newsgroup should be.

There's also alt.comp.lang.learn.c-c++, which is looser than
comp.lang.c, but I don't think it's what you're looking for.

 

[Walter Banks]

WG14 has been consistently active. In the last few years significant changes have been made to reflect the actual usage of C. Cell phones, automotive and process control are using TR18037 features. There is a lot in C99 that addresses MISRA concerns.
Rumours of its death or retirement are premature.

w..

 

[websnarf]

If your OS conforms to POSIX, then you can discuss it in
comp.unix.programmer

What has UNIX got to do with anything? The number of people who
mistakenly think they can post here with gcc or Visual C questions is
pretty staggering.

If your OS is Linux, then also try comp.os.linux.development.apps

I don't get you train of thought -- these are newsgroups about
operating systems, not C.

You can discuss this in comp.compilers and on the GCC mailing list.


You can discuss this in your platform's group, e.g. comp.unix.programmer
and comp.os.linux.development.apps

A compiler need not target only one platform, and what if I want to
discuss multiple extensions of different compilers? (In apartheid
South Africa, these kinds of divisions were called bantustans.)

comp.unix.programmer, comp.os.linux.development.apps,

Again with the OS-specific groups. If I'm not discussing Linux or Unix
programming, why would I discuss C algorithms/implementations in those
newsgroups?

[...] comp.programming

Well, I do there, but the newsgroup is implicitely language neutral.
The audience really doesn't include people who want to dive into the
differences between va_arg implementations on various compilers. Its
just too diluted -- you might as well point me in the direction of
alt.talk.

Look -- in a single post I want to discuss how one might implement
va_copy() in VC or gcc, discuss platform neutral heap extensions, or
compare debuggers. Similarly, how about extensions such as jacob
navia's lcc variant, or Walter Bright's D? comp.programming might be
the place, except that its diluted by an audience who probably wouldn't
bite.

Paul, could you stop sounding like you have no clue about Usenet?

What are you talking about? There is a big gapping vacumm in Usenet,
and that is discussion of practical C programming. By name its obvious
that comp.lang.c is supposed to be that group. Instead there is this
clever shift where this group should properly called comp.std.c, and
the comp.std.c group should be called comp.std.c.discussion or
something like.

By shifting over by one, that runs us out of room, and we're stuck with
no group to discuss the practice of programming in C. Of course that
doesn't stop the constant posting by people about platform specific C
concerns here -- you'd think *somebody* would buy a clue from that.

 

[jacob navia]

(e-mail address removed) a écrit :

What are you talking about? There is a big gapping vacumm in Usenet,
and that is discussion of practical C programming. By name its obvious
that comp.lang.c is supposed to be that group. Instead there is this
clever shift where this group should properly called comp.std.c, and
the comp.std.c group should be called comp.std.c.discussion or
something like.

Well, that is the point: this clever shift, where here will only be the
talk about standard C as it is now, or (better) as it was in 1989.

Nobody authorized the people here to do that but they did it, and they
will destroy any discussion about anything beyond that. Of course if
somebody asks why i++ = i++ does not work THAT will be answered for the
millionths time.

This lack of depth in the discussion provokes that most people stop
contributing and go away. C people will be seen as a conservative group
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.

Walter Bright participates sometimes here, but he has started his own
language and probably doesn't have any interest in evolving C as such,
even if D is very similar to C.

By shifting over by one, that runs us out of room, and we're stuck with
no group to discuss the practice of programming in C. Of course that
doesn't stop the constant posting by people about platform specific C
concerns here -- you'd think *somebody* would buy a clue from that.

This group has no chart actually, 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.

But the "regulars" have always won in discouraging people from any
in-depth discussion. Maybe because they fear that C will lose some
original "purity" or (probably more often) because they believe that C++
is the future and that C should be destroyed as anything capable of
evolving.

Sadly that could be the opinion of many standards comitee people too.

I do not see any other explanation for the complete absence of any
directions from that comitee. They are NOT planning any revision for
2009, and basically they will block any new development of the language
forever.

I hope I am wrong.

jacob

 

[websnarf]

When you needs a string that knows its length you should use pascal.
It does this by design.

You are saying you should throw out an entire language because you
don't like the way it handles strings? Are you aware that many Pascal
implementations have strings limited to a length of 255 characters?

There are somewhat easier, and less retarded solutions to this problem:

http://bstring.sf.net/

 

[Ben Pfaff]

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

 

[jacob navia]

Ben Pfaff a écrit :

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

 

[Chris Hills]

And if you want a newsgroup that discusses C programming without
limiting itself to the ISO standard, you can always advocate the
creation of such a newsgroup.

OR even a change of use of this one

 

[Ben Pfaff]

Ben Pfaff a icrit :

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.

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.

 

[Mark McIntyre]

Ben Pfaff a écrit :

You mean then in substance:

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

More accurately
"C has no native string type, if you find you need to excessively
manipulate strings, perl may suit your needs better".

Of course, feel free to stick with your highly pejorative version.

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