By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,603 Members | 1,422 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,603 IT Pros & Developers. It's quick & easy.

when to use C and when to use C++

P: n/a
Hi everyone,

I have been asked this question quite a few times and i wonder what
could the actual reason?

" When to prefer C over C++ or vice versa, of course this is for real
world pratical scenario"

As per my understanding, C++ makes it easier to program application
related logic as OOPS helps in that sense, but for some reason that is
not a reasonable explanation, could any one add on their comments?

Nov 13 '06 #1
Share this Question
Share on Google+
102 Replies


P: n/a
sa*****@yahoo.co.in wrote:
Hi everyone,

I have been asked this question quite a few times and i wonder what
could the actual reason?

" When to prefer C over C++ or vice versa, of course this is for real
world pratical scenario"
Usually the reason for the question is that some asshole wants to start
a flame war.
As per my understanding, C++ makes it easier to program application
related logic as OOPS helps in that sense, but for some reason that is
not a reasonable explanation, could any one add on their comments?
Of course it is not a reasonable explanation for the question not an
adequate answer for it. It is at best a prejudice, at worst a lie.
Nov 13 '06 #2

P: n/a
sa*****@yahoo.co.in a écrit :
Hi everyone,

I have been asked this question quite a few times and i wonder what
could the actual reason?

" When to prefer C over C++ or vice versa, of course this is for real
world pratical scenario"

As per my understanding, C++ makes it easier to program application
related logic as OOPS helps in that sense, but for some reason that is
not a reasonable explanation, could any one add on their comments?
The problem of C++ is that it is an extremely complex language. People
that have invested a lot of time in mastering its complexity are
productive with it, people that do not want to bother may use C.

Using C coupled with a garbage collector makes many of the features
of C++ unnecessary since memory management, one of the principal reasons
for constructors/destructors disappears from view.

A problem with C is that the language is severly crippled by the absence
of any high level library for data structures like the STL. This is not
a problem with the language itself but with the people that organize the
discussion and evolution of C. The standards comitee denies any progress
to the language and apparently they have decided that no new standard
will appear in the next 10 years or so, since there will be no C 2009
and the next standard will (maybe) appear in 2019...

This means in practice that lists, arrays and many other commonly used
data structures are absent from the C standard library. It means too
that you have to use some external library, tying your code to it,
what many people will not want to do, so they start endlessly coding
their 1000th linked list package.

This group is part of the problem of C. As you can see from the answer
of Mr Ambuhl above, it is full of people that think insults are the
only answer to people that want to discuss anything more serious than:

<begin quote >
Hi people

I have coded:
i++ = (i++ + i++);

and it doesnt't work... PLEEZE HELP
< end quote>

In general, disucssions concerning the evolution of C are destroyed
systematically by a group of people called "regulars" that have
taken as granted that *their* view of C (frozen about 1989) is the
only view that can be defended in this group.

So, since comp.std.c has the same view, there is effectively no
discussion group, and no discussion of the evolution of C at all.

When to use C?

You can use C anywhere, you can code anything with it, it is a general
purpose language. Its advantages are its simplicity, and its
disadvantages are its simplicity.

jacob

Nov 13 '06 #3

P: n/a
jacob navia wrote:
>
Using C coupled with a garbage collector makes many of the features
of C++ unnecessary since memory management, one of the principal reasons
for constructors/destructors disappears from view.
I don't intend to be drawn into yet another pointless GC debate but this
falls short of the truth. Memory is but one of the many resources that
can be managed through objects with constructors and destructors, that's
why the idiom is called "Resource Acquisition Is Initialization".

--
Ian Collins.
Nov 13 '06 #4

P: n/a
Ian Collins a écrit :
jacob navia wrote:
>>Using C coupled with a garbage collector makes many of the features
of C++ unnecessary since memory management, one of the principal reasons
for constructors/destructors disappears from view.

I don't intend to be drawn into yet another pointless GC debate but this
falls short of the truth. Memory is but one of the many resources that
can be managed through objects with constructors and destructors, that's
why the idiom is called "Resource Acquisition Is Initialization".
I said "*one of* " the principal reasons.
Nov 13 '06 #5

P: n/a
Ian Collins said:
jacob navia wrote:
>>
Using C coupled with a garbage collector makes many of the features
of C++ unnecessary since memory management, one of the principal reasons
for constructors/destructors disappears from view.
I don't intend to be drawn into yet another pointless GC debate but this
falls short of the truth.
The OP asked for comments, and Jacob provided one. The OP did *not* ask only
for accurate comments from knowledgeable people.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.
Nov 13 '06 #6

P: n/a
On Mon, 13 Nov 2006 07:48:36 +0100, jacob navia
<ja***@jacob.remcomp.frwrote:
>A problem with C is that the language is severly crippled by the absence
of any high level library for data structures like the STL. This is not
a problem with the language itself but with the people that organize the
discussion and evolution of C. The standards comitee denies any progress
to the language and apparently they have decided that no new standard
will appear in the next 10 years or so, since there will be no C 2009
and the next standard will (maybe) appear in 2019...
Interestingly the development of D was spurred by missing C facilities
and to overcome C++ complexities.

Andreas
-------
1 + 1 = 3, for large values of 1.
Nov 13 '06 #7

P: n/a

sa*****@yahoo.co.in wrote:
Hi everyone,

I have been asked this question quite a few times and i wonder what
could the actual reason?

" When to prefer C over C++ or vice versa, of course this is for real
world pratical scenario"

