Why C?

[jacob navia]

Dear friends:

In another thread, John Bode wrote:

2. Most of today's senior programmers started out with C and feel
more comfortable using something they know well.
And in that same thread, Robert Tisdale wrote:
The only reason that C still exists is that
there are a large number of C programmers
that still aren't comfortable with C++.
There is no reason now to expect them to ever learn C++.
We are just waiting for them to retire or die.

Mr Tisdale has often been called a troll here.

I never understood why until I read that sentence.

But he is saying the same thing that Mr Bode.

In another language, yes, but the same thing.

By the way, I am 54, and I feel somehow concerned...

:-)

Am I too old to learn anything?

In any case I hope that Mr Tisdale will have to wait
a long time, do not feel like leaving right now.

The crux of the matter is that I never swallowed the
object oriented hype. I think that "object oriented"
programming is OK in a number of applications that
are well described by hierarchical models, but not
for *all* applications.

Surely not.

I saw Bjarne start with the idea of a better C and
get stuck in an ocean of complexity, that swallowed
him and his intrepid collaborators alive.

Is that because of his object oriented mind set?

Maybe, maybe not. There are many other simpler
languages (all object oriented) that have started
after C++. There was already objective C when he started,
that has survived well in the Mac and in the later
incantations of the Next step OS.

The creation/destruction of objects was one of
the innovations of C++. Yes, but:

Automatic creation and destruction of objects can be
obtained with a good GC. And I mean objects not in the
C++ sense but in the C sense, i.e. a contiguous amount of
memory cells, that have related information structured
in a programmer defined way.

The problem of making an incomprehensible compiler, that
generates code with algorithms completely impossible to
follow by hand (i.e. by mind) is that nobody knows
any more exactly how the software works.

Complexity leads to britle software, that is patched
without any understanding because to patch it you
have to understand all the class hierarchy in it.

C software is transparent compared with C++. This
inherent simplicity is the great strength and the
great weakness of C.

Because I am not a "C wave the flag" person either.
Data processing is much more complicated than that.

The positive side of C++ is the STL.

The STL can be done in a simpler way in C. Templates
are just macros. The only thing to do is to make a macro
facility that can be programmed, in C.

I am thinking about an open compiler interface, where you
write your macros not in "template C++" but in C.

The compiler would load a DLL/shared object and execute the
program in there, that will produce (eventually) text to be
inserted at the current position. You write C at compile time
parametizing it in C.

A recursive language.

I "didn't make it" to C++ for many reasons, reasons that I
consider valid. It is a pity there is so little disucssion
here about the real issues in data-processing and we stay
at the superficial level of "I like it" or "I do not like it".

jacob

[Mike Wahler]

"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:41***********************@news.wanadoo.fr...

I "didn't make it" to C++ for many reasons, reasons that I
consider valid. It is a pity there is so little disucssion
here about the real issues in data-processing and we stay
at the superficial level of "I like it" or "I do not like it".

Neither "data-processing" nor "the real issues in data-processing"
are topical here. Nor are language comparisons, advocacy, etc.
The standard C language is the topic here.

-Mike

[Steve Graegert]

jacob navia wrote:

Dear friends:

In another thread, John Bode wrote:

> 2. Most of today's senior programmers started out with C and feel
> more comfortable using something they know well.
And in that same thread, Robert Tisdale wrote:

> The only reason that C still exists is that
> there are a large number of C programmers
> that still aren't comfortable with C++.
> There is no reason now to expect them to ever learn C++.
> We are just waiting for them to retire or die.

Mr Tisdale has often been called a troll here.
I never understood why until I read that sentence.
But he is saying the same thing that Mr Bode.
In another language, yes, but the same thing.

I merely believe they were actually talking about themselves.
By the way, I am 54, and I feel somehow concerned...

:-)

Am I too old to learn anything?
You're never to old to learn something. Especially not as a programmer
who always needs to learn more as new technologies emerge.

[snip]
The crux of the matter is that I never swallowed the
object oriented hype. I think that "object oriented"
programming is OK in a number of applications that
are well described by hierarchical models, but not
for *all* applications.
I totally agree to that. I've developed, or at least been involved in a
lot of projects, where C++ was the language of choice, especially when
in comes to reusability, in terms of components, GUI development and
interoperability (in terms of networking across platforms). Sure all
these are some kind of built-in features of C (and a lot of other
languages) to some degree, but for those who have seen both worlds, C++
is superior on these issues.

On the other hand, when we were devloping low level libraries for
embedded devices, other constraints where in place and C was ideal for
these tasks. We didn't even think about using C++.

[snip]
I saw Bjarne start with the idea of a better C and
get stuck in an ocean of complexity, that swallowed
him and his intrepid collaborators alive.
Complexity is not always a bad thing. You can do a lot of things in a
lot of different ways, but everybody is free to use as much of the
complexity as needed to accomplish his or her task. Use what you need
and leave the rest alone.

