Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Dennis Ritchie -- An Appreciation

Reply
Thread Tools

Dennis Ritchie -- An Appreciation

 
 
ImpalerCore
Guest
Posts: n/a
 
      11-30-2011
On Nov 30, 4:42*pm, Jorgen Grahn <(E-Mail Removed)> wrote:
> On Tue, 2011-11-29, Joe keane wrote:
>
> ...
>
> > I think operator overloading is a gain of about zero.

>
> > I've never written in C and been like 'darn it, if i only had operator
> > overloading!'.

>
> Operator overloading ties in with many of the other C++ features -- I
> don't think it would be very useful as an isolated feature.


It depends on how you view the difference between something like

c_day_duration c_date_subtract( struct c_greg_date date1,
struct c_greg_date date2 );

vs

c_day_duration operator-( struct c_greg_date date1,
struct c_greg_date date2 );

I would be lying if I didn't desire this kind of overloading at some
verbose points in my code, at least for struct types where
mathematical operations made some sense. But I can certainly get by
without it. The point is that I don't think one would need a class
abstraction to make use of it.

Best regards,
John D.
 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      11-30-2011
On 12/ 1/11 11:09 AM, Quentin Pope wrote:
> On Wed, 30 Nov 2011 22:59:39 +0100, jacob navia wrote:
>> Le 30/11/11 22:42, Jorgen Grahn a écrit :
>>> On Tue, 2011-11-29, Joe keane wrote:
>>> ...
>>>> I think operator overloading is a gain of about zero.
>>>>
>>>> I've never written in C and been like 'darn it, if i only had operator
>>>> overloading!'.
>>>
>>> Operator overloading ties in with many of the other C++ features -- I
>>> don't think it would be very useful as an isolated feature.
>>>
>>> /Jorgen
>>>
>>>

>> That is because you did not know that Fortran has operator oerloading,
>> C#, even Java. I have added operatr overloading to the lcc-win compiler
>> and it is very useful. See the other message about this in this thread.

>
> Sorry, but it is NOT useful. In those other languages, it is a curse. It
> leads to many bugs, and plenty of confusing code where it is difficult to
> tell what a simple-looking line of code is actually doing without digging
> through piles of other code to track down the relevant overloading.


That statement could be make about just about any language feature!

If you want a counter augment, look at all the baggage that had to be
added to C to support complex numbers.

> Overloading is not the C way. It is not standard C and not portable.


That I agree with.

--
Ian Collins
 
Reply With Quote
 
 
 
 
jacob navia
Guest
Posts: n/a
 
      11-30-2011
Le 30/11/11 23:10, ImpalerCore a écrit :
> On Nov 30, 4:42 pm, Jorgen Grahn<(E-Mail Removed)> wrote:
>> On Tue, 2011-11-29, Joe keane wrote:
>>
>> ...
>>
>>> I think operator overloading is a gain of about zero.

>>
>>> I've never written in C and been like 'darn it, if i only had operator
>>> overloading!'.

>>
>> Operator overloading ties in with many of the other C++ features -- I
>> don't think it would be very useful as an isolated feature.

>
> It depends on how you view the difference between something like
>
> c_day_duration c_date_subtract( struct c_greg_date date1,
> struct c_greg_date date2 );
>
> vs
>
> c_day_duration operator-( struct c_greg_date date1,
> struct c_greg_date date2 );
>
> I would be lying if I didn't desire this kind of overloading at some
> verbose points in my code, at least for struct types where
> mathematical operations made some sense. But I can certainly get by
> without it. The point is that I don't think one would need a class
> abstraction to make use of it.


You don't. lcc-win has operator overloading without any classes or other
"goodies".

For instance

z = (a+b-1)/(b*(b-a));

or

z = div(subtract(sum(a,b),1),mult(b,subtract(b,a))))


Which you prefer?

This is so OBVIOUS that the people arguing against it look
completely ridiculous.


 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      11-30-2011
Le 30/11/11 23:09, Quentin Pope a écrit :
> On Wed, 30 Nov 2011 22:59:39 +0100, jacob navia wrote:
>> Le 30/11/11 22:42, Jorgen Grahn a écrit :
>>> On Tue, 2011-11-29, Joe keane wrote:
>>> ...
>>>> I think operator overloading is a gain of about zero.
>>>>
>>>> I've never written in C and been like 'darn it, if i only had operator
>>>> overloading!'.
>>>
>>> Operator overloading ties in with many of the other C++ features -- I
>>> don't think it would be very useful as an isolated feature.
>>>
>>> /Jorgen
>>>
>>>

>> That is because you did not know that Fortran has operator oerloading,
>> C#, even Java. I have added operatr overloading to the lcc-win compiler
>> and it is very useful. See the other message about this in this thread.

>
> Sorry, but it is NOT useful. In those other languages, it is a curse. It
> leads to many bugs, and plenty of confusing code where it is difficult to
> tell what a simple-looking line of code is actually doing without digging
> through piles of other code to track down the relevant overloading.
>


