C (functional programming) VS C++ (object oriented programming)

[Joe Mayo]

I think I become more and more alone...
Everybody tells me that C++ is better, because once a project becomes
very large, I should be happy that it has been written in C++ and not C.
I'm the only guy thinking that C is a great programming language and
that there is no need to program things object oriented.

Many people says also that they save more time by programming projects
object oriented, but I think its faster to program them in a good
structured functional way.

What do you think?

 

[Mark Bluemel]

I think I become more and more alone...

Try bathing occasionally...

Everybody tells me that C++ is better,

For some value of "Everybody"...

because once a project becomes
very large, I should be happy that it has been written in C++ and not C.

No you should be sad that it was written in C++ not Intercal.

I'm the only guy thinking that C is a great programming language and
that there is no need to program things object oriented.

Really? You're the only guy thinking that? That's news to me...

Many people says also that they save more time by programming projects
object oriented, but I think its faster to program them in a good
structured functional way.

What do you think?

I think that that you should find a group which discusses the pros and
cons of various languages... This probably isn't it.

 

[Richard Heathfield]

Joe Mayo said:

I think I become more and more alone...
Everybody tells me that C++ is better,

Well, not everybody. The people who tell you C++ is better than C fall into
two categories:

1) the ones who have never spent the time necessary to master C;
2) the ones who /have/ spent the time mastering both C and C++, and who
have discovered that C++ fits the way they think about programming better
than C does.

Conversely, the people who tell you C is better than C++ fall into two
categories:

1) the ones who have never spent the time necessary to master C++;
2) the ones who /have/ spent the time mastering both C and C++, and who
have discovered that C fits the way they think about programming better
than C++ does.

I'm the only guy thinking that C is a great programming language and
that there is no need to program things object oriented.

No, you aren't.

Many people says also that they save more time by programming projects
object oriented,

Great! Let them. Meanwhile, feel free to save more time by programming them
the way that suits you best. If that means using C, use C.

What do you think?

They're programming languages, not religions.

 

[santosh]

Joe Mayo wrote:

I think that that you should find a group which discusses the pros and
cons of various languages... This probably isn't it.

Such a group might be comp.programming

But this particular topic has been beaten to death countless times all over
the Net. Broaching it again is only likely to start yet another flame war.

 

[jacob navia]

I think I become more and more alone...
Everybody tells me that C++ is better, because once a project becomes
very large, I should be happy that it has been written in C++ and not C.
I'm the only guy thinking that C is a great programming language and
that there is no need to program things object oriented.

Many people says also that they save more time by programming projects
object oriented, but I think its faster to program them in a good
structured functional way.

What do you think?

Customer: Look jacob, you wrote the stuff in C!
me: Yes why?
Customer: No structure, no classes, no nothing. Besides we do
not have anybody that knows C here!

At the same time, as more and more people decide that C is hopeless,
the C++ people advance, making progress in all directions.

I still believe that a simple non object oriented language like C
has a place in software development where it offers speed and
transparency.

Central to this situation is the standards committee, that for the time
being has decided to do... well nothing until 2019 or later. Small steps
are done, they declared "gets" deprecated, and there are some very
interesting TR in the pipeline but nothing is definitely adopted
into the standard. C 2009 is dead as it seems.

And this group, with the core "regulars" is an example of people
living in the past, without even noticing or acknowledging that
data processing is evolving, that all languages must adapt or disappear.

Both GNU and Microsoft agree: C is dead. Gcc still hasn't gotten to
accept the C99 standard fully, and Microsoft ignores it. At least
Microsoft tries to participate in the standards committee, they proposed
their "safer C" extensions to the library, what is a major advance.
The GNU people do not discuss C anymore, and their compiler is a C++
compiler, where all development is done.

There are no technical reasons for this situation. It could be possible
to clean and expand the standard library, one of the most glaring
deficiencies of the language. Designed in the 70s, it hasn't changed
since then, and it shows!

No abstraction, low level, dangerous procedures like strncpy, gets,
asctime, and MANY others. It knows nothing about containers, hash
tables, stacks, linked lists. The zero terminated strings are the only
string type supported.

