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

[Andrew Poelstra]

Details? Apart from increasing the length of the significant portion of
identifiers, that is.

That was it. It also added case-sensitivity, I think. To allow
namespaces, they could be changed as little as simply allowing
a new namespace-separator character to be used in tokens.

 

[Ian Collins]

Significant length of identifiers, for instance. I don't remember what
the minimum is in the current standard, but imagine an ABI where
identifiers are truncated at 32 characters. Throw in namespaces, and
suddenly the length of the significant portion varies depending on the
length of the name of the namespace, you have to subtract a couple of
characters to serve as separators, etc. Nested namespaces complicate
the matter further. I'm not saying these problems can't be solved
(clearly they've been solved in C++), but they will require a lot of
thought.

They have also caused a lot of pain. There isn't a standardised C++
ABI. By the tine the language was standardised, different compilers
already had their own, so it was too late to change. Only now are we
seeing convergence (at least on platforms where it is widely used) on
the g++ ABI.

Too many assumptions here which don't hold up in real life. An addition
to the standard that requires changing the underlying ABI and in the
object file format will most likely be ignored and will only serve to
undermine the industry's respect for the standard and the committee.

I agree, C is simply too important and widely used to mess with the ABI.
To introduce a change would require all the compilers on a given
platform to be updated simultaneously. Namespaces aren't the only
suggested feature that would require an ABI change, operator overloaded
would require additional changes.

 

[Ian Collins]

Luckily, you're wrong. Name mangling rules are part of the ABI so
different compilers can coexist on the same platform.

Unfortunately he is correct, different compilers have their own name
mangling schemes. Most platforms ABIs are C.

 

[Hans-Bernhard Bröker]

Or, you could require namespace support to be included in linkers.
IRRC C99 required changes to linkers, so this isn't a taboo
requirement. (And really, almost all compilers come with their own
linkers these days. It wouldn't be a big deal if both needed to be
updated.)

You have that backwards. The reason there are so many distinct
implementations around is _exactly_ what's bad about any change that
requires them all to change. Easy for you to say that hundreds of
linkers worldwide have to change --- what exactly did you offer to pay
for that?

 

[Keith Thompson]

It should do. Mnemonics are the things you have to remind you,
having to remember other things as well implies they weren't
mnemonics after all. I can agree on "it's not a mnemonic after all".
In which case, what merit does it have?

False.

 

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

It should do. Mnemonics are the things you have to remind you,
having to remember other things as well implies they weren't
mnemonics after all.

That's too strong a criterion for me. A mnemonic can be a reminder of
some part (even a small part) of the whole. It does not have toi
substitute for understanding.

I can agree on "it's not a mnemonic after all".
In which case, what merit does it have?

Exactly the "some mnemonic value" the Keith stated: it describes the
direction of the data flow. It does not describe anything else not
does it substitute for understanding the whole expression.

It seems to me an uncontentious claim, but then this is comp.lang.c
I won't argue this any further if you want to disagree for a last
time.

 

[Ben Bacarisse]

For each n, the ring of n*n matrices.

Not all such sets of matrices from a ring. I'm sure you know that.

The fact that you can generalise
the operation (with restrictions) to arbitrary dimensions in no way
reduces the fact that it is clearly (to a mathematician) a cognate to
multiplication.

Agreed. But conversely, the fact that you can restrict the operation
does not diminish the fact that, to some, the analogy with
multiplication is strained.

Discussions here would be so much more productive if people took the
time to acknowledge some validity (if there is some) in other people's
point of view. Pretty much the only reason I posted was that your
reply was so totally dismissive of Alan's view. I am with you in that
I see why mathematicians call it multiplication, but I can also see
the craziness -- the operation is not even defined for some pairs of
matrices. Your reply essentially said "it is called multiplication
because it is multiplication".

<snip>

 

[Nick]

This is my point of view. Applications of operator overloading should
be numeric data and access to containers.

All other applications should be submitted to a detailed scrutiny:

o Does the operator overloading make the code easier to read?
o Is the operator overloading solution efficient? (Creation of temporary
objects, etc)
o Are the applications of the operator intuitive?
o Do they mimic correctly the behavior with other types?

Which greatly reduces the value of it as a feature of the language. I
can't imagine I'm ever going to want to implement a new sort of number
in C and need it so well integrated that calling a few functions on some
special variables is too much trouble. It's a benefit to the
implementor, and to the writers of a few libraries, but not much else
I'd have thought.

 

[Nick Keighley]

Ian Collins a écrit :

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

[operators, like + and - (I said + and * the first time round but of
course * does things other than multiply!)]

They are overwritten all [the] 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.

My experience backs Nick's observation.  The only time I've (or worked
with other people's code) overloaded arithmetic operators is for
extended numeric types.  I do make frequent use of [] and ().

This is my point of view. Applications of operator overloading should
be numeric data and access to containers.

All other applications should be submitted to a detailed scrutiny:

o Does the operator overloading make the code easier to read?
o Is the operator overloading solution efficient? (Creation of temporary
   objects, etc)
o Are the applications of the operator intuitive?
o Do they mimic correctly the behavior with other types?

and assignment and equality seem to fulfill these requirements.

if (current_shape == saved_shape)
matched_shape_case (current_shape);

control_channel = selected_channel;

what about smart pointers and function objects?

I seem to be repeating myself...

 

[jacob navia]

Nick a écrit :

Which greatly reduces the value of it as a feature of the language. I
can't imagine I'm ever going to want to implement a new sort of number
in C and need it so well integrated that calling a few functions on some
special variables is too much trouble.

Then ick, do not use operator overloading, and just use the libraries that
come with it. Counted string libraries, bignums libraries, container libraries,
etc. Nobody forces you to use that if you do not need it.

It's a benefit to the

implementor, and to the writers of a few libraries, but not much else
I'd have thought.

What else you "had thought"... ?

The silver bullet? No it isn't.

 

[jacob navia]

Ben Bacarisse a écrit :

Not all such sets of matrices from a ring. I'm sure you know that.


Agreed. But conversely, the fact that you can restrict the operation
does not diminish the fact that, to some, the analogy with
multiplication is strained.

Discussions here would be so much more productive if people took the
time to acknowledge some validity (if there is some) in other people's
point of view. Pretty much the only reason I posted was that your
reply was so totally dismissive of Alan's view. I am with you in that
I see why mathematicians call it multiplication, but I can also see
the craziness -- the operation is not even defined for some pairs of
matrices. Your reply essentially said "it is called multiplication
because it is multiplication".

<snip>

To come back to the operator overloading discussion.

The big problem with operator overloading and matrices multiplication
is the intermediate objects problem.

If we overload in a "standard" way matrix multiplication, addition etc
we can write:

C = (A+B)/(B*D);

The overloaded "*" operator creates a temporary (t1) so we have
C = (A+B)/t1;

The overloaded "+" operator creates a t2 temporary so that
C = t2/t1;

If the matrices are big, we have 2 times the storage...

There are solutions to this problem, but they are tricky. One of them
is that all operators return a tokenized structure, that instructs
the overloaded assignment operators what operations should be done.
This should be done at runtime, what makes this solution the equivalent
of having a run time interpreter of this precompiled instructions...
not very easy.

 

[Ian Collins]

what about smart pointers and function objects?

These wouldn't be anywhere near as useful in C as they are in C++
because C lacks automatic constructors and destructors.

 

[bartc]

To come back to the operator overloading discussion.

The big problem with operator overloading and matrices multiplication
is the intermediate objects problem.

If we overload in a "standard" way matrix multiplication, addition etc
we can write:

C = (A+B)/(B*D);

The overloaded "*" operator creates a temporary (t1) so we have
C = (A+B)/t1;

The overloaded "+" operator creates a t2 temporary so that
C = t2/t1;

If the matrices are big, we have 2 times the storage...

Would the problems be any different when writing:

C = DIV(ADD(A,B),MUL(B,D)); ?

If not, then they would not be specific to operator overloading.

 

[Jasen Betts]

That was it. It also added case-sensitivity, I think. To allow
namespaces, they could be changed as little as simply allowing
a new namespace-separator character to be used in tokens.

C has been case sensitive for as long as I can remember. I would be
suprised if the compiler invented for unix was ever case insensitive.


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

 

[James Kuyper]

That was it. It also added case-sensitivity, I think. To allow
namespaces, they could be changed as little as simply allowing
a new namespace-separator character to be used in tokens.

I would expect that changing the number of significant characters in an
identifier is a substantially easier task than expanding the list of
allowed characters. After all, why bother prohibiting a character
without a good reason? A character that's prohibited is generally
prohibited precisely because it is already in use for some conflicting
purpose, in which case it might be a major headache to work around the
conflict.

 

[Dag-Erling Smørgrav]

Dag-Erling Smørgrav a écrit :
Exactly, they are different IMPLEMENTATIONS of a given interface.
The objective here is to let the user choose which trees or data
structure fits best in his/her requirements.

My point is that the only difference between RB and AVL trees, AFAIK, is
that RB trees are easier to implement, which is why most container
libraries use them. There is no practical difference for the user. The
semantics and complexity are exactly the same.

DES

 

[Dag-Erling Smørgrav]

That was it. It also added case-sensitivity, I think.

Were there still linkers at that point which did not already meet those
requirements?

To allow namespaces, they could be changed as little as simply
allowing a new namespace-separator character to be used in tokens.

C++ already supports namespaces without the need for a special namespace
separator, so that's not an issue. I'm more worried about the amount of
work required to get all the details right in the standard text.

% cat >ns.cc
namespace foo { int x; }
namespace bar { int x; }
^D
% g++ -o ns.o -c ns.cc
% nm ns.o
0000000000000004 B _ZN3bar1xE
0000000000000000 B _ZN3foo1xE

Hmm...

% cat >>ns.cc
extern "C" { int _ZN3foo1xE, _ZN3bar1xE; }
^D
% g++ -o ns.o -c ns.cc
/var/tmp//ccj5qdkU.s: Assembler messages:
/var/tmp//ccj5qdkU.s:19: Error: symbol `_ZN3foo1xE' is already defined
/var/tmp//ccj5qdkU.s:25: Error: symbol `_ZN3bar1xE' is already defined

Oops!

Special namespace separator characters might be a good idea after all,
although you have to admit that this is unlikely to happen by accident.

DES

 

[Ben Bacarisse]

C has been case sensitive for as long as I can remember.

Yes, the language has been but the discussion was about linkers and C
versions. C90 included this wording:

"The implementation may further restrict the significance of an
external name (an identifier that has external linkage) to six
characters and may ignore distinctions of alphabetical case for such
names."

to accommodate old linkers. Andrew's comment that C99 required a
change is based on the fact that this wording has been dropped in C99
(and the 6 character limit has gone up as well).

<snip>

 

[Ben Bacarisse]

Were there still linkers at that point which did not already meet those
requirements?


C++ already supports namespaces without the need for a special namespace
separator, so that's not an issue. I'm more worried about the amount of
work required to get all the details right in the standard text.

% cat >ns.cc
namespace foo { int x; }
namespace bar { int x; }
^D
% g++ -o ns.o -c ns.cc
% nm ns.o
0000000000000004 B _ZN3bar1xE
0000000000000000 B _ZN3foo1xE

Hmm...

% cat >>ns.cc
extern "C" { int _ZN3foo1xE, _ZN3bar1xE; }
^D
% g++ -o ns.o -c ns.cc
/var/tmp//ccj5qdkU.s: Assembler messages:
/var/tmp//ccj5qdkU.s:19: Error: symbol `_ZN3foo1xE' is already defined
/var/tmp//ccj5qdkU.s:25: Error: symbol `_ZN3bar1xE' is already defined

Oops!

Are you worried about a program that wants to define external names
like _ZN3foo1xE? If so read on, if not, I've missed your point!

Special namespace separator characters might be a good idea after all,
although you have to admit that this is unlikely to happen by
accident.

In a sense there is one already. The names you tried to define start
with _ and an uppercase letter so they are already reserved to the
implementation. No C program can expect to be able to do that with or
without namespaces.

 

[Phil Carmody]

False.

Disagree.

Phil