B
Ben Pfaff
user923005 said:
But would you deny that C++'s close relationship to C had an
effect on its initial success? My guess is that this is a true
statement, although I'm no scholar of C++ history.
But would you deny that C++'s close relationship to C had an
effect on its initial success? My guess is that this is a true
statement, although I'm no scholar of C++ history.
M
Malcolm McLean
I think the name was a big factor.Ben Pfaff said:
Most people would ignore "C with classes" because they last needed classes
back in high school. However to admit you don't know a language called C++
is to brand yourself a person--. So it caught on.
M
Malcolm McLean
I've just spent the last three days translating a Fortran 77 routine to C.Charlton Wilbur said:
It was a long routine. The C version will probably run slower, but it will
be easier to try out different algorithms to speed it up, and it can take
inputs of arbitrary size. F77 doesn't have a malloc().
M
Malcolm McLean
Is an axe better than a saw? You can use either for a lot of jobs, but most
people would dismiss the question as meaningless.
It is necessary to know an object-oriented language if you wish to be an
adequately skilled programmer. In practise that means either Java or C++.
You should also understand where not to use object-oriented design.
More and more languages are coming out and that is inevitably having an
effect on C's market share. However none look like displacing C as the
default lanauge for serious programming.
To do object-oriented design. Though it is possible to implement object
hierarchies in any language, including C, it is so messy as to be unusable.
If you are asking why do object-oriented design, if you want your program to
be extended by a third party in ways unforseen by you, but without any
changes to your source code, objects offer by far the easiest way to do
this. For instance a space invader may travel a path specified by a "line"
object. A line has certain properties, namely that it has a length, and x, y
coordinates given by a t value. Any object supporting the interface "line"
can be passed to the space invader control, including really odd lines such
as the programmer's name in Arabic.
More controversially, object-oriented desings may be easier to test, debug
and maintain than procedural ones. Personally I am sceptical, but it is
received wisdom.
R
Roland Pibinger
'How close is "as close as possible to C?" Traditionally, it has
almost been possible to equate that statement with "compatible with C
except where the C++ type system would be compromised." '
http://www.research.att.com/~bs/siblings_short.pdf
U
user923005
/*
Where is the C++ tyep system compromised here:
*/
int main(void)
{
int new = 0;
return new;
}
U
user923005
Having read the paper, I agree with it. I think this statement is
telling:
'The "as close as possible ..." rules were crafted under the
assumption that "the other language" was immutable. In reality, it has
not been so: Just look as the number of cross borrowings between C and
C++ [Stroustrup,2002].'
U
user923005
Certainly not. On the other hand, I think that years of "Thinking in
C" made it harder for me to think in terms of objects. On the other,
other hand, I had years of Fortran and PL/I before C, and so my
handicap started further back.
The two languages have some syntatical similarities, but I would argue
that used properly, neither language really resembles the other at
all.
J
J. J. Farrell
I suppose it hinges on what you consider "minor", but please specify
why you consider this claim to be false. It's very rare for programs
to need to call main() recursively, or to care about the type of a
charater constant, for example. The need to cast void * to other
object pointer types is slightly more intrusive, but I'd still
consider it minor. Which are the non-minor exceptions?
A
arnuld
yes that is what *exactly* i meant
thanks "user------"
R
Richard Bos
Syntactically, colourless green ideas sleep furiously. Semantically,
both those sentences are nonsense.
Richard
R
Racaille
Actually, they're pushing (a subset of) C++ for writing
device drivers / kernel modules in OS X.
Search for I/O Kit, etc this may give you some clue.
Thanks god it's not possible to do the same (use C++) in the linux or
freebsd kernel
You are not expected to understand this, either.
D
Dave Vandervies
No. Semantically, "C is a subset of C++" is a perfectly valid and
well-formed claim; the simple fact that it's false doesn't make it
nonsense.
dave
D
Default User
llothar said:
Time for you go.
*plonk*
Brian
U
user923005
Take this tarball:
http://wwwmaster.postgresql.org/download/mirrors-ftp?file=/source/v8.2.3/postgresql-8.2.3.tar.bz2
Which is the PostgreSQL database (written in the C language).
Rename all of the .c files to .cpp and try to compile it.
Basically none of the files will compile.
This also belies the claim that "Good C programs tend to be C++
programs".
U
user923005
Dictionary.com Unabridged (v 1.1) - Cite This Source
non·sense /'n?ns?ns, -s?ns/ Pronunciation Key - Show Spelled
Pronunciation[non-sens, -suhns] Pronunciation Key - Show IPA
Pronunciation
-noun
1. words or language having little or no sense or meaning.
2. conduct, action, etc., that is senseless, foolish, or absurd: to
have tolerated enough nonsense.
3. impudent, insubordinate, or otherwise objectionable behavior: He
doesn't have to take that nonsense from you.
4. something absurd or fatuous: the utter nonsense of such a
suggestion.
5. anything of trifling importance or of little or no use.
6. Genetics. a DNA sequence that does not code for an amino acid and
is not transcribed (distinguished from sense).
[Origin: 1605-15; non- + sense]
-Related forms
non·sen·si·cal /n?n's?ns?k?l/ Pronunciation Key - Show Spelled
Pronunciation[non-sen-si-kuhl] Pronunciation Key - Show IPA
Pronunciation, adjective
non·sen·si·cal·ly, adverb
non·sen·si·cal·ness, non·sen·si·cal·i·ty, noun
-Synonyms 1. twaddle, balderdash, moonshine, absurdity.
Dictionary.com Unabridged (v 1.1)
Based on the Random House Unabridged Dictionary, © Random House, Inc.
2006.
Perhaps meaning 4 is related to the claim.
A document related to this thread that is well worth reading:
"Productivity Analysis of Object-Oriented Software Developed in a
Commercial Environment"
Thomas E. Potok
R
Randy Howard
Feel free to explain how that repudiates the claim which you snipped
about OS X and "specification languages"
J
J. J. Farrell
I don't see how that's relevant to the question. If the minor
exceptions are widely used, there'll obviously be problems compiling.
U
user923005
Many of the problems are related to keywords.
Some of the problems are caused by the new casting rules (the C style
casts are no longer acceptable in certain cases).
There are various other differences pointed out in the document
appearing elsethread from AT&T.
Whatever the reasons are, the code bases have diverged. To me,
language differences are not minor if code cannot even be compiled
without rewriting it.
The changes from C to C++ are more drastic than from Fortran IV to
Fortran95.
I suppose that each and every difference between C and C++ could be
considered minor differences. But if those differences mean that a
major rewrite is necessary to compile, then *I* consider them to be
major differences. I guess by major I was thinking in terms of things
like "It would cost over one million dollars to convert PostgreSQL
from C into C++"
It is true that there is a subset of C that will compile and run as C+
+. But programs in real life are almost never members of that set.
IMO-YMMV.
J
J. J. Farrell
Agreed on all counts - different interpretations of "minor". The list
of differences is small, and each of them is minor. It is possible to
turn valid C code into valid C++ code with a few minor modifications;
that is, it is incredibly unlikely to need any redesign, almost all
the changes would be little more than editorial, and there usually
wouldn't be that many of them. That doesn't mean that C code can be
compiled as C++ code, or that it's a minor job to take a real-world C
program and do the minimal work required to make it a valid C++
program.