[snip]
Maybe, maybe not. There are many other simpler
languages (all object oriented) that have started
after C++.
Exactly, and it is a good thing. It's the evolution of languages and
technologies.
The creation/destruction of objects was one of
the innovations of C++. Yes, but:
This is only the tip of the ice berg. There are lots of other
improvments that made C++ a valuable tool. For example, we highly
profited from the template mechanism in our projects, just to mention
one of the improvements.
Automatic creation and destruction of objects can be
obtained with a good GC. And I mean objects not in the
C++ sense but in the C sense, i.e. a contiguous amount of
memory cells, that have related information structured
in a programmer defined way.
Why should an application programmer worry about the undelying memory
management when there is a language feature that does it for him/her.
The problem of making an incomprehensible compiler, that
generates code with algorithms completely impossible to
follow by hand (i.e. by mind) is that nobody knows
any more exactly how the software works.
I don't think a good programmeer needs to know how the compiler works to
be able to write good software. It's helpful, of course, but not a
requirement, unless you are doing systems programming at a lower level.
Complexity leads to britle software, that is patched
without any understanding because to patch it you
have to understand all the class hierarchy in it.
This is partially true, also for C programs. To patch a C program you
should have a knowledge on how the program works. The same is true for a
C++ program that simply has it's logic structured hierarchically.
Analyzing a C program you have not written yourself can be as annoying
as analyzing a C++ program with all the hierarchy it embodies.
C software is transparent compared with C++. This
inherent simplicity is the great strength and the
great weakness of C.
True. Read statements above.
Because I am not a "C wave the flag" person either.
Data processing is much more complicated than that.

The positive side of C++ is the STL.
Absolutely, and I'm glad there is one.
The STL can be done in a simpler way in C. Templates
are just macros. The only thing to do is to make a macro
facility that can be programmed, in C.
It may be simpler to implement, but I doubt that this would be simpler
to use. What about side effects and macros? That's why some C functions
are implemented as macros while other simply can't, just because of that.
I am thinking about an open compiler interface, where you
write your macros not in "template C++" but in C.

The compiler would load a DLL/shared object and execute the
program in there, that will produce (eventually) text to be
inserted at the current position. You write C at compile time
parametizing it in C.

A recursive language.
Yes, why not bring some new concepts into C. This idea is worth being
discussed in more detail.
I "didn't make it" to C++ for many reasons, reasons that I
consider valid. It is a pity there is so little disucssion
here about the real issues in data-processing and we stay
at the superficial level of "I like it" or "I do not like it".

You mentioned a lot of good points, although I do not agree to all of
them. Just as you said, I hope the discussion is being held at a high
level exchanging good ideas on why to C or not to C.

Thanks

Steve

[jacob navia]

Steve Graegert wrote:

The STL can be done in a simpler way in C. Templates
are just macros. The only thing to do is to make a macro
facility that can be programmed, in C.

It may be simpler to implement, but I doubt that this would be simpler
to use. What about side effects and macros? That's why some C functions
are implemented as macros while other simply can't, just because of that.

I am thinking about an open compiler interface, where you
write your macros not in "template C++" but in C.

The compiler would load a DLL/shared object and execute the
program in there, that will produce (eventually) text to be
inserted at the current position. You write C at compile time
parametizing it in C.

A recursive language.

Yes, why not bring some new concepts into C. This idea is worth being
discussed in more detail.

There are two interfaces to call your compile time functions.

1: You get called when the compiler informs you of a syntax
event, an event that you are interested in.

You express your interest for a specific event by using:

#pragma event(FunctionStart,MyFnCall,templates.dll)

When a function definition starts, the compiler loads
the MyFnCall function from the templates.dll shared library
and runs it. The function can produce text to, for
instance, record the fact that this particular function was called by
generating a string:
"fprintf(stdout,"entering function fn\n");"

The compiler compiles this string as it was written
in the program at that point.

Or the function will not produce anything but record in some
variables private to the dll the fact that this function is
called and look in the local variables of it if there is
any managed object that needs special initialization.

Or other stuff, whatever.

The interface between the compile time function and
the compiler are C strings.

The compiler run time provides you with functions and
methods to access the argument list, get the current function
name, and many other info that you may need. You get an
environment data block with most of the relevant info.

You call in the compiler by obtaining a function pointer table
from the compiler at load time. This will be done
automatically.

2:

You get called because you write a call to your compile
time function yourself in the source text:

#pragma compiletime(list,listgen, templates.dll)

Then you do:

list<int> *intList;
Then your list function generates code
"typedef struct tag_int_list {"
" struct tag_int_list*Next;"
" int data;"
"} INTLIST;"
" INTLIST *intList;"

And you can generate a series of library functions to handle
integer lists.

This is no longer generated automatically in a
preconceived way by the compiler but is programmed
by the user. The template expansion is done in
a function like this:

char *listgen(Type T)
{
char *typeName = GetTypeName(T);
static alreadycalled;

Output(NULL); // Initializes the buffer to empty.
if (GetLexicalLevel() == GLOBAL &&
alreadycalled == 0) {
Output("typedef struct tag_%s_list {",typeName);
Output("struct tag_%s_list *Next;",typeName(T));
if (Sizeof(T) <= sizeof(void *)) {
Output("%s data;",typeName);
}
else { // types bigger than ints are allocated.
Output("%s *data;",typeName);
}
alreadycalled = 1;
}
else if (GetLexicalLevel() >= LOCAL) {
// This template implementation decides that
// all types must be previously known by writing
// at the global level:
// list<int>, for instance. Other schemas
// are possible of course.
if (alreadycalled == 0) {
// No more incomprehensible template
// errors. Just normal messages.
CompilerError("template list<> called uninitialized");
return "";
}
// we are in a local variable declaration.
// Output just the name of the already defined
// type
Output("%sLIST");
}
else {
// We are not at the global level, and not in a
// local declaration. Probably parameter passing,
// or within another structure definition...
// Bad call, emit an error
CompilerError("Bad call to list<> template");
}
return Output("");
}

