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?

[Juha Nieminen]

Gerhard Fiedler wrote:

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.

And this already presents one of the problems with XML. For efficient
transfer you have to use some unrelated format and have both ends agree
on it. You immediately destroyed one of the key "advantages " of XML.

[Gerhard Fiedler]

On 2008-10-28 15:27:03, Jeff Schwab wrote:

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

I find often that many who use (and like) as well as many who don't use
(and sometimes hate) C don't understand this particular position of C, as
some sort of portable assembly. It clarifies a lot about why C is what it
is -- and also where it is a good choice.

Gerhard

[James Kanze]

On Oct 27, 7:28 pm, Juha Nieminen <nos...@thanks. invalidwrote:

blargg wrote:

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

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

It's not quite the same context. While XML is not without its
problems, one of the goals is to allow non-programmers to design
their own language, more or less easily. And because all of
such languages have the same basic grammar, they can all be
based on the same parser, and can all benefit from the same
smart editor tools.

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

In the case of XML, it is the user who defines the language.

As an example of what I'm talking about, consider MathML vs.
LaTeX equations, and which one is easier for a human to
write.)

Neither are, IMHO, particularly simple. MathML will benefit
from an XML aware editor; LaTeX will need special support. In
the case of LaTeX, of course, the language has been around
awhile, and is pretty universal in mathematic circles, so
editors already have that support. The simplest way to use
MathML is probablly to write LaTeX, and pass it through a
converter. But XML is used for many other things, where there
really aren't good existing tools.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Oct 28, 6:48 pm, Juha Nieminen <nos...@thanks. invalidwrote:

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.

But it compresses well:-). I agree, and this over-verbosity is
one of the things I don't particularly care for in XML. Before
XML, each time I've needed some specialized syntax, i designed
it from scratch (usually with a vaguely lisp-like grammar,
although I'd usually put the keyword outside the parentheses,
and often used {..} for parentheses, rather than (...)). And
write a parser for it, which was good for a couple of days work.
And not have any support (e.g. auto-indent) for it in the
editor. Today, I'll do it in XML, write my DTD in a couple of
hours, and have a complete parser and editor support
immediately.

I'm not really fond of XML, however: it's not that it's better
than any possible alternatives, it's that there are no
alternatives, other than developing an entire data description
language from scratch each time around. The results are never
as good as a custom data description language would be, but a
half a day's work, compared to a week or more (generally more,
because if you define your own format, you have to document it
in detail as well). There are doubtlessly some cases where the
extra work is justified, but file size is rarely a valid
justification, given the omnipresence of gzip, bzip2, etc.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Gerhard Fiedler]

On 2008-10-28 15:48:35, Juha Nieminen 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.

XML is as verbose as you make it. If your XML files are too verbose, you
can't really blame the XML definition for that. It's possible to create an
XML spec for a configuration file that is not more verbose than the
standard .ini file format, for example.

<ini cfg1="value1" cfg2="value2"/>

Of course, you can also make this

<MyReallyLongRo otNodeName>
<AnEvenLongerCo nfigurationValu eName>
value1
</AnEvenLongerCon figurationValue Name>
<AndAnotherStil lLongerConfigur ationValueName>
value2
</AndAnotherStill LongerConfigura tionValueName>
</MyReallyLongRoo tNodeName>

Neither is required or prohibited by XML. Both are XML (well, there's the
spec line that's missing).

Gerhard

[Yannick Tremblay]

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

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

Sorry, my mistake. What I meant was "unnatural" usage of operators.
I.e. defining an operator+() that does something that is not expected.

Example bad code: MFC CRect monstruosity
-----------------------------------------
CRect operator +( POINT point) const throw( );
CRect operator +(LPCRECT lpRect) const throw( );
CRect operator +( SIZE size ) const throw( );
---------------------------------------------

What on earth is adding a point to a rectangle supposed to mean? Or
adding a size to a rectangle? Or even worse, adding a rectangle to
another?

If what they wanted was shifting a recantangle sideway in direction x
and y, why didn't they say so:

CRect shift(xShift, yShift);
or
CRect move(xDirection , yDirection);

Clear and it does what it says but some idiot seem to find the need to
abuse operators for that.

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

My point.
Anti C++ C hackers claim that because it is possible to write
obfuscated C++, then C++ is bad. Regardless that the same powers that
allow one bad programmer to write obfuscated C++ do allo a good
programmer to write clear code that make appropriate use of levels of
abstraction.

>some_library:: smart_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

That's true, it is much more difficult to undertand the whole of the
C++ language.

However, in practice, is it more difficult to understand a
complete application written in C++ than it is to understand an
equivalent application written in C?

I suggest it is in fact easier if good programming practices were
followed. The C++ application should have less lines of code, have
cleaner interfaces without hidden side effect, simpler memory
management, cleaner layering of levels of abstraction, may take
advantages of OO techniques, better generic codes, etc. All stuff
that is more difficult to do in pure C.

So although in C, you can read the low level driver code and be fairly
confident that you fully understand what is happening, it is much more
difficult to shift up in application land and be able to view
everything. C++ allows this process to happen more easily. However,
it is maybe more suceptible to poor coding due to the same power. The
sword has two edges.

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

Although it is availabe, it is less often used and abused because the language
offers facilities that are often more appropriate.

So while the bad C++ programmer create unreadable code by abusing the
operator overloading and a monolith of a class hierarchy the does not
follow LSP, the bad C programmer absue the Preprocessor to rewirte
code on the fly with no traces in the current file. :-(
Yannick

[Juha Nieminen]

Gerhard Fiedler wrote:

XML is as verbose as you make it. If your XML files are too verbose, you
can't really blame the XML definition for that. It's possible to create an
XML spec for a configuration file that is not more verbose than the
standard .ini file format, for example.

<ini cfg1="value1" cfg2="value2"/>

Short and obfuscated names don't necessarily reduce the verboseness of
XML. Case in point: Just look at any MathML file.

[Juha Nieminen]

James Kanze wrote:

>As an example of what I'm talking about, consider MathML vs.
LaTeX equations, and which one is easier for a human to
write.)

Neither are, IMHO, particularly simple.

I didn't ask if either one is particularly simple. I asked which one
is *simpler* for a human to write (and read).

The LaTeX equation syntax is *by far* simpler to read and write by a
human.

[Richard Herring]

In message <NK************ **@read4.inet.f i>, Juha Nieminen
<no****@thanks. invalidwrites

>Gerhard Fiedler wrote:

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

And this already presents one of the problems with XML. For efficient
transfer you have to use some unrelated format and have both ends agree
on it. You immediately destroyed one of the key "advantages " of XML.

If bandwidth is really an issue, the compression should be happening
transparently at a lower level in the network stack. It isn't an issue
the application layer should be concerned with, so decoupling it is
surely a Good Thing.

--
Richard Herring

[Gerhard Fiedler]

On 2008-10-29 13:26:40, Juha Nieminen wrote:

>XML is as verbose as you make it. If your XML files are too verbose, you
can't really blame the XML definition for that. It's possible to create an
XML spec for a configuration file that is not more verbose than the
standard .ini file format, for example.

<ini cfg1="value1" cfg2="value2"/>

Short and obfuscated names don't necessarily reduce the verboseness of
XML. Case in point: Just look at any MathML file.

One example doesn't make a general point, good or bad. I don't know MathML,
and I don't have to. If it's a bad example, it's just a bad example. I'm
sure you won't have difficulties finding bad examples of C++ code, yet you
seem to continue using it :)

My general point above was that any XML file can be as succinct as an ini
file format. You can probably transform most free-form data formats into
XML without making them considerably more verbose.

Gerhard