Is c++ only better c ?
Pawel_Iks
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
James Kanze
wrote:
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.
--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
osmium
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
"James Kanze" <james...@gmail.com> wrote in message
news:ded8588f-baa2-4229...@34g2000hsh.googlegroups.com...
On Oct 24, 11:55 am, Maxim Yegorushkin <maxim.yegorush...@gmail.com>
wrote:
> On Oct 24, 10:27 am, Pawel_Iks <pawel.labed...@gmail.com> 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?
> > 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,
[...]
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
> Maxim Yegorushkin wrote:
> > 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++.
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.
SG
> You can get "fairly clean" abstract interfaces in C; something as simple as;
> quick code scribbling - may have typo:
>
>
> 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.
--
Ian Collins
Juha Nieminen
>> 1) Anything you can do in C, you can do in C++.
>
> 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.
Chris M. Thomasson
"SG" <s.ges...@gmail.com> wrote in message
news:f523aee3-ff9c-4f11...@i76g2000hsf.googlegroups.com...
> On 24 Okt., 21:44, "Chris M. Thomasson" <n...@spam.invalid> wrote:
>> 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.
Jeff Schwab
Do you write code in either of those languages?
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 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.
s0s...@gmail.com
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
blargg
<ian-...@hotmail.com> wrote:
Won't someone think of the compiler writers???
That's a common argument I hear when it is pointed out that one can use
C++ as (almost) straight C, "extreme" C++, or anything inbetween.
James Kanze
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
> James Kanze wrote:
> >> 1) Anything you can do in C, you can do in C++.
> > 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++".
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.
Jeff Schwab
Huh? "Something" != "nothing"; that's not just a different tone, it's
an altogether different meaning.
Paavo Helde
> Maxim Yegorushkin wrote:
>> 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 main difference IMO is that in C one has full control over the language
and does know exactly what code is generated. It is possible to gain the
about the same amount of control in C++, but it takes quite a long learning
curve to achieve. The need of control is always justified by performance
needs (either real or perceived), but I am quite sure that many people just
want to have maximum control as a rule and would prefer to code in
assembler if it was even slightly feasible. This is actually a strong point
in favor of C++, as here one can use or build much more powerful toys for
controlling the application, whereas retaining fine-grained control over
the code where needed.
In practical viewpoint, the main issue in switching from C to C++ is the
const correctness. Binding a temporary to a reference needs 'const' by the
language, and as soon as you bring one const in, it can trigger a avalanche
of needed consts all over the code base, the necessity of which is quite
difficult to explain to a seasoned C hacker.
Paavo
Jeff Schwab
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
> 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
> 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
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).
Yannick Tremblay
Jeff Schwab <je...@schwabcenter.com> wrote:
>
>
>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
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::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
"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
> 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
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
Juha Nieminen
> 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
> [...] 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
> 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
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.
Gerhard Fiedler
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
<MyReallyLongRootNodeName>
<AnEvenLongerConfigurationValueName>
value1
</AnEvenLongerConfigurationValueName>
<AndAnotherStillLongerConfigurationValueName>
value2
</AndAnotherStillLongerConfigurationValueName>
</MyReallyLongRootNodeName>
Neither is required or prohibited by XML. Both are XML (well, there's the
spec line that's missing).
Gerhard
Yannick Tremblay
Jeff Schwab <je...@schwabcenter.com> wrote:
>Yannick Tremblay wrote:
>> In article <jtGdnb4HDdYm7pnU...@giganews.com>,
>> Jeff Schwab <je...@schwabcenter.com> wrote:
>>>
>>> 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
> 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
>> 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
<nos...@thanks.invalid> writes
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
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
tonytech08
> 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.
iMatix OpenAMQ, Apache QPid? Topical discussion on Slashdot a couple
of days ago about Microsoft participation in the binary messaging
technology.
Juha Nieminen
> 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.
Just to show a concrete example, here's an equation as written in LaTeX:
\begin{equation}
x^2+4x+4=0
\end{equation}
The same equation written in MathML:
<mrow>
<mrow>
<msup>
<mi>x</mi>
<mn>2</mn>
</msup>
<mo>+</mo>
<mrow>
<mn>4</mn>
<mo>⁢</mo>
<mi>x</mi>
</mrow>
<mo>+</mo>
<mn>4</mn>
</mrow>
<mo>=</mo>
<mn>0</mn>
</mrow>
Jerry Coffin
says...
> Gerhard Fiedler wrote:
> > 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.
>
> Just to show a concrete example, here's an equation as written in LaTeX:
>
> \begin{equation}
> x^2+4x+4=0
> \end{equation}
>
> The same equation written in MathML:
[ ... elided ]
This really is a problem with MathML, not with XML in general though. If
you wanted to define a LateXML, you could easily allow a equation to
look like:
<equation>
x^2+4x+4=0
</equation>
Of course, if that was _all_ you had for the content in a file, the
overhead of an XML header would be fairly substantial, at least on a
percentage basis. I've yet to see a situation in which that was really
an issue though.
I'd characterize LaTeX as a "programmer's format", whereas MathML is a
"software Engineeer's" format. MathML is the kind of thing you could
implement reasonably well with an army of average intelligence, average
talent, etc., programmers, and still get the job done. Implementing
LaTeX at all well requires fewer programmers, but they need far more
knowledge of the subject matter, and probably better judgement to do the
job well. At the same time, if they do have the judgement and the
knowledge, LaTeX (or something similar) gives them a lot more leeway to
put their talent to use in producing a superior result.
--
Later,
Jerry.
The universe is a figment of its own imagination.
Ian Collins
The verbosity id largely irrelevant, most of the XML I deal with (which
is a lot) is generated by machines to communicate between machines or
generated by humans as source for generating other formats.
XML should not be considered in isolation, but in the context of the
tools that work with it (CSS, DOM, XSLT and friends).
--
Ian Collins
James Kanze
> 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).
So I answered the relevant question, rather than the irrelevant
one you asked.
> The LaTeX equation syntax is *by far* simpler to read and
> write by a human.
The point is that neither are designed to be read by a human;
they are designed to be read my a machine in order to generate
output which is read by a human. And even when writing, you're
using a machine to input and view what you are writing. Whether
one is easier or more difficult to write depends more on the
tool being used to write them than it depends on the format
itself. Potentially (although probably not in practice, at
least not yet), MathML would have the advantage here, because
its tool could leverage off the large amount of other XML tools
around.
Juha Nieminen
>> The LaTeX equation syntax is *by far* simpler to read and
>> write by a human.
>
> The point is that neither are designed to be read by a human;
> they are designed to be read my a machine in order to generate
> output which is read by a human.
That's like saying that the text you just wrote is not designed to be
read by a human but by a machine (for the sole reason that you are
writing it with a machine rather than pen and paper).
Ian Collins
I thought Perl was off topic here :)
--
Ian Collins
James Kanze
Yes and no.
Yes in the sense that what you are reading is NOT what I
actually typed. (I only typed a line break between paragraphs,
for example. My editor ensures that the line with is no more
than 64.)
Yes also in the sense that what I typed resulted in a sequence
of bytes, which you read through a program which renders them as
text on the screen. And what you read depends on that renderer;
if it interprets those bytes as EBCDIC, what I've written will
be pretty unreadable.
No, however, in the more important sense that what you are
reading is a very direct, one to one rendering of the bytes in
the file; each byte (or each character) in the file corresponds
to a single text character rendered on your screen or printer.
This is not the case for LaTeX or MathML or XHTML or other
markup languages. More importantly, with the possible exception
of LaTeX, you wouldn't actually type the character sequence
being transmitted, or even necessarily see it. Even with LaTeX,
I suspect that most people will use something like LyX, and
rarely look at or worry about the actual "program" that they've
written.