Note that this templates are programmed without any need
for the cumbersome "IF" template macros that are needed
when a compile expands the template.

The downside of this flexibility is (as always) that this
needs a bit of more effort.

I have a prototype of this up and running but it needs to be
fleshed out, the compile time procedures must be written,
the load/unload protocol must be refined, more events and
precise meanings must be defined, etc.

But the basic idea is this.

jacob

[Skybuck Flying]

"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:41***********************@news.wanadoo.fr...

Dear friends:

In another thread, John Bode wrote:

> 2. Most of today's senior programmers started out with C and feel
> more comfortable using something they know well.

And in that same thread, Robert Tisdale wrote:

> The only reason that C still exists is that
> there are a large number of C programmers
> that still aren't comfortable with C++.
> There is no reason now to expect them to ever learn C++.
> We are just waiting for them to retire or die.

Mr Tisdale has often been called a troll here.

I never understood why until I read that sentence.

But he is saying the same thing that Mr Bode.

In another language, yes, but the same thing.

By the way, I am 54, and I feel somehow concerned...

:-)

Am I too old to learn anything?

In any case I hope that Mr Tisdale will have to wait
a long time, do not feel like leaving right now.

The crux of the matter is that I never swallowed the
object oriented hype. I think that "object oriented"
programming is OK in a number of applications that
are well described by hierarchical models, but not
for *all* applications.

Surely not.

I saw Bjarne start with the idea of a better C and
get stuck in an ocean of complexity, that swallowed
him and his intrepid collaborators alive.

IMHO C++ is precisly this... overly complex junk.

If you think C++ equals OO you haven't seen Delphi for example. ;)

I love Delphi's OO :)

Programming without it would be unthinkable.

It's not a solution for everything... but it does help a gigantic lot ;)

Then again... C is closer to ASM.

That means C might be more suited for LOW LEVEL STUFF and ENGINE stuff.

Though pascal/delphi can do many things that C can do as well too...

Skybuck.

[E. Robert Tisdale]

Steve Graegert wrote:

Yes, why not bring some new concepts into C.
That's what C++ does.
This idea is worth being discussed in more detail.

Probably not.
Most C programmers don't want to add new features to the language.
Witness the resistance to the new C99 standard.

Most C programmers (like Jacob Navia I suppose) are amateur programmers.
They have learned just enough C to write the programs
that they need to write to help them succeed
with their chosen professional careers whatever those careers may be.
They don't want to learn more complicated computer programming languages
and they don't want to learn about new and more subtle features of C.

Let me paraphrase the original question,
"Why use C when C++ can do everything that C can do?"
All the "reasons" given for using C instead of C++
are actually "rationalizations" or "excuses".
None of them hold up under critical scrutiny.

Your assertion that
C was ideal for low level libraries for embedded device
begs the question.
If C was ideal for this purpose, then so was C++.
You offer no evidence to the contrary.
The notion that you can make complicated problems simpler
by using simpler programming languages is wishful thinking.
C++ is complicated because it needs to be complicated
to deal with complicated problems
that programmers need to solve today.
Smalltalk and Java are simpler because the language designers
chose to sacrifice performance and efficiency
to make programming easier and more reliable.
This was a good trade-off in most (> 90%) of all cases
but practically impossible to work around if, like me,
you really care about performance and efficiency.
Anyway, the current trend is for programming languages
to become more -- not less -- complicated.

The future belongs to professional programmers
who are willing to learn and use new language features
and new computer programming languages.
This means that amateur programmers are going to find
more and more programs that use language features
that they can't really read or understand.
Most of them are going to decide that
they can't be bothered to learn about them
and will elect to ignore them until the end of their careers.

Computer programming is *not* revolutionary.
It's evolutionary.

A scientific truth does not triumph
by convincing its opponents and making them see the light,
but rather because its opponents eventually die
and a new generation grows up that is familiar with it.
-- Max Planck

[Dik T. Winter]

In article <cm**********@nntp1.jpl.nasa.gov> E.**************@jpl.nasa.gov writes:

Trolling again?

Probably not.
Most C programmers don't want to add new features to the language.
Witness the resistance to the new C99 standard.
Right so. You should only add new features to a language when they do
not invalidate older programs.
Most C programmers (like Jacob Navia I suppose) are amateur programmers.
Is Jacob? I think not...
They don't want to learn more complicated computer programming languages
and they don't want to learn about new and more subtle features of C.
Ever looked at Algol 68? A language that I have used quite extensive.
Let me paraphrase the original question,
"Why use C when C++ can do everything that C can do?"
All the "reasons" given for using C instead of C++
are actually "rationalizations" or "excuses".
None of them hold up under critical scrutiny.
Actually my distrust of C++ comes from experience. Once upon a time I had
to install a program on both the Sun and SGI platforms. It was written
for the SGI, and compiled on that platform without glitch. It would
however not compile at the Sun, as the C++ implemented there was subtly
different from the C++ implemented on SGI. But both adhered to a then
current standard. I had to look very hard to see how to change the source
so that it would compile on the Sun, and I succeeded. After I made the
changes, the program did compile on the Sun, but no longer on the SGI.
It was impossible to get a program that would compile on both platforms.
I admit that this was in the early days of C++, and what was 'standard'
changed nearly dayly. But it gave me a general distrust of languages
that make incompatible changes, as was occuring with C++ at that time.
The notion that you can make complicated problems simpler
by using simpler programming languages is wishful thinking.
C++ is complicated because it needs to be complicated
to deal with complicated problems

