C versus C++

[chsalvia]

I would say that, in general, you don't need to learn C before
learning C++. In fact, I would go as far as saying that there's
really no reason to learn C at all. Most programming tasks are better
handled in C++, in my opinion. But there is one significant exception
I think.

I'm sure there are many people here who will disagree with me, but it
seems to me that the C programming style is somewhat more well suited
to database and/or file-system programming than C++. Of course, you
*could* program a database or a file system in C++, but in practice,
it's mostly done in pure C.

The reason has nothing to do with language capability. As a superset
of C, C++ is more than capable of doing anything C can do, obviously.
But C++ encourages a certain, "style" or "mindset" or programming,
which is totally different than C style programming.

C++ programmers tend to think in terms of objects - non-permanent,
dynamic data structures which are stored in memory. C programmers,
however, tend to think in terms of raw data: pointers to contiguous
memory blocks, structs, etc. And objects don't always translate well
to concepts involving permanent storage, like disk blocks, etc.
That's why major file systems like XFS, reiser, etc., as well as
database systems are usually programmed in C, even though they *could*
just as well be programmed in C++.

Just to avoid confusion: I'm *NOT* saying that C is better than C++
for anything. I'm saying that, in practice, C-style programming
usually lends itself better to programs which manipulate raw data on
disk, such as file-systems or databases, rather than C++ style
programming, which usually revolves around objects in memory.

 

[Alf P. Steinbach]

* (e-mail address removed):

I would say that, in general, you don't need to learn C before
learning C++.

Yes, that is a FAQ: it's almost always a good idea to read the FAQ
before posting.

In fact, I would go as far as saying that there's
really no reason to learn C at all.

Yes, it's a fact that you would say that, because you have. And it may
be a fact that for you there's no reason to learn C at all. If you
meant that there's no reason to learn C at all for anybody, then you're
irrational.

Most programming tasks are better
handled in C++, in my opinion. But there is one significant exception
I think.

I'm sure there are many people here who will disagree with me, but it
seems to me that the C programming style is somewhat more well suited
to database and/or file-system programming than C++.

That's just stupid. It may be you're trolling. Hm, yes, I think you're
trolling: you couldn't have chose such idiotic examples by chance.

Cheers,

- Alf

 

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

I would say that, in general, you don't need to learn C before
learning C++. In fact, I would go as far as saying that there's
really no reason to learn C at all. Most programming tasks are better
handled in C++, in my opinion. But there is one significant exception
I think.

I'm sure there are many people here who will disagree with me, but it
seems to me that the C programming style is somewhat more well suited
to database and/or file-system programming than C++. Of course, you
*could* program a database or a file system in C++, but in practice,
it's mostly done in pure C.

The reason has nothing to do with language capability. As a superset
of C, C++ is more than capable of doing anything C can do, obviously.
But C++ encourages a certain, "style" or "mindset" or programming,
which is totally different than C style programming.

C++ programmers tend to think in terms of objects - non-permanent,
dynamic data structures which are stored in memory. C programmers,
however, tend to think in terms of raw data: pointers to contiguous
memory blocks, structs, etc. And objects don't always translate well
to concepts involving permanent storage, like disk blocks, etc.

I have not looked one any DB code but most OS code I've seen have been
quite object oriented, with structs being the objects and the functions
that operate on them the methods, and there are both constructors and
destructors. However due to the lack of OO support in C all data is
public and the methods are not members, and constructors have to be
called manually.

That's why major file systems like XFS, reiser, etc., as well as
database systems are usually programmed in C, even though they *could*
just as well be programmed in C++.

I'd say that they are programmed in C because either they have to be
part of an OS written in C (for the FS) and because if something is
written in C it can be called from almost any other language (for the DB
application). That and the fact that most DB projects are either decades
old or derived from code that is, rewriting something that works just to
change the language is usually not a popular idea.

Just to avoid confusion: I'm *NOT* saying that C is better than C++
for anything. I'm saying that, in practice, C-style programming
usually lends itself better to programs which manipulate raw data on
disk, such as file-systems or databases, rather than C++ style
programming, which usually revolves around objects in memory.

Having said that I do recognise the fact that all problems are not best
solved with an OO design, procedural programming also have it's place.
Personally I find that you get the best effect when you mix a couple of
styles (templates and OO is a good example).

 

[Default User]

I would say that, in general, you don't need to learn C before
learning C++. In fact, I would go as far as saying that there's
really no reason to learn C at all. Most programming tasks are better
handled in C++, in my opinion. But there is one significant exception
I think.

