Is c++ only better c ?

[Pawel_Iks]

I've read somewhere that c++ is something more than better c ... then
I talk with my friend and he claimed that c++ is nothing more than
better c ... I tried to explain him that he was wrong but I forgot all
arguments about it. Could someone told something about it?

 

[Maxim Yegorushkin]

I've read somewhere that c++ is something more than better c ... then
I talk with my friend and he claimed that c++ is nothing more than
better c ... I tried to explain him that he was wrong but I forgot all
arguments about it. Could someone told something about it?

Some actually consider C++ to be worse than C: http://esr.ibiblio.org/?p=532

 

[James Kanze]

Some actually consider C++ to be worse than
C:http://esr.ibiblio.org/?p=532

You'll find some idiot to defend just about any position. (Not
that all people who are critical of C++ are idiots. But the
intelligent ones don't like C either; the real problem with C++
is that it inherits too much from C.)

C++ definitely improves C. It also adds a lot of things which
support idioms which aren't supported in C. I suppose that you
could call support for OO, or support for generic programming,
an "improved" C, but IMHO, that's stretching it. I suspect,
however, that what the friends of the original poster were
criticizing is C++'s C-ness; it does inherit a number of
problems (e.g. declaration syntax) from C.

 

[osmium]

I've read somewhere that c++ is something more than better c ... then
I talk with my friend and he claimed that c++ is nothing more than
better c ... I tried to explain him that he was wrong but I forgot all
arguments about it. Could someone told something about it?

IMO, the best place to get an answer for that kind of question is in the
link below..

http://www.research.att.com/~bs/bs_faq.html

 

[Chris M. Thomasson]

You'll find some idiot to defend just about any position. (Not
that all people who are critical of C++ are idiots. But the
intelligent ones don't like C either; the real problem with C++
is that it inherits too much from C.)

C++ definitely improves C. It also adds a lot of things which
support idioms which aren't supported in C. I suppose that you
could call support for OO,

[...]

You can get "fairly clean" abstract interfaces in C; something as simple as;
quick code scribbling - may have typo:


IShape.h
--------------------------------------------
struct IShape_VTable {
void (*IObject_Destroy) (void*);
void (*IShape_Draw) (void*);
/* ect... */
};

struct IShape {
struct IShape_VTable* VTable;
};

#define IObject_Destroy(Self) ( \
(Self)->VTable->IObject_Destroy((Self)) \
)

#define IShape_Draw(self) ( \
(Self)->VTable->IShape_Draw((Self)) \
)




That all the infrastructure. Now to create actual shapes...

Circle.h
--------------------------------------------
extern struct IShape*
Circle_Create(
/* ... */
);




Circle.c
--------------------------------------------
#include "Circle.h"
#include <stdlib.h>


static void Circle_IObject_Destroy(void*);
static void Circle_IShape_Draw(void*);


static struct IShape_VTable Circle_VTable = {
Circle_IObject_Destroy,
Circle_IShape_Draw
};


struct Circle {
struct IShape IShape;
/* ... */
};


struct IShape*
Circle_Create(
/* ... */
) {
struct Circle* Self = malloc(*Self);
if (Self) {
Self->IShape.VTable = &Circle_VTable;
return &Self->IShape;
}
return NULL;
}


void
Circle_IObject_Destroy(
void* IObject
) {
free(IObject);
}


void
Circle_IShape_Draw(
void* IShape
) {
struct Circle* const Self = IShape;
/* ... */
}





Now, finally we can use the Circle via. the abstract interfaces IShape and
IObject:

main.c
--------------------------------------
#include "Circle.h"


int main(void) {
struct IShape* Shape = Circle_Create(/* ... */);
IShape_Draw(Shape);
IObject_Destroy(Shape);
return 0;
}




There... simple!

;^D

 

[Juha Nieminen]

Some actually consider C++ to be worse than C

In my personal opinion those are delusional prejudiced people who
suffer from a huge resistance of change. The claim is completely
ridiculous for two reasons:

1) Anything you can do in C, you can do in C++.
2) You are not forced to use anything extra in C++ if you don't want to.