Have you ever looked at Ada? Anyhow, solving complicated problems
does not necessarily mean you have to use complicated constructs.
Did you ever write a threads-library for C++? I did, for the SPARC.
And the ultimate result was a library completely written in C. The
task was complicated, but the tools needed were not.

Every problem has its own tools (and hence language) that fits best.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Tim Rentsch]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:

[previous poster] wrote:

Yes, why not bring some new concepts into C.

That's what C++ does.

This idea is worth being discussed in more detail.

Probably not.
Most C programmers don't want to add new features to the language.
Witness the resistance to the new C99 standard.

[52 lines of OT comments snipped]

Almost all of this was off topic. Please limit your comments to those
(agreement or disagreement notwithstanding) likely to be of interest
to the newsgroup's readers.

Also, just a little tip - most articles benefit if their fact/opinion
ratio is raised above 1%.

[sunil]

Dear all,
This is a great discussion. Both C and C++ are great languages for
Software Engineering. But I prefer to use C when dealing with low
level operations like microcontroller or kernel level or device driver
develeopments. I prefer to use C++ when I need generic programming
(templates) or dealing with computer science data structures (STL) or
several other application level developments.

Thanks to the developers of both C and C++.

Sunil

Steve Graegert <st****@caths.co.uk> wrote in message news:<41***********************@newsread2.arcor-online.net>...

jacob navia wrote:

Dear friends:

In another thread, John Bode wrote:

> 2. Most of today's senior programmers started out with C and feel
> more comfortable using something they know well.

And in that same thread, Robert Tisdale wrote:

> The only reason that C still exists is that
> there are a large number of C programmers
> that still aren't comfortable with C++.
> There is no reason now to expect them to ever learn C++.
> We are just waiting for them to retire or die.

Mr Tisdale has often been called a troll here.
I never understood why until I read that sentence.
But he is saying the same thing that Mr Bode.
In another language, yes, but the same thing.

I merely believe they were actually talking about themselves.

By the way, I am 54, and I feel somehow concerned...

:-)

Am I too old to learn anything?

You're never to old to learn something. Especially not as a programmer
who always needs to learn more as new technologies emerge.

[snip]

The crux of the matter is that I never swallowed the
object oriented hype. I think that "object oriented"
programming is OK in a number of applications that
are well described by hierarchical models, but not
for *all* applications.

I totally agree to that. I've developed, or at least been involved in a
lot of projects, where C++ was the language of choice, especially when
in comes to reusability, in terms of components, GUI development and
interoperability (in terms of networking across platforms). Sure all
these are some kind of built-in features of C (and a lot of other
languages) to some degree, but for those who have seen both worlds, C++
is superior on these issues.

On the other hand, when we were devloping low level libraries for
embedded devices, other constraints where in place and C was ideal for
these tasks. We didn't even think about using C++.

[snip]

I saw Bjarne start with the idea of a better C and
get stuck in an ocean of complexity, that swallowed
him and his intrepid collaborators alive.

Complexity is not always a bad thing. You can do a lot of things in a
lot of different ways, but everybody is free to use as much of the
complexity as needed to accomplish his or her task. Use what you need
and leave the rest alone.

[snip]

Maybe, maybe not. There are many other simpler
languages (all object oriented) that have started
after C++.

Exactly, and it is a good thing. It's the evolution of languages and
technologies.

The creation/destruction of objects was one of
the innovations of C++. Yes, but:

This is only the tip of the ice berg. There are lots of other
improvments that made C++ a valuable tool. For example, we highly
profited from the template mechanism in our projects, just to mention
one of the improvements.

Automatic creation and destruction of objects can be
obtained with a good GC. And I mean objects not in the
C++ sense but in the C sense, i.e. a contiguous amount of
memory cells, that have related information structured
in a programmer defined way.

Why should an application programmer worry about the undelying memory
management when there is a language feature that does it for him/her.

The problem of making an incomprehensible compiler, that
generates code with algorithms completely impossible to
follow by hand (i.e. by mind) is that nobody knows
any more exactly how the software works.

I don't think a good programmeer needs to know how the compiler works to
be able to write good software. It's helpful, of course, but not a
requirement, unless you are doing systems programming at a lower level.

Complexity leads to britle software, that is patched
without any understanding because to patch it you
have to understand all the class hierarchy in it.

This is partially true, also for C programs. To patch a C program you
should have a knowledge on how the program works. The same is true for a
C++ program that simply has it's logic structured hierarchically.
Analyzing a C program you have not written yourself can be as annoying
as analyzing a C++ program with all the hierarchy it embodies.

C software is transparent compared with C++. This
inherent simplicity is the great strength and the
great weakness of C.

True. Read statements above.

Because I am not a "C wave the flag" person either.
Data processing is much more complicated than that.

The positive side of C++ is the STL.

Absolutely, and I'm glad there is one.

The STL can be done in a simpler way in C. Templates
are just macros. The only thing to do is to make a macro
facility that can be programmed, in C.

It may be simpler to implement, but I doubt that this would be simpler
to use. What about side effects and macros? That's why some C functions
are implemented as macros while other simply can't, just because of that.

I am thinking about an open compiler interface, where you
write your macros not in "template C++" but in C.

The compiler would load a DLL/shared object and execute the
program in there, that will produce (eventually) text to be
inserted at the current position. You write C at compile time
parametizing it in C.

A recursive language.

Yes, why not bring some new concepts into C. This idea is worth being
discussed in more detail.