Making a better string library, allowing for operator overloading for
containers and new numeric types, improving the language to adapt it
to the new hardware environment available is frowned upon, "that
wouldn't be C", as if C would disappear if we put strncpy and gets
in the trash can.

I have invested the last 12 years of my life working to improve the
situation. The lcc-win32 implementation of C99 is one of the most
successful around, and in August we passed the *half million*
downloads.

The interest for C is still big, but this has been an effort
of a few people, that have invested an enormous amount of work
into that implementation.

Will it be possible to turn this tide around?

Can a simple language like C exist?

Yes, of course. It needs a rewrite of the standard library, and
some syntactic sugar to accommodate containers, lists, stacks, and other
data structures into a standard library that could be much simpler
to use than the STL, but much more efficient and adapted to
smaller memory footprints.

This could be done with the extensions I have proposed here (and
in comp.std.c). They can be reviewed here:

http://www.q-software-solutions.de/~jacob/proposal.pdf

jacob

 

[jacob navia]

Try bathing occasionally...


For some value of "Everybody"...


No you should be sad that it was written in C++ not Intercal.


Really? You're the only guy thinking that? That's news to me...


I think that that you should find a group which discusses the pros and
cons of various languages... This probably isn't it.

You are the typical example of many people here:

Arrogant and prone to verbal violence without any justification:

> Try bathing occasionally...

Ahhh how comic!

> I think that that you should find a group which discusses the pros and
> cons of various languages... This probably isn't it.

Of course not!

This group doesn't discuss C. It is just for people like you that
get their "kicks" by insulting others, being nasty, and just ignoring
the issues the OP raised!

 

[John Bode]

I think I become more and more alone...
Everybody tells me that C++ is better, because once a project becomes
very large, I should be happy that it has been written in C++ and not C.
I'm the only guy thinking that C is a great programming language and
that there is no need to program things object oriented.

Many people says also that they save more time by programming projects
object oriented, but I think its faster to program them in a good
structured functional way.

What do you think?

I think you need to look up the definition of functional programming,
because C is *not* a functional programming language. Haskell and ML
are functional languages.

Both procedural and object-oriented techniques (as well as functional
techniques) have their strengths and weaknesses. IME some solutions
are easier to visualize and express in terms of objects rather than
procedures (concurrency is one area where I think an object-oriented
approach is much cleaner and easier to understand).

I've been working with C++ for several years now, and there are a lot
of areas where I prefer it to C (string handling alone is orders of
magnitude less frustrating in C++). But there are times when I don't
need the overhead, and a straight C solution will work just as well.

Here are some lessons I've learned over the years, FWIW:

1. There are no magic bullets
2. All programming languages suck
3. It's always in your best interest to learn and explore as many
different programming languages as you can, because one size does
*not* fit all.

 

[jacob navia]

I think you need to look up the definition of functional programming,
because C is *not* a functional programming language. Haskell and ML
are functional languages.

Important clarification. C is just structured programming, not
"functional" programming.

Both procedural and object-oriented techniques (as well as functional
techniques) have their strengths and weaknesses. IME some solutions
are easier to visualize and express in terms of objects rather than
procedures (concurrency is one area where I think an object-oriented
approach is much cleaner and easier to understand).

I've been working with C++ for several years now, and there are a lot
of areas where I prefer it to C (string handling alone is orders of
magnitude less frustrating in C++).

Yes, this is true. Hence my efforts to improve this part of C. But
many people here believe that the only possible string type is just
those zero terminated buffers!

But there are times when I don't
need the overhead, and a straight C solution will work just as well.

Exactly. And C could be the language that fills those needs, if
it had a slightly better run time and syntax.

Here are some lessons I've learned over the years, FWIW:

1. There are no magic bullets
2. All programming languages suck
3. It's always in your best interest to learn and explore as many
different programming languages as you can, because one size does
*not* fit all.

I agree with that.

 

[Mark Bluemel]

Mark Bluemel wrote: [Snip]
You are the typical example of many people here:

Arrogant and prone to verbal violence without any justification:

Some degree of arrogance, I'm prepared to own up to, I suppose.

"Prone to verbal violence"? I'm not sure my record is that bad.

Ahhh how comic!

It amused me at the time. You are welcome to ignore or killfile me if my
postings consistently offend you.

Of course not!