As per my understanding, C++ makes it easier to program application
related logic as OOPS helps in that sense, but for some reason that is
not a reasonable explanation, could any one add on their comments?
Use C when it's appropriate. If you are writing a program
in C++, you may end up writing a lot of low-level routines
that are perfectly valid C. If at that time you recognize that
you are writing C, it increases the flexibility of your code
if you compile those sections as C and create a C library,
and then use them from C++, since they will also
be useable from C applications.

Some people argue that C++ makes it easier to program,
but this is often because they lack sufficient knowledge
of how to apply object-oriented programming techniques
in their C-code. In my (limited experience), C++ tends to
encourage difficult to maintain, hideous crap that is
just annoying to read.

The STL is an extremely nice feature of C++, but it
is often horribly inefficient. The data structures are
designed to be flexible and generic, and as a result
they are not the perfect match for any programming
situation. When you code in C or C++, one of
the primary reasons for that language choice is
speed...so why kill yourself on the performance side
by using overly generic data structures?

I will freely acknowledge that I have a strong bias
against C++. I think I've met 3 people who write C++
code that doesn't make me vomit. Several C++
coders I know have expressed such amazing
ignorance of C as claiming that the -operator
is not a part of the C language and an apparent
ignorance of the 'struct' keyword. (Which is to say
that one person actually said 'That's C++, C doesn't
have the arrow operator', and the abundance of
code that fails to use structures makes me believe
these people are just friggin' clueless.)

Most of the 'nice' feature of C++ are syntactic
sugar (introspection, operator overloading, automatic
constructors/destructors). The try/catch clause is
nice, but leads to sloppy programming. Namespaces
are nice, but lead to sloppy build environments. The
STL is nice, but is usually not the best choice.

In summary, use C when it is appropriate,
and use C++ never.

--
Bill Pursell

Nov 13 '06 #8

P: n/a
Bill Pursell wrote:
>
The STL is an extremely nice feature of C++, but it
is often horribly inefficient.
Sorry, FUD.
The data structures are
designed to be flexible and generic, and as a result
they are not the perfect match for any programming
situation. When you code in C or C++, one of
the primary reasons for that language choice is
speed...so why kill yourself on the performance side
by using overly generic data structures?
What's overly generic about a vector?
I will freely acknowledge that I have a strong bias
against C++.
Fair enough, but please don't spread misinformation.

--
Ian Collins.
Nov 13 '06 #9

P: n/a
Bill Pursell said:

<snip>
Use C when it's appropriate.
Better advice would be "use the *most* appropriate tool for the job". The
choice of "most appropriate tool" depends on the job, the tools available,
the various (and often conflicting) requirements of efficiency,
portability, ease of maintenance, development time constraints, and
familiarity. It would (probably) be very unwise to write a C program to
process a business transaction, however easy that might be for you, if the
other 10,000,000 lines of the suite are written in COBOL, because most of
the available maintenance expertise is going to be in COBOL, not C. But if
you're starting a new project and picking a brand new team (or going it
alone), you might well look at Python and Perl and so on for your text
processing application, and then think to yourself, "sheesh, I'd be much
happier writing this in C, simply because I know C so much better, so I'd
find it easier to write, easier to read, easier to debug..."
If you are writing a program
in C++, you may end up writing a lot of low-level routines
that are perfectly valid C. If at that time you recognize that
you are writing C, it increases the flexibility of your code
if you compile those sections as C and create a C library,
and then use them from C++, since they will also
be useable from C applications.
Agreed.
Some people argue that C++ makes it easier to program,
I, on the other hand, would argue that sticking with what you know makes it
easier to program in the short term. That isn't necessarily the best
choice, though.

Just the other day, I found myself about 20 lines into a C program, when I
thought, "hmmm, to do *this*, I'm going to need to do *that*, which means
I'll have to write some routines to do *the other*, and by the time I've
done *that*, I'll have implemented about half the STL - so why not just use
C++ and save myself a lot of time?" So I did.
but this is often because they lack sufficient knowledge
of how to apply object-oriented programming techniques
in their C-code. In my (limited experience), C++ tends to
encourage difficult to maintain, hideous crap that is
just annoying to read.
Then I suggest you spend a little time developing your ability to write
easily maintainable, non-hideous, jewels of C++ that are a delight to read.
It isn't easy! But it is certainly possible.
The STL is an extremely nice feature of C++, but it
is often horribly inefficient.
I agree, but often it doesn't matter, because "horribly inefficient" is a
relative term. When I use the STL, I am sacrificing a certain amount of
performance in favour of ease of writing, ease of reading, and ease of
maintenance. If I can save myself 40 hours of development time and end up
with a program which runs in 10 seconds using STL, when my own hand-written
C routines might be able to perform the same task in 8 seconds, then I'm
likely to jump at the chance *unless* those extra 2 seconds become a
significant part of the equation. Let's simplify matters, and assume I'm
the only person who will ever run the program. If so, then my payoff for
using C comes only when I run the program for the 72001st time(!). If, on
the other hand, I have many users lined up for the program, then the
equation changes. Even then, it might be worth writing the C++ version
simply to get the users up and running, and then re-writing it in C if and
only if I start to get a lot of complaints about performance.
The data structures are
designed to be flexible and generic, and as a result
they are not the perfect match for any programming
situation. When you code in C or C++, one of
the primary reasons for that language choice is
speed...so why kill yourself on the performance side
by using overly generic data structures?
Because "killing yourself" isn't the only choice. C++'s "overly generic"
data structures are nevertheless no slouches at performance. Yes, maybe you
can beat them with customised routines, but those customised routines take
time to write and get right. If the payoff is worth it, by all means do so,
but don't just *assume* that the payoff will be worth it.
I will freely acknowledge that I have a strong bias
against C++.
So do I. It's only my *second* favourite language.
I think I've met 3 people who write C++
code that doesn't make me vomit.
I suggest that you consult a doctor. :-)
Several C++
coders I know have expressed such amazing
ignorance of C as [...]
Well, we can't blame the language for its users!