Operator overloading work best with number and numerical data.

Please consider:


z = (a+b-1)/(b*(b-a));

or

z = div(subtract(sum(a,b),1),mult(b,subtract(b,a))))


Which you prefer?

This is so OBVIOUS that the people arguing against it look
completely ridiculous.



> Overloading is not the C way. It is not standard C and not portable.
>


This isn't a reason, an argument or whatever. It is just

"That's the way it is".

And when somebody asks:

but WHY should we go on like that?

you answer

"That's the way it is".

> C has a much better solution - explicit function calls.


Yes, see above:

z = div(subtract(sum(a,b),1),mult(b,subtract(b,a))))

and I assumed that the result is returned in the stack... what is
a horror with bignumbers...

Otherwise you have:

tmp1 = sum(a,b);
tmp1 = subtract(tmp1,1);
tmp2 = subtract(b,a);
tmp2 = mult(b,tmp2);
z = div(tmp1,tmp2);

Even better!


> Look at GMP for a
> good example of a C interface for numerical types without any need for
> overloading.
>


Of course, it is alwayssupposed that the real users will
use the overloaded ibterface that calls back to C.


 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      11-30-2011
On 12/ 1/11 12:15 PM, jacob navia wrote:
> Le 30/11/11 23:10, ImpalerCore a écrit :
>> On Nov 30, 4:42 pm, Jorgen Grahn<(E-Mail Removed)> wrote:
>>> On Tue, 2011-11-29, Joe keane wrote:
>>>
>>> ...
>>>
>>>> I think operator overloading is a gain of about zero.
>>>
>>>> I've never written in C and been like 'darn it, if i only had operator
>>>> overloading!'.
>>>
>>> Operator overloading ties in with many of the other C++ features -- I
>>> don't think it would be very useful as an isolated feature.

>>
>> It depends on how you view the difference between something like
>>
>> c_day_duration c_date_subtract( struct c_greg_date date1,
>> struct c_greg_date date2 );
>>
>> vs
>>
>> c_day_duration operator-( struct c_greg_date date1,
>> struct c_greg_date date2 );
>>
>> I would be lying if I didn't desire this kind of overloading at some
>> verbose points in my code, at least for struct types where
>> mathematical operations made some sense. But I can certainly get by
>> without it. The point is that I don't think one would need a class
>> abstraction to make use of it.

>
> You don't. lcc-win has operator overloading without any classes or other
> "goodies".
>
> For instance
>
> z = (a+b-1)/(b*(b-a));


Do you use pass by value, or do you pass by reference under the hood?

--
Ian Collins
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      11-30-2011
Le 01/12/11 00:21, Ian Collins a écrit :
>
> Do you use pass by value, or do you pass by reference under the hood?
>


Of course by reference... qfloats are 120 bytes long...
For a function of 2 arguments you would have to push 240 bytes
each time... impossible.

 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      11-30-2011
On 11/30/2011 05:09 PM, Quentin Pope wrote:
> On Wed, 30 Nov 2011 22:59:39 +0100, jacob navia wrote:

....
>> That is because you did not know that Fortran has operator oerloading,
>> C#, even Java. I have added operatr overloading to the lcc-win compiler
>> and it is very useful. See the other message about this in this thread.

>
> Sorry, but it is NOT useful. In those other languages, it is a curse. It
> leads to many bugs, and plenty of confusing code where it is difficult to
> tell what a simple-looking line of code is actually doing without digging
> through piles of other code to track down the relevant overloading.


Any feature of any language can be misused. I you have to look "through
piles of other code to track down the relevant overloading", in order to
know what the overload is doing, then it should not have been overloaded
- it's just that simple.

The expression a + b gives the result of adding a to b; if the meaning
of that phrase is not crystal clear for the relevant type(s), WITHOUT
having to read the code or documentation for the operator overload, then
operator+() should never have been overloaded for that(those) type(s).

This design rule is frequently violated; that's not exactly an uncommon
feature of good design rules.

Vectors, arrays, complex numbers, quaternions, tensors in general are
all examples of types for which the meaning of operator+() is crystal
clear to anyone who knows enough about those types to justify writing
code that uses them. operator*() is a trickier matter for most of those
types, because they have at least two different plausible meanings for
a*b. That's an argument for things like .outer_product() and
..inner_product(), etc.

> Overloading is not the C way. It is not standard C and not portable.


Of course, that goes without saying.

 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      11-30-2011
On 11/29/2011 06:36 PM, Joe keane wrote:
> In article <(E-Mail Removed)>,
> Nick Keighley <(E-Mail Removed)> wrote:
>> you could safely concatentate strings in C++ without using an
>> overloaded oeprator.

>
> kind of my point

....
>> What exactly is your point?