At regular intervals, some idiot will come up with this topic. It's
pretty pointless, and it's all been hashed out before. You're posting
from Google Groups, learn how to search for past discussions.





Brian

 

[James Kanze]

On 2007-07-14 16:40, (e-mail address removed) wrote:

[...]

Having said that I do recognise the fact that all problems are not best
solved with an OO design, procedural programming also have it's place.

And what's the first thing you do when you use C, and procedural
programming. You define a struct, a set of functions which
manipulate it, and cross your fingers that no client code
manipulates it other than through your struct.

Or you use C++, so you can declare the data members private.

Encapsulation is a good thing, regardless of the paradigm you're
using.

 

[Zachary Turner]

I'd say that they are programmed in C because either they have to be
part of an OS written in C (for the FS) and because if something is
written in C it can be called from almost any other language (for the DB
application). That and the fact that most DB projects are either decades
old or derived from code that is, rewriting something that works just to
change the language is usually not a popular idea.

Actually most code that runs in an operating system kernel is
typically better suited to C than C++ because C++ makes no guarantee
over how and where certain types of things will be allocated. For
example, when you declare a virtual method the compiler allocates a
vtbl and puts it in memory somewhere. Where? The C++ standard
doesn't mandate how and where to allocate a vtbl, but this can easily
matter if the code is running inside the kernel (which obviously most
file systems and device drivers do).

There are other examples of this in C++ as well, and while you could
define a "white list" of C++ features that you can use when developing
such software, it effectively boils down to C with the class keyword,
so you might as well just use C and save yourself the trouble of
possibly using the wrong thing on accident.

 

[William Pursell]

And what's the first thing you do when you use C, and procedural
programming. You define a struct, a set of functions which
manipulate it, and cross your fingers that no client code
manipulates it other than through your struct.

Or you use C++, so you can declare the data members private.

<sigh> You don't cross your fingers. You provide
encapsulation through different methods. The following
is pure C, and all the data members are private:

#include <stdio.h>
#include <stdlib.h>

struct circle;
double get_area( const struct circle *);
struct circle *new_circle( double radius );
void free_circle( struct circle *);

int
main( int argc, char **argv)
{
double radius;
struct circle *c;

radius = argc > 1 ? strtod(argv[ 1 ], NULL) : 1;

c = new_circle( radius );
printf("radius: %f, Area: %f\n",
radius, get_area( c ));
free_circle( c );

return 0;
}

All you need to build an executable is the
object file, and you never even get to see the
layout of the struct circle. You don't
even know if I store the area when you create the
circle or if it's computed each time you invoke
get_area().

Encapsulation is indeed a wonderful thing, and
it can be accomplished in many ways. It often
seems that C++ has made it so that people never
even learn how to use a linker.

 

[Markus Schoder]

Actually most code that runs in an operating system kernel is typically
better suited to C than C++ because C++ makes no guarantee over how and
where certain types of things will be allocated. For example, when you
declare a virtual method the compiler allocates a vtbl and puts it in
memory somewhere. Where? The C++ standard doesn't mandate how and
where to allocate a vtbl, but this can easily matter if the code is
running inside the kernel (which obviously most file systems and device
drivers do).

There are other examples of this in C++ as well, and while you could
define a "white list" of C++ features that you can use when developing
such software, it effectively boils down to C with the class keyword, so
you might as well just use C and save yourself the trouble of possibly
using the wrong thing on accident.

You cannot write an OS in either pure standard C or C++ you always need
many more guarantees than the standards give you.

Anyway since C++ has a richer run time environment it is certainly more
difficult to get working for OS development.

 

[Jack Klein]

I would say that, in general, you don't need to learn C before
learning C++. In fact, I would go as far as saying that there's
really no reason to learn C at all. Most programming tasks are better
handled in C++, in my opinion.

[snip]

And why should we care what your opinions are? What are your
qualifications to have your opinions taken seriously?

In the part of your post that I snipped, you claim that certain types
of coding that are done in C could be done equally well in C++. What
experience do you have doing that type of coding in either C or C++?

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[chsalvia]

I would say that, in general, you don't need to learn C before

learning C++. In fact, I would go as far as saying that there's
really no reason to learn C at all. Most programming tasks are better
handled in C++, in my opinion.

[snip]

And why should we care what your opinions are? What are your
qualifications to have your opinions taken seriously?

In the part of your post that I snipped, you claim that certain types
of coding that are done in C could be done equally well in C++. What
experience do you have doing that type of coding in either C or C++?