<snip>
In summary, use C when it is appropriate,
and use C++ never.
....except when it is appropriate. Or, better still, use the best tool for
the job.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.
Nov 13 '06 #10

P: n/a
Martin Ambuhl a écrit :
sa*****@yahoo.co.in wrote:
>Hi everyone,

I have been asked this question quite a few times and i wonder what
could the actual reason?

" When to prefer C over C++ or vice versa, of course this is for real
world pratical scenario"


Usually the reason for the question is that some asshole wants to start
a flame war.
Translation:
"I want to kill any discussion that goes beyond homework level".

The easiest way is to insult anyone that posts an interesting question
that *could* lead to an interesting discussion.

comp.lang.c is just for questions like this

Hi people

I wrote
i++ = i++ + i++
and it doesn't work...

PLEEZE HELP
Nov 13 '06 #11

P: n/a
Richard Heathfield a écrit :
Ian Collins said:

>>jacob navia wrote:
>>>Using C coupled with a garbage collector makes many of the features
of C++ unnecessary since memory management, one of the principal reasons
for constructors/destructors disappears from view.

I don't intend to be drawn into yet another pointless GC debate but this
falls short of the truth.


The OP asked for comments, and Jacob provided one. The OP did *not* ask only
for accurate comments from knowledgeable people.
No, he did not.

And you are sure the appointed expert in what I know
and what I do not know.

Nov 13 '06 #12

P: n/a

sa*****@yahoo.co.in wrote:
Hi everyone,

I have been asked this question quite a few times and i wonder what
could the actual reason?

