C++ has Boost libraries, C?

[Walter Roberson]

We were speaking of operator overloading and I indicated that it is
well adapted for numeric types, and that other applications like
"abc"+"cde" --> "abccde" are wrong, since it violates some of the basic
rulmes of addition: a + b == b + a. That's why I said that. Not so
explicitely but that was my intention. In c++ this doesn't hold.

In IEEE 754 float arithmetic, x + y + z is not necessarily the same as
z + y + x, but you still consider this meaning of '+' to be acceptable.

(If x is negative epsilon, y is 1.0 and z is epsilon, then
x + y exists as a number less than 1.0 and adding back in epsilon
gives a different number, possibly 1.0; but if the operations
are done in another order, then (by definition) 1.0 + epsilon gives
1.0, and subtracting epsilon off of that gives a number which is
not 1.0; the two results are certain to be different for these
particular values. There are other situations in which the order
of operations can make a large cumulative difference.)

 

[Keith Thompson]

We were speaking of operator overloading and I indicated that it is
well adapted for numeric types, and that other applications like
"abc"+"cde" --> "abccde" are wrong, since it violates some of the basic
rulmes of addition: a + b == b + a. That's why I said that. Not so
explicitely but that was my intention. In c++ this doesn't hold.

<OT>

What exactly does "wrong" mean in this context?

If, hypothetically, a future C standard incorporated operator
overloading, should overloadings that you consider "wrong" be
prohibited? Should the compiler enforce the rule that an overloaded
"+" operator must be commutative? And if so, how?

Or is this merely your opinion on a style point?

</OT>

 

[jacob navia]

Keith Thompson a écrit :

<OT>

What exactly does "wrong" mean in this context?

If, hypothetically, a future C standard incorporated operator
overloading, should overloadings that you consider "wrong" be
prohibited? Should the compiler enforce the rule that an overloaded
"+" operator must be commutative? And if so, how?

Or is this merely your opinion on a style point?

</OT>

It would be highly undesirable that you define
the "+" operator that does a division, the "*" operator that
does an exponential, etc.

I mean with "wrong" that the nature of the operation is
violated, what makes the reading of such code a nightmare
or a good candidate for the "obfuscated C contest".

Nothing in lcc-win32 will enforce this of course, since
there is no known algorithm that can say why redefining
addition as multiplication would be "wrong".

If we extend operator overloading with some keywords
so that the programmer can SPECIFY that addition is
commutative, for instance, we could then assume
that a+b == b+a and it would NOT be necessary to redefine

int operator+(Type a,int b);
and
int operator+(int b,Type a);

and the compiler would be allowed to invoke one redefined
operator for both notations.

 

[Walter Roberson]

If we extend operator overloading with some keywords
so that the programmer can SPECIFY that addition is
commutative, for instance, we could then assume
that a+b == b+a and it would NOT be necessary to redefine

int operator+(Type a,int b);
and
int operator+(int b,Type a);

and the compiler would be allowed to invoke one redefined
operator for both notations.

That could be useful -- but I fear that there would be a big tendancy
to use such a facility with floating point numbers, operations upon
which are not really commutative or distributive.

 

[Serve Laurijssen]

Why constant time lookup? It depends if you want that feature or not.
The flexibility of having just to change a declaration and all your code
still works if you use a normal array, a list, a flexible array, etc
is worth the inconvenience of having in mind which container is
being used and how fast/slow it is.

thats why you should reinvent the iterator concept too if you wanna make a
really general container library in C. Then you can iterate over all the
containers in the same way.
But whatever, if you can justify overloading [] on a list then we will
probably never agree and we better stop here. It's very very off topic
anyways

 

[Lane Straatman]

"jacob navia" <[email protected]> wrote in message

[Boost this]

[Boost that]
I've looked at Boost for quite a while now, and a realization of it in C is
simply not going to happen anytime soon. Whatever the merits are, it's one
of those things like curing cancer: people buzz about it, but it remains
unrealized and for good reasons. LS