473,320 Members | 1,955 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Boost process and C

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

Apr 29 '06
335 11376
Paul Hsieh wrote:
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.)
May 1 '06 #101
On 2006-05-01, Keith Thompson <ks***@mib.org> wrote:
"Herbert Rosenau" <os****@pc-rosenau.de> writes:
On Sat, 29 Apr 2006 13:05:21 UTC, jacob navia <ja***@jacob.remcomp.fr>
wrote: [...]
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.
May 1 '06 #102
On 2006-04-30, jacob navia <ja***@jacob.remcomp.fr> wrote:
Ben C a écrit :
Some of the side-effects are less agreeable though.

You end up needing something like C++ references, in order to provide a
way of overloading the operators in expressions like a = b = c.

In expressions like a = b + c, where a, b and c are all large instances,
you really want to copy the result of b + c directly into a. What you
end up with is operator+(b, c) returning an instance, and then
operator=(a, b) copying the instance into a. Compilers have clever ways
to work around this, while still having to call the constructor for the
temporary b + c and a's assignment operator (or copy ctor if it's an
initialization), as if it were doing add followed by copy, since those
could have arbitrary sideeffects.

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
In "higher-level" languages
which are further abstracted from the implementation, it's attractive to
remove this distinction-- Python for example achieves this well. But I'm
not convinced of the wisdom of the hybrid, C with operator overloading.

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.
May 1 '06 #103
Ben C a écrit :
On 2006-05-01, Keith Thompson <ks***@mib.org> wrote:
"Herbert Rosenau" <os****@pc-rosenau.de> writes:
On Sat, 29 Apr 2006 13:05:21 UTC, jacob navia <ja***@jacob.remcomp.fr>
wrote:
[...]
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);


lcc-win32 does this automatically already. It converts all functions
that return a sructure by value from:
TYPE fn(...)

to

void fn(TYPE *result,...);

The only thing is that the user has no access to "result", the first
argument that is automatically supplied by the system. Workarounds
exists but they are not pretty (in the existing implementation)
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.


lcc-win32 ofers a second alternative: the garbage collector, where all
this problems of allocation/deallocation are solved automatically. This
may or may be not a good solution, depends on your memory usage. In any
case it should be considered when speaking about memory allocation issues.
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++.

No, we do not need constructors if overloaded operators receive an
already built object, and receive a pointer to the result.

Note that operator overloading is needed for two main applications:

1) Defining a new kind of numeric types.
2) Defining access for a new kind of array.

Period. Other usage is possible, but it is not the main thrust of the
implementation.
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.


lcc-win32 does not allow operator overloading for operations that are
already "taken" by the language. For instance pointer subtraction is
well defined in C, so it is not possible to define:

TYPE operator-(TYPE *a,TYPE *b);

You have to either define:

TYPE operator-(TYPE a,TYPE b);

or

TYPE operator-(TYPE &a,TYPE &b);

if you accept references into the lanuage.

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.


There is a work around for this problem that is also used in C++:

All operators for the elementary operators return a dummy result that
just records the type of operation and the arguments in a list.

The overloaded operator assignment then, parses the whole expression and
directs the operations to be realized.

But those are very sophisticated usages. Much simpler is the ability to
add numeric types into the language without so much pain as in C right now.

And, above all, keeping the whole stuff SIMPLE.

jacob
May 1 '06 #104
Chris Hills schrieb:
In article <4b*************@individual.net>, Ian Collins <ian-
ne**@hotmail.com> writes
Richard Heathfield wrote:
jacob navia said:

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:

<various answers snipped>

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?

Well, okay, let's just say for the sake of argument that we're going to add
standard data structure APIs to C.

First step - decide what's in and what's out. Let battle commence.

When you eventually get the blood out of the carpet, the second step is to
agree on an interface. That will take forever and a day.

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.


The C++ committee did it, is it too hard for C to do the same?


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
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
May 1 '06 #105
Richard Bos a écrit :
Operator overloading... yeurgh. What does random_struct_x *=
random_union_y + random_integer_z; _do_ in the first place?
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?
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.
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!

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.

MYSTRUCT Lstruct // a global structure