" When to prefer C over C++ or vice versa, of course this is for real
world pratical scenario"
I tend to use C++ at work, where development speed is crucial (ie. you
don't really care about putting string terminations, you don't want to
care much about allocations of string/other objects... etc.. - sad but
true). On the other hand, when I code in my spare time, I code for
fun,so I like to think about each and every detail (as it's fun :) I
enjoy it so I don't mind to spend extra time placing null terminations,
etc...

Just my case...

Nov 13 '06 #13

P: n/a
mdh

Richard Heathfield wrote:
Bill Pursell said:

<snip>
Use C when it's appropriate.

Better advice would be "use the *most* appropriate tool for the job".

Richard,
[Perhaps a little OT]

Thanks for that. I have often wondered about this myself. I started
with C as it seemed to be the underlying language in "Cocoa", (OS X).
(Problem is, that I have really begun to like C!! Besides, I am not
sure a list as active and enjoyable as this one, exists elsewhere?) My
next thought is do I need to then learn C++? It this question does not
make too much sense, it is because I do not yet clearly see all the
intricacies of the different programming languages.

Nov 13 '06 #14

P: n/a
mdh said:

<snip>
(Problem is, that I have really begun to like C!!
That is not a problem, believe me. C is a very likeable language. (It is
also a very hateable language, it seems.)
My
next thought is do I need to then learn C++?
Only you can answer that. (Do all programmers need to learn C++? No. Do some
programmers need to learn C++? Yes.)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.
Nov 13 '06 #15

P: n/a
mdh wrote:
Thanks for that. I have often wondered about this myself. I started
with C as it seemed to be the underlying language in "Cocoa", (OS X).
I would have expected "Objective C."
Nov 13 '06 #16

P: n/a
mdh

mdh wrote:
Thanks for that. I have often wondered about this myself. I started
with C as it seemed to be the underlying language in "Cocoa", (OS X).
james of tucson wrote:
I would have expected "Objective C."
James...not quite sure I understand the difference between the 2. I
know it is OT...but care to tell in a short sentence, or maybe
privately by e-mail?

Nov 13 '06 #17

P: n/a
Ian Collins wrote:
jacob navia wrote:
>Using C coupled with a garbage collector makes many of the features
of C++ unnecessary since memory management, one of the principal reasons
for constructors/destructors disappears from view.
I don't intend to be drawn into yet another pointless GC debate but this
falls short of the truth. Memory is but one of the many resources that
can be managed through objects with constructors and destructors, that's
why the idiom is called "Resource Acquisition Is Initialization".
Note that this idiom is fairly specific to C++, with its deterministic
finalization and peculiar exception handling mechanism (supporting either a
"catch" or a "finally" block, but not both). Garbage-collected OO languages
typically offer nondeterministic finalization, and the "destructor" (or
whatever it's called) is a last, untimely resort to freeing resources, which
otherwise have to be managed explicitly.

C with a garbage collector and exception handling would come a lot closer to
matching C++ (for those who insist). Of course, if it's OO you're after
you're sort of going to need classes... and then you'll want generics too
(though not necessarily in the form of C++'s templates). Before you know it,
you'll have C# or Java.

Which, I guess, just goes to show you that different languages have
different uses.

S.
Nov 13 '06 #18

P: n/a
Skarmander wrote:
C with a garbage collector and exception handling would come a lot
closer to matching C++ (for those who insist).
Objective-C's manual reference counting is one compromise -- the
language is much closer to C, and adds object allocation constructs
without going as far as literally replacing the language.

I thought Objective-C was an obscurity until I started programing on
MacOSX, and discovered that it was easy for a C programmer to work with
and quite useful.
Nov 13 '06 #19

P: n/a
mdh wrote:
>
>mdh wrote:
>>Thanks for that. I have often wondered about this myself. I started
with C as it seemed to be the underlying language in "Cocoa", (OS X).

james of tucson wrote:
>I would have expected "Objective C."

James...not quite sure I understand the difference between the 2. I
know it is OT...but care to tell in a short sentence, or maybe
privately by e-mail?
Your learning C will not be a waste if and when you want to use
Objective-C, but you must be aware that they are not the same thing.

[OT]
Objective-C is essentially C, plus some SmallTalk-style objects. It is
much smaller and more dynamic than C++, but also requires more runtime
support. In addition, it is a proper superset of C (i.e. any valid C
program is also a valid Objective-C program); any additional keywords
either begin with the '@' character, or are used in a such a limited
context that they do not conflict with their C meanings (or lack thereof)

See:
http://en.wikipedia.org/wiki/Objecti...-C_and_C.2B.2B

news:comp.lang.objective-c
[/OT]

--
Clark S. Cox III
cl*******@gmail.com
Nov 13 '06 #20

P: n/a
mdh

Clark S. Cox III wrote:
[OT]
Objective-C is essentially C,.......

thanks

Nov 13 '06 #21

P: n/a
Bill Pursell wrote:
When you code in C or C++, one of
the primary reasons for that language choice is
speed...so why kill yourself on the performance side
by using overly generic data structures?
If you read comp.lang.c++ regularly, you will see
benchmarks posted from time to time, where C++ code
using those "generic" structures (eg. string handling)
actually outperforms "equivalent" C code, because those
structures also make the job of optimisation easier for
the compiler.
Several C++ coders I know have expressed such amazing
ignorance of C
I know several C coders who have an amazing ignorance
of Perl. C must be a dreadful language !!

Most of the 'nice' feature of C++ are syntactic
sugar (introspection, operator overloading, automatic
constructors/destructors).
Automatic constructors and destructors are much more
than syntactic sugar.
The try/catch clause is nice, but leads to sloppy programming.
Well, it's just the same as setjmp/longjmp, but easier to
work with. I notice you use the passive voice, "leads to
sloppy programming". It is up to any particular programmer
whether to write sloppy code or not, it doesn't just happen
by itself.
Namespaces are nice, but lead to sloppy build environments.
Huh?

Nov 13 '06 #22

P: n/a

sa*****@yahoo.co.in wrote:
Hi everyone,

I have been asked this question quite a few times and i wonder what
could the actual reason?

" When to prefer C over C++ or vice versa, of course this is for real
world pratical scenario"

As per my understanding, C++ makes it easier to program application
related logic as OOPS helps in that sense, but for some reason that is
not a reasonable explanation, could any one add on their comments?
It *really* depends on the application in question. Some solutions
make more sense when expressed as objects, others make more sense when
expressed as procedures. There's no hard and fast rule, and more often
than not the answer is determined by what the developers already know.
If all your guys have decades' worth of experience in C, go with C. If
all your developers have only ever used C++, go with C++.

OOP does not magically make application programming easier; it makes
certain solutions easier to visualize, but the coding itself may be
just as involved (maybe more so!) as writing straight C.

I don't have a ton of experience with C++, but I will say that if your
problem involves heavy-duty text processing, C++ is the better choice.
The C++ string class, while not ideal, gives you more useful tools for
string manipulation than the C string library.

Some of the features that make C++ worth using (such as virtual
functions) incur some performance cost. For a lot of general-purpose
applications programming, this cost is negligible, but if you have to
account for every CPU cycle, it may be better to go with straight C.

Nov 13 '06 #23

P: n/a
John Bode wrote:
>
Some of the features that make C++ worth using (such as virtual
functions) incur some performance cost. For a lot of general-purpose
applications programming, this cost is negligible, but if you have to
account for every CPU cycle, it may be better to go with straight C.
Or C++ without using those features.

In the case of virtual methods, the alternatives in C tend to be either
a switch or a table of function pointers which is the common
implementation of virtual methods. So not using them may cost more
cycles and hinder optimisation.

Profile, profile, profile!

--
Ian Collins.
Nov 13 '06 #24

P: n/a

Old Wolf wrote:
Bill Pursell wrote:
Most of the 'nice' feature of C++ are syntactic
sugar (introspection, operator overloading, automatic
constructors/destructors).

Automatic constructors and destructors are much more
than syntactic sugar.
How so?
The try/catch clause is nice, but leads to sloppy programming.

Well, it's just the same as setjmp/longjmp, but easier to
work with. I notice you use the passive voice, "leads to
sloppy programming". It is up to any particular programmer
whether to write sloppy code or not, it doesn't just happen
by itself.
Absolutely. My complaints about C++ are primarily
that it seems to encourage sloppy programming. Or
perhaps it is more that I've seen many people go
down the road of "if I write in C++ then my code
will magically be beautiful, so I don't have to worry
about it". I recognize that I'm being completely
irrational about this, but at the moment (lasting about
6 months now) I'm in a big anti-C++ mood.
Namespaces are nice, but lead to sloppy build environments.

Huh?
This is really just a personal gripe with one particular
piece of software I had to deal with. The namespaces
were horribly convoluted and cluttered and it was
obvious that the programmer was creating new
namespaces whenever he had a symbol name clash
rather than clarifying the design. It led me to think
that namespaces were simply a mechanism for giving
the programmer more rope with which to hang himself.
It seems to me that being forced to keep the global
namespace uncluttered imposes more discipline on
the design, and makes you more aware of ensuring
proper linkage attributes. I think that the concept
of namespaces is great, and I love them in Python, but
I just don't see that they buy you anything in C++.
You can accomplish the same thing by keeping
your libraries in order, and having namespaces seems
to encourage disorganized libraries and discourages
proper modularity.

--
Bill Pursell

Nov 13 '06 #25

P: n/a
On Mon, 13 Nov 2006 09:55:55 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>Martin Ambuhl a écrit :
>sa*****@yahoo.co.in wrote:
>>Hi everyone,

I have been asked this question quite a few times and i wonder what
could the actual reason?

" When to prefer C over C++ or vice versa, of course this is for real
world pratical scenario"


Usually the reason for the question is that some asshole wants to start
a flame war.

Translation:
"I want to kill any discussion that goes beyond homework level".
Translation:
"Jacob Navia likes insulting the regulars in CLC because he is a fool"

Back to Martin's comment:
The commonest two reasons for someone asking why use C or C++ are
a) he's a troll and wants to start a flame war and
b) he's a student struggling with a stupid homework question.

So you see, Jacob's childish remark fits neither camp.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Nov 13 '06 #26

P: n/a
On Mon, 13 Nov 2006 08:21:31 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>Ian Collins a écrit :
>jacob navia wrote:
>>>Using C coupled with a garbage collector makes many of the features
of C++ unnecessary since memory management, one of the principal reasons
for constructors/destructors disappears from view.

I don't intend to be drawn into yet another pointless GC debate but this
falls short of the truth. Memory is but one of the many resources that
can be managed through objects with constructors and destructors, that's
why the idiom is called "Resource Acquisition Is Initialization".

I said "*one of* " the principal reasons.
Which part of "I don't intend to be drawn" did you find hard to
understand?

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Nov 13 '06 #27

P: n/a
Bill Pursell wrote:
Old Wolf wrote:
>>Bill Pursell wrote:

>>>Most of the 'nice' feature of C++ are syntactic
sugar (introspection, operator overloading, automatic
constructors/destructors).

Automatic constructors and destructors are much more
than syntactic sugar.


How so?
Try implementing Resource Acquisition Is Initialization without them.
>
>>>The try/catch clause is nice, but leads to sloppy programming.

Well, it's just the same as setjmp/longjmp, but easier to
work with. I notice you use the passive voice, "leads to
sloppy programming". It is up to any particular programmer
whether to write sloppy code or not, it doesn't just happen
by itself.


Absolutely. My complaints about C++ are primarily
that it seems to encourage sloppy programming.
Process or organisations encourage sloppy programming, not the language.
Granted C as a low level language tends to require greater discipline.
>
>>>Namespaces are nice, but lead to sloppy build environments.

Huh?

I think that the concept
of namespaces is great, and I love them in Python, but
I just don't see that they buy you anything in C++.
You can accomplish the same thing by keeping
your libraries in order, and having namespaces seems
to encourage disorganized libraries and discourages
proper modularity.
I find the opposite, using namespaces helps me organise my code be
keeping things where they belong.

--
Ian Collins.
Nov 13 '06 #28

P: n/a
Old Wolf wrote:
Bill Pursell wrote:
>The try/catch clause is nice, but leads to sloppy programming.

Well, it's just the same as setjmp/longjmp, but easier to
work with. I notice you use the passive voice, "leads to
sloppy programming".
That is not the passive voice: it is active. A passive voice
construction might be "sloppy programming is led to."
Nov 13 '06 #29

P: n/a

At first I wasn't sure if I'd take part in this C Vs C++ discussion, but
I'll dip my feet...

jacob navia:
The problem of C++ is that it is an extremely complex language.

That can be said, Yes. However if you ask proficient C++ programmers,
they'll tell you they don't find it that complicated at all.

People that have invested a lot of time in mastering its complexity are
productive with it, people that do not want to bother may use C.

Fair enough statement. Regulars here such as Richard Heathfield and Keith
Thompson appear not to be reluctant to put the work in to learn a language,
so you're argument doesn't quite explain why they favour C.

Using C coupled with a garbage collector makes many of the features
of C++ unnecessary since memory management, one of the principal reasons
for constructors/destructors disappears from view.

Constructors, destructors, class objects, smart pointers, operator
overloading, templates -- I myself favour C++ for a menagarie of reasons.

This means in practice that lists, arrays and many other commonly used
data structures are absent from the C standard library.

int array[5];

You can use C anywhere, you can code anything with it, it is a general
purpose language. Its advantages are its simplicity, and its
disadvantages are its simplicity.

Good points.

--

Frederick Gotham
Nov 13 '06 #30

P: n/a
Bill Pursell:
Use C when it's appropriate. If you are writing a program
in C++, you may end up writing a lot of low-level routines
that are perfectly valid C.

I myself do, but I don't call them "low-level". Things like arrays,
pointers and bitmasking are just as much a part of C++ as they are a part
of C, even though many C++ programmers deny this.

If at that time you recognize that you are writing C, it increases the
flexibility of your code if you compile those sections as C and create a
C library, and then use them from C++, since they will also be useable
from C applications.

You should have seen the abuse I got when I suggested that exact thing over
on comp.lang.c++.

Some people argue that C++ makes it easier to program,
but this is often because they lack sufficient knowledge
of how to apply object-oriented programming techniques
in their C-code. In my (limited experience), C++ tends to
encourage difficult to maintain, hideous crap that is
just annoying to read.

Your opinion. My own differs.

The STL is an extremely nice feature of C++, but it
is often horribly inefficient. The data structures are
designed to be flexible and generic, and as a result
they are not the perfect match for any programming
situation. When you code in C or C++, one of
the primary reasons for that language choice is
speed...so why kill yourself on the performance side
by using overly generic data structures?

You'd be suprised! I could write a more efficient "memcpy" in C++ than I
could in C.

If I were to use "memcpy" in C to copy an array of int's, I would have to
perform the redundant check that the arrays are suitably aligned for
optimal copying-time.

In C++, however, I could use a combination of function overloading and
templates. For instance:

#include <cstddef>

template<class T>
void memcpy(T *to,T const *from,std::size_t const len)
{
T const *const pover_to = to + len;

while (pover_to != to) *to++ = *from++;
}

I will freely acknowledge that I have a strong bias
against C++.

And I that I have a strong favouring toward it.

I think I've met 3 people who write C++
code that doesn't make me vomit. Several C++
coders I know have expressed such amazing
ignorance of C as claiming that the -operator
is not a part of the C language and an apparent
ignorance of the 'struct' keyword. (Which is to say
that one person actually said 'That's C++, C doesn't
have the arrow operator', and the abundance of
code that fails to use structures makes me believe
these people are just friggin' clueless.)

You should meet a Java programmer : ).

Most of the 'nice' feature of C++ are syntactic
sugar (introspection, operator overloading, automatic
constructors/destructors). The try/catch clause is
nice, but leads to sloppy programming.

It _can_, but a proficient programmer can write good code.

Namespaces are nice, but lead to sloppy build environments. The STL is
nice, but is usually not the best choice.

I disagree with both these arguments.

In summary, use C when it is appropriate,
and use C++ never.

I agree that the appropriate language should be used whenever it is
appropriate, however I am slightly biases as I always find C++ to be
appropriate.

--

Frederick Gotham
Nov 13 '06 #31

P: n/a
Frederick Gotham:
T const *const pover_to = to + len;
to + len / sizeof(T)

--

Frederick Gotham
Nov 13 '06 #32

P: n/a
Frederick Gotham wrote:
>
You'd be suprised! I could write a more efficient "memcpy" in C++ than I
could in C.

If I were to use "memcpy" in C to copy an array of int's, I would have to
perform the redundant check that the arrays are suitably aligned for
optimal copying-time.

In C++, however, I could use a combination of function overloading and
templates. For instance:
Which wouldn't give you a more efficient memcpy().

If you wanted an optimised memcpy(), you'd probably write it in
assembly, complete with the "redundant check that the arrays are
suitably aligned" and take advantage of whatever block move instructions
your processor possessed.

You would save on typing.
#include <cstddef>

template<class T>
void memcpy(T *to,T const *from,std::size_t const len)
{
T const *const pover_to = to + len;

while (pover_to != to) *to++ = *from++;
}
Far form optimal where T is char on anything other than an 8 bit machine.

--
Ian Collins.
Nov 13 '06 #33

P: n/a
Frederick Gotham wrote:
At first I wasn't sure if I'd take part in this C Vs C++ discussion, but
I'll dip my feet...

jacob navia:

>>This means in practice that lists, arrays and many other commonly used
data structures are absent from the C standard library.

int array[5];
That is an array only in very special situations... In most cases it
will "decay" into a pointer to int. The size information is destroyed
or discarded and there it goes, a buffer overflow please...

I have tried to incorporate some C++ features into the C implementation
I distribute (lcc-win32). One of the principal reasons was to have
arrays that are *really* arrays and do not "decay" into anything. Using
simple features like operator overloading, I have managed to demonstrate
that with a few extensions, C can be a high level language without the
complications of C++ and with enough expression power to code
any algorithm.

The features I have added are:

o operator overloading
o default function arguments
o references
o try/catch

And that is it.

This few features allows for an amazing power of expression,
that I have used to omplement a string library, that mimicks
the normal C string library (Strcmp, Strcat Strstr, etc) but uses
length delimited strings.

Porting from the C library to this library is quite easy, in most cases
it means just some capitalization of the C functions.

Essential for this is (again) arrays that can be accessed with
[ ] but allow for indexing with bounds checking.

Arrays, and specialy strings, are not first class object TYPES
in C, but just pointers to some "zero terminated" memory or pointers
to the first element without any size information.

That's why I added arrays to the list of objects that you have to
manage yourself in C.
Nov 13 '06 #34

P: n/a
Mark McIntyre wrote:
On Mon, 13 Nov 2006 09:55:55 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>>Martin Ambuhl a écrit :
>>>sa*****@yahoo.co.in wrote:
Hi everyone,

I have been asked this question quite a few times and i wonder what
could the actual reason?

" When to prefer C over C++ or vice versa, of course this is for real
world pratical scenario"
Usually the reason for the question is that some asshole wants to start
a flame war.

Translation:
"I want to kill any discussion that goes beyond homework level".


Translation:
"Jacob Navia likes insulting the regulars in CLC because he is a fool"

Back to Martin's comment:
The commonest two reasons for someone asking why use C or C++ are
a) he's a troll and wants to start a flame war and
b) he's a student struggling with a stupid homework question.