What are you asking me for a resume? Is there some specific content
included in one of the claims I made that you disagree with, or what?
I claimed that C++ is generally superior for most programming tasks,
but that C style programming lends itself better to creating file
systems and database programs. Do you disagree with that?

 

[Rui Maciel]

What are you asking me for a resume?  Is there some specific content
included in one of the claims I made that you disagree with, or what?

You showed quite a bit of ignorance on your comments regarding what is C and
C++.

I claimed that C++ is generally superior for most programming tasks,
but that C style programming lends itself better to creating file
systems and database programs.  Do you disagree with that?

First of all, claiming that "language A is generally superior to language B"
is a type of discussion that can only possibly generate by a troll and can
only possibly lead to more trolling. So I simply do not believe that anyone
is willing to take your fishing expedition seriously.

Secondly, all your "C++ is generally superior" is, as it was already stated
quite clearly, based on a hefty dose of ignorance of the properties and
inner workigns of the mentioned languages. So what is there to discuss or
disagree with? Absolutely nothing.


Rui Maciel

 

[Rui Maciel]

What are you asking me for a resume?  Is there some specific content
included in one of the claims I made that you disagree with, or what?

You showed quite a bit of ignorance on your comments regarding what is C and
C++.

I claimed that C++ is generally superior for most programming tasks,
but that C style programming lends itself better to creating file
systems and database programs.  Do you disagree with that?

First of all, claiming that "language A is generally superior to language B"
is a type of discussion that can only possibly generate by a troll and can
only possibly lead to more trolling. So I simply do not believe that anyone
is willing to take your fishing expedition seriously.

Secondly, all your "C++ is generally superior" is, as it was already stated
quite clearly, based on a hefty dose of ignorance of the properties and
inner workigns of the mentioned languages. So what is there to discuss or
disagree with? Absolutely nothing.


Rui Maciel

 

[Roland Pibinger]

You provide
encapsulation through different methods. The following
is pure C, and all the data members are private:

struct circle;
double get_area( const struct circle *);
struct circle *new_circle( double radius );
void free_circle( struct circle *);

All you need to build an executable is the
object file, and you never even get to see the
layout of the struct circle. You don't
even know if I store the area when you create the
circle or if it's computed each time you invoke
get_area().

I agree in principle with your point of view. The disadvantage of C
(as depicted in your example) is that you have to allocate the object
(struct circle) on the heap.

 

[chsalvia]

First of all, claiming that "language A is generally superior to language B"

is a type of discussion that can only possibly generate by a troll and can
only possibly lead to more trolling. So I simply do not believe that anyone
is willing to take your fishing expedition seriously.

Secondly, all your "C++ is generally superior" is, as it was already stated
quite clearly, based on a hefty dose of ignorance of the properties and
inner workigns of the mentioned languages. So what is there to discuss or
disagree with? Absolutely nothing.

I expressed a general preference for C++ over C as an introductory
side note. The main thing I wanted to discuss was the idea that C
style programming lends itself better to programming file systems and
databases. Unfortunately, my introductory comments seem to have
become more of an issue than the main idea.

 

[BobR]

I expressed a general preference for C++ over C as an introductory
side note. The main thing I wanted to discuss was the idea that C
style programming lends itself better to programming file systems and
databases. Unfortunately, my introductory comments seem to have
become more of an issue than the main idea.

Then take it to an NG where it is more On-Topic!
( try comp.std.c++, comp.std.c )

 

[Jack Klein]

I would say that, in general, you don't need to learn C before
learning C++. In fact, I would go as far as saying that there's
really no reason to learn C at all. Most programming tasks are better
handled in C++, in my opinion.

[snip]

And why should we care what your opinions are? What are your
qualifications to have your opinions taken seriously?

In the part of your post that I snipped, you claim that certain types
of coding that are done in C could be done equally well in C++. What
experience do you have doing that type of coding in either C or C++?

What are you asking me for a resume? Is there some specific content
included in one of the claims I made that you disagree with, or what?
I claimed that C++ is generally superior for most programming tasks,
but that C style programming lends itself better to creating file
systems and database programs. Do you disagree with that?

Whether I agree or disagree is not the point. I did a quick search of
the last 16 months of this group and found exactly four posts from
you, the first about three months ago, and in one of them said you had
been programming in C++ for about two years.

Nowhere have you mentioned how long you have programmed in C, or
indeed if you have ever programmed in C at all. Erroneous newbie
statements like proclaiming that C++ is a superset of C (which it is
not) make me wonder how well you know both languages, or either of
them.

Nowhere did you mention any experience at all in programming file
system or data base programs at all. Have you programmed a file
system or a data base in C, or in C++? If so, can you provide an
example of a specific algorithm that was better or more easily
implemented or more efficiently implemented in one language or the
other?

