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?

[Jeff Schwab]

Pawel_Iks wrote:

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?

C++ is not necessarily a better C at all. C is better at being C than
C++ is, and is inherently superior in specific ways. I prefer C++ for
the vast majority of programming tasks, but (Bjarne's opinion
notwithstanding ) the two languages are fundamentally different, and it
would not make sense to merge them.

I prefer C for some of the lower level portions of OS kernel and device
driver development, e.g. the code that runs on an ACPI embedded
controller. It's not that the C code is any better than C++ would be,
but that someone reading the code doesn't have to consider every
operation a potential function call. The meaning of an expression like
a+b has a variety of potential meanings, even in C, but the variety is
at least bounded. C is also much nicer than typical C++ to interface
with from assembly, because the name mangling is so much simpler. Even
C++ that is entirely in the shared subset with C may have decorated
names, so C++ that provides the same kind of consistently defined,
human-readable symbols has to both declare and define the symbols as
extern "C".

The beauty of C is that you know precisely what every statement means.
The beauty of C++ is that you don't have to.

[Walter Bright]

Juha Nieminen wrote:

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.

Yes and no. Anyone can invent a complex solution to a problem, but it
takes genius to find a simple solution.

[Juha Nieminen]

blargg wrote:

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]

Jeff Schwab wrote:

Juha Nieminen wrote:

>Pawel_Iks wrote:

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

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]

On 2008-10-27 16:28:26, Juha Nieminen wrote:

(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]

Gerhard Fiedler wrote:

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

[Yannick Tremblay]

In article <jt************ *************** ***@giganews.co m>,
Jeff Schwab <je**@schwabcen ter.comwrote:

>

I prefer C for some of the lower level portions of OS kernel and device
driver development, e.g. the code that runs on an ACPI embedded
controller. It's not that the C code is any better than C++ would be,
but that someone reading the code doesn't have to consider every
operation a potential function call. The meaning of an expression like
a+b has a variety of potential meanings, even in C, but the variety is
at least bounded. C is also much nicer than typical C++ to interface

Well, if you are going to talk about bad C++ that redefine operator+()
for basic types, then one should also consider preprocessor abuse in
pure C.

[Jeff Schwab]

Yannick Tremblay wrote:

In article <jt************ *************** ***@giganews.co m>,
Jeff Schwab <je**@schwabcen ter.comwrote:

>>
I prefer C for some of the lower level portions of OS kernel and device
driver development, e.g. the code that runs on an ACPI embedded
controller. It's not that the C code is any better than C++ would be,
but that someone reading the code doesn't have to consider every
operation a potential function call. The meaning of an expression like
a+b has a variety of potential meanings, even in C, but the variety is
at least bounded. C is also much nicer than typical C++ to interface

Well, if you are going to talk about bad C++ that redefine operator+()
for basic types,

You can't redefine operator+ for primitive types, even in C++, thank
WG21. You can overload operator+ for the case when at least one
argument is not primitive, but that's not the same thing.

In well-written C++ code, the reader doesn't have to know exactly what's
happening at the next lower level of abstraction; for example,
some_library::s mart_pointer's destructor may clean up a resource, or
flush a buffer; operator-may return a temporary proxy object whose
constructor and destructor obtain and release a lock. These techniques
can be great for high-level programming, but they're wide open to the
kind of savage abuse that "seems like a good idea at the time." Almost
any use of them would be dangerous in code that is innately
hardware-specific. The "next lower level of abstraction" specifically
should not be hidden from (e.g.) a device driver that needs to
communicate with the registers on a device controller.

The introduction to The C Programming Language claims that "a programmer
can reasonably expect to know and understand and indeed regularly use
the entire language." The same is not true of C++. Note that C++ is my
"desert island" language, and I love it dearly, so I don't claim that C
has its advantages without reason. I also wonder why the C committee
bothers with quasi-automated features like VLAs, since C's long-term
niche is clearly with developers who need just enough abstraction to let
the same code run on target platforms with different assembly languages.

then one should also consider preprocessor abuse in
pure C.

The same preprocessor is available in C++, and seems to be abused with
roughly equal frequency in both languages. Note that what constitutes
"abuse" in C++ is often valid in C; for example, macro definitions don't
respect C++ namespaces, but in C, that's not a problem.

[Juha Nieminen]

Gerhard Fiedler wrote:

XML is primarily meant for the (easily
portable) exchange of data between programs

And XML is one of the least efficient ways of doing that, spacewise.
This is especially true with large amounts of data which have to be
transferred eg. over a network. XML is hyperverbose, often for no good
reason.

[Gerhard Fiedler]

On 2008-10-28 15:48:35, Juha Nieminen wrote:

Gerhard Fiedler wrote:

>XML is primarily meant for the (easily
portable) exchange of data between programs

And XML is one of the least efficient ways of doing that, spacewise.
This is especially true with large amounts of data which have to be
transferred eg. over a network. XML is hyperverbose, often for no good
reason.

Yes, but that's a different thing, and I think that this is what computers
are for :) XML is usually quite easily compressable, so for network
transfer this shouldn't be a problem.

Gerhard