c to c++

[Guest]

So by "C is a semantic subset of C++" you mean "Everything
in C is also in C++ except for those things that aren't."

Gotcha.

For our next exercise, we will prove "All crows are purple
except for those that aren't," and continuing in this way we will
advance human understanding immeasurably, except for the parts
that are measurable.

I just ask you for getting out from your world of perfect logical jokes
and pure mind stimulations, and come for a moment in a practical world
where programming is not a logical and philosophical speculation, but a
tool used to make software. In mathematics a single negative case
against a theorem is enough to drop that thesis. In real life, if
something is true in 98% of cases, nobody, or almost nobody, cares if
there is a 2% of cases in which it's not valid. They're just called
"exceptions". Have I been poorly accurate saying C is a semantic and
syntactic subset of C++ for that 2% of cases? Ok, let's say it's
*almost* a subset of C++, except for a pair of cases, that you can
almost count, where a C++ compiler gets angry while a C compiler says
nothing. And of course I know an implicit cast void* -> char* works for
a C compiler but not for a C++ compiler, and there are cases similar to
this. But I also know in *almost* any other case C is actually a subset
of C++, for the things already said in this thread. I don't really give
a **** that you can mention a pair of cases where this is not true,
because in 98% of cases my sentence remains true. And *almost* nobody
cares pedantic or strictly accurate definitions, or logical and steril
speculation on the nature of a programming language, in the real world
of computing.

--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/CM/CC/E/IT/LS/M d-(--) C++++$ UBL++++$ P++++ L+++++$ E--- W+++ w--
PS+++ PE-- Y++ PGP+++ R++ tv-- b++>+++ D+ G>+++ e++>+++++ h* r++ z+++
------END GEEK CODE BLOCK------

 

[Martin Ambuhl]

I just ask you for getting out from your world of perfect logical jokes
and pure mind stimulations, and come for a moment in a practical world
where programming is not a logical and philosophical speculation, but a
tool used to make software. In mathematics a single negative case
against a theorem is enough to drop that thesis. In real life, if
something is true in 98% of cases, nobody, or almost nobody, cares if
there is a 2% of cases in which it's not valid. They're just called
"exceptions".

Does your employer know of your extremely lax standards? God help
anyone who needs to use any program you have worked on.

 

[J. J. Farrell]

In my opinion it would be clearer if you said that C is almost a subset
of C++, or close to being a subset or something similar. That, I
believe, is what you mean, and it is certainly something I agree with.

Exactly; that's the sort of phraseology the normal man in the street
(who happened to have a clue what subset meant) would use in this
situation. It's correct and unambiguous.

If you know C but know nothing about C++ you can very quickly learn what
you need to know to be able to use a C++ compiler while writing
something very close to normal idiomatic C. I guess the common subset,
plus casting void pointers, would cover most things.

 

[Kenny McCormack]

Does your employer know of your extremely lax standards? God help
anyone who needs to use any program you have worked on.

Marty, you're so funny. Such a little teddy bear.

 

[Richard]

Does your employer know of your extremely lax standards? God help
anyone who needs to use any program you have worked on.

Which part of "real life" confused you? He was talking about general
terminology. He was NOT not talking about his code only working 98% of
the time.

 

[Keith Thompson]

I just ask you for getting out from your world of perfect logical jokes
and pure mind stimulations, and come for a moment in a practical world
where programming is not a logical and philosophical speculation, but a
tool used to make software. In mathematics a single negative case
against a theorem is enough to drop that thesis. In real life, if
something is true in 98% of cases, nobody, or almost nobody, cares if
there is a 2% of cases in which it's not valid. They're just called
"exceptions". Have I been poorly accurate saying C is a semantic and
syntactic subset of C++ for that 2% of cases? Ok, let's say it's
*almost* a subset of C++, except for a pair of cases, that you can
almost count, where a C++ compiler gets angry while a C compiler says
nothing.

And if you had just used the word "almost" from the very beginning,
there would have been no argument.

I suspect (though I have no direct evidence) that *most* well-written
C programs *cannot* be compiled as C++. Most C programs do dynamic
memory allocation. If well-written, most such programs do so by
calling malloc (or calloc, or realloc) and assigning the result to
some variable without a cast.