So let me point this out in detail:

1. Posts on the topic "I think language X is better than language Y"
generally don't belong in a group for language X or for language Y.
They belong in a general purpose programming group, a platform
specific group if you are talking about the implementations on a
specific platform, or perhaps an advocacy group.

2. Everybody has opinions, and far too many people are eager to
spread them all over the Internet, hence the number of blogs. If you
want experienced technical people in a technical newsgroup to consider
your opinions worth discussion, you need to provide some evidence that
your opinions merit consideration. The fact that you have an opinion,
no matter how highly you value your opinion, does not mean it is worth
anything to anyone else.

3. Basically your post is off-topic. It is not about the C++
programming language, and is really no more topical here than
comparisons between C++ and any of: Java, FORTH, C#, BASIC, PL/1, or
COBOL.

Congratulations on having an opinion. What makes you think anyone
else is interested in it?

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[Rui Maciel]

I expressed a general preference for C++ over C as an introductory
side note.  

Everyone around here has personal preferences. Why should your personal
preferences be debated in a public forum simply due to the fact that they
are your own personal preferences?

The main thing I wanted to discuss was the idea that C
style programming lends itself better to programming file systems and
databases.  Unfortunately, my introductory comments seem to have
become more of an issue than the main idea.

You made a statement (C++ is better than C) and tried to support that
statement. Then it was pointed out that your statement was based on nothing
more than an hefty dose of ignorance. What more is there to discuss?


Rui Maciel

 

[James Kanze]

<sigh> You don't cross your fingers. You provide
encapsulation through different methods. The following
is pure C, and all the data members are private:

If you can.

The technique that you describe is well known. It has the
distinct disadvantage, however, of not allowing object data to
be in local variables, generally requiring dynamic allocation.

That doesn't mean that you don't use it. You do. But it's more
work for everyone concerned, and can easily lead to memory
leaks.

 

[James Kanze]

Actually most code that runs in an operating system kernel is
typically better suited to C than C++ because C++ makes no guarantee
over how and where certain types of things will be allocated.

C++ offers the same guarantees as C, where ever such guarantees
are applicable.

For example, when you declare a virtual method the compiler
allocates a vtbl and puts it in memory somewhere. Where?

That's for your compiler to document. Typically, somewhere in
the text segment, I'd hope.

The C++ standard doesn't mandate how and where to allocate a
vtbl, but this can easily matter if the code is running inside
the kernel (which obviously most file systems and device
drivers do).

C doesn't mandate how and where to allocate actual function
code, either, nor const objects. If you're writing kernel code,
you probably have to read the compiler documentation, and use
special features when linking, and maybe even when compiling.

There are other examples of this in C++ as well, and while you could
define a "white list" of C++ features that you can use when developing
such software, it effectively boils down to C with the class keyword,
so you might as well just use C and save yourself the trouble of
possibly using the wrong thing on accident.

The most important single feature of C++, regardless of what you
are doing, is private data.

In practice, in kernel code, I'd probably ban exceptions,
because they often do involve a lot of extra memory, and can
have unexpected run-time repercussions. (Kernel code is often
concerned with worst case times, not average times.) I'd also
insist that the standard operator new and operator delete be
replaced with something very specific, and only be used in the
outer layers of the kernel.

And of course, there are parts of the kernel which simply can't
be written in C++. Nor in C.

 

[Zachary Turner]

C++ offers the same guarantees as C, where ever such guarantees
are applicable.

That's for your compiler to document. Typically, somewhere in
the text segment, I'd hope.

Markus said it best above: C++ has a more complex runtime
environment. I can't speak for Unix kernel programming, but I can for
Windows. Writing any kind of kernel mode component in windows
requires you to always be aware if the memory you are allocating is
from paged pool (OS can swap it out to disk if necessary) or non-paged
pool (never swapped out to disk). C++ fails miserably here, because
it is impossible to specify whether your vtbl, RTTI, generated
template classes, or any number of other things will be in paged or
non-paged pool.

This is why C++ is unacceptable for anything in kernel mode in the
windows world, and I'm guessing the reasons are very similar for other
operating systems.

The most important single feature of C++, regardless of what you
are doing, is private data.

Luckily, C has private data.

// test.cpp
typedef struct
{
int x;
} mystruct_t;

static mystruct_t mystruct;

static void operate_on_struct(mystruct* obj)
{
obj->x = 5;
}


It's obviously not quite as rich as the features provided by C++, but
it definitely gets the job done.