Boost process and C

[Flash Gordon]

Richard Heathfield a écrit :

Exactly. That is why you would use operator overloading in computers
that have the MMX instruction set (PCs) and not use any operator
overloading for those operations in computers that do NOT have that
feature.

Compare this solution with other solutions where the language would add
a special |+ operation (or similar) to the language itself.

All implementations would have to use it.

The advantage of operator overloading here is PRECISELY that you do it
where it is needed and nowhere else!

If I write code depending on the |+ operator then I need it implemented
on all the systems I need it ported to. It does not matter to me whether
it is implemented as an MMX instruction or a function call. You don't
need operator overloading for that, you need it added to the base language.

The language is made extensible without adding any specific extension.

The reserved namespace and stating in the standard that extensions are
allowed does that. Hell, since |+ is currently an error you can add it
as an extension to your compiler if you want, as long as it produces a
diagnostic when invoked in standard conforming mode! No need for
operator overloading to allow you to do that.

B)

This feature is useful when applied to special forms of arrays. Suppose:
typedef struct _String {
size_t length;
char *data;
} String;

If you want to maintain the natural syntax

String s;
...

s[2] = 'e';

it is good to be able to overload the [].

That's arguable. Some might consider it good. Others might consider it
unnecessarily confusing. [] suggests that s is an array, which it
clearly is not.

Excuse me, it IS an array, but indexed with an size_t offset from the
beginning that is all.

It's a structure containing an array.

Why is this:

SomeIntType_t a,b=7,c=6;
a = b*c;

more *difficult* to read than

SomeIntType_t a,b,c;

intToSomeIntType(&b,7);
intToSomeIntType(&c,6);
SomeIntType_Add(&c,b,a);

?????????

Well, your suggestion here seems to have use * for addition... ;-)

Anyway, I would have done
SomeIntType_t a;
SomeIntType_t b = makeSomeTime(7);
SomeIntType_t c = makeSomeTime(6);

c = SomeTypeMult(b,c);

Unless the operation is very complex, in which case it might be worth
people knowing that rather than thinking, oh, that's just a multiplication.

Operator overloading may well be useful. So feel free to propose it to
the standard committee. However, that is not this group which discusses
the existing language.

 

[Richard Heathfield]

jacob navia said:

Richard Heathfield a écrit :

Exactly. That is why you would use operator overloading in computers
that have the MMX instruction set (PCs) and not use any operator
overloading for those operations in computers that do NOT have that
feature.

In other words, it would be an implementation extension rather than part of
the language - which is basically what happens now. Code that used it would
not be portable to computers that don't have that functionality.

If you want to maintain the natural syntax

String s;
...

s[2] = 'e';

it is good to be able to overload the [].

That's arguable. Some might consider it good. Others might consider it
unnecessarily confusing. [] suggests that s is an array, which it clearly
is not.

Excuse me, it IS an array, but indexed with an size_t offset from the
beginning that is all.

Excuse me, but it is *not* an array. It is an instance of a struct type
containing an array.

Why is this:

SomeIntType_t a,b=7,c=6;
a = b*c;

more *difficult* to read than

SomeIntType_t a,b,c;

intToSomeIntType(&b,7);
intToSomeIntType(&c,6);
SomeIntType_Add(&c,b,a);

?????????

The function calls in the second version remind the reader that something
more complicated than mere arithmetic is happening. At present, a
maintenance programmer is entitled to assume from a single glance that a =
b * c is merely an arithmetic operation, obviously of no consequence in his
bug hunt, whereas what you are proposing would mean that such an operation
could conceal an arbitrary number of side effects, and indeed may not even
have anything whatsoever to do with multiplication.

 

[Jordan Abel]

Richard Heathfield a écrit :

Exactly. That is why you would use operator overloading in computers
that have the MMX instruction set (PCs) and not use any operator
overloading for those operations in computers that do NOT have that feature.

More likely you mean, use a new type with a real operator that does that
on computers that have MMX, and use operator overloading to implement
saturation arithmetic in software on computers that don't have it.

 

[Keith Thompson]

Robert Latest a écrit :

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.

Of course the "regulars" are right. C should be kept as dead as
possible. This is of course RIGHT since you say that C++ is the best
thing in the world. There is no point in dveloping C. C++ has done it
already.

