Has thought been given given to a cleaned up C? Possibly called C+.

[bartc]

If there was an operator keyword (or something) that would declare
a one-or-two parameter function to take its arguments in that style,
there would be no need for extra keywords.

Then you could have

a = b pow c;

as well as

w = u dot v;
iA = inv A;
At = transvert A;
name = fname cat lname;

This works better with a single operand.

With two, there's the problem of precedence, plus I don't think it does much
for readability:

a = b c d e f g h;

I have used such an operator before:

a = b max c;

but you have to fight an instinct to write max(b,c) instead. Although:

a max= b;

seems natural enough.

 

[Eric Sosman]

[...]
If there was an operator keyword (or something) that would declare
a one-or-two parameter function to take its arguments in that style,
there would be no need for extra keywords.

Then you could have

a = b pow c;

"Hello, world!\n" fputs stdout;

More seriously, you could also have

a = b pow c + d;

.... and a thicket of precedence questions. A mechanism for
inventing new operators needs some way to describe how they
mix with existing operators. This could get particularly
nasty in code using operators from different libraries
written by different vendors, unaware of each other:

a = b top c hat d white e tie f tails g;

.... where top, hat, white, tie, and tails come from Apple,
Google, Microsoft, Oracle, and that contractor we hired a year
or two ago, respectively.

 

[Andrew Poelstra]

The container library is around 80K (32 bit machines)

In that space I have
o lists (double/sinlgle linked)
o bitstrings
o AVL trees
o Red/Black trees
o Dictionary (Hash tables)
o Flexible arrays.

Is 80K "too large" ???

Over-specced?

You have remained silent (as all other "regs") in the discussions
about the library here.

It is very easy. You limit yourself to piss at other people's proposals
without ever proposing anything.

Is any or all of your library usably complete (and available)
right now?

 

[Seebs]

Seebs a écrit :

The standard makes this distinction, I did not invented it.

I never said, nor implied, that you invented it. I merely observed that
the apparent contradiction in your statement (pointed out by Richard Bos)
is adequately explained if you consider that distinction, which is indeed
part of the language.

I do not think so. Modern C software design can be quite sophisticated.
Why should we stay at the level of, say, strcpy?

Because that has been a goal of the design of the library for quite some
time.

"top heavy"?

Imposing a fair amount of overhead, in terms of:
* conceptual complexity
* code required to implement or use
* storage
* runtime

The goal was to have an extremely flexible design that can accomodate
further enhancements without making old code obsolete. True, for a
simple linked list it looks too heavy, but the advantages of a standard
container is that it makes all programs *compatible* by allowing data
interchange in a standard way.

I don't see how it does. Interchange between programs relies on IPC, and
I can't simply send someone else my raw data structures -- if they don't
have the functions to which I have function pointers in my containers, then
that won't work.

Of course if you just want a simple linked list it is top heavy. Writing
a red/black tree implementation or a dictionary is not the same however,
and even if the syntax looks forbidding at first sight thebgains come
with regular use.

That's possible. I think you might well be right that having this tool
around would be of use to people; the big issue, I think, is that it's not
clear that it's enough use to justify adding it to the spec, rather than
publishing it as a separate library.

We gain huge utility from the existence of zlib, but that doesn't mean that
ISO should standardize on it.

I do not think that newbies are the problem here. It is rather the
oldbies ( ) like me that have this FED UP feeling when they start
coding the 100th linked list implementation...

That could be a point, but I'm not sure how this mandates a language change
rather than merely a provided third-party library.

-s

 

[Keith Thompson]

Flash Gordon wrote: [...]

My experience is that operator overloading leads to confusion for
experienced users.

It certainly can.

In most cases, it should be avoided. The C++ overloading of >> and <<
for IO operations is definitely a pretty bad idea. There are rare
cases where it does make sense because the operator has a very natural
meaning (vector addition, matrix multiplication). It is a feature that
should be used with care. But >> and << for I/O is not one of them.

I don't agree. It's an arbitrary choice of symbol that does have
some mnemonic value; the arrow indicates the direction in which
the data flows. It's really no more arbitrary than the original
choice of >> and << to denote shift operators when they were first
introduced.

To a C++ programmer, the >> and << operators have a well known
meaning as I/O operations, perhaps better known than their older
meaning as shift operations.

If operator overloading were to be added to C, I wouldn't object
to doing something similar. Though I'd want a cleaner way to
specify formatting (hexadecimal, field width, etc.) for a single
item without changing the state of the stream.

 

[Ben Bacarisse]

If there was an operator keyword (or something) that would declare
a one-or-two parameter function to take its arguments in that style,
there would be no need for extra keywords.

Then you could have

a = b pow c;

<OT>
Haskell does this with ``. Given a function f (of the right type) you
can write x `f` y. mod and div are done this way.

<even more OT>
Haskell also has the reverse. Given an operator like +, (+) is a
function that behaves like +. (+x) and (x+) are also functions, but
they are now the function that adds x to something.
</even more OT></OT>