The only way C++ could even theoretically be worse than C would be if
you were *forced* to do something in C++ which you don't have to do in
C, and this something is detrimental to the program. However, C++ does
not force you to do *anything* you couldn't do in C as well. Anything
you can do in C, you can do in C++. Thus the very claim that "C++ is
worse than C" is plain BS.

For example one could argue that, let's say, "Java is worse than C",
and there can plausibly be rational reasons for this claim because in
Java you are forced to do things rather differently than in C. For
example in Java you are *forced* to write classes, which you don't have
to do in C. Java does not support everything C supports (at least not
verbatim).

Now, if the claim was changed to "what C++ adds to C only makes the
language worse", it could make even a little bit of sense. Of course
this claim is also complete BS, but at least it's a more logical and
sensible statement.

The hilarious thing about C++-hating C-hackers is that it's rather
easy to make them squirm: Just challenge them to implement a small
simple program which handles dynamic memory, to compare the simplicity
and safety of the equivalent C and C++ implementations. Then just sit
back and be entertained by the (often surprisingly) imaginative ways
they will try to cheat their way out of the problem (because they really
*don't* want to compare C and C++ implementations of the problem
side-by-side).

 

[James Kanze]

In my personal opinion those are delusional prejudiced people
who suffer from a huge resistance of change. The claim is
completely ridiculous for two reasons:

1) Anything you can do in C, you can do in C++.

That's not true:

int
main()
{
someFunction( 42 ) ;
return 0 ;
}

is a perfectly legal C program (supposing someFunction defined
in some other translation unit), but not a legal C++ function.
Among the things that you can do in C, but not in C++, are:

-- not declare external functions, then call them with the
wrong number or type of arguments,

-- assign a void* to a typed pointer, regardless of type, with
no explicit conversion to warn you that something extremely
dangerous is going on.

There are probably others, but these two come immediately to
mind.

Whether these possibilities can in any possible way be
considered an improvement, I leave to the judgement of the
reader.

In C99, there are a couple of more things you can do, like
VLA's and designated initializers. But since most of the people
who prefer C over C++ also reject C99, I'll not go into those.

 

[Juha Nieminen]

That's not true:

I didn't say "any C program is a valid C++ program". What I said was
"anything you can do in C, you can do in C++".

Sure, there are a few cases where the type system of C++ is slightly
stricter than C's (although I'm a bit surprised this is still the case
with C99), but I wouldn't say that's a very radical difference.

Of if I put that in other terms: If someone considered C++ to be worse
exclusively because you have to declare functions before you use them,
that would be a rather stupid and trivial argument. When C hackers bash
C++, they are not talking about function declarations and void pointers,
they are talking about what C++ *adds* to the language that C doesn't
have (such as templates).

 

[SG]

You can get "fairly clean" abstract interfaces in C; something as simple as;
quick code scribbling - may have typo:

[... C++ abstract class and virtual function emulation in plain C ...]

There... simple!

Well, that was a really simple case, wasn't it? Try inheriting from
more than one abstract class. My point is: You can code "OO style"
in plain C. But it's gonna be verbose and error-prone. I have to admit
I didn't try any of the available frameworks for "OO-emulation in
plain C" (like GObject). Spending time learning these frameworks
instead of learning C++ doesn't seem like a good choice to me since C+
+ has other neat things to offer:
- RAII (one of the biggest selling points IMHO)
- support for generic programming (via templates, also big selling
point)

Cheers,
SG

 

[Ian Collins]

Of if I put that in other terms: If someone considered C++ to be worse
exclusively because you have to declare functions before you use them,
that would be a rather stupid and trivial argument. When C hackers bash
C++, they are not talking about function declarations and void pointers,
they are talking about what C++ *adds* to the language that C doesn't
have (such as templates).

They tend to work them selves up into a lather about the added
complexity of C++ while refusing to acknowledge the complexity is optional.

 

[Chris M. Thomasson]

You can get "fairly clean" abstract interfaces in C; something as simple
as;
quick code scribbling - may have typo:

[... C++ abstract class and virtual function emulation in plain C ...]

There... simple!

Well, that was a really simple case, wasn't it?

Indeed. Although, I personally like to use the minimalist technique I
described for plug-in frameworks.

Try inheriting from more than one abstract class.