That's YOUR point of view, I disagree.

jacob, until you stop making these *absurd* claims about what you
think everyone else believes, you will not be taken seriously here.

The "regulars" do not believe, and have never stated, that "C should
be kept as dead as possible", or that "C++ is the best thing in the
world". In attempting to support this ridiculous claim, you have
quoted E. Robert Tisdale, a notorious troll who absolutely does not
represent the point of view of anyone else in this newsgroup.

Most of us believe that C is (in many ways) a good language as it is,
though there is certainly room for improvement. Many of us believe
that C++ or other languages might be more appropriate than C for some
tasks; that in no way implies that C is, or should be, a dead
language.

Until and unless you understand that, you will not be able to have any
kind of serious discussion here. At the very least, I suggest you
stop trying to tell us what *we* believe, and concentrate on telling
us what *you* believe (assuming it's topical).

 

[CBFalconer]

Robert Latest a écrit :
.... snip ...

Lean and simple?

Assembler is even leaner and is much simpler.

Please post the source code to the last project you wrote in
assembler, and which ported unchanged to, say, an 8080, an 8051, an
8086, a 6800, a68000, an IBM 360/370, a PDP11, an HP3000. I trust
it ran to completion, and produced the same output on all systems
for the same input.

I won't insist on any more than the above selection. Note that I
even omitted a PIC and the Rabbit and the 6502. I will even let
you pick the (available) OS for each machine. However I do expect
more than a single 'halt' instruction.

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

 

[CBFalconer]

Ben Pfaff wrote:
.... snip ...

That's a pretty wishy washy premise on which to base an implied
disapproval of Bstrlib. Let me just guess that you haven't really
seriously taken a look at it.

The last time I took an (admittedly cursory) look at Bstrlib, I
found it cursed with non-portabilities and unwarrented assumptions,
not to mention an interminable API. This is a criticism very few
can make of the standard C string operations.

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

 

[Keith Thompson]

Where would you draw the line on topicality?

My interpretation is [...]
Potential improvements?

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

If you don't like the features of C, you can either:

(1) Do without, or

(2) Use some other language that provides those features, or

(3) Use a C compiler that implements those features as an extension
(thus tying your code to that specific implementation), or

(4) Push to have the new features added to the next revision of the C
standard, and then wait for the new standard to be published, and
then wait for implementations to support the new standard. If
you're *very* lucky, this might take as little as a decade.

If you think the standardization process is too slow, you can discuss
it in comp.std.c. If you know of an alternative other than the ones
I've mentioned (and they've *all* been mentioned here), feel free to
suggest it.

 

[CBFalconer]

.... snip ...

[1] Please remember that the introduction of C99 did not magically
change the documentation of all existing implementations. The
documentation for Turbo C 2.01 still claims that it is an ANSI C
compiler, even though ANSI C has moved on and Turbo C 2.01 has not.
It is not unreasonable for people to expect to be able to compile
ANSI C programs in Turbo C 2.01.

In fact, that is one portability test I try to apply to my code.
It has been known to rub ones nose in unwarranted assumptions.

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

 

[Ben Pfaff]

That's a pretty wishy washy premise on which to base an implied
disapproval of Bstrlib. Let me just guess that you haven't really
seriously taken a look at it.

I've never looked at Bstrlib, so I have no comments specifically
about it. But I believe that my statement holds in general.

 

[Ian Collins]

And the STL is easier to port?

I think the point was you don't have to, because it is part of the
language, the compiler vendor does this.

 

[Ian Collins]

What's so great about operator overloading?

Nothing that justifies adding it to C.

 

[Ian Collins]

This contradicts both of the two Off topic categories that you cite.

How and where?

 

[regis]

Operator overloading is, IMHO, a really, really bad idea. I've only
been coding C for just under a year, and 11 months ago I was really
bent out of shape that I couldn't write:
struct foo A,B,C;
A = B + C;
but I'm really glad now that I can't, and I would hate to see operater
overloading be expanded in C. Operator overloading in C is the root
cause of a very large number of bugs already. How many bugs are a
result of "3+4" being different that "3.0 + 4.0"? Those bugs would
have been avoided had the programmer been required to type
"int_add(3,4)" or "float_add(3,4)". Now, I'm not arguing that the '+'
symbol be dropped for arithmetic on basic numeric types, but expanding
the language to allow '+' as an infix operator on user-defined structs
is just asking for trouble. The only gain is (arguably) cleaner code,
but quite frankly "A = foo_add(B,C)" is more informative than "A =
B+C" and less prone to error.