I "didn't make it" to C++ for many reasons, reasons that I
consider valid. It is a pity there is so little disucssion
here about the real issues in data-processing and we stay
at the superficial level of "I like it" or "I do not like it".

You mentioned a lot of good points, although I do not agree to all of
them. Just as you said, I hope the discussion is being held at a high
level exchanging good ideas on why to C or not to C.

Thanks

Steve

[E. Robert Tisdale]

sunil wrote:

This is a great discussion.
Both C and C++ are great languages for Software Engineering.
But I prefer to use C when dealing with low level operations
like microcontroller or kernel level or device driver developments.
You can use C++ for this as well.
C doesn't have any features that C++ doesn't have.
I prefer to use C++ when I need generic programming (templates)
or dealing with computer science data structures (STL)
or several other application level developments.

Thanks to the developers of both C and C++.

They are the same people.
C++ is simply an extension of C.

See the
History of C++

http://www.hitmill.com/programming/cpp/cppHistory.asp

[jacob navia]

Delphi is a nice programming environment, no doubt about it.
C programming environments are starting to catch up now though.

[Flash Gordon]

On Tue, 02 Nov 2004 12:37:47 +0100
jacob navia <ja***@jacob.remcomp.fr> wrote:

Delphi is a nice programming environment, no doubt about it.
C programming environments are starting to catch up now though.

Starting to catch up?

Borland C++ builder has been available for a *long* time, and it
provides a very similar environment to Delphi being written by the
same people. There are others if you want that type of things and are
prepared to actually look for them. Admittedly very few will *only* do C
since most will do C++ as well and often a number of other languages.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

[Dan Pop]

In <41***********************@news.wanadoo.fr> jacob navia <ja***@jacob.remcomp.fr> writes:

In another thread, John Bode wrote:

2. Most of today's senior programmers started out with C and feel
more comfortable using something they know well.

And in that same thread, Robert Tisdale wrote:

The only reason that C still exists is that
there are a large number of C programmers
that still aren't comfortable with C++.
There is no reason now to expect them to ever learn C++.
We are just waiting for them to retire or die.

Mr Tisdale has often been called a troll here.

I never understood why until I read that sentence.

But he is saying the same thing that Mr Bode.

In another language, yes, but the same thing.

Which doesn't make them right. C was not my first programming language.
By the time I learned C I was already familiar with Fortran, BASIC,
Pascal and several assembly languages (also several languages used by
programmable calculators). Yet, C was love at first sight: it allowed me
to express my intentions in a far more clear and concise way than anything
else I used before.

A couple of years later I tried C++. I didn't like it at all: many
features that looked useful at first sight proved to become maintenance
nightmares when used in non-trivial programs. The whole language was
marred with traps and pitfalls of the worst kind, that made trivial to
generate horribly difficult to find bugs. Furthermore, handling a
non-trivial program written by someone else proved to be next to
impossible if not downright impossible: practically no one writes the kind
of documentation a C++ program requires in order to be maintainable.
Some very sophisticated tools provide a certain help, but I don't feel
comfortable at all when I have to rely on anything more sophisticated
than grep, find and vi when dealing with someone else's code.

Since then I learned a few other languages, so it's not that my learning
capabilities were gone by the time I tried to learn C++. One could
argue that my mind is too weak to meet the requirements of *using* C++.

The life of the high level programmer, who merely uses class libraries
already developed by other people to solve his problems is much easier
than the life of the low level programmer who has to actually implement
and maintain all those class libraries.

I have seen C++ projects being abandoned when the developer moved to
another job. No one else could make any sense out of his code and his
comments. In one specific case, I was assigned the job of reimplementing
such a project in Perl, so that people coming after me could still have a
fighting chance of understanding and maintaining the code.

I'm not saying that one cannot write good C++ code, but I do say that it
takes more discipline and software engineering experience than the average
C++ programmer does possess. The big deal is not writing working C++
code but reading and maintaining someone else's C++ code.

As far as OOP in general is concerned, I've always felt that it never
delived what it promised. The concepts looked *much* better in theory
than in practice.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union

[Dan Pop]

In <cm**********@nntp1.jpl.nasa.gov> "E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:

Most C programmers don't want to add new features to the language.
Witness the resistance to the new C99 standard.

1. There is no resistance to the new C99 standard. Give me the
*conforming* implementations for everything I have to support and
I'll start using it.

2. There is a genuine lack of interest in C99, because the new features
it introduces are not the ones the C programming community at large
is really interested in. Give me typeof, statements and declarations
in expressions, pointer arithmetic on void pointers (sizeof(void) == 1)
and __builtin_types_compatible_p and you can take back all the new
features of C99, except inline functions and VLAs.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union

[Old Wolf]

"Skybuck Flying" <no****@hotmail.com> wrote:

IMHO C++ is precisly this... overly complex junk.
If you think C++ equals OO you haven't seen Delphi for example. ;)
I love Delphi's OO :)
Programming without it would be unthinkable.

Surely you are trolling here? There is absolutely nothing that
you can do in Borland Delphi that you can't do in Borland
C++Builder (with the same level of complexity).

[Chris Hills]

In article <cm**********@nntp1.jpl.nasa.gov>, E. Robert Tisdale
<E.**************@jpl.nasa.gov> writes

sunil wrote:

Thanks to the developers of both C and C++.
They are the same people.

No we are not.
C++ is simply an extension of C.
It was when it started but no longer.
See the
History of C++
http://www.hitmill.com/programming/cpp/cppHistory.asp