Ouch! :^(

My point is: You can code "OO style"
in plain C. But it's gonna be verbose and error-prone.

Fair enough.

I have to admit
I didn't try any of the available frameworks for "OO-emulation in
plain C" (like GObject). Spending time learning these frameworks
instead of learning C++ doesn't seem like a good choice to me since C+
+ has other neat things to offer:
- RAII (one of the biggest selling points IMHO)
- support for generic programming (via templates, also big selling
point)

Agreed.

 

[Juha Nieminen]

They tend to work them selves up into a lather about the added
complexity of C++ while refusing to acknowledge the complexity is optional.

What bothers me the most with their argument about "added complexity"
is that it feels like they have actually never even tried this "added
complexity" they are talking about.

The basic mistake in thinking is that "more features" equals to "more
complexity", which equals to "the language is harder to use and
understand". They emphasize that C is good because it's so simple.

There is no such equality. More features don't automatically make the
language more complex. In fact, it's often the exact opposite: More
features can make using the language *simpler*, not more complicated.

 

[Juha Nieminen]

I've read somewhere that c++ is something more than better c ... then
I talk with my friend and he claimed that c++ is nothing more than
better c ... I tried to explain him that he was wrong but I forgot all
arguments about it. Could someone told something about it?

I think that this is just an argument about semantics. If you say "C++
is something more than just a better C" that sentence has a positive
exalting tone to it, but if you say "C++ is nothing more than a better
C" that sentence has a belittling and unappreciating tone. In the end,
both sentences are saying the exact same thing. There's just a
difference in attitude.

 

[s0suk3]

You'll find some idiot to defend just about any position.  (Not
that all people who are critical of C++ are idiots.  But the
intelligent ones don't like C either; the real problem with C++
is that it inherits too much from C.)
C++ definitely improves C.  It also adds a lot of things which
support idioms which aren't supported in C.  I suppose that you
could call support for OO,

[...]

You can get "fairly clean" abstract interfaces in C; something as simple as;
quick code scribbling - may have typo:

IShape.h
--------------------------------------------
struct IShape_VTable {
  void (*IObject_Destroy) (void*);
  void (*IShape_Draw) (void*);
  /* ect... */

};

struct IShape {
  struct IShape_VTable* VTable;

};

#define IObject_Destroy(Self) ( \
  (Self)->VTable->IObject_Destroy((Self)) \
)

#define IShape_Draw(self) ( \
  (Self)->VTable->IShape_Draw((Self)) \
)

That all the infrastructure. Now to create actual shapes...

Circle.h
--------------------------------------------
extern struct IShape*
Circle_Create(
 /* ... */
);

Circle.c
--------------------------------------------
#include "Circle.h"
#include <stdlib.h>

static void Circle_IObject_Destroy(void*);
static void Circle_IShape_Draw(void*);

static struct IShape_VTable Circle_VTable = {
  Circle_IObject_Destroy,
  Circle_IShape_Draw

};

struct Circle {
  struct IShape IShape;
  /* ... */

};

struct IShape*
Circle_Create(
 /* ... */
) {
  struct Circle* Self = malloc(*Self);
  if (Self) {
    Self->IShape.VTable = &Circle_VTable;
    return &Self->IShape;
  }
  return NULL;

}

void
Circle_IObject_Destroy(
 void* IObject
) {
  free(IObject);

}

void
Circle_IShape_Draw(
 void* IShape
) {
  struct Circle* const Self = IShape;
  /* ... */

}

Now, finally we can use the Circle via. the abstract interfaces IShape and
IObject:

main.c
--------------------------------------
#include "Circle.h"

int main(void) {
  struct IShape* Shape = Circle_Create(/* ... */);
  IShape_Draw(Shape);
  IObject_Destroy(Shape);
  return 0;

}

There... simple!

;^D

