Dennis Ritchie -- An Appreciation

[James Kuyper]

....
const and volatile were keywords in C89.

The rumored borrowing that I was talking about above was said to have
occurred before standardization of C89, but I would assume that it was
sometime after "C with Classes" evolved into "C++", in late 1983.

... wchar_t is a bit of a mix -
it was a standard type in C89 (with one of the TCs), but not actually
a keyword. inline was added to c99 (although it was a common
extension).

Correct.

 

[Richard Damon]

On 10/22/2011 10:57 AM, Malcolm McLean wrote:
...

Perhaps it could, under the right circumstances - science fictional
concepts like machines or drugs that implant information directly in
your head come to mind. I doubt, however, that such speed learning is
the norm in the real world.

I was already very familiar with C when I first learned C++. I
immediately recognized the value of many of the new features offered by
C++. I have a long history of rapidly acquiring new computer languages,
and the amount of time it took me to learn C++ is an example of that -
but the amount of time was a lot longer than a single day. It took
longer than that for me just to finish reading a detailed description of
the new features.

I could see a person spending a day reading a tutorial on C++ for C
programmers and come away with enough to write some basic C++ programs.
They may be more using "C with Classes" then full C++. After all, it
probably only takes an hour or two to learn how to move from C to C that
is compatible with C++ (using prototypes, no implicit cast from void*,
avoid keywords like class, etc.). At that point you can almost claim to
be writing C++, add in a few basics like member functions and
inheritance, a few basic template rules, and you are then writing C++.
Maybe even have time for some simple stream I/O and it even starts to
look like basic C++.

In one day they aren't using much of STL, name spaces (except adding a
using namespace std or other advance features.

 

[Joe Pfeiffer]

I could see a person spending a day reading a tutorial on C++ for C
programmers and come away with enough to write some basic C++
programs. They may be more using "C with Classes" then full C++. After
all, it probably only takes an hour or two to learn how to move from C
to C that is compatible with C++ (using prototypes, no implicit cast
from void*, avoid keywords like class, etc.). At that point you can
almost claim to be writing C++, add in a few basics like member
functions and inheritance, a few basic template rules, and you are
then writing C++. Maybe even have time for some simple stream I/O and
it even starts to look like basic C++.

In one day they aren't using much of STL, name spaces (except adding a
using namespace std or other advance features.

I had the experience of having students ask if they could turn in
assignments written in C++ instead of C, and receiving C programs with
iostreams.

 

[Ben Bacarisse]

On Oct 22, 3:57 pm, Malcolm McLean <[email protected]>
wrote:

when! Stroustrup e1? I've been at it a decade or so and I don't
consider myself completly familiar with C++. Template meta-programming
anyone!
Agreed.


a damn sight more than that!

this, public, private, protected, class, virtual, template, exception,
catch, try, operator...

.... new, delete, true, false, friend, typename, typeid, using,
namespace, mutable, export, reinterpret_cast, const_cast, static_cast,
dynamic_cast, explicit, throw...

....and it significantly changed the meaning of auto.

I know you were not offering a fill list (and I doubt I have either) but
the point is better made if the list is fuller. The journey from C to
C++ has become quite an adventure. In the days if cfront, it was not
much more than a stroll in the park.

<snip>

 

[Ben Pfaff]

a damn sight more than that!

this, public, private, protected, class, virtual, template, exception,
catch, try, operator...

I don't think that "exception" is a keyword in C++.

 

[James Kuyper]

....
I could see a person spending a day reading a tutorial on C++ for C
programmers and come away with enough to write some basic C++ programs.
They may be more using "C with Classes" then full C++. After all, it
probably only takes an hour or two to learn how to move from C to C that
is compatible with C++ (using prototypes, no implicit cast from void*,
avoid keywords like class, etc.). At that point you can almost claim to
be writing C++, add in a few basics like member functions and
inheritance, a few basic template rules, and you are then writing C++.
Maybe even have time for some simple stream I/O and it even starts to
look like basic C++.

In one day they aren't using much of STL, name spaces (except adding a
using namespace std or other advance features.

A statement that "I've learned C++" would not be justified by that level
of understanding..

 

[Charles Richmond]

I learnt it in a day. I bought a little book describing C++ for C
programmers, and read it on the bus. By the time the bus journey had
ended, I'd read the book and knew C++.

However that was when it was still quite new, before it had ballooned
into what it is now.

Almost anyone can pick up an acorn, but *not* after it growns into
a 200 foot oak tree!!!

 

[Charles Richmond]

I learnt it in a day. I bought a little book describing C++ for C
programmers, and read it on the bus. By the time the bus journey had
ended, I'd read the book and knew C++.

However that was when it was still quite new, before it had ballooned
into what it is now.

Almost anyone can pick up an acorn, but *not* after it growns into
a 200 foot oak tree!!!

 

[Charles Richmond]

I learnt it in a day. I bought a little book describing C++ for C
programmers, and read it on the bus. By the time the bus journey had
ended, I'd read the book and knew C++.

However that was when it was still quite new, before it had ballooned
into what it is now.

Almost anyone can pick up an acorn, but *not* after it growns into
a 200 foot oak tree!!!

 

[Malcolm McLean]

A statement that "I've learned C++" would not be justified by that level
of understanding..

There weren't any templates or namespaces, and exception handling was
widely non-implemented.

