Dennis Ritchie -- An Appreciation

J

Jorgen Grahn

.
If Dennis Ritchie had designed his language by adding the needed
features (explicit pointer arithmetic, dynamic memory allocation,
recursion) to Fortran, than, UNIX and the rest of the world, would
probably be using his Fortran derivative.

And, if Simula had a faster linker, C++ may have never been created
by Bjarne Stroustrup ...

IIRC, there were other fundamental problems[1] which made Simula unusable
for him. He liked the language, but ran into performance problems when
doing some specifik job with it.

He disliked core parts of C, but based C++ off it because ... I guess
for the same reasons we're using it 20 years later.

/Jorgen

[1] Unless the Simula linker is a runtime thing and we're really
talking about the same problem.
 
8

88888 Dihedral

I think that calling OS related services is always subject to exceptions and failures. Checking I/O streams with exceptions is a burden!
 
8

88888 Dihedral

There was no unit test in C long time ago. Programs written with DEBUG, TESTING and FINAL modes in C needs a lot macros and defines! Of course, in the final mode the testing and debugging parts wont be needed! I stumbled into the same problem in C++, TOO!
 
J

Jorgen Grahn

I probably depends a lot on the type of programs you write, I find I use
it a lot.

Yes -- I was about to add such a reservation to my posting.
I think my programming is quite varied, but I do no GUI programming
for example.
It also is fundamental to some parts of C++, for example
iostreams (the generic use of streams for insertion and the separation
of streams and buffers as implemented very much depends on
polymorphism).

It's great that you can treat strings as files, but apart from that
the polymorphism is pretty much under the hood.
Also exceptions would be a lot less friendly without
polymorphism.

Yes, that's another -- they more or less need it.
I do agree that using inheritance just because you might get some code
sharing can lead to very bad code, and I've seen my share of "forced"
class hierarchy, but there are a lot of good uses for run-time
polymorphism.

There *are* good uses, and it's a feature that belongs in C++, but
it's IMHO overused.

/Jorgen
 
J

Jorgen Grahn

That was partly why I stopped using C++.

Unless you're defining an object hierarchy, you're not doing object-
oriented design. Instead you're encapuslating structures.

I take it you think encapsulating structures is inferior to defining
object hierarchies? I don't. Encapsulating structures means building
new types, documenting them, deciding what operations they should
support and which ones should be explicitly forbidden, defining
invariants and so on.
MYFILE *myfopen();
void myfclose(MYFILE *stream);
int myfput(MYFILE *fp, int ch);

etc is a perfectly legitimate idiom, but you don't gain much by going
to C++ and making MYFILE a class.

That's not C++. The C++ version would not use pointers, or have
superfluous "myf" prefixes on the function names (C++ supports
overloading).

/Jorgen
 
F

Fritz Wuehler

C is the mother of the modern OO languages like C++ and Java.

Oh it's a mother alright, but the OO comes from Simula and elsewhere. Go
read some Bjarne and find out the truth.

You're one sick puppy. PL/I (not 1, ya big MORON!) stomps C flat.

Not that you're hard to please, you're just dopey.
And don't forget Jim Gosling.

Yeah, the guy who wrote Emacs! Hey Stallman, eat shit!
 
M

Malcolm McLean

I take it you think encapsulating structures is inferior to defining
object hierarchies?  I don't. Encapsulating structures means building
new types, documenting them, deciding what operations they should
support and which ones should be explicitly forbidden, defining
invariants and so on.
It's not really object-oriented design. And C++ doesn't buy you much.
You can encapsulate objects in C, and it's a design paradigm I use
heavily.

You're doing object-oriented design when your objects have
relationships to each other, in C++ class hierarchies, in other
languages interfaces.
 
N

Nick Keighley

On Oct 26, 5:13 am, Fritz Wuehler <fr...@spamexpire-
PL/I [...] stomps C flat.

which is why magazines used to feature articals that started "So, what
does this [apparently innocuous] line of PL/I actually do? You might
be surprised at the answer!"

Its tendency to allow almost anything to be assiged to anything else
led to quite astonishing results.