So you see, Jacob's childish remark fits neither camp.
What a logic. This is 100% McIntyre:

Ambuhl says:
>>>Usually the reason for the question is that some asshole wants to
start a flame war.
I said:
>>Translation:
"I want to kill any discussion that goes beyond homework level".
and it is ME that is insulting people. Maybe because I do not treat
anybody of asshole obviously.

Refraining from insults is considered here a reason for being
flamed as
"Jacob Navia likes insulting the regulars in CLC because he is a fool"
Well... this is an example of this sectarian logic. Only comprehensible
from within the sect rules, hierarchy and "reasoning".
Nov 13 '06 #35

P: n/a
jacob navia wrote:
Frederick Gotham wrote:
>At first I wasn't sure if I'd take part in this C Vs C++ discussion,
but I'll dip my feet...

jacob navia:

>>This means in practice that lists, arrays and many other commonly used
>>data structures are absent from the C standard library.


int array[5];

That is an array only in very special situations... In most cases it
will "decay" into a pointer to int. The size information is destroyed
or discarded and there it goes, a buffer overflow please...
This deficiency is being addressed, have a look at std::tr1::array. Not
standard yet, but on its way.

--
Ian Collins.
Nov 13 '06 #36

P: n/a
jacob navia said:
Frederick Gotham wrote:
>At first I wasn't sure if I'd take part in this C Vs C++ discussion, but
I'll dip my feet...