Basically you were using C++ once you had an object hierarchy, and for
that you just needed "class" and "public, protected, private) together
with the base membership syntax. That was fundamentally it. The
operator overloaded IO stream library made programs look very
different to C, but was ultimately a distraction. inline, slash slash
comments, operator and references were just minor tweaks. The
difficult one was "virtual".

 

[James Kuyper]

On Oct 24, 12:14�am, James Kuyper <[email protected]> wrote:

[restoring clipped attribution:]

There weren't any templates or namespaces, and exception handling was
widely non-implemented.

Basically you were using C++ once you had an object hierarchy, and for
that you just needed "class" and "public, protected, private) together
with the base membership syntax. That was fundamentally it. The
operator overloaded IO stream library made programs look very
different to C, but was ultimately a distraction. inline, slash slash
comments, operator and references were just minor tweaks. The
difficult one was "virtual".

So Charles Richmond's acorn analogy is entirely apt.

 

[Jorgen Grahn]

There weren't any templates or namespaces, and exception handling was
widely non-implemented.

Basically you were using C++ once you had an object hierarchy,

The kind of perverted C++ I hate the most is C code squeezed into an
unnatural inheritance hierarchy. I wasn't around in the early days,
but I get the impression that virtual inheritance was the C++ feature
stuck in the minds of many C programmers switching.

I find run-time polymorphism one of the less useful features of C++. I
design a lot of classes, but there are very few "is-a" relationships
between them.

/Jorgen

 

[Malcolm McLean]

The kind of perverted C++ I hate the most is C code squeezed into an
unnatural inheritance hierarchy.  I wasn't around in the early days,
but I get the impression that virtual inheritance was the C++ feature
stuck in the minds of many C programmers switching.

I find run-time polymorphism one of the less useful features of C++. I
design a lot of classes, but there are very few "is-a" relationships
between them.

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.

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.

I've seen a few very well designed object-oriented programs, notably
3D Studio Max, but they're very much the exception. An object-oriented
design is difficult to get right. C++ also makes it harder than it
should be to define base classes designed for other programmers to
inherit from. Largely it's a documentation issue.

 

[Richard Damon]

The kind of perverted C++ I hate the most is C code squeezed into an
unnatural inheritance hierarchy. I wasn't around in the early days,
but I get the impression that virtual inheritance was the C++ feature
stuck in the minds of many C programmers switching.

I find run-time polymorphism one of the less useful features of C++. I
design a lot of classes, but there are very few "is-a" relationships
between them.

/Jorgen

I probably depends a lot on the type of programs you write, I find I use
it a lot. 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). Also exceptions would be a lot less friendly without
polymorphism.

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.

 

[André Gillibert]

I've seen a few very well designed object-oriented programs, notably
3D Studio Max, but they're very much the exception. An object-oriented
design is difficult to get right. C++ also makes it harder than it
should be to define base classes designed for other programmers to
inherit from. Largely it's a documentation issue.

And, of course, the fact the most basic and standard C++ library,
iostreams, is poorly documented and has a weird design (e.g. two seek
methods), doesn't help C++ programmers to get a sane mind.

Even the Qt library abuses inheritance. For example, QProcess (which
represents a child process) is derived from QIOProcess (which
represents a I/O stream like a file descriptor on UNIX), with a
setReadChannel method to select if the QIOProcess reads from
the stderr or stdout of the child process.

 

[André Gillibert]

quite. "Why Pascal Isn't My Favoutite Language" (or something like
that) is worth a read

The original Pascal language was a teaching tool, although derivates of
1980's and 1990's (Object Pascal, Delphi), became complete programming
languages.

The C programming language was designed as practical system
programming tools, and so was a good candidate at becoming popular
for system programming.

IMO, details of the language are not an important part of its success.

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

 

[Ian Collins]

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.

That's a rather strange reason for not using a language, considering C++
isn't just an OO language.

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.

As soon as the resource (be it a file, or memory or whatever) needs some
form of management, then it certainly dose make sense. I'd happily just
stick to C + smart pointers if I had to.

 

[Bill Cunningham]

C is close enough to the hardware to allow me to avoid writing
assembly in order to keep a program fast. Yet C is abstract enough
to write complicated ideas in a symbolic way in order to make the
code easy to maintain.

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

My first programming language was Fortran IV. My second programming
language was PL/1. But C (while the 3rd programming language that I
learned) was the first programming language that I loved.

And I am really, really hard to please.

There are some programming giants. Donald Knuth, W. Richard Stevens,
and Dennis Ritchie top my list. How about yours?

Charles Babbage and Ada Lovelace.

 

[Bill Cunningham]

Charles Babbage and Ada Lovelace.

And don't forget Jim Gosling.

 

[Nick Keighley]

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 seem to find myself naturally finding IS_A relations. The Open
Closed Principle, as usually implemented, relies on polymorphism. Do I
work in wierd domains or am I in a thought strait jacket?

Graphical Editor- every widget is derived froma base class
Mobile Radio- each "end user" type is derived from a common base
class and an end user can be anything from a handset to a despatcher
to a complete telephony network

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.

until you want MYFILE to be a string or a comms link a database or...

I've seen a few very well designed object-oriented programs, notably
3D Studio Max, but they're very much the exception. An object-oriented
design is difficult to get right. C++ also makes it harder than it
should be to define base classes designed for other programmers to
inherit from. Largely it's a documentation issue.

maybe true