"PL/I: the best of both FORTRAN *and* COBOL"
 
N

Nick Keighley

could you leave some context in your posts?

There was no unit test in C long time ago.

it's not very hard to implement a basic unit test facility in C. Even
the humble assert() will do at a pinch.
Programs written with DEBUG, TESTING and FINAL modes in C needs a lot macros and defines!

I don't agree that it has to be that way. And how do other languages
work around this alleged problem?

unit test for instance can be in a standalone module
Of course, in the final mode the testing and debugging parts wont be needed!

this only applies to programs that are never modified and hence known
to be bug free
I stumbled into the same problem in C++, TOO!

probably because you were using the same programmer
 
I

Ian Collins

It's not really object-oriented design. And C++ doesn't buy you much.
You can encapsulate objects in C, and it's a design paradigm I use
heavily.

Why are you so hung up on object-oriented design? C++ isn't just an OO
language (a read of the standard library will show you that).
 
B

Bill Cunningham

Fritz said:
Oh it's a mother alright, but the OO comes from Simula and elsewhere.
Go read some Bjarne and find out the truth.


You're one sick puppy. PL/I (not 1, ya big MORON!) stomps C flat.


Not that you're hard to please, you're just dopey.


Yeah, the guy who wrote Emacs! Hey Stallman, eat shit!

True but I kinda meant Java.

Bill
 
8

88888 Dihedral

I test extremely, thus I have to recompile a lot and fast for my obj lib and package to grow fast!
 
F

Fritz Wuehler

Bill Cunningham said:
True but I kinda meant Java.

Yeah but Java borrowed/stole heavily from other stuff also, notably
Modula-3 and the same foundations C++ was based on (Simula for example). I
don't think Java was Gosling's biggest achievement although it certainly
made him the most fame and fortune. Before Java he did do some real
invention.
 
N

Nick Keighley

I test extremely, thus I have to recompile a lot and fast for my obj lib and package to grow fast!  

CONTEXT!!!!!

is that a response to my post or just a disjointed stream of
conciousness?
 
L

luser- -droog

Yeah but Java borrowed/stole heavily from other stuff also, notably
Modula-3 and the same foundations C++ was based on (Simula for example). I
don't think Java was Gosling's biggest achievement although it certainly
made him the most fame and fortune. Before Java he did do some real
invention.

Is that a veiled reference to NeWS? The greatest Window System before
or since!
 
J

Jorgen Grahn

It's not really object-oriented design.
(reordered)

You're doing object-oriented design when your objects have
relationships to each other, in C++ class hierarchies, in other
languages interfaces.

I accept that object-oriented programming (as Stroustrup defines it,
at least) includes run-time polymorphism. But let's say I do my design,
look for places where a "is-a" relationship is the best solution --
and I don't find any. Am I suddenly not doing object-oriented design?

Because that's what happens to me in practice. Less than 5% of my
classes do run-time polymorphism.
And C++ doesn't buy you much.

I work in both languages and I can assure you: it *does* make a big
difference. Not the inheritence, but all the other features.
You can encapsulate objects in C, and it's a design paradigm I use
heavily.

So do I, and it's definitely workable -- but not having RAII, operator
overloading, function overloading, templates and container types
really hurts.

/Jorgen
 
M

Markus Wichmann

So do I, and it's definitely workable -- but not having RAII, operator
overloading, function overloading, templates and container types
really hurts.

Oh, please. At least to of the above tend to make code unreadable. I
mean, if you see the following line, for instance:

x = y++;

and the compiler doesn't warn on this line on highest level, then in C
we have a pretty limited set of possibilities, namely:

- x and y can both be arithmetic types
- x and y can both be pointers to the same type
- x can be a void* and y can be a typed pointer
- x or y can be preprocessor macros, though in this case that would
really be bad... oh wait, there's at least one instance of it in my
system library:

#define errno (*__errno_location())