There may also be a fair number of C programs that use C++ keywords as
identifiers.

Most such programs could be converted to C++ almost trivially (though
of course they'd still have to be tested to make sure nothing was
accidentally broken).

And there are (probably rare, but very real) cases where a program is
valid C and valid C++, but with different semantics.

The question of whether C is a subset of C++ is relevant only if
you're going to try to compile C code with a C++ compiler. If you're
going to do that, and if you care about the correctness and
reliability of the result, you cannot ignore theses issues.

And of course I know an implicit cast void* -> char* works for
a C compiler but not for a C++ compiler, and there are cases similar to
this. But I also know in *almost* any other case C is actually a subset
of C++, for the things already said in this thread. I don't really give
a **** that you can mention a pair of cases where this is not true,
because in 98% of cases my sentence remains true. And *almost* nobody
cares pedantic or strictly accurate definitions, or logical and steril
speculation on the nature of a programming language, in the real world
of computing.

This is not just speculation. Many real-world C programs are not
valid C++ programs, for various reasons.

That kind of imprecision just isn't acceptable in the real world of
computing.

Q: What do you call a program that gives you correct answers 98% of
the time?
A: Wrong.

It's certainly true that C is *almost* a subset of C++. Is it really
such a burden to type those 6 little letters that magically transform
a false statement into a true one?

 

[William Hughes]

I just ask you for getting out from your world of perfect logical jokes
and pure mind stimulations, and come for a moment in a practical world
where programming is not a logical and philosophical speculation, but a
tool used to make software. In mathematics a single negative case
against a theorem is enough to drop that thesis. In real life, if
something is true in 98% of cases, nobody, or almost nobody, cares if
there is a 2% of cases in which it's not valid. They're just called
"exceptions". Have I been poorly accurate saying C is a semantic and
syntactic subset of C++ for that 2% of cases? Ok, let's say it's
*almost* a subset of C++, except for a pair of cases, that you can
almost count, where a C++ compiler gets angry while a C compiler says
nothing. And of course I know an implicit cast void* -> char* works for
a C compiler but not for a C++ compiler, and there are cases similar to
this. But I also know in *almost* any other case C is actually a subset
of C++, for the things already said in this thread. I don't really give
a **** that you can mention a pair of cases where this is not true,
because in 98% of cases my sentence remains true. And *almost* nobody
cares pedantic or strictly accurate definitions, or logical and steril
speculation on the nature of a programming language, in the real world
of computing.

Well, let's try an operational definition. C++ will be said to be a
pratical superset of C if it is trivial to get a large body
of C code to compile with a C++ compiler. Using this definition, C++
is not a practical superset of C. There are enough "exceptions" that
C to C++ translation is rarely done.

- William Hughes

 

[Guest]

I suspect (though I have no direct evidence) that *most* well-written
C programs *cannot* be compiled as C++. Most C programs do dynamic
memory allocation. If well-written, most such programs do so by
calling malloc (or calloc, or realloc) and assigning the result to
some variable without a cast.

But since the first university lesson of programming fundamentals, we
were taught to always make an explicit cast when using malloc, calloc,
realloc, or any function handling void* pointers, just for a matter of
portability and clarity of code. So I don't think a code that makes
implicit casts in those cases is a well-written C code. Or, at least, I
always do an explicit cast when I use any kind of *alloc function. Just
because my fingers won't break if I press a pair of keys more to type
(char*) or (int*) ...

There may also be a fair number of C programs that use C++ keywords as
identifiers.

Most such programs could be converted to C++ almost trivially (though
of course they'd still have to be tested to make sure nothing was
accidentally broken).

That's quite common. I've seen tons of C sources with a

typedef enum { false, true } bool;

and of course a C++ compiler won't like that. But it doesn't strictly
depend on a semantic lack in the language, or because two languages have
a different syntax on some points. That's just a conflict of
identifiers/keywords caused by the programmer.

--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/CM/CC/E/IT/LS/M d-(--) C++++$ UBL++++$ P++++ L+++++$ E--- W+++ w--
PS+++ PE-- Y++ PGP+++ R++ tv-- b++>+++ D+ G>+++ e++>+++++ h* r++ z+++
------END GEEK CODE BLOCK------

 