jacob navia:

>>This means in practice that lists, arrays and many other commonly used
data structures are absent from the C standard library.

int array[5];

That is an array only in very special situations...
Wrong. The array is always an array, throughout its lifetime.

In most cases it
will "decay" into a pointer to int.
Wrong. Its name does, but it doesn't.
The size information is destroyed
or discarded
Wrong. The size information is available via sizeof array, and the number of
elements in the array is available via the canonical expression:

sizeof array / sizeof array[0]

<snip>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.
Nov 14 '06 #37

P: n/a
Ian Collins <ia******@hotmail.comwrites:
jacob navia wrote:
[...]
>That is an array only in very special situations... In most cases it
will "decay" into a pointer to int. The size information is destroyed
or discarded and there it goes, a buffer overflow please...
This deficiency is being addressed, have a look at std::tr1::array. Not
standard yet, but on its way.
That's C++, isn't it? Did you perhaps momentarily forget which
newsgroup you're reading?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '06 #38

P: n/a
Keith Thompson wrote:
Ian Collins <ia******@hotmail.comwrites:
>>jacob navia wrote:

[...]
>>>That is an array only in very special situations... In most cases it
will "decay" into a pointer to int. The size information is destroyed
or discarded and there it goes, a buffer overflow please...

This deficiency is being addressed, have a look at std::tr1::array. Not
standard yet, but on its way.