without operator overloading, how about just an infix notation
for 2-ary functions (with, e.g., functions evaluated left to right,
all with the same priority) ?

typedef struct Vect { double x, y; } Vect;

infix Vect Vect_Sub (Vect u, Vect v) {
return (Vect) { .x= u.x - v.x, .y= u.y - v.y };
}
infix Vect Vect_Scale (double lambda, Vect u) {
return (Vect) { .x= lambda*u.x, .y= lambda*u.y };
}
infix double Vect_Dot (Vect u, Vect v) {
return u.x * v.x + u.y * v.y;
}
int main (void) {
Vect u, v, w, p, q, r, s, t;
...
t= ((v Vect_Sub u) Vect_Dot (w Vect_Sub v))
Vect_Scale (p Vect_Sub q Vect_Sub r Vect_Sub s);
...
}

 

[Mark McIntyre]

Keith Thompson a écrit :

But that's the point Keith.

The point is that you want the regulars to drift away? Stop taking
acid please.

We want to talk ABOUT THE LANGUAGE ITSELF.
indeed.

Not just the narrow definition of "The language as it was in 1989" or
"The language as specified in the C standard",

but that *is* the language.

but including discussions
like this discussion, that is the first in many years that touches
topics that go beyond

your idea is like creating a group specially to discuss the French
language, but insisting to also discuss Franglais, patois, lingala,
and all the other derivants of French.

Everything is frozen here, like in a museum.

You're quite wrong, but then I don't expect you to see this, since you
have a twisted and bizarre view of CLC. Please go away and play
somewhere else.
--
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

 

[Mark McIntyre]

Yes, because in this polemic situation it is difficult to discuss

It is only polemic because you make inflammatory statements like this:

Everything is frozen here, like in a museum.
Neither you nor anyone else has any authority to tell me what I should do or not do.

And make false statements such as

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

The first three of these are entirely topical here and are frequently
discussed. The last is indeed offtopic, since its the subject of
comp.std.c.

I really do find it hard to see why you can't understand this. Perhaps
you ought to stop being so "gallic" and feeling insulted about it, and
try to listen to the advice you receive instead. Is it /really/ so
difficult to restrict your posts to topical material, and avoid
wandering off into discussions about how lcc's extensions work, or dos
assembly language or whatever?
--
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

 

[Mark McIntyre]

C should be kept as dead as
possible.

Yup, its dead. You can move on now, nothing to see.

Usenet is there to allow people interchange ideas, proposals, ways of
working, etc

indeed. So why don't you interchange some, instead of trying to force
everyone to agree with you?

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

 

[Mark McIntyre]

Robert Latest a écrit :

It is a technique for defining new numeric types and new kinds of
operations for numeric types.

And? Whats so great about that?

This is not possible in standard C.

Yes. And?

Whats your point? That other environments have features that are
useful? Great. In that case will you please add the sys$system
routines to lcc immediately, they were handy features too, like
whenever I need to rewind a DEC tape or dismount a cluster member in
my 8800s.
--
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

 

[Mark McIntyre]

Richard Heathfield a écrit :

Consider that the MMX instruction set is around 10 years old now,

Can you point out where in my 80386 and in my 68000 the MMX
instructions are to be found? Please don't claim that these chips are
no longer used. How about in the IA-64 core or in the chip driving my
(and probably your) router? Or in my palmtop PC or DVD recorder?

and that we have yet to see a mapping of those operations into C.

perhaps because not all the world's a pentium?
--
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

 

[Mark McIntyre]

That's a pretty wishy washy premise on which to base an implied
disapproval of Bstrlib.

Ben did not say that, you made it up to provoke a reaction. Please
don't do that, it detracts from the quality of your arguments and
causes people to apply hostile filters.
--
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

 

[CBFalconer]

I think the point was you don't have to, because it is part of the
language, the compiler vendor does this.

And, if you write the library in truly portable C, without any
silly extensions and/or entanglements, you just compile the library
module. All the compiler vendor need to do is meet the
specifications of the C standard.

Simple, huh?

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