void fn(void)
{
MSTRUCT &a = Lstruct;

Now, "a" is a pointer that will always point to Lstruct and always
be dereferenced when it is used:

a.one_field = 23;

instead of
a->one_field = 23; // Not needed since "a" is
// always dereferenced.

Not very difficult to understand. Besides those two properties they are
exactly like any other pointer and keep the advantage of passing things
around with a pointer and not by value.
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.

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

Other people that recognize that a single linked list will be always a
single linked list in all cases will be HAPPY TO LEAVE THAT CODING to
some library function that is portable across all implementations.
C is simple, clean and efficient. Let's keep it that way.


Nobody is changing that, as I have stressed over and over. But it is
impossible to define new numeric types and new kind of arrays in C, so,
sorry, this hole should be closed, that is all.

We need length prefixed strings, and the ability to define new numeric
types and operations for them.
May 1 '06 #106
jacob navia <ja***@jacob.remcomp.fr> wrote:
Richard Bos a écrit :
Operator overloading... yeurgh. What does random_struct_x *=
random_union_y + random_integer_z; _do_ in the first place?
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... 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.


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


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).
C is simple, clean and efficient. Let's keep it that way.


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
May 1 '06 #107
Richard Bos a écrit :
[snip]
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.

This could be a valid concern Richard of course. But at least in
lcc-win32's implementation this does NOT apply.

If a function takes a structure by value as argument and you pass it a
reference, the reference will be COPIED into the stack and if you change
that it will change the COPY and not the original object as it should
be. Maybe this is not what C++ does, I do not know.

To allow passing references as a pointer you have to write
function3(TYPE &object);

In that case the object can be changed.
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.


I do not really care, I am not trying to copy C++. The only advantage of
references is that they are never NULL in my implementation, and they
are (maybe) not as powerful as the C++ ones.

Why?

Avoiding changing objects behind the back of the programmer.

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.

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.


Excuse me but this arguments AGAINST having to learn over and over again
the zig different list implementations you see? There would be only one!
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).


C'mon Richard :-)
C is simple, clean and efficient. Let's keep it that way.


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.


What is wrong with length prefixed strings Richard?

Can you put forward your *arguments* instead of just sending polemic to
the discussion?

WHY are length prefixed strings wrong?

I am waiting for an argument Richard.

jacob
May 1 '06 #108
Richard Bos wrote:
jacob navia <ja***@jacob.remcomp.fr> wrote:

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


I wrote:

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

You wrote:

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

:-)

jacob
May 1 '06 #109
Michael Mair wrote:
.... 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/>

May 1 '06 #110
Spoon <ro**@127.0.0.1> writes:
Paul Hsieh wrote:
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.)


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.

--
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.
May 1 '06 #111
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..
jacob navia wrote:
jacob navia a écrit :
Most of them think, as one of them
said:

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


May 1 '06 #112
Spoon wrote:
Paul Hsieh wrote:
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


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


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.)
algorithms in C or C variants either.


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.

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

May 1 '06 #113
we******@gmail.com 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
May 1 '06 #114
Herbert Rosenau wrote:
On Sat, 29 Apr 2006 12:18:12 UTC, jacob navia <ja***@jacob.remcomp.fr>
wrote:
The problem is that instead of getting away from strings as zero
terminated array of characters they STILL hang to it. THEN all functions
must be explicitely be given the length of the strings/buffers/etc even
if it is immediately obvious that the programmer can't know in all cases
what that dammed length is nor should he care!

typedef struct _string {
size_t length;
char *Stringdata
} String;


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/

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