[Kenny McCormack]

But since the first university lesson of programming fundamentals, we
were taught to always make an explicit cast when using malloc, calloc,
realloc, or any function handling void* pointers, just for a matter of
portability and clarity of code. So I don't think a code that makes
implicit casts in those cases is a well-written C code. Or, at least, I
always do an explicit cast when I use any kind of *alloc function. Just
because my fingers won't break if I press a pair of keys more to type
(char*) or (int*) ...[/QUOTE]

Unfortunately, this is where you've given up your right to ever be a
member of the He-Man CLC Regulars clique. This not casting the return
value of malloc() is gospel around here. The reasons they give to
defend this bit of dogma are, like most bits of religious belief, rooted
more in desire to prove what they already know to be true, than in the
methods of science (which generally takes the opposite tack).

Incidentally, one might take the view that preserving portability to
C++, by going ahead and putting those casts in, is a virtue, not a vice
(as the regs would have you believe). This might very well be more
important that the specious kind of portability that they like to rave
about.

 

[Keith Thompson]

But since the first university lesson of programming fundamentals, we
were taught to always make an explicit cast when using malloc, calloc,
realloc, or any function handling void* pointers, just for a matter of
portability and clarity of code. So I don't think a code that makes
implicit casts in those cases is a well-written C code. Or, at least, I
always do an explicit cast when I use any kind of *alloc function. Just
because my fingers won't break if I press a pair of keys more to type
(char*) or (int*) ...

I suggest that you've been taught incorrectly. We've repeatedly
debated the point at great length here, so I'll just point you to the
comp.lang.c FAQ, <http://www.c-faq.com/>, section 7, particularly
question 7.7b. The cast adds nothing useful, and can (depending on
the compiler) mask a serious error.

Even if you disagree, the fact remains that plenty of smart people
feel fairly strongly that casting the result of malloc is a bad idea.

(A quibble: there's no such thing as an "implicit cast". A cast is an
operator, and can only be explicit. We're talking about implicit
*conversions*.)

That's quite common. I've seen tons of C sources with a

typedef enum { false, true } bool;

and of course a C++ compiler won't like that. But it doesn't strictly
depend on a semantic lack in the language, or because two languages have
a different syntax on some points. That's just a conflict of
identifiers/keywords caused by the programmer.

Keywords are part of the syntax.

But the entire point of this whole discussion is that C is *almost* a
subset of C++. That one word, "almost", makes all the difference.

 

[Ian Collins]

That's quite common. I've seen tons of C sources with a

typedef enum { false, true } bool;

and of course a C++ compiler won't like that. But it doesn't strictly
depend on a semantic lack in the language, or because two languages have
a different syntax on some points. That's just a conflict of
identifiers/keywords caused by the programmer.

How do you explain away VLAs?

 

[Martin Ambuhl]

But since the first university lesson of programming fundamentals, we
were taught to always make an explicit cast when using malloc, calloc,
realloc, or any function handling void* pointers, just for a matter of
portability and clarity of code.

It's unfortunate that you had clueless instructors. It is also
unfortunate that you followed them blindly.

So I don't think a code that makes
implicit casts in those cases is a well-written C code.

Your "thoughts" are unfortunately well off-base.

 

[Richard Bos]

i was wondering whether its worth converting from c to c++?
i'm lazy but if its worth the effort...

If you're lazy, you shouldn't be programming in the first place, no
matter the language.

Richard

 

[jameskuyper]

(e-mail address removed) wrote:
....

against a theorem is enough to drop that thesis. In real life, if
something is true in 98% of cases, nobody, or almost nobody, cares if
there is a 2% of cases in which it's not valid.

In lots of contexts, including many of great practical interest to me,
a 2% exception rate is several orders of magnitude too frequent to be
acceptable.

How would you like to use a shaver that was guaranteed not to
electrocute you, with only a 2% chance of violating that guarantee per
shaving session? In that situation, I'd start growing a beard, if I
had no safer way of shaving available.

... They're just called
"exceptions". Have I been poorly accurate saying C is a semantic and
syntactic subset of C++ for that 2% of cases? Ok, let's say it's
*almost* a subset of C++, except for a pair of cases,

