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

[Dag-Erling Smørgrav]

Those aren't any more secure than regular strcpy().

That's a pretty tall claim. It will be interesting to see you back it
up with actual arguments and not just bluster.

DES

 

[Dag-Erling Smørgrav]

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

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.

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.

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.

DES

 

[Dag-Erling Smørgrav]

Feeling C++-ey would be simple enough without any standard library
changes:

namespace std {
#include <stdio.h>
#include <stdlib.h>
}

And boom, you've got std::malloc() and std:uts() and all that.

You can't randomly wrap declarations for existing symbols in a
namespace. The linker won't find them.

DES

 

[Dag-Erling Smørgrav]

The linker doesn't have namespaces, C++ only has mamespaces because
the compiler mangles names, and each compiler mangles differently.

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

DES

 

[Dag-Erling Smørgrav]

IRRC C99 required changes to linkers,

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

DES

 

[Dag-Erling Smørgrav]

o AVL trees
o Red/Black trees

What is the advantage of having both? AFAIK they have the same
semantics and the same computational complexity.

DES

 

[Dag-Erling Smørgrav]

I agree. That is one reason why containers are part of the C++
standard library and not the C one. Containers were a bodge in Java
before generics were bolted onto that language.

They're still a bodge. Java's generics are just syntactic sugar to hide
down- and up-casts between Object and whatever it is you want to put in
your container. Same thing with enums, they're just syntactic sugar for
static singleton objects of subclasses of a user-defined class.

DES

 

[Dag-Erling Smørgrav]

For that matter I am pretty much repulsive to Java libs.

I'm sorry they feel that way about you

DES

 

[Ian Collins]

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

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

 

[Walter Banks]

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.

To broaden the comment. C code created by clever macros (and
some we see are very clever) are a nightmare to debug. One personal
experience on this was a set of macro's we developed and used to
create compiler automatic edge effect testing were essentially
impossible to debug when the macro or compiler generated code
failed.

Walter..

 

[jacob navia]

Ian Collins a écrit :

<snip>

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

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?

jacob

 

[Flash Gordon]

Ian Collins a écrit :

<snip>

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

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?

Mean while, in the rest of the world we have to work with code written
by people who have not heard of the need for such scrutiny. So although
you don't have to deal with the problems because you strictly limit
yourself the rest of us do.

 

[Alan Curry]

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

Most of us had our intuitive idea of "what multiplication is" permanently
fixed long before the word "ring" entered the picture (if it ever did!)
and would have recognized commutativity as one of its main features, long
before we learned the word "commutativity".

My "*" operator overload definition for arrays would be the Hadamard product.
It has an obvious resemblance to real multiplication that the mathematicians'
"matrix multiplication" doesn't.

On the other hand, the lack of agreement on what the "*" operator should do
on arrays is also a strong argument that it shouldn't do anything, i.e. C is
correct as is.

 

[Phil Carmody]

The linker doesn't have namespaces, C++ only has mamespaces

I know I've accused it of some pretty heinous things in the
past, but never that. I obviously need to crank them up a notch.

Hoorah for visual rhymes,
Phil

 

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

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. I can agree on "it's not a mnemonic after all".
In which case, what merit does it have?

Phil

 

[Phil Carmody]

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

For each n, the ring of n*n matrices. 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.

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

Woh-woh-woh - it was _precisely_ in a context of commutitivity where
his objection was brought up. I can't quote chapter and verse as
jacob is burried right at the bottom of my killfile, but according
to those who followed up to him, it was clear that commutitivity was
the issue that had been raised.

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.

Cases, plural; in fact an infinitude of them.

Phil

 

[Phil Carmody]

What is the advantage of having both? AFAIK they have the same
semantics and the same computational complexity.

Different constants?

You do realise that 1 and 10^9 are different, don't you? In which
case you're well on the way to realising that 1 is different from
2. And with that information, you're hopefully equipped with the
capability to understand that AVL trees and RB trees are clearly
distinguishable in terms of their runtime behavior. Please realise
that capability.

Phil

 

[Phil Carmody]

why not somethig of this kind
f64 v;
cout << fmt("%4:4f64") << v;

[post to c and c++ newsgroup]

the above should be possible in C++ (pheraps using instead "%4.4f").

don't remember what is fmt, could be one "stream manipulator"? could be
one class [the call to one constructor of a tmp object]?
don't know. do you know it someone of you?

Is it possible this below?
double a, b;
cout << SPrintf("%2.2f %2.3f", a, b) << "\n";

with SPrintf() one function (stream manipulator?)
ostream& SPrintf(ostream& v, char* fmt, ...)?
that print like printf() in stdout?

Ellipsis cannot be made to work type-safely in C++. Instead, one uses some
kind of operator overloading, which takes care of needed conversions. There
is the boost.format library, the usage looks like:

cout << format("%2.2f %2.3f") % a % b;

puke

 

[Ben Pfaff]

And with that information, you're hopefully equipped with the
capability to understand that AVL trees and RB trees are
clearly distinguishable in terms of their runtime behavior.

I wrote a paper about that once:
http://benpfaff.org/papers/libavl.pdf

 

[jacob navia]

Dag-Erling Smørgrav a écrit :

What is the advantage of having both? AFAIK they have the same
semantics and the same computational complexity.

DES

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.