I used to code C in ways very similar to that, but it's a total
nightmare. It's not what C was designed for, and it's not the way to
code it (incidentally, it's the only *productive* way to code it!).

It's basically a faking of basic OO concepts such as an abstract type
with operations bundled to it, and it can be a clean way to code basic
applications. At a large scale, however, the lack of language support
for these programming techniques leads to a great deal of verbosity
and boilerplate code, almost to the point where the disadvantages
outweigh the advantages (it even increases the risk of memory leaks!).

C just isn't a good scaling language.

Sebastian

 

[James Kanze]

Juha Nieminen wrote:

They tend to work them selves up into a lather about the added
complexity of C++ while refusing to acknowledge the complexity
is optional.

I believe it was Robert Martin that first pointed it out, but
the complexity is always there; it's inherit in the application.
In the case of C++, that complexity manifests itself in the
language; in the case of C, in the code we have to write to
solve the problem. Which means that in the case of C++, we have
to master it once, for all applications; in the case of C, we
have to master it for each application.

 

[James Kanze]

I didn't say "any C program is a valid C++ program". What I
said was "anything you can do in C, you can do in C++".

I'm not sure then what your point is. Both are Turing complete.
So is assembler, and Basic, and just about every other
language. What makes some people prefer C to C++ is that you
can do things in C that you can't do in C++, at the coding
level. Of course, these things are very bad software
engineering (like using a function without having declared it
first), but that's the way it is.

Sure, there are a few cases where the type system of C++ is
slightly stricter than C's (although I'm a bit surprised this
is still the case with C99), but I wouldn't say that's a very
radical difference.

The fact that you don't have to include headers to use a
function is IMHO a radical difference. I *think* this feature
was deprecated in C99; I'm not sure. But the people who prefer
C over C++ generally eschew C99 as well.

Of if I put that in other terms: If someone considered C++ to
be worse exclusively because you have to declare functions
before you use them, that would be a rather stupid and trivial
argument. When C hackers bash C++, they are not talking about
function declarations and void pointers, they are talking
about what C++ *adds* to the language that C doesn't have
(such as templates).

Have you looked at their code? I know what they say, but I also
know what they do.

 

[Juha Nieminen]

Won't someone think of the compiler writers???

It's the job of the compiler writers to make the life of the
programmers easier, not the other way around.

(As a side note, I detest XML precisely because of that: XML has been
designed to make it easier to create programs which read XML, at the
cost of making it harder for users to write XML. (Basically XML is
pre-tokenized data, which lifts the need for the program reading XML to
tokenize it.) This is the complete reversals of what software should be
all about: Software should do as much as possible to make the life of
the user as easy as possible, not the other way around!
As an example of what I'm talking about, consider MathML vs. LaTeX
equations, and which one is easier for a human to write.)

 

[Juha Nieminen]

Huh? "Something" != "nothing"; that's not just a different tone, it's
an altogether different meaning.

Only if you insist in interpreting the words literally. The concept "a
better C" already implies that there's *something* more in C++ than in
C. The word "nothing" in that sentence doesn't mean "no extra features",
it means "the extra features are not all that important". Like in the
expression "that's nothing".

 

[Gerhard Fiedler]

(As a side note, I detest XML precisely because of that: XML has been
designed to make it easier to create programs which read XML, at the
cost of making it harder for users to write XML. (Basically XML is
pre-tokenized data, which lifts the need for the program reading XML to
tokenize it.) This is the complete reversals of what software should be
all about: Software should do as much as possible to make the life of
the user as easy as possible, not the other way around!

I see this differently. Firstly, XML is primarily meant for the (easily
portable) exchange of data between programs, not for direct user input.
Secondly, in the places where you "hack" XML manually, it's because there
was no time or no funding to write a program that would create the required
input data comfortably -- which would be the same problem with any other
input scheme. And thirdly, if you have data to input into a program, and
need to hack the input manually because there is not proper
input-generating program, it's kind of comforting to have a defined way how
data is tokenized - not having to guess (or to check in the code) whether
strings have to be quoted with single quotes, double quotes, or any other
old way (like embedded spaces quoted with backslash), and whether embedded
quotes in strings have to be quoted with backslashes, doubling the quote,
or whatever, and so on...

Considering this, maybe you can find some improvement in XML when compared
to the alternatives

Gerhard

 

[Matthias Buelow]

Considering this, maybe you can find some improvement in XML when compared
to the alternatives

What are the alternatives?

Better than S-Expr syntax? I often hear "XML is better than the
alternatives" but noone so far could show me a single example where
there isn't a better alternative. Ok, maybe with the exception of SGML
for simple uses (for which it was originally developped).