Anyone can publish anything it does not make it true.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[jacob navia]

Dik T. Winter wrote: (citing Mr Tisdale)

> Most C programmers (like Jacob Navia I suppose) are amateur programmers.

Is Jacob? I think not...

I am an amateur of course. I like programming, building
systems, creating software. I mean I am not doing this
just because I need to earn money even if I earn my life
with it. I do it because I like it, like the amateur
programmers.

That's why I participate here, helping other amateurs
of this activity for instance, or engaging in momentous
threads about C, data-procesing, etc.

You can have the software I write for amateurs like
me if you download the C compiler system I work with.

http://www.cs.virginia.edu/~lcc-win32

It is a system designed for amateurs, people that
do not want to install a 2.4 GB system (latest MSVC)
or a complex language where the compiler is an
incomprehensible black box.

Just C. Fast, simple, small, the whole system is
4 MB, complete with IDE, compiler and all you need
to write systems in C.

My users are C amateurs like me, like many people
I know.

I remember the bulletin boards where the last words were
always:

Enjoy !

[Michael Wojcik]

In article <cm**********@nntp1.jpl.nasa.gov>, "E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:

sunil wrote:

This is a great discussion.
If you mean "great" in the sense of "bigger than it needs to be", I'll
agree.

C doesn't have any features that C++ doesn't have.

Trivially false. For example, C++ lacks C's feature of automatically
converting void* to and from any object pointer type.
Thanks to the developers of both C and C++.

They are the same people.

Trivially false. Dennis Ritchie is not Bjarne Stroustrop.

--
Michael Wojcik mi************@microfocus.com

I gave my love some irises.
(She was sick with viruses.) -- Charlie Gibbs

[E. Robert Tisdale]

jacob navia wrote:

Dik T. Winter wrote: (citing Mr Tisdale)

> Most C programmers (like Jacob Navia I suppose) are amateur programmers.

Is Jacob? I think not...

I am an amateur of course.
I like programming, building systems, creating software.
I mean [that] I am not doing this just because
I need to earn money even if I earn my life with it.

Are you a hobbyist?
I do it because I like it, like the amateur programmers.
Professional programmers are hired and paid
to write code for other people to use.
Amateur programmers are hired and paid to do something else
and write programs for their own use to help them do there work.
There is nothing wrong with being an amateur.
They may be experts -- Olympic athletes are amateurs.
Amateur programmers tend to learn just one
computer programming language and try to use it for everything.
We expect professional programmers to become experts
in a variety of computer programming languages
and use whatever language is designated for a programming task.
That's why I participate here,
helping other amateurs of this activity for instance,
or engaging in momentous threads about C, data-processing, etc.

You can have the software I write for amateurs like
me if you download the C compiler system I work with.

http://www.cs.virginia.edu/~lcc-win32

It is a system designed for amateurs, people that
do not want to install a 2.4 GB system (latest MSVC)
or a complex language where the compiler is an
incomprehensible black box.

Just C. Fast, simple, small,
the whole system is 4 MB, complete with IDE, compiler
and all you need to write systems in C.

My users are C amateurs like me,
like many people I know.

I remember the bulletin boards
where the last words were always:

Enjoy !

[E. Robert Tisdale]

Michael Wojcik wrote:

Dennis Ritchie is not Bjarne Stroustrup.

Dennis Ritchie hired Bjarne Stroustrup.

[Bart]

On Mon, 01 Nov 2004 22:44:17 +0100, jacob navia
<ja***@jacob.remcomp.fr> wrote:

I saw Bjarne start with the idea of a better C and
get stuck in an ocean of complexity, that swallowed
him and his intrepid collaborators alive.

C is far simpler than C++ and that can't be a bad thing. Most C++
source I've seen has no need for a code obfuscator..
Bart

[sunil]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message news:<cm**********@nntp1.jpl.nasa.gov>...

sunil wrote:

This is a great discussion.
Both C and C++ are great languages for Software Engineering.
But I prefer to use C when dealing with low level operations
like microcontroller or kernel level or device driver developments.
You can use C++ for this as well.
C doesn't have any features that C++ doesn't have.

No dear, not at all. Kernel developers are very busy people. They
can't explain you the pros & cons of C and C++. You will have to prove
that C++ can be used to write kernels without flaw (or at least with
same efficiency as C). Only discussing is not the solution. C++
compilers can't stop code bloat and memory interference. C allows us
to use memory independently, C++ doesn't.

I prefer to use C++ when I need generic programming (templates)
or dealing with computer science data structures (STL)
or several other application level developments.

Thanks to the developers of both C and C++.

They are the same people.
C++ is simply an extension of C.

See the
History of C++

No, mainly Bzarne Stroustrup has written C++ while Dennis Ritchie
wrote the C.
http://www.hitmill.com/programming/cpp/cppHistory.asp

[Mike Wahler]

"sunil" <s_**********@yahoo.co.in> wrote in message
news:56**************************@posting.google.c om...

C++
compilers can't stop code bloat and memory interference.
No, they cannot prevent 'code bloat' (I have no idea what
you mean by 'memory interference'), but a programmer can.
With either language, or both.
C allows us
to use memory independently, C++ doesn't.

C++ provides exactly the same control over memory allocation
as does C.

-Mike

[Bjarne Stroustrup]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message news:<cm**********@nntp1.jpl.nasa.gov>...

Michael Wojcik wrote:

Dennis Ritchie is not Bjarne Stroustrup.