This group doesn't discuss C.

Some of us try to... In this case I didn't and still don't see any
value in a "C vs C++" debate in this newgroup...

However, my last sentence in the paragraph you quoted deliberately left
room (by the use of the word "probably") for others who feel differently.

It is just for people like you that
get their "kicks" by insulting others, being nasty,

I don't think that in general my postings in this group are about
insulting people or being nasty. If I have given that impression, I'm
rather disappointed.

However, I do reserve the option of having an occasional jibe at someone
who I feel deserves it...

In this case, someone using an avowed false name posted something that
looks like provoking an unprofitable exchange of hot air.

and just ignoring
the issues the OP raised!

What issues did he raise? Nothing solid enough to really discuss. Just a
startpoint for airing prejudices.

 

[jacob navia]

What issues did he raise? Nothing solid enough to really discuss. Just a
startpoint for airing prejudices.

And maybe looking earnestly into the C library and thinking a bit:

"Maybe we should reconsider this stuff" ???

Never occurred to you that many critiques of C are completely justified
and we should address those?

There is no point in "hot air" discussions but an earnest analysis
of the faults in the library would be a better starting point.

 

[Richard Heathfield]

Mark Bluemel said:

Mark Bluemel wrote: [Snip]
You are the typical example of many people here:

Arrogant and prone to verbal violence without any justification:

Some degree of arrogance, I'm prepared to own up to, I suppose.

Hubris is one of the first three essential characteristics of a programmer.
The other two in the first three are impatience and laziness. (The *other*
three are, of course, humility, patience, and diligence.)

"Prone to verbal violence"? I'm not sure my record is that bad.

It isn't. Please bear in mind that your interlocutor is someone who
frequently misunderstands the simplest points, frequently takes offence,
frequently construes criticism as a personal attack, frequently mocks what
he does not understand, and frequently accuses people of lying, apparently
because he doesn't comprehend what they're actually talking about.

So if I were you I wouldn't pay too much attention.

In this case I didn't and still don't see any
value in a "C vs C++" debate in this newgroup...

Nor do I. It's not a competition.

I don't think that in general my postings in this group are about
insulting people or being nasty. If I have given that impression, I'm
rather disappointed.

That is not the impression I've got from your articles.

<snip>

 

[santosh]

Joe Mayo wrote:

I still believe that a simple non object oriented language like C
has a place in software development where it offers speed and
transparency.

Central to this situation is the standards committee, that for the time
being has decided to do... well nothing until 2019 or later. Small steps
are done, they declared "gets" deprecated, and there are some very
interesting TR in the pipeline but nothing is definitely adopted
into the standard. C 2009 is dead as it seems.

Why don't you join your national body for C Standardisation instead of
complaining endlessly in this group?

And this group, with the core "regulars" is an example of people
living in the past, without even noticing or acknowledging that
data processing is evolving, that all languages must adapt or disappear.

I'd wager that most of the "regulars" here maintain successfull careers and
fully understand C's relative importance in the field of s/w engineering.
However that doesn't imply that the group's de facto topicality rules,
which have served it well, can be thrown out of the window.

Both GNU and Microsoft agree: C is dead.

For Microsoft, maybe. But surely gcc's C compiler is still used in a variety
of environments where C is a main implementation language. C isn't dead;
it's use on the most user visible platform of computing, i.e. the desktop,
has reduced, but it's very much used elsewhere.

Gcc still hasn't gotten to
accept the C99 standard fully, and Microsoft ignores it.

That doesn't imply C is dead, just that it's latest Standard is rather
unpractical.

At least
Microsoft tries to participate in the standards committee, they proposed
their "safer C" extensions to the library, what is a major advance.

C is not, and can never be, a "safe" language like Java or C#/.NET. If you
want a "safe" language, you can use one of them.

C was designed to be effectively used by those who take the time and effort
to understand it's design choices and their ramifications.

The GNU people do not discuss C anymore, and their compiler is a C++
compiler, where all development is done.

This is most likely untrue. You are engaging in polemic.

There are no technical reasons for this situation. It could be possible
to clean and expand the standard library, one of the most glaring
deficiencies of the language. Designed in the 70s, it hasn't changed
since then, and it shows!