>
> I think operator overloading is a gain of about zero.
>
> I've never written in C and been like 'darn it, if i only had operator
> overloading!'.


I have (except for the minced oath - and I didn't use a real oath, either).

....
> The opereator overloading is a candy bar.


C's scalar types represent characters, numbers, or pointers. It also has
derived types that are arrays, and functions. Operator overloads can
make a class type look like one of those kinds of types, and they can be
a very useful, reasonable thing to define, if the class represents an
extension to the idea of characters, numbers, pointers, arrays or
functions. When used for any other purpose, they tend to obfuscate code,
rather than clarify it. Any member function whose meaning doesn't fit
the usual meaning of a given operator should not be implemented as an
overloaded of that operator.

The use of >> and << for I/O, and the use of + for string concatenation,
both clearly violate this design principle, and I cannot defend them.
However, but by now such usage is a well-established convention, and
unlikely to be changed.

 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      12-01-2011
On Nov 30, 11:21*pm, jacob navia <(E-Mail Removed)> wrote:
> Le 30/11/11 23:09, Quentin Pope a écrit :
> > On Wed, 30 Nov 2011 22:59:39 +0100, jacob navia wrote:
> >> Le 30/11/11 22:42, Jorgen Grahn a écrit :
> >>> On Tue, 2011-11-29, Joe keane wrote:



> >>>> I think operator overloading is a gain of about zero.

>
> >>>> I've never written in C and been like 'darn it, if i only had operator
> >>>> overloading!'.


read up on "blub" or the The Sapir-Whorf Hypothesis


> >>> Operator overloading ties in with many of the other C++ features -- I
> >>> don't think it would be very useful as an isolated feature.


I think Jacob has demonstrated you can do useful things with operator
overloading in a C-like language


> >> That is because you did not know that Fortran has operator oerloading,
> >> C#, even Java. *I have added operatr overloading to the lcc-win compiler
> >> and it is very useful. See the other message about this in this thread..

>
> > Sorry, but it is NOT useful. In those other languages, it is a curse. It
> > leads to many bugs, and plenty of confusing code where it is difficult to
> > tell what a simple-looking line of code is actually doing without digging
> > through piles of other code to track down the relevant overloading.


I keep on hearing this. But if you confine it to arithmetic types it
seems pretty useful. Lots of programming lanaguage features can be
abused. Perhaps C should stop using pointers?

> Operator overloading work best with number and numerical data.
>
> Please consider:
>
> z = (a+b-1)/(b*(b-a));
>
> or
>
> z = div(subtract(sum(a,b),1),mult(b,subtract(b,a))))
>
> Which you prefer?


the LISP people would say the second one was more consistent but would
be even better in proper prefix notation...

(set! z (/ (- (+ a b) 1) (* b (- b a))))

but of course /they/ are crazy...

<snip>
 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      12-01-2011
On Nov 30, 11:37*pm, James Kuyper <(E-Mail Removed)> wrote:
> On 11/29/2011 06:36 PM, Joe keane wrote:
>
> > In article <(E-Mail Removed)>,
> > Nick Keighley *<(E-Mail Removed)> wrote:
> >> you could safely concatentate strings in C++ without using an
> >> overloaded oeprator.

>
> > kind of my point

> ...
> >> What exactly is your point?

>
> > I think operator overloading is a gain of about zero.

>
> > I've never written in C and been like 'darn it, if i only had operator
> > overloading!'.

>
> I have (except for the minced oath - and I didn't use a real oath, either).
>
> ...
>
> > The opereator overloading is a candy bar.

>
> C's scalar types represent characters, numbers, or pointers. It also has
> derived types that are arrays, and functions. Operator overloads can
> make a class type look like one of those kinds of types, and they can be
> a very useful, reasonable thing to define, if the class represents an
> extension to the idea of characters, numbers, pointers, arrays or
> functions.


operator overloading in C++ can also be used for conversion operators
as well.


> When used for any other purpose, they tend to obfuscate code,
> rather than clarify it. Any member function whose meaning doesn't fit
> the usual meaning of a given operator should not be implemented as an
> overloaded of that operator.
>
> The use of >> and << for I/O, and the use of + for string concatenation,
> both clearly violate this design principle, and I cannot defend them.
> However, but by now such usage is a well-established convention, and
> unlikely to be changed.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: RIP Dennis Ritchie Lynn McGuire C++ 12 10-18-2011 08:35 AM
Dennis Ritchie Has Died Bradley K. Sherman C Programming 28 10-18-2011 04:44 AM
Query from Dennis Ritchie C learner C Programming 6 04-04-2011 05:44 PM
Errata for The C Programming Language, Second Edition, by Brian Kernighanand Dennis Ritchie Ioannis Vranos C Programming 4 05-16-2009 03:48 PM
What is this noalias thing Dennis Ritchie is railing about ? Spiros Bousbouras C Programming 22 09-13-2007 09:28 AM



Advertisments