Why C++ is vastly superior to C

[MikeP]

"OMG", Leigh is back? Hi Leigh. How did that affair with you and Paul
work out?

 

[MikeP]

You were on my "blocked senders" list because I couldn't take anymore of
your .... nevermind. You are back online in this world. Get help with
your ultra-low-level-of-nothingness-<whatever>.

(See, I'm not good with "people-issues". ). Right?

 

[MikeP]

However, it illustrates that one often is willing to sacrifice some
efficiency in order to have simple, general, easy to follow rules.

It may be that the quality of the code as a whole improves by having
simple rules, even though that means non-optimal code for some
special cases.

"HELLO". "Teachers" do not really know how to teach anything. You can say
one thing like that to someone who is a sponge for the information, and
it is KEY. I've noted other times that your practicality is such as my
own (or something like that). (No, I don't want to "date you", bitch).
LOL! I'm open to COMPLEMENTARY association (lawyers (not "language
lawyers", but those may be solicited and used (not RAPED, been there/done
that) precisely), sales people (I will tell you what to sell and how and
NO, you WILL NOT "own" MY customers), ... blah, blah... it's my
"LinkedIn" profile I just posted here!

 

[MikeP]

The class in question is something that might be found in a library.
Every library writer I know is willing to learn some more of the ins
and outs to improve their library. If the library author does his job
well, users don't have to be aware of the complexities of the library.

Hey "Scrooge", I suggest that what you quoted resembles MASTURBATION to a
"high degree". (I am facetious. Or am I?).

 

[MikeP]

Le 25/05/11 12:15, Rui Maciel a écrit :

Yes, you are right in principle. It is conceivable that a huge
program uses only a small fraction of its executable foot print
and all of it fits in the cache.

This a programming NG. Show me the 'cache' keyword or whatever. There is
no "cache". What part of "ankh" don't you understand? There is no
"cache"!

 

[glen stark]

Premature optimisation means performing "optimisations" before you have
sufficient knowledge to determine what is actually optimal.

I get really tired of how this quote is abused (I'm not accusing you of
abusing it, I'm speaking generally).

When Knuth wrote that, he was writing in the context of of algorithms.
His point was it's important to analyze and optimize your algorithms and
logic before mucking around with the fiddly-bits. In other words, what
optimization is premature is a matter of good judgment.

His statement does *not* mean that you should neglect performance until
you have a working prototype you can profile, which is unfortunately the
context in which I most often see it quoted. He was being intentionally
hyperbolic, in order to point out the fact that you can purchase just as
much inefficiency by overthinking performance at too early a stage, as you
would if you neglect it completely.

Finding the right priority to assign performance during your design and
initial coding decisions is a judgement call. It depends on the needs of
your application and the hardware that you're working with. Developing
good judgment in that (and most) regards requires introspection, self-
evaluation, and constant learning. Oversimplifications and dogmatism will
prevent self-improvement, and thus prevent developing good judgement.

I can't find the reference anymore, but I recall reading an essay from
Knuth where he laments how much that quote is misused and misunderstood.
If anyone knows the reference, please pass it on.

 

[gwowen]

I get really tired of how this quote is abused (I'm not accusing you of
abusing it, I'm speaking generally).

When Knuth wrote that, he was writing in the context of of algorithms.  

"Programmers waste enormous amounts of time thinking about, or
worrying about, the speed of noncritical parts of their programs, and
these attempts at efficiency actually have a strong negative impact
when debugging and maintenance are considered. We should forget about
small efficiencies, say about 97% of the time: premature optimization
is the root of all evil. Yet we should not pass up our opportunities
in that critical 3%." -- Structured Programming With Goto Statements
- http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf

He's *evidently* and *clearly* talking about programs, and evidently
saying "do not sacrifice code clarity for speed, unless the speed-up
actually matters. He wasn't talking about algorithms - the paper from
which the quote comes is about using 'goto' in structured programs -
something that is essentially algorithm agnostic.

Your intepretation is incorrect.

 

[Virchanza]

Why C++ is vastly superior to C:
     http://warp.povusers.org/programming/cplusplus_superior_to_c.html

"In conclusion, the reason why C is so vastly inferior to C++ as
described in this article can be summarized with one single sentence:
C has no support for RAII nor templates, while C++ does. That's two
of the most important features that make C++ by far the superior
language."

Lynn

The functionality of C++ is a superset of the functionality of C.
So of course C++ has more features and functionality. Even if you have
a preference for "C style programming", you can always choose to use a
C++ compiler to compiler your code without using any of the C++-
specific features such as templates and classes.

So what use is C nowadays? The answer is that the standard for C
is much simpler than C++ and so it takes far less man-hours to produce
a C compiler for any given platform. I've programmed microcontrollers
in C, purely because there was no C++ compiler available (PIC
microcontrollers). C is far more prevalent than C++ in the land of
microcontrollers.

 

[Balog Pal]

So what use is C nowadays? The answer is that the standard for C
is much simpler than C++ and so it takes far less man-hours to produce
a C compiler for any given platform. I've programmed microcontrollers
in C, purely because there was no C++ compiler available (PIC
microcontrollers). C is far more prevalent than C++ in the land of
microcontrollers.

For the record, IAR has C++ for PIC stuff. But it is expensive like hell, so
in practice you're really stuck with C.

 

[Juha Nieminen]

C is far more prevalent than C++ in the land of microcontrollers.

That's probably completely true, but prevalence doesn't say anything
about quality.

 

[BGB]

The functionality of C++ is a superset of the functionality of C.
So of course C++ has more features and functionality. Even if you have
a preference for "C style programming", you can always choose to use a
C++ compiler to compiler your code without using any of the C++-
specific features such as templates and classes.

So what use is C nowadays? The answer is that the standard for C
is much simpler than C++ and so it takes far less man-hours to produce
a C compiler for any given platform. I've programmed microcontrollers
in C, purely because there was no C++ compiler available (PIC
microcontrollers). C is far more prevalent than C++ in the land of
microcontrollers.

well, and it is also easier to write tools to process ones' C code and
generate reflection metadata or similar, but retrofitting these tools to
support C++ would be a non-trivial task...

also useful for metaprogramming and reflective code generation (where
tools write tasks to accomplish certain tasks based on code that is
already there).

this can also be useful when combined with run-time code generation, or
with self-modifying programs, or when implementing VMs for other
languages which need to be able to interface with ones' natively
compiled code.


so, having a technically simpler language may outweigh some of the gains
of being able to write code in it a little easier. even then, C is still
a fairly complex language, but some of us don't uphold simplicity as a
gold standard either, as "simple" languages (for example: Forth,
Smalltalk, Lisp and Scheme, ...) have generally failed to gain
widespread adoption (or be ideally suited to many real-world programming
tasks).


or such...