Dennis Ritchie hired Bjarne Stroustrup.

Correction: I worked in the Bell Labs Computer Science Research Center
with Dennis Ritchie, Ken Thompson, Doug McIlroy, Brian Kernighan,
Steve Johnson, Bob Morris, Sandy Fraser, Greg Chesson, etc., for many
years, but Dennis wasn't a manager when I arrived.

-- Bjarne Stroustrup; http://www.research.att.com/~bs

[Ravi Uday]

"Bjarne Stroustrup" <bj****@gmail.com> wrote in message
news:1f**************************@posting.google.c om...

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message

news:<cm**********@nntp1.jpl.nasa.gov>...

Michael Wojcik wrote:

Dennis Ritchie is not Bjarne Stroustrup.

Dennis Ritchie hired Bjarne Stroustrup.

Correction: I worked in the Bell Labs Computer Science Research Center
with Dennis Ritchie, Ken Thompson, Doug McIlroy, Brian Kernighan,
Steve Johnson, Bob Morris, Sandy Fraser, Greg Chesson, etc., for many
years, but Dennis wasn't a manager when I arrived.

-- Bjarne Stroustrup; http://www.research.att.com/~bs

You have said -

C++ is a general purpose programming language with a bias towards systems
programming that
a.. is a better C
b.. supports data abstraction
c.. supports object-oriented programming
d.. supports generic programming.
Is it real that its biased towards system programming !!

- Ravi

[Skybuck Flying]

"Old Wolf" <ol*****@inspire.net.nz> wrote in message
news:84*************************@posting.google.co m...

"Skybuck Flying" <no****@hotmail.com> wrote:

IMHO C++ is precisly this... overly complex junk.
If you think C++ equals OO you haven't seen Delphi for example. ;)
I love Delphi's OO :)
Programming without it would be unthinkable.

Surely you are trolling here? There is absolutely nothing that
you can do in Borland Delphi that you can't do in Borland
C++Builder (with the same level of complexity).

You don't get it or your trolling since the whole point is that in C++
Builder you will be confronted with other people's complex c++ junk like
operator overloading just to name one.

In delphi it simply doesn't exist.

LESS IS MORE PRINCIPLE ! ;)

Bye,
Skybuck.

[Flash Gordon]

On Wed, 3 Nov 2004 15:28:35 +0100
"Skybuck Flying" <no****@hotmail.com> wrote:

"Old Wolf" <ol*****@inspire.net.nz> wrote in message
news:84*************************@posting.google.co m...

"Skybuck Flying" <no****@hotmail.com> wrote:

IMHO C++ is precisly this... overly complex junk.
If you think C++ equals OO you haven't seen Delphi for example. ;)
I love Delphi's OO :)
Programming without it would be unthinkable.

Surely you are trolling here? There is absolutely nothing that
you can do in Borland Delphi that you can't do in Borland
C++Builder (with the same level of complexity).

You don't get it or your trolling since the whole point is that in C++
Builder you will be confronted with other people's complex c++ junk
like operator overloading just to name one.

In delphi it simply doesn't exist.

LESS IS MORE PRINCIPLE ! ;)

Well, I am working on some Delphi code which uses multiple inheritance,
overriding methods from ancestor objects, virtual methods, polymorphism
and probably everything apart from operator overloading. It is
sufficiently complex, despite being relatively small, that in some
instances I am finding it almost impossible to work out what code will
be called on a given event.

BTW, the last time I used Borland C++ builder the libraries were the
Delphi libraries with appropriate header files so you could use them
from C++. I doubt that this has changed and it is strong evidence that
you can do anything in Delphi that you can do in C++ Builder.

I've redirected followups to an appropriate group, since this is
completely OT here.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

[E. Robert Tisdale]

Bjarne Stroustrup wrote:

E. Robert Tisdale wrote:

Michael Wojcik wrote:

Dennis Ritchie is not Bjarne Stroustrup.

Dennis Ritchie hired Bjarne Stroustrup.

Correction: I worked in the Bell Labs Computer Science Research Center
with Dennis Ritchie, Ken Thompson, Doug McIlroy, Brian Kernighan,
Steve Johnson, Bob Morris, Sandy Fraser, Greg Chesson, etc., for many
years, but Dennis wasn't a manager when I arrived.

-- Bjarne Stroustrup; http://www.research.att.com/~bs

Thanks Bjarne.
I didn't mean to make you the subject of this thread.

My understanding was that you were hired (by Bell Labs I suppose)
to design a language to *replace* C and not *compete* with it.
That you were encouraged by and collaborated with
Dennis Ritchie and Brian Kernighan in this new design.
And that C++ extends and subsumes C.

[Michael Wojcik]

In article <cm**********@nntp1.jpl.nasa.gov>, "E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:

Michael Wojcik wrote:

Dennis Ritchie is not Bjarne Stroustrup.

Dennis Ritchie hired Bjarne Stroustrup.

Astoundingly irrelevant.

--
Michael Wojcik mi************@microfocus.com

[Dan Pop]

In <1a************@brenda.flash-gordon.me.uk> Flash Gordon <sp**@flash-gordon.me.uk> writes:

Well, I am working on some Delphi code which uses multiple inheritance,
overriding methods from ancestor objects, virtual methods, polymorphism
and probably everything apart from operator overloading. It is
sufficiently complex, despite being relatively small, that in some
instances I am finding it almost impossible to work out what code will ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^be called on a given event.