C++ adds:
- x or y can be class instances, in which case:
- there might be a typeof y::eek:perator++() which is then called
- there might be an operator++(typeof y) defined somewhere else
- there might be typeof x::eek:perator=(typeof y&)
- there might be operator=(typeof x&, typeof y&)
- typeof x might have an implicit constructor taking a typeof y
- typeof x might have an implicit constructor taking whatever
typeof y::eek:perator++() or operator++(typeof y) return
- I don't know exactly about this one, but operator++(typeof y) might
even return a class instance that has an operator(typeof x)(), IIRC

- even if they aren't class instances, we have:
- x might be a reference to typeof y
- y might be a reference to something
- x might even reference y, which means that this line invokes
undefined behaviour
- or y might reference x, which yields the same

As you can see, C++ blows this line all the way from "something will be
incremented and something else will store the old value" to "no friggin
idea what this line does! Might be anything. And I wouldn't even know
where to start looking"

As of yet I only saw one useful application of operator overloading and
references, and that was a typesafe printf() implementation (which
basically has the compiler choose the correct functions according to the
argument type and those functions then check whether the conversion
specification on the format string was correct).

Templates are yet another pothole to the learning programmer: Every
instanciation creates an entirely new and unrelated set of routines and
class variables. I mean, if I have:

class A { static int count; };

then there's only one A::count in the whole program. If I have

template <class T> class A {static int count; };

suddenly there's no bound to the number of A::counts in the program,
because there is _no_ A::count, but instead A<int>::count,
A said:

Ciao,
Markus
 
M

Malcolm McLean

I accept that object-oriented programming (as Stroustrup defines it,
at least) includes run-time polymorphism.  But let's say I do my design,
look for places where a "is-a" relationship is the best solution --
and I don't find any. Am I suddenly not doing object-oriented design?

Because that's what happens to me in practice. Less than 5% of my
classes do run-time polymorphism.
Let's say you examine your program, and find that there are no logical
subroutines you can break out of the main loop. Are you still doing
structured programming?
I work in both languages and I can assure you: it *does* make a big
difference. Not the inheritence, but all the other features.
I don't find it does.

I find that typically my programs are structured as arrays of arrays
of arrays, mainly of structures at the upper levels. Where I need more
complex structures, quite often special links are needed for
performance, or for the algorithm. So in both cases the use of fancy
containers doesn't make much sense. I'm not saying it wouldn't help if
there was a way of avoiding the little realloc dance when resizing a C
array, but this small benefit doesn't justify all the complexity in
interfacing that use of containers introduces. I know that in the C++
stl you can do everything with iterators, the problem is that most
programmers aren't disciplined enough to use the system.
 
I

Ian Collins

I don't find it does.

I find that typically my programs are structured as arrays of arrays
of arrays, mainly of structures at the upper levels. Where I need more
complex structures, quite often special links are needed for
performance, or for the algorithm. So in both cases the use of fancy
containers doesn't make much sense. I'm not saying it wouldn't help if
there was a way of avoiding the little realloc dance when resizing a C
array, but this small benefit doesn't justify all the complexity in
interfacing that use of containers introduces. I know that in the C++
stl you can do everything with iterators, the problem is that most
programmers aren't disciplined enough to use the system.

Where is "all the complexity in interfacing" introduced when using a
vector of whatever in place of a raw array? As you state, the
complexity is significantly reduced by automatic memory management.

You seem to do a good job of avoiding answering direct questions, so I'm
curious to see if you reply.
 
M

Malcolm McLean

Where is "all the complexity in interfacing" introduced when using a
vector of whatever in place of a raw array?  As you state, the
complexity is significantly reduced by automatic memory management.
In C, typically functions that operate on a list will take a pointer
to an array of structures, and a count. There's then a loop from 0 to
count stepping through the array.

In C++ standard template library, the standard way is to pass in two
iterators, one to the start and one to the end of the sequence. The
iterator is then incremented until it equals the end point.

The C++ way is considerably more complicated, both in terms of what
the compiler is actually doing, and to use. The proof is that it's
very common to see functions written "incorrectly".
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
474,093
Messages
2,570,610
Members
47,230
Latest member
RenaldoDut

Latest Threads

Top