That's C++, isn't it? Did you perhaps momentarily forget which
newsgroup you're reading?
Oops, I forgot to stick to the group's main topics of insults and
accusations...

It won't happen again.

--
Ian Collins.
Nov 14 '06 #39

P: n/a
Ian Collins said:
Keith Thompson wrote:
>Ian Collins <ia******@hotmail.comwrites:
>>>jacob navia wrote:

[...]
>>>>That is an array only in very special situations... In most cases it
will "decay" into a pointer to int. The size information is destroyed
or discarded and there it goes, a buffer overflow please...
This deficiency is being addressed, have a look at std::tr1::array. Not
standard yet, but on its way.


That's C++, isn't it? Did you perhaps momentarily forget which
newsgroup you're reading?
Oops, I forgot to stick to the group's main topics of insults and
accusations...
How about sticking to C, at least?
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.
Nov 14 '06 #40

P: n/a
Ian Collins a écrit :
Keith Thompson wrote:
>>Ian Collins <ia******@hotmail.comwrites:

>>>jacob navia wrote:

[...]

>>>>That is an array only in very special situations... In most cases it
will "decay" into a pointer to int. The size information is destroyed
or discarded and there it goes, a buffer overflow please...
This deficiency is being addressed, have a look at std::tr1::array. Not
standard yet, but on its way.


That's C++, isn't it? Did you perhaps momentarily forget which
newsgroup you're reading?

Oops, I forgot to stick to the group's main topics of insults and
accusations...

It won't happen again.
How true!

Nov 14 '06 #41

P: n/a
Skarmander a écrit :
Ian Collins wrote:

C with a garbage collector and exception handling would come a lot
closer to matching C++ (for those who insist).
I insist and I have made exactly such an implementation available

http://www.cs.virginia.edu/~lcc-win32
Nov 14 '06 #42

P: n/a
jacob navia wrote:
Skarmander a écrit :
>Ian Collins wrote:
Not me squire, I don't agree with this. Please take greater care with
your quoting.
>C with a garbage collector and exception handling would come a lot
closer to matching C++ (for those who insist).


I insist and I have made exactly such an implementation available

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

--
Ian Collins.
Nov 14 '06 #43

P: n/a
Richard Heathfield a écrit :
jacob navia said:

>>Frederick Gotham wrote:
>>>At first I wasn't sure if I'd take part in this C Vs C++ discussion, but
I'll dip my feet...