May 1 '06 #115
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).
--
"We put [the best] Assembler programmers in a little glass case in the hallway
near the Exit sign. The sign on the case says, `In case of optimization
problem, break glass.' Meanwhile, the problem solvers are busy doing their
work in languages most appropriate to the job at hand." --Richard Riehle
May 1 '06 #116
Ben Pfaff a écrit :
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".

May 1 '06 #117
In article <ln************@nuthaus.mib.org>, Keith Thompson <kst-
u@mib.org> writes
Spoon <ro**@127.0.0.1> writes:
Paul Hsieh wrote:
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.)


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

May 1 '06 #118
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.

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.
--
"When I have to rely on inadequacy, I prefer it to be my own."
--Richard Heathfield
May 1 '06 #119
On Mon, 01 May 2006 21:52:08 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:
Ben Pfaff a écrit :
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".


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
May 1 '06 #120
Ben Pfaff a écrit :
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.

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.


OK, that seems more balanced.

Thanks
May 1 '06 #121
Mark McIntyre a écrit :
On Mon, 01 May 2006 21:52:08 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:

Ben Pfaff a écrit :
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".

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.


But if you agree that C has a extremely weak string type Mark, why
wouldn't a revision of that part of the language be a good thing?

I wouldn't say that C "has no string type". Strings in C were a mere
afterthought and they are inefficient and very error prone. Granted.

But they do exist and they do get used, very often with catastrophic
results.

Why not change/improve this part of the language then?

jacob
May 1 '06 #122
On Mon, 1 May 2006 19:22:35 UTC, we******@gmail.com wrote:
Herbert Rosenau wrote:
On Sat, 29 Apr 2006 12:18:12 UTC, jacob navia <ja***@jacob.remcomp.fr>
wrote:
The problem is that instead of getting away from strings as zero
terminated array of characters they STILL hang to it. THEN all functions
must be explicitely be given the length of the strings/buffers/etc even
if it is immediately obvious that the programmer can't know in all cases
what that dammed length is nor should he care!

typedef struct _string {
size_t length;
char *Stringdata
} String;
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?


No, but when a twit like jacob gets whining that the C standard has to
change to fullify his wishes then I send him to another language that
fullifys that.
Are you aware that many Pascal
implementations have strings limited to a length of 255 characters?
I know. But is uninteresting here.
There are somewhat easier, and less retarded solutions to this problem:

http://bstring.sf.net/


Does not matter. I've written such extension myself for a special use
while in the same program beside that was massive handling of standard
C strings.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!
May 1 '06 #123
On Mon, 1 May 2006 20:27:36 UTC, jacob navia <ja***@jacob.remcomp.fr>
wrote:

But if you agree that C has a extremely weak string type Mark, why
wouldn't a revision of that part of the language be a good thing?


The only who whines that C strings are weak is the twit who names
himself as jacob navia.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!
May 1 '06 #124
Chris Hills <ch***@phaedsys.org> writes:
In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.org> writes

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


Yes, that could theoretically be done -- but I would oppose it.

I like having a group that discusses the C language as defined by the
ISO standard(s). Loosening the definition of what's topical here in
comp.lang.c would mean that there would no longer be any such group.
That would be a great loss, and I'm certain I'm not the only person
who feels that way.

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.

--
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.
May 1 '06 #125
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. We want to talk ABOUT THE LANGUAGE ITSELF.

Not just the narrow definition of "The language as it was in 1989" or
"The language as specified in the C standard", but including discussions
like this discussion, that is the first in many years that touches
topics that go beyond

"I wrote i++=i++ and doesn't work...."

What are those discussions "About C"???

I am long enough here to see that those are:

Homework assignments students that get their jobs done by an always
helpful hand from comp.lang.c (in many cases).

Trivia like:
i++ = i++;
Why is my gcc telling me
undefined reference to _cos?
etc
etc

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

Everything is frozen here, like in a museum.

jacob
May 1 '06 #126
Richard Bos wrote:
jacob navia <ja***@jacob.remcomp.fr> wrote:

Richard Bos a écrit :
Operator overloading... yeurgh. What does random_struct_x *=
random_union_y + random_integer_z; _do_ in the first place?


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.

Also *= is a unary operator, so the syntax looks clumsy.
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.


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:

That's why we have const. If a function isn't going to change the value
passed in, it should reference (or pointer) to a const object. If the
parameter isn't const, assume the worst. No difference between pointers
and references in this case.

--
Ian Collins.
May 1 '06 #127
Ian Collins a écrit :
Richard Bos wrote:
jacob navia <ja***@jacob.remcomp.fr> wrote:
Richard Bos a écrit :
Operator overloading... yeurgh. What does random_struct_x *=
random_union_y + random_integer_z; _do_ in the first place?

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.


Also *= is a unary operator, so the syntax looks clumsy.


Multiplication needs TWO operators. In C++ you have the "implicit this".
In C you don't have any implicit arguments so you need a different
prototype.

May 1 '06 #128
we******@gmail.com wrote:
Spoon wrote:
Paul Hsieh wrote:
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

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.

Look at the names, they include 'programmer' or 'development', so they
are valid places to discuss the main programming language used in those
environments, C.

--
Ian Collins.
May 1 '06 #129
Ian Collins a écrit :

That's why we have const. If a function isn't going to change the value
passed in, it should reference (or pointer) to a const object. If the
parameter isn't const, assume the worst. No difference between pointers
and references in this case.

lcc-win32 will COPY the argument into the stack ALWAYS when the function
prototype specifies a structure passed by value.

typedef struct {int a; int b;} Struct;

Struct someGlobal;

void fn(Struct);

int main(void)
{
Struct &a = someGlobal;

fn(a);
...
}

The call to fn(a) will provoke a dereferencing of a, and a copy of the
result of that dereferencing into the stack.

This means that even if you do NOT have any "const" declaration the
prototype specifications are ALWAYS followed.

This makes for clearer software. Otherwise you can effectively never
know if a function will change its argument!

jacob
May 1 '06 #130
I said:

Multiplication needs TWO operators.


It should have been

Multiplication needs TWO operands.

Sorry for this stupid bug :-)

May 1 '06 #131
jacob navia wrote:
Ian Collins a écrit :

That's why we have const. If a function isn't going to change the value
passed in, it should reference (or pointer) to a const object. If the
parameter isn't const, assume the worst. No difference between pointers
and references in this case.

lcc-win32 will COPY the argument into the stack ALWAYS when the function
prototype specifies a structure passed by value.

typedef struct {int a; int b;} Struct;

Struct someGlobal;

void fn(Struct);

int main(void)
{
Struct &a = someGlobal;

fn(a);
...
}

The call to fn(a) will provoke a dereferencing of a, and a copy of the
result of that dereferencing into the stack.

This means that even if you do NOT have any "const" declaration the
prototype specifications are ALWAYS followed.

This makes for clearer software. Otherwise you can effectively never
know if a function will change its argument!

I'm not sure what you are saying, the above describes normal pass by
value in C, I was answering a question about pass by reference....

--
Ian Collins.
May 1 '06 #132
jacob navia wrote:
Ian Collins a écrit :
Richard Bos wrote:
jacob navia <ja***@jacob.remcomp.fr> wrote:

Richard Bos a écrit :
> Operator overloading... yeurgh. What does random_struct_x *=
> random_union_y + random_integer_z; _do_ in the first place?
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.


Also *= is a unary operator, so the syntax looks clumsy.

Multiplication needs TWO operators. In C++ you have the "implicit this".
In C you don't have any implicit arguments so you need a different
prototype.

Very true, but how would you invoke the operator you prototype above?

--
Ian Collins.
May 1 '06 #133
Ian Collins a écrit :
jacob navia wrote:
Ian Collins a écrit :

That's why we have const. If a function isn't going to change the value
passed in, it should reference (or pointer) to a const object. If the
parameter isn't const, assume the worst. No difference between pointers
and references in this case.


lcc-win32 will COPY the argument into the stack ALWAYS when the function
prototype specifies a structure passed by value.

typedef struct {int a; int b;} Struct;

Struct someGlobal;

void fn(Struct);

int main(void)
{
Struct &a = someGlobal;

fn(a);
...
}

The call to fn(a) will provoke a dereferencing of a, and a copy of the
result of that dereferencing into the stack.

This means that even if you do NOT have any "const" declaration the
prototype specifications are ALWAYS followed.

This makes for clearer software. Otherwise you can effectively never
know if a function will change its argument!


I'm not sure what you are saying, the above describes normal pass by
value in C, I was answering a question about pass by reference....


Excuse me. I was just saying that passing a reference to a function that
accepts a structure VALUE does NOT force a pass by reference. To pass by
reference you have to write:

void fn(STRUCT &);

ONLY then, a pass by reference is done.
May 1 '06 #134
Ian Collins a écrit :
jacob navia wrote:
Ian Collins a écrit :

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


>Richard Bos a écrit :
>
>
>
>>Operator overloading... yeurgh. What does random_struct_x *=
>>random_union_y + random_integer_z; _do_ in the first place?
>
>
>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.
Also *= is a unary operator, so the syntax looks clumsy.

Multiplication needs TWO operators. In C++ you have the "implicit this".
In C you don't have any implicit arguments so you need a different
prototype.


Very true, but how would you invoke the operator you prototype above?

Just
int128 a,b,c;
...
a *= b;
May 1 '06 #135
jacob navia wrote:

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

Everything is frozen here, like in a museum.

There are similar issues on the C++ group, but the biggest difference is
there is always somewhere else for OT discussions to migrate to.

--
Ian Collins.
May 1 '06 #136
jacob navia wrote:
Ian Collins a écrit :
I'm not sure what you are saying, the above describes normal pass by
value in C, I was answering a question about pass by reference....


Excuse me. I was just saying that passing a reference to a function that
accepts a structure VALUE does NOT force a pass by reference. To pass by
reference you have to write:

void fn(STRUCT &);

ONLY then, a pass by reference is done.


Ah, I see. That is how it should be.

--
Ian Collins.
May 1 '06 #137
jacob navia <ja***@jacob.remcomp.fr> writes:
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. We want to talk ABOUT THE LANGUAGE ITSELF.


If you just wanted to talk about the language itself, I wouldn't have
any problem.

The language itself doesn't have operator overloading, yet you insist
on talking at length about operator overloading.

--
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.
May 1 '06 #138
Keith Thompson wrote:
jacob navia <ja***@jacob.remcomp.fr> writes:
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. We want to talk ABOUT THE LANGUAGE ITSELF.

If you just wanted to talk about the language itself, I wouldn't have
any problem.

The language itself doesn't have operator overloading, yet you insist
on talking at length about operator overloading.

Keith,

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.
Potential improvements?

--
Ian Collins.
May 1 '06 #139
Ian Collins <ia******@hotmail.com> writes:
[...]
Keith,

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.
Potential improvements?


I would say that potential improvements *would be* topical here if it
weren't for the existence of comp.std.c.

Discussions of potential improvements are off-topic if they're a thin
disguise for advertisements for some specific compiler that happens to
implement them as an extension.

--
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.
May 1 '06 #140
jacob navia said:
This lack of depth in the discussion provokes that most people stop
contributing and go away.
So why the constant high traffic?

C people will be seen as a conservative group
Only by silly people who can't understand the very, very, very simple idea
of discussing /THIS/ computery stuff in comp.this and /THAT/ computery
stuff in comp.that.
of old fashioned programmers that do not go beyond the linked list and
are so conservative that harmless changes like generic functions, or
even default arguments are seen as an heresy.
No, they're seen as being suitable for discussion elsewhere.
This group has no chart actually,
That is true on so many levels, and is possibly the most accurate statement
you've ever made.
and this narrowing of the scope of
this discussion group about the C programming language (something that
also involves the evolution of C) has no legal basis whatsoever.
This isn't a question of "legal basis". This is a question of keeping
important expertise around. The traffic is quite high enough as it is, and
it's already impossible for busy people to read every article in sufficient
detail to do it justice.

If we start accepting questions on raw I/O, directory parsing, menu design,
getting and setting file attributes, free memory, process catalogs,
threads, free disk space, maps, the current background colour, detecting
and updating the current printing device, tape drives, vectors, BIOS
information, baud rate retrieval, drive letters, connecting to a socket,
pixel-scraping, default arguments, pids, uids, gids, EBCDIC, file
timestamps, partitioned data sets, interrupt vectors, updating the system
date and time, inheritance, process forking, classes, event handling,
setting the current drive, ASCII, operator overloading, pipes, interfacing
with physical registers, try/catch exception handling, connecting to a
database, bitmap file formats, clearing the screen, the syntax of select
statements, the syntax of SELECT statements, polymorphism, floodfill, pie
charts, text prediction, daemons, device contexts, resource handles,
multimaps, inline assembly language, iostreams, readln, writeln, setting
environment variables, curses, ncurses, vncurses, and all the rest of it,
then it will be rather harder for the experts in straightforward portable C
programming to discover where that expertise can best be applied.
Eventually they'll stop bothering to try, and that expertise will be lost
to Usenet.
But the "regulars" have always won in discouraging people from any
in-depth discussion.
Not true. What we have done is ***encouraged*** that discussion to take
place elsewhere on Usenet, where there are plenty of newsgroups for the
purpose.
Maybe because they fear that C will lose some original "purity"
No. Duh. It's because - here, let me try this in words of one syllable.

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

Get it yet?
or (probably more often) because they believe that C++
is the future and that C should be destroyed as anything capable of
evolving.
Oh, for heaven's sake, this is programming, not a religion. People find it
useful to have a newsgroup for discussing portable C programming. If you
find that useful too, great, stick around - you're welcome to join the
group but not to destroy it. If you don't find it useful to have a
newsgroup for discussing portable C programming, great, that's fine, go
elsewhere where there are lots of other newsgroups.
I hope I am wrong.


Always, it seems.

--
Richard 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)
May 2 '06 #141
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. We want to talk ABOUT THE LANGUAGE ITSELF.


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

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

Richard
May 2 '06 #142
Richard Bos a écrit :
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. We want to talk ABOUT THE LANGUAGE ITSELF.

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

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

Richard


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

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

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

jacob
May 2 '06 #143
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.

--
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)
May 2 '06 #144
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.

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

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

The minimum set for containers would be:

Lists
Flexible arrays
Hashtables

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

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

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

The usage would be:

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

In this way, the user could change specific parts of the API at run time
to fit his/her needs ("subclassing") easily.
And how will you persuade people to use the new
library instead of whatever they are using right now?

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

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


Yes, because in this polemic situation it is difficult to discuss
matters with the necessary objectivity. I am not saying I know all the
answers and this is quite difficult. It is made even more difficult if
there is an hostile atmosphere around.
May 2 '06 #145
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.
The standards comitee doesn't even accept simple data structures like
strings. Lists, flexible arrays, stacks, queues, etc etc must be done
over and over, and are kept OUTSIDE the standard library.

Why?
Why not? This way the language itself is kept lean and simple,
and those that need more complex stuff can choose from a host of
good libraries that do what they want. GLib comes to mind as an
example.
I repeat that such an attitude towards data structures means that indeed
C is the past and C++ the dreaded future.


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

robert

May 2 '06 #146
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?

robert
May 2 '06 #147
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
May 2 '06 #148
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.
Potential improvements?


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

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

May 2 '06 #149
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.
May 2 '06 #150

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

65
by: perseus | last post by:
I think that everyone who told me that my question is irrelevant, in particular Mr. David White, is being absolutely ridiculous. Obviously, most of you up here behave like the owners of the C++...
205
by: Jeremy Siek | last post by:
CALL FOR PAPERS/PARTICIPATION C++, Boost, and the Future of C++ Libraries Workshop at OOPSLA October 24-28, 2004 Vancouver, British Columbia, Canada http://tinyurl.com/4n5pf Submissions
17
by: Howard Gardner | last post by:
/* If I am using boost, then how should I write this program? As it sits, this program is using SFINAE to determine whether or not a type supports particular syntax. I suspect that there is...
2
by: smith4894 | last post by:
{ not sure you're aware of that but there are the newsgroups for all major operating systems. you might want to try asking in the forum 'comp.os.linux.development.apps', since memory-mapped files...
5
by: linyanhung | last post by:
I used a boost multi thread in VS 2005 on a Duo Core PC, and made a two thread process. The code is something like this: #include <boost/thread/thread.hpp> void fun1() { //do something
8
by: Matt England | last post by:
My team currently using Boost Threads, but we are considering switching to ZThreads. (We seek cross-platform, C++ multithreading capabilities in an external library.) ZThread(s): ...
2
by: ironpingwin | last post by:
Hi! I'd like to make few threads which will run in the same time in C++. I try to use boost library v 1.34.1 (it can't be newest, because I compile on remote machine, which is not...
13
by: brad | last post by:
Still learning C++. I'm writing some regex using boost. It works great. Only thing is... this code seems slow to me compared to equivelent Perl and Python. I'm sure I'm doing something incorrect....
5
by: ameyav | last post by:
Hi All, I am converting some C code into C++ code. The objective is to improve throughput. I have some code written in C which serially parses through a list of files, opens each one of them,...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.