If you think there's only a "pair" of relevant cases, I recommend a
review of Annex C of the C++ standard. In n2723.pdf (a fairly recent
draft of the next version of the C++ standard) it takes about 14 pages
to describe the relevant cases.

 

[Richard Tobin]

If you're lazy, you shouldn't be programming in the first place

On the contrary, almost all human progress is driven by laziness,
and computer programming is a prime example. If you weren't lazy
you'd do it yourself, instead of telling the computer how to do it.

-- Richard

 

[Richard Tobin]

Laziness is one of the three programming virtues, along with
impatience and hubris. (The other three, of course, are impatience,

"Patience", presumably.

diligence, and humility. Cf Larry Wall.)

-- Richard

 

[Kenny McCormack]

(e-mail address removed) wrote:
...

In lots of contexts, including many of great practical interest to me,
a 2% exception rate is several orders of magnitude too frequent to be
acceptable.

Blah, blah, blah.

Welcome to another episode of "Completely missing the point!"

Hints:
1) Blacklight (and most sane people in this thread) are talking about
conversation (between human beings) - and not about computer programs.
Pretending not to understand this raises a stupid red herring.

2) To all those who have been blasting him for not saying "almost", the
fact is, he *DID* say "almost". Maybe not in the original post, but in
a very early followup. Again, pretending not to understand this is just
plain stupid.

3) Whatever we're talking about, the shaver analogy is just plain stupid.
That is one of the regs standard tricks - to make everything so
melodramatic.

 

[user923005]

I mean, C++ recognizes the same syntactic constructs, structures and
operators introduced by C (syntactic subset), and, strictly considering
the meanings that C assignes to them, C++ shares those same meanings
(semantic subset). Now I also know this code

        char *buf = malloc(10);

will be compiled by almost any pure C compiler (in the worst hypothesis
you'll just receive a warning) while a good C++ compiler will give you
an error for an improper cast void* -> char* . But we're not talking in
math and we're not trying to prove a theorem in a rigourus way, so one
or two exceptions against the thesis don't necessarily drop the thesis.

For an amusing experiment, download the PostgreSQL source code base:
http://wwwmaster.postgresql.org/download/mirrors-ftp/source/v8.3.6/postgresql-8.3.6.tar.bz2

then rename all the .c files as .cc and compile them with g++.
You will find that basically none of it compiles, despite the admitted
excellence of the code.

Adding casts to all of the malloc() calls won't help, by the way.

I guess that you have read the subset theory somewhere but have not
actually tried it in practice upon a real code base.

As another amusing exercise, I tried to compile the 485 C routines
from the snippets collection.
I got 0 object modules completed and 9,997 lines of error messages.

 

[Kaz Kylheku]

On the contrary, almost all human progress is driven by laziness,
and computer programming is a prime example. If you weren't lazy
you'd do it yourself, instead of telling the computer how to do it.

That is so overwhelmingly true as a generality. Yet, there are counterexamples,
such as people computerizing manual procedures in ways which make an
organization less efficient, and end up creating more work.

Or using a calculator to do something which overall would have been done faster
if you had reached for a pencil or paper, or done it in your head.

Sometimes we write throwaway programs which are not run enough times to justify
their development effort. You don't always know whether a program you are
embarking on will be like that; hindsight tells you it was a waste of time.

(Unless you impair your hindsight with some plausible-sounding rationalization
which convinces you that it had been a good idea to write that program, so you
can maintain a self-image as a rational being).

 

[CBFalconer]

.... snip ...

I mean, C++ recognizes the same syntactic constructs, structures
and operators introduced by C (syntactic subset), and, strictly
considering the meanings that C assignes to them, C++ shares
those same meanings (semantic subset). Now I also know this code

char *buf = malloc(10);

will be compiled by almost any pure C compiler (in the worst
hypothesis you'll just receive a warning) while a good C++
compiler will give you an error for an improper cast void* ->
char* . But we're not talking in math and we're not trying to
prove a theorem in a rigourus way, so one or two exceptions
against the thesis don't necessarily drop the thesis.

And you have just disproved your own statement. That error occurs
because C++ doesn't assign the same meaning to void* as does C.