Most platform already have suitable and Standardised, (not C Standard),
alternatives to many Standard C functions.

No abstraction, low level, dangerous procedures like strncpy, gets,
asctime, and MANY others.

Any software project worth it's name has in-house procedures that spell out
these problems and propose recommended alternatives. As has been explained
to you on countless occasions, the Standard cannot change the semantics or
remove these functions because doing so would break huge amounts of
existing code.

It knows nothing about containers, hash
tables, stacks, linked lists.

All of these are, in most situations, already available in the form of
preexisting libraries. The GNU GLib is an example.

The zero terminated strings are the only
string type supported.

Alternative string packages abound.

Making a better string library, allowing for operator overloading for
containers and new numeric types, improving the language to adapt it
to the new hardware environment available is frowned upon, "that
wouldn't be C", as if C would disappear if we put strncpy and gets
in the trash can.

Yes, if you exceed a certain threshold for modifications to the language,
there will come a time when calling it C would become misleading and
disingenuous. Your lcc-win32 language is heading in that direction.

The interest for C is still big, but this has been an effort
of a few people, that have invested an enormous amount of work
into that implementation.

Will it be possible to turn this tide around?

On your platforms of choice, I don't think so.

Can a simple language like C exist?

It not only exists, but thrives and will continue to exist even if maybe not
where _you_ want it to.

But as you yourself noted, one shouldn't fear change. If the vast majority
of desktop programmers deem C impractical, why would you cling to the past
and ignore reality?

Yes, of course. It needs a rewrite of the standard library, and
some syntactic sugar to accommodate containers, lists, stacks, and other
data structures into a standard library that could be much simpler
to use than the STL, but much more efficient and adapted to
smaller memory footprints.

As I said before, there are already workarounds and prebuilt libraries to do
much of what you propose wiring into the language and taking it down the
rocky road that C++ has already travelled.

This could be done with the extensions I have proposed here (and
in comp.std.c). They can be reviewed here:

http://www.q-software-solutions.de/~jacob/proposal.pdf

Thanks, I'll take a look.

 

[Christopher Benson-Manica]

Such a group might be comp.programming

comp.lang.c.advocacy anyone? I'm in favor of anything that increases
the liklihood that these "c is dead" threads will end up somewhere
else.

But this particular topic has been beaten to death countless times all over
the Net. Broaching it again is only likely to start yet another flame war.

It's probably topical on alt.dead.horses.

 

[Richard]

Why don't you join your national body for C Standardisation instead of
complaining endlessly in this group?


I'd wager that most of the "regulars" here maintain successfull careers and
fully understand C's relative importance in the field of s/w engineering.
However that doesn't imply that the group's de facto topicality rules,
which have served it well, can be thrown out of the window.

Look. It may or may not have served it well. All I know is that it is
one of the rudest technical groups I have ever come across and that a
little more leeway and thought before sneering and saying "off topic" is
required. The example I have about the inclusion of mstat.h is a good
example. People come here in good faith to get help programming C. If
you can help, help. Most issues stay in the same threads. Dont like it?
Kill the thread. Clearly, as Chris Hills says, if there IS indeed a more
suitable groups where there are actually resident experts then that
thread will indeed move there.

 

[jacob navia]

C is not, and can never be, a "safe" language like Java or C#/.NET. If you
want a "safe" language, you can use one of them.

This means that interfaces like strncpy of gets or asctime are OK?

I mean nobody is saying that we should eliminate pointers (as Java does)
but is it necessary to keep every wart in the
language forever?

This attitude of

"C is so dangerous anyway that it is better to leave it die a peaceful
death"

leads to the death of C as a programming language. Yes, it will survive
a few years in small circuit boards but then, even those will disappear.

C was designed to be effectively used by those who take the time and effort
to understand it's design choices and their ramifications.

Yeah the elite...

This is most likely untrue. You are engaging in polemic.

o GNU doesn't participate in any discussion or standards
committee about improving C or is a part of the standardization
effort as far as I can see. Their compiler doesn't introduce anything
new or innovative for C since several years. Yes, they were innovative
at the beginning, in the 90s. But then they have all their hands
full with C++ and stopped any C development.

Most platform already have suitable and Standardised, (not C Standard),
alternatives to many Standard C functions.

