when to use C and when to use C++

[mdh]

[OT]
Objective-C is essentially C,.......

thanks

 

[Old Wolf]

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?

 

[John Bode]

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.

 

[Ian Collins]

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!

 

[Bill Pursell]

Automatic constructors and destructors are much more
than syntactic sugar.

How so?

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.

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.

 

[Mark McIntyre]

Martin Ambuhl a écrit :

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

 

[Mark McIntyre]

Ian Collins a écrit :

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

 

[Ian Collins]

How so?

Try implementing Resource Acquisition Is Initialization without them.

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.

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.

 

[Martin Ambuhl]

Bill Pursell wrote:

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

 

[Frederick Gotham]

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]

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]

Frederick Gotham:

T const *const pover_to = to + len;

to + len / sizeof(T)

 

[Ian Collins]

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.

 

[jacob navia]

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.

 

[jacob navia]

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:

I said:

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

 

[Ian Collins]

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.

 

[Richard Heathfield]

jacob navia said:

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.

 

[Keith Thompson]

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?

 

[Ian Collins]

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.

 

[Richard Heathfield]

Ian Collins said:

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.