^^^^^^^^^^^^^^^^^^^^^^^^^^

It must be really fun to maintain such code. Languages allowing people
to write code that cannot be taken at face value are certainly not for
me.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union

[Skybuck Flying]

"Dan Pop" <Da*****@cern.ch> wrote in message
news:cm**********@sunnews.cern.ch...

In <1a************@brenda.flash-gordon.me.uk> Flash Gordon <sp**@flash-gordon.me.uk> writes:

Well, I am working on some Delphi code which uses multiple inheritance,
overriding methods from ancestor objects, virtual methods, polymorphism
and probably everything apart from operator overloading. It is
sufficiently complex, despite being relatively small, that in some
instances I am finding it almost impossible to work out what code will ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^

be called on a given event.

^^^^^^^^^^^^^^^^^^^^^^^^^^

Euhm euhm... dude I don't your code.. but have you ever heard of a debugger
and stepping through it ?

Gjez ;)

It must be really fun to maintain such code. Languages allowing people
to write code that cannot be taken at face value are certainly not for
me.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union

[Flash Gordon]

On Thu, 4 Nov 2004 23:14:55 +0100
"Skybuck Flying" <no****@hotmail.com> wrote:

"Dan Pop" <Da*****@cern.ch> wrote in message
news:cm**********@sunnews.cern.ch...

In <1a************@brenda.flash-gordon.me.uk> Flash Gordon

<sp**@flash-gordon.me.uk> writes:

Well, I am working on some Delphi code which uses multiple
inheritance, overriding methods from ancestor objects, virtual
methods, polymorphism and probably everything apart from operator
overloading. It is sufficiently complex, despite being relatively
small, that in some instances I am finding it almost impossible to
work out what code will

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^
^^^^

be called on a given event.

^^^^^^^^^^^^^^^^^^^^^^^^^^

Euhm euhm... dude I don't your code.. but have you ever heard of a
debugger and stepping through it ?

Gjez ;)

So where do you put your break point when you don't know which bit of
code will be executed when you hit a key? Answer, you don't oblody know
where to put your break point.

It must be really fun to maintain such code. Languages allowing
people to write code that cannot be taken at face value are
certainly not for me.

Yes Dan, it is hell. I would never write code like that myself and as
part of the ongoing development I am simplifying it.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

[Chris Hills]

In article <na************@brenda.flash-gordon.me.uk>, Flash Gordon
<sp**@flash-gordon.me.uk> writes

On Thu, 4 Nov 2004 23:14:55 +0100
"Skybuck Flying" <no****@hotmail.com> wrote:

"Dan Pop" <Da*****@cern.ch> wrote in message
news:cm**********@sunnews.cern.ch...

> In <1a************@brenda.flash-gordon.me.uk> Flash Gordon

<sp**@flash-gordon.me.uk> writes:

>
> >Well, I am working on some Delphi code which uses multiple
> >inheritance, overriding methods from ancestor objects, virtual
> >methods, polymorphism and probably everything apart from operator
> >overloading. It is sufficiently complex, despite being relatively
> >small, that in some instances I am finding it almost impossible to
> >work out what code will
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^
> ^^^^
> >be called on a given event.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^

Euhm euhm... dude I don't your code.. but have you ever heard of a
debugger and stepping through it ?

Gjez ;)

So where do you put your break point when you don't know which bit of
code will be executed when you hit a key? Answer, you don't oblody know
where to put your break point.

That is what a trace is for. And conditional break points and triggers.
Also you know what area of code you are intrested in... unless it is
unstructured spegetti.

Mind uyou I am more used to embedded code where the use of an ICE is
standard practice. We use themn for testing as well as debugging.

Regards
Chris

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Flash Gordon]

On Sat, 6 Nov 2004 15:09:21 +0000
Chris Hills <ch***@phaedsys.org> wrote:

In article <na************@brenda.flash-gordon.me.uk>, Flash Gordon
<sp**@flash-gordon.me.uk> writes

On Thu, 4 Nov 2004 23:14:55 +0100
"Skybuck Flying" <no****@hotmail.com> wrote:

"Dan Pop" <Da*****@cern.ch> wrote in message
news:cm**********@sunnews.cern.ch...
> In <1a************@brenda.flash-gordon.me.uk> Flash Gordon
<sp**@flash-gordon.me.uk> writes:
>
> >Well, I am working on some Delphi code which uses multiple
> >inheritance, overriding methods from ancestor objects, virtual
> >methods, polymorphism and probably everything apart fromoperator> > >overloading. It is sufficiently complex, despite being
relatively> > >small, that in some instances I am finding it almost
impossible to> > >work out what code will

>

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^> >
^^^^

> >be called on a given event.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^

Euhm euhm... dude I don't your code.. but have you ever heard of a
debugger and stepping through it ?

Gjez ;)

So where do you put your break point when you don't know which bit of
code will be executed when you hit a key? Answer, you don't oblody
know where to put your break point.

That is what a trace is for. And conditional break points and
triggers. Also you know what area of code you are intrested in...
unless it is unstructured spegetti.

It is a complete mess and in this instance I don't know which bit of
code I am interested in because I can't find it!

Stack traces have proved almost useless.

I'm having to get the program to the right state then gradually add in
more and more break points until I find the right bit.

I'm also removing the needless complexity so that I can find my way
around it.
Mind uyou I am more used to embedded code where the use of an ICE is
standard practice. We use themn for testing as well as debugging.

I used to do embedded SW and a decent ICE give you far better tools for
things like that.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.