And why couldn't we standardize them in the language then?

Any software project worth it's name has in-house procedures that spell out
these problems and propose recommended alternatives. As has been explained
to you on countless occasions, the Standard cannot change the semantics or
remove these functions because doing so would break huge amounts of
existing code.

This is bogus and you know it. It suffices to give the new functions
a slightly different name!

All of these are, in most situations, already available in the form of
preexisting libraries. The GNU GLib is an example.

All of those libraries are not standard, then the user is burdened with
learning each one of them in each platform!

If C had a standard interface for lists, stacks, etc, the programmers
could choose from different implementations offering the same interface!

Programs would be much more portable!

Alternative string packages abound.

Same as above.

Yes, if you exceed a certain threshold for modifications to the language,
there will come a time when calling it C would become misleading and
disingenuous. Your lcc-win32 language is heading in that direction.

typedef struct tagString { size_t length; char *data; } String;

This is NOT C. Calling this C would be disingenious.

 

[santosh]

Look. It may or may not have served it well.

You are entitled to your opinion, but my experience with this group has been
invariably positive. This group is already high volume as it is. Uptil
sometime this year, it had much less of these topicality threads and heated
discussions.

I should admit that most of my C code is very portable and system specific
routines are confined to a small portion, often written just once and
re-used, so my interest in this group naturally gravitates towards Standard
C and it's various details.

Put simply I should probably say that any non-ISO C issue that _can_ be
discussed in an existing active group should be redirected. In a few cases
some questions cannot be redirected to any useful Usenet group. The topic
may not have a dedicated group, or, as is increasingly common on Usenet
these days, a potential candidate group might be dead, or hijacked by
trolls and spammers. In this case, if someone here knows the answer a quick
off-topic response should be okay, followed by any pointers to web based
resources.

All I know is that it is one of the rudest technical groups I have ever
come across and that a little more leeway and thought before sneering and
saying "off topic" is required.

Try alt.lang.asm sometime, and you'll reconsider this statement. IME this
group is not at all rude, and what little brusqueness there is, is confined
to relatively few posts and posters.

OTOH, the trolls are genuinely rude.

Clearly, as Chris Hills says, if
there IS indeed a more suitable groups where there are actually resident
experts then that thread will indeed move there.

Not necessarily. Newbies may not know of the existence of more suitable
groups. Many newbies post _any_ question which remotely includes C here.
Some even post generic algorithm questions here, as a recent example on AVL
trees illustrates.

Some OPs are too lazy to move to another group even after being told to do
so. As Al Balmer said, persistently answering off-topic questions will
likely only encourage more people to ask off-topic questions or ignore
requests for redirection.

 

[Friedrich Dominicus]

1) the ones who have never spent the time necessary to master C++;
2) the ones who /have/ spent the time mastering both C and C++, and who
have discovered that C fits the way they think about programming better
than C++ does.

How about
1) have spend much time on "real" OO languages
2) have found that's C++ not that OO-is
3) do dislike decisions done in C++ (virtual vs. non virtual
functions)
4) tried other OO languages not in the mainstream
5) found them more promising
6) used them but simply realized that they change too fast and need
extra work with every new release
7) appriciates that there do exist C libraries which work since
decades
8) has decided for himself that if OO and C then the way should be
Objective C ;-)

No, you aren't.

Depends really. Sometimes I have the feeling that OO is a good
choice. Sometimes I think it's poor choice.

Great! Let them. Meanwhile, feel free to save more time by programming them
the way that suits you best. If that means using C, use C.

I really would like to see any serious comparison on
1) let's say GTK vs QT (or something similiar)
2) C and C++
3) C and C++ and Smalltalk
4) C and C++ and other languages (bee it statically typed like
Haskell, Ocaml etc,
or dynamically typed like most of the scripting languages.)
5) C + scripting language vs whatever


Then in the end the question still is open how much time is really
spend on the implementation and how much time on maintenance later or
work before implementation.

They're programming languages, not religions.

I feel they are a bit too believing...

Regards
Friedrich

 

[santosh]

This means that interfaces like strncpy of gets or asctime are OK?

Of course not. It means that care should be taken when they have to be used
and, whenever possible, they should be replaced with better, preferably
standardised alternatives.