<snip>

 

[Flash Gordon]

Unless there was a standard for mangled names in C. Namespaces require
name mangling.

It doesn't need a standard for name mangling in the sense of something
added to the language standard. All it needs is for the implementation
(or OS) to decide on what method it will use (which can be considered a
standard for that particular implementation or OS), just as it has to
decide currently how simple names will be stored in the object file
(assuming there is such a thing).

A simple way of avoiding breaking anything existing is for the
implementation to decide that anything not in a namespace will be
unmangled, and anything defined as in a namespace will start with a
character which is not currently (for that implementation) a valid
character to start an identifier.

The confusion with the linker could be solved at the linker. If
currently the linker allows you to do "-lfoo" to link in foo, it could
allow "-lfoo:bar" to link in foo with a namespace of bar.

All these problems are solvable, and I agree it would be nice (from my
perspective) if they were solved. Whether it is worth the effort is
another matter, one which the standards bodies and compiler writers have
to decide on. Personally I suspect they will not implement namespaces in C.

 

[Keith Thompson]

You have remained silent (as all other "regs") in the discussions
about the library here.

It is very easy. You limit yourself to piss at other people's proposals
without ever proposing anything.

There you go again, jacob.

The "regs" have commented on your library. Please do not claim
otherwise.

 

[Phil Carmody]

(Sorry, have to drop .moderated, as for some unknown reason GNUS refuses
to post there.)

Flash Gordon wrote: [...]

My experience is that operator overloading leads to confusion for
experienced users.

It certainly can.

In most cases, it should be avoided. The C++ overloading of >> and <<
for IO operations is definitely a pretty bad idea. There are rare
cases where it does make sense because the operator has a very natural
meaning (vector addition, matrix multiplication). It is a feature that
should be used with care. But >> and << for I/O is not one of them.

I don't agree. It's an arbitrary choice of symbol that does have
some mnemonic value; the arrow indicates the direction in which
the data flows.

'Flows', eh?

So in
s >> a >> b >> c;
c flowed out first as it's the furthest from the source?

It's really no more arbitrary than the original
choice of >> and << to denote shift operators when they were first
introduced.

To a C++ programmer, the >> and << operators have a well known
meaning as I/O operations, perhaps better known than their older
meaning as shift operations.

If operator overloading were to be added to C, I wouldn't object
to doing something similar. Though I'd want a cleaner way to
specify formatting (hexadecimal, field width, etc.) for a single
item without changing the state of the stream.

Agreed. That was one of many things that turned me from an actively
proselytising C++ programmer in the turn of the 90s, so someone who
now finds laughing and puking the only two options when faced with
C++ code.

While still under the impression that I liked C++, I did write an
alternative to the stream-state-changing warts which was simpler,
and clearer. Definitely nothing they'd ever want in the standard
language at all, then.

Oh, god, gotta rush to the bathroom, I just remembered operator++(int);

Phil

 

[Phil Carmody]

|
|> jacob navia wrote:
|> >
|> > a+b <--> b+a
|> > a*b <--> b*a
|>
|> What do you have against a-b and a/b?
|
|And against vector multiplication?

scalar*vector follows the rule just fine. And vector*vector as long as you
mean dot product. Cross product is exactly where you have gone too far if you
overload the "*" operator for it.

Matrix multiplication is just crazy. I don't see why the mathematicians
insist on calling it "multiplication" at all.

Because it is, in that ring. An objection based on non-commutativity
is to me as toothless as an objection based on a ring not being an
integral domain (having zero divisors). Which is toothless.

Phil

 

[Nick Keighley]

[...] the problem I see with operator overloading is
that you are stuck with an arbitrary set of operators to work with. If
you really are just implementing, say, complex numbers or very large
integers, then it's useful - but you don't do that very often.  This is
Jacob's position AIUI.  But if you want to do something else you end up
forcing it into this mould.  This is what tends to happen.

my experience with C++ is the you hardly ever overload the obvious
things like + and * but you do end up defining your own << >> (as
these are used for i/o) and == < = as these are actually useful.

Really you need to be able to define new operators, even if this is just
syntactic sugar for functions.  Give them all the same precedence and
off you go.

Algol-68, of course, allowed you to define precedence as well...

or you go the lisp route and have no operators at all, everythign is a
function

 

[Jasen Betts]

Richard Bos a écrit :

The container library is around 80K (32 bit machines)

In that space I have
o lists (double/sinlgle linked)
o bitstrings
o AVL trees
o Red/Black trees
o Dictionary (Hash tables)
o Flexible arrays.

can you plug-in another container system
(eg: indexed on-disk storage like libdb )
by writing a wrapper?


--- news://freenews.netfront.net/ - complaints: (e-mail address removed) ---

 

[bartc]