jacob navia:

> >>This means in practice that lists, arrays and many other commonly used
>>>>data structures are absent from the C standard library.

int array[5];

That is an array only in very special situations...


Wrong. The array is always an array, throughout its lifetime.
>>In most cases it
will "decay" into a pointer to int.


Wrong. Its name does, but it doesn't.

>>The size information is destroyed
or discarded


Wrong. The size information is available via sizeof array, and the number of
elements in the array is available via the canonical expression:

sizeof array / sizeof array[0]

<snip>
[root@gateway tmp]# cat tarray.c
void fn(int array[8])
{
printf("sizeof array = %d\n",sizeof(array));
}

int main(void)
{
int array[8];

fn(array);
}
[root@gateway tmp]# gcc tarray.c
[root@gateway tmp]# ./a.out
sizeof array = 4
[root@gateway tmp]#
Nov 14 '06 #44

P: n/a
jacob navia <ja***@jacob.remcomp.frwrote:
Richard Heathfield a écrit :
jacob navia said:
>Frederick Gotham wrote:

jacob navia:

>>This means in practice that lists, arrays and many other commonly used

data structures are absent from the C standard library.

int array[5];
This (which is a declaration of an array)...
>That is an array only in very special situations...
Wrong. The array is always an array, throughout its lifetime.
>The size information is destroyed or discarded
Wrong. The size information is available via sizeof array, and the number of
elements in the array is available via the canonical expression:

sizeof array / sizeof array[0]
[root@gateway tmp]# cat tarray.c
void fn(int array[8])
....is not at all the same as this, which is a function declaration which
includes a _pointer_ _argument_ which only looks like an array.

Richard
Nov 14 '06 #45

P: n/a
jacob navia:
That is an array only in very special situations... In most cases it
will "decay" into a pointer to int. The size information is destroyed
or discarded and there it goes, a buffer overflow please...

An array can implicitly convert to a pointer to its first element.

A double can implicitly convert to an int.

I would be wrong to suggest that a double is just int because it can
implicitly convert to one. Similarly, you can't say that an array is just a
pointer simply because it can implicitly convert to one.

If you want to be able to pass an array to a function and still retain its
length, then simply do:

#include <stddef.h>

void Func(T *p,size_t len); /* Defined elsewhere */

#define FUNC(arr) (Func(arr,sizeof arr/sizeof*arr))

This would sort of be equivalent to the following C++ code:

#include <cstddef>

template<class T,std::size_t len>
void Func(T (&arr)[len]);

--

Frederick Gotham
Nov 14 '06 #46

P: n/a
Frederick Gotham:
#define FUNC(arr) (Func(arr,sizeof arr/sizeof*arr))

Of course, I should have parentheses around all appearances of the macro
parameter.

--

Frederick Gotham
Nov 14 '06 #47

P: n/a
Richard Bos a écrit :
jacob navia <ja***@jacob.remcomp.frwrote:

>>Richard Heathfield a écrit :
>>>jacob navia said:
Frederick Gotham wrote:
>jacob navia:

This means in practice that lists, arrays and many other commonly used
>>data structures are absent from the C standard library.
>
>int array[5];


This (which is a declaration of an array)...

>>>>That is an array only in very special situations...

Wrong. The array is always an array, throughout its lifetime.
The size information is destroyed or discarded

Wrong. The size information is available via sizeof array, and the number of
elements in the array is available via the canonical expression:

sizeof array / sizeof array[0]

>>[root@gateway tmp]# cat tarray.c
void fn(int array[8])


...is not at all the same as this, which is a function declaration which
includes a _pointer_ _argument_ which only looks like an array.

Richard
What was I saying?

int array[5]: the size information is destroyed or discarded...

Yeah, looks like an array, feel like an array, but it is not an array.
Exactly what I was saying. Besides, passing it to another function
makes all the size information that *could* have been stored there get lost.

Nov 14 '06 #48

P: n/a
Frederick Gotham a écrit :
jacob navia:

>>That is an array only in very special situations... In most cases it
will "decay" into a pointer to int. The size information is destroyed
or discarded and there it goes, a buffer overflow please...

An array can implicitly convert to a pointer to its first element.

A double can implicitly convert to an int.
Both SCALARS. And the conversion is not "in palce". Another object
is created, that contains the transformed value!!!
>
I would be wrong to suggest that a double is just int because it can
implicitly convert to one. Similarly, you can't say that an array is just a
pointer simply because it can implicitly convert to one.

If you want to be able to pass an array to a function and still retain its
length, then simply do:

#include <stddef.h>

void Func(T *p,size_t len); /* Defined elsewhere */

#define FUNC(arr) (Func(arr,sizeof arr/sizeof*arr))

This would sort of be equivalent to the following C++ code:

#include <cstddef>

template<class T,std::size_t len>
void Func(T (&arr)[len]);

All this would be unnecessary if I could declare:

int fn(int array[253]);

and have the expected semantics.

Nov 14 '06 #49

P: n/a
jacob navia said:
>>>>>>int array[5];
<snip>
>
What was I saying?

int array[5]:
The original, as you can see above, was not int array[5]: but int array[5];
and that means it was /not/ a parameter definition, but an ordinary array
definition.

If you want to talk about parameter definitions, fine, let's talk about
those, but they aren't arrays, so they're not relevant to your point, such
as it was.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.
Nov 14 '06 #50

102 Replies

This discussion thread is closed

Replies have been disabled for this discussion.