Most of them do have viable alternatives. Granted they are not incorporated
in the C Standard, but most s/w projects are not purely ISO C, and these
common alternatives are easily used.

I mean nobody is saying that we should eliminate pointers (as Java does)
but is it necessary to keep every wart in the
language forever?

For backward compatibility for the foreseeable future, yes. But just being
in the Standard doesn't mean that good programmers have to use them.

This attitude of "C is so dangerous anyway that it is better to leave it
die a peaceful death" leads to the death of C as a programming language.

No one said this. C is what it is. Trying to change it support every Latest
and Greatest feature and every implementor's pet ideas won't serve the
language well.

This is why conforming implementations are expressly allowed to have
extensions. If your extensions really are in great demand and are very
useful, it should become heavily used in time.

Now tell me what fraction of C code out there uses operator overloading and
garbage collection and bignums? Of course it doesn't help that the only C
implementation that implements these "extensions" is wedded to the
Microsoft platform.

Yes, it will survive a few years in small circuit boards but then, even
those will disappear.

I think you are being overly pessimistic, and in any case, you are
forgetting the enormous amounts of code that needs to be maintained.

Yeah the elite...

No, the competent.

When basic competency is required in all the rest of science, why should
programming alone try to bend over backwards to accommodate the clueless?

o GNU doesn't participate in any discussion or standards
committee about improving C or is a part of the standardization
effort as far as I can see.

Not participating in Standard related processes doesn't mean that the C
compiler is not being actively maintained and improved.

Their compiler doesn't introduce anything
new or innovative for C since several years. Yes, they were innovative
at the beginning, in the 90s.

You seem to believe the FUD that a product has to always do something "new"
and "innovative" to be useful.

C itself is a good counter example. It has had relatively few additions
since the 1989 ANSI standard, yet it remains a widespread and popular
programming language.

But then they have all their hands
full with C++ and stopped any C development.

This is probably untrue. They are among the few widespread compiler to have
implemented much of C99, and incremental improvements are probably still
happening.

OTOH, it's also true that C++ is such a complex language for the
implementor, that it tends to dry up time and resources for other areas.

And why couldn't we standardize them in the language then?

The response C99 has received from implementers and programmers shows that
most people want C to remain small and simple, allowing each project to use
whatever additions it wants on an as-needed basis. This is both flexible
and keeps the core language small and efficient.

All of those libraries are not standard, then the user is burdened with
learning each one of them in each platform!

If C had a standard interface for lists, stacks, etc, the programmers
could choose from different implementations offering the same interface!

Programs would be much more portable!

How do you say this. All the above data structures can be implemented in
fully portable C. All that is required is an initial implementation which
can then be re-used with minimal modifications under all conforming
compilers.

typedef struct tagString { size_t length; char *data; } String;

This is NOT C. Calling this C would be disingenious.

Maybe not but things like operator overloading, function overloading,
default arguments _are_ substantial changes to the core language, to the
extent that I would categorise any code that makes heavy use of these
features as not C.

 

[Richard Heathfield]

santosh said:

jacob navia wrote:


Of course not.

The asctime function seems rather pointless to me, and gets is of course
unusable. But what is your objection to strncpy?

<snip>

 

[Martin Ambuhl]

jacob navia wrote:
[...]

You are the typical example of many people here:

Arrogant and prone to verbal violence without any justification:


Ahhh how comic!


Of course not!

This group doesn't discuss C. It is just for people like you that
get their "kicks" by insulting others, being nasty, and just ignoring
the issues the OP raised!

Consider the above subjected to the analysis Jacod presents. We find
that Jacob's post shows arrogance. We find that it is "prone to verbal
violence without any justification". We find that this post has no
discussion of C. Many of Jacob's posts have no discussion of C, but
are, like this one, insulting and nasty. Amazingly, we find that
Jacob's post completely ignores "the issues the OP raised!"

Here's a clue, Jacob. Not everyone here is you. That you are arrogant,
insulting, prone to verbal violence without justification, nasty, and
ignore the issues the OP raised does not mean that is true of the rest
of us. I have rarely seen such an exercise in self-criticism disguised
as an attack for others.

Not all of us are as antisocial as you, Jacob. Accept it.