[...] the problem I see with operator overloading is
that you are stuck with an arbitrary set of operators to work with. If
you really are just implementing, say, complex numbers or very large
integers, then it's useful - but you don't do that very often. This is
Jacob's position AIUI. But if you want to do something else you end up
forcing it into this mould. This is what tends to happen.

my experience with C++ is the you hardly ever overload the obvious

They are overwritten all time and it makes debugging and following
foreign C++ code a nightmare until you are very very very familiar with
the code. And even then in base functions you can have zero idea about
which will be invoked. C++ has lost popularity for a reason : its a
maintenance nightmare.

My feeling is that operator overloading should not be made available to mere
programmers.

If there are interesting new datatypes for which these operators would be
useful, then build them into the language somehow (or at least mention them
in an addendum to the standard), rather than provide mechanisms to allow
anybody to apply them to anything.

Oh for goodness sake. Stop mentioning Algol. It's gone.

Algol-68 never really arrived (at least I've never found a working version),
so it can't have gone anywhere.

In that case it is an interesting abstract language to compare ideas with,
or as a model of how to implement, or not implement, a particular feature.

 

[Nick Keighley]

Oh for goodness sake. Stop mentioning Algol. It's gone.

he was talking about language design. Algol-68 tackeled this problem.
Maybe it's gone because its solution was unsatisfactory. But it was an
attempt.

 

[Ben Bacarisse]

(Sorry, have to drop .moderated, as for some unknown reason GNUS refuses
to post there.)

Flash Gordon wrote: [...]
My experience is that operator overloading leads to confusion for
experienced users.

It certainly can.

In most cases, it should be avoided. The C++ overloading of >> and <<
for IO operations is definitely a pretty bad idea. There are rare
cases where it does make sense because the operator has a very natural
meaning (vector addition, matrix multiplication). It is a feature that
should be used with care. But >> and << for I/O is not one of them.

I don't agree. It's an arbitrary choice of symbol that does have
some mnemonic value; the arrow indicates the direction in which
the data flows.

'Flows', eh?

So in
s >> a >> b >> c;
c flowed out first as it's the furthest from the source?

Using the word "flow" does not mean you must forget the associativity
of the operator. The data for c (as you know) "flows" from the stream
that results from calculating (s >> a >> b).

Because left-associativity[1] is so common, I see this pattern in my
head without having to think about it.

[1] Check: "left" yes, pretty sure I mean left -- otherwise known as
"UK driving associativity"

<snip>

 

[Ben Bacarisse]

Because it is, in that ring.

What ring? Matrices don't (in general) form a ring. They are not
even always defined over one.

An objection based on non-commutativity
is to me as toothless as an objection based on a ring not being an
integral domain (having zero divisors). Which is toothless.

I agree, but it seems like an odd point to being up. There's no
evidence that Alan Curry was worried about non-commutativity when he
described matrix multiplication as "crazy".

If it matters, I agree with you. It seems perfectly reasonable to me
to call the matrix operation "multiplication" if only because of the
special case where it /does/ generate a ring.

 

[William Hughes]

Matrix multiplication is just crazy. I don't see why the mathematicians
insist on calling it "multiplication" at all.

Matrix multiplication is not "just crazy" it
corresponds to composition of linear
transforms. The operation of taking two operators
and forming a third by composition is frequently
called multiplication.

- William Hughes

 

[Nick Keighley]

Flash Gordon wrote:


In most cases, it should be avoided. The C++ overloading of >> and <<
for IO operations is definitely a pretty bad idea. There are rare cases
where it does make sense because the operator has a very natural meaning
(vector addition, matrix multiplication). It is a feature that should be
used with care. But >> and << for I/O is not one of the

in practice it works quite well

what about comparison and assignment?

 

[Nick Keighley]

Richard Bos a écrit :




The container library is around 80K (32 bit machines)

In that space I have
o lists (double/sinlgle linked)
o bitstrings
o AVL trees
o Red/Black trees
o Dictionary (Hash tables)
o Flexible arrays.

Is 80K "too large" ???

Over-specced?

You have remained silent (as all other "regs") in the discussions
about the library here.

how can you complain about him being silent /and/ complain about him
commenting on your proposal?

It is very easy. You limit yourself to piss at other people's proposals
without ever proposing anything.

perhaps he doesn't see the need for a library like yours in the
standard. Why can't you confine yourself to a technical discussion
instead of these rants?

 

[jacob navia]

Jasen Betts a écrit :

can you plug-in another container system
(eg: indexed on-disk storage like libdb )
by writing a wrapper?

Yes. If you look at the header files, all containers have
One creation function that returns a structure with
a pointer to a table of methods as its first member,
then some standard fields (size, length, number of
elements), and then you are on you own.

If you follow the directives (not required but useful)
you name your methods the same as other containers
Add for adding one element, etc

Syntax is not very pretty:

Container->lpVtbl->Add(Container, element);

but you get used very quickly. Otherwise

#define Container_Add(a,b) a->lpVtbl->Add(a,b)