C++: Is it a powerful language?

[Roberto Dias]

Why is C++ a powerful language? Does it fit for engineering purpose? I
mean, for doing matrices manipulation, numerical computing, solving
equations, and, eventually, for file streaming. Should I migrate
direct for C++, by-passing the C?

Thanks,

[assaarpa]

> Why is C++ a powerful language?

More chores you would manually do in C are handled by the facilities offered
in the C++ language.

Does it fit for engineering purpose?
Yes, it does, here are a few reasons:

- Easier to go with the flow: ready-to-use with a wide range of sourcecode
and libraries
- Reasonably close virtualization of contemporary computer artchitechtures

C++ is also over-engineered and some day more and more programmers will
realize that it is too easy to invoke undefined behaviour with this
language: basicly too much time is spent on realizing bugfree and stable
sourcecode. Read this newsgroup to get the general idea how many things can
go wrong and how much difference there is in opinion how the situation can
be remedied. You'll be amazed.
mean, for doing matrices manipulation, numerical computing, solving
equations, and, eventually, for file streaming. Should I migrate
direct for C++, by-passing the C?

Looks like you might want to take a look at OCaml. ;-) www.ocaml.org , but
if you insist on the C++ you won't go amiss: a lot of real world production
code is written in C++, it's hard to justify saying that C++ wouldn't be one
of the most commonly used programming languages in the world for programming
*desktop* systems. In the embedded land you will find C used much more often
for compiler-technical reasons *cough* ..

But seriously, take a look at OCaml before you commit too much on the C++
ONLY -path.. you will want to learn C++ all the same, there is rarely way
around that.. but when you see a different approach you will be better
prepared to *avoid* C++ when it makes sense (behavioural model in language
where you spend less time playing with implementation *details* and use more
time on problem solving.. then you write the functinal model in C or C++
because that's what you got on commercial systems..) Why would you want to
do that? Because it's a breeze. ;-)

YMMV..

[Jerry Coffin]

[ .. ]

class A {
void foo();
}

gets:
struct A {
void* vtable[];
}

A__foo();
A.vtable[0] = A__foo();

am I wrong??

Yes -- you're comparing apples to oranges. A vtable lookup is needed
ONLY for virtual functions. The C equivalent of a virtual function is
NOT a simple function call. Rather, it's typically implemented with a
pointer to a function or a switch statement.

This is a situation that rarely favors C much, if at all. Calling a
virtual function basically IS calling a function via a pointer. It's
barely possible you'll see a miniscule difference favoring C because a
vtable lookup is an indexed double indirection instead of a single
indirection, but unless you're calling a truly trivial function, the
difference typically gets lost in the noise -- the two are usually
essentially tied, with C possibly winning by a really trivial margin.

With a switch statement things are different. A switch statement will
typically compile to a jump table only if the case values are dense. In
this case, C will typically come close to tying C++, but since C++
typically already has 'this' in a register, it'll often win by a small
margin. If the case values aren't dense, the switch statement will
typically compile to code resembling cascaded if statements, and will
almost always lose, usually by a fairly wide margin.

There are other places that C typically loses by an even wider margin
though. A typical example is sorting. In C, you typically use qsort,
which calls the comparison function via a pointer. In C++ you typically
use std::sort, which is a template that uses a comparison
function/operator without a pointer, and can often even compile the
comparison inline. This can lead to a large difference -- on the order
of 10:1 isn't even particularly rare.

The same can be true in the opposite direction, of course. One obvious
example is character-based I/O. In C, a getchar (for one example) is
often implemented as a macro, so reading a character can involve half a
dozen processor instructions (or so). The equivalent using iostreams
may easily involve two or three function calls (one virtual) per
character.

In the end, the speed of C is probably more uniform -- for example, two
C programmers implementing the same algorithm will typically produce
code that runs quite close to the same speed. C++ varies much more
widely. Two C++ programmers implementing the same algorithm might
easily produce code that differs in speed by 10: or even 20:1.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[assaarpa]

> class A

{
void foo();
}

gets:
struct A
{
void* vtable[];
}
A__foo();
A.vtable[0] = A__foo();

am I wrong??
Yup. The method foo() isn't virtual one, so it does *not* reside in the
vtbl, assuming your compiler implements virtual methods using vtbl (most do
in practise). The real issue in this case is that the "this" pointer is
implicitly passed to the implementation of the method. If your alternative,
C implementation needs a pointer to the context to modify there is no
practical difference as far as performance is concerned except for some
fluke caused by the compiler implementation.

Why would it be necessary? You seem to have a perverted view of what
makes a program fast.

Well, using class functions will result in a vtable lookup for the
function. It's not much time, but it _is_ time. When programming for

Instead of sarcastically asking Oh My God Where You Learned C++ From I want
to point out to the first paragraph of my reply. Basicly you have a
misconception and hope that is now fixed. :)
mobile devices some critical sections can be speed up by leaving this.
Rather not use C++ on mobile devices at all because the compilers SUCK. Look
at what some Symbian implementations use, some retarded and ancient versions
of g++ 1.95.xx series or 2.xx -- if you are lucky, or CodeWarrior..le t's not
say NOKIA.. bad karma. ;) Oh just did... never mind.. but anyway, until the
compiler situation is improved don't hold your breath. While at it, there is
need for Standard Library implementation with much smaller memory footprint
(after linking, oh forgot.. The C++ Standard doesn't know what linking is..
never mind..), well using it on a, say, cellphone is destined to
mediocricity anyway. Good luck with c++ and mobile devies. ;-o
As said: Most time it's not the language that makes a program slow, it's
the programmer.

....

[Thomas Matthews]

Gernot Frisch wrote:

"Victor Bazarov" <v.********@com Acast.net> schrieb im Newsbeitrag
news:rI******** ***********@new sread1.mlpsca01 .us.to.verio.ne t...

Gernot Frisch wrote:

Why is C++ a powerful language?
It's getting compiled to "C"

What are you talking about?

class A
{
void foo();
}

gets:
struct A
{
void* vtable[];
}
A__foo();
A.vtable[0] = A__foo();

am I wrong??

lol. You can write C++ programs, and if speed is a problem, you can
use C functions

Why would it be necessary? You seem to have a perverted view of
what
makes a program fast.

Well, using class functions will result in a vtable lookup for the
function. It's not much time, but it _is_ time. When programming for
mobile devices some critical sections can be speed up by leaving this.
Not nic style, however - avoid wherever possible.
As said: Most time it's not the language that makes a program slow,
it's the programmer.

My understanding was that the "vtable" was only used
when _v_irtual functions were used. Without virtual
functions, there should be no speed difference.

The time for "vtable" lookup should be negligible
compared to other bottlenecks in the system, such
as I/O.

Also, my understanding was that when you want to
speed up a function, you would write that function
in assembly language, rather than C or C++.

And further more, speed optimization should only occur
after the program is profiled (i.e. use a profiler or
logic analyzer or something else to see where the
most time is spent in a program).

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.l earn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library

[assaarpa]

> And further more, speed optimization should only occur

after the program is profiled (i.e. use a profiler or
logic analyzer or something else to see where the
most time is spent in a program).

I always thought that if you need to profile to determine if the program
needs optimization, you don't need to profile. That is, on software mainly
targeted for single-user (desktop) systems.. ;-)

In practise have found out that when something takes far too long time to
process, it is extremely rarely you don't know as the designer where the
time is spent. Rougly generalized, code is fast enough or it isn't. The
problem with this generalization is that the problem is rarely the code, it
can be perfect. It just happens that it is the wrong code for the task.

Example follows. You are building a vector of unique objects where each
object is assigned unique identifier, in this case index. When new object is
added into the vector, trivial approach would be to check every single
object already in the vector. At 100,000 object mark with current mainstream
desktop system the processing time can already be measured in minutes. If
however the appending of new objects is done through a simple hash table or
map suddenly the same case runs in seconds, since this is supposed to be
example case let's say 8 minutes for the brute-force linear search and 3.7
seconds for binary search method for 100,000 objects being indexed.

Profiler will tell what we already know.. that calling the indexing is
really, really slow. Ofcourse, if we build a complete system without ever
compiling and running and doing unit tests and so on, have a complete system
materialized out of thin air and suddenly have to start unwinding it,
profiler might come in handy. Virtually only times I ever had to rely on
profiler (and benefit from it) been situations where I suddenly being to
maintain codebase I am not previously familiar with. Say, if I am one day
given a job of taking a look at particular piece of sourcecode and find ways
of improving it.. I could take stabs looking at the sourcecode and do local
optimizations, but really, to make optimizations that are worth the effort
mean I must be familiar with the design. Apparently it is more pragmatic to
let the profiler to analyze the runtime characteristics and take appropriate
measures, redesign the system if the need and resources are there.

That said:

- I rarely (read: never) needed a profiler to accomplish performance goals
- I witnessed profiler being put into good use more than once (if you want
to be pedantic, twice)
- The C++ Standard doesn't know about profilers at all so who the hell
cares?
- I'm trolling so feel free to announce everyone that you shall promptly
proceed to killfile me :)

VTune, anyone? ;---o

[Victor Bazarov]

assaarpa wrote:

And further more, speed optimization should only occur
after the program is profiled (i.e. use a profiler or
logic analyzer or something else to see where the
most time is spent in a program).

I always thought that if you need to profile to determine if the program
needs optimization, you don't need to profile. That is, on software mainly
targeted for single-user (desktop) systems.. ;-)
[...]

Everything you say here does have merit, but only for a program written by
a single designer/programmer for a single user. As soon as you factor in
a team of each kind, you need to profile whether you think you need it or
not.

[Thomas Matthews]

assaarpa wrote:

And further more, speed optimization should only occur
after the program is profiled (i.e. use a profiler or
logic analyzer or something else to see where the
most time is spent in a program).

I always thought that if you need to profile to determine if the program
needs optimization, you don't need to profile. That is, on software mainly
targeted for single-user (desktop) systems.. ;-)

In practise have found out that when something takes far too long time to
process, it is extremely rarely you don't know as the designer where the
time is spent. Rougly generalized, code is fast enough or it isn't. The
problem with this generalization is that the problem is rarely the code, it
can be perfect. It just happens that it is the wrong code for the task.

[snip]
- I rarely (read: never) needed a profiler to accomplish performance goals
- I witnessed profiler being put into good use more than once (if you want
to be pedantic, twice)
- The C++ Standard doesn't know about profilers at all so who the hell
cares?
- I'm trolling so feel free to announce everyone that you shall promptly
proceed to killfile me :)

VTune, anyone? ;---o

In the embedded systems area, profilers, logic analyzers and
oscilloscopes are frequently used to measure efficiency and
timing of programs. Missed events are caused by the program
being too slow in certain areas. Sometimes, the code is waiting
on a hardware part. Other times, the code is optimized and
hardware assistance is needed, such as in the realm of cryptography.

Profilers have shown me that many bottlenecks aren't where the
design shows them. In multi-person projects, I highly recommend
using a profiler.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.l earn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library

[beliavsky]

Roberto Dias:

Why is C++ a powerful language? Does it fit for engineering purpose? I
mean, for doing matrices manipulation, numerical computing, solving
equations, and, eventually, for file streaming.

C++ is one of the major languages for scientific computing. Especially
for linear algebra and other areas where the main data structures are
arrays, Fortran 95 or Matlab/Octave/Scilab may be easier starting
points.

[Gianni Mariani]

Jerry Coffin wrote:
...

This is a situation that rarely favors C much, if at all. Calling a
virtual function basically IS calling a function via a pointer. It's
barely possible you'll see a miniscule difference favoring C because a
vtable lookup is an indexed double indirection instead of a single
indirection, but unless you're calling a truly trivial function, the
difference typically gets lost in the noise -- the two are usually
essentially tied, with C possibly winning by a really trivial margin.
Your statement is generally correct, however you fail to note that on
some architectures, a function called through a vtable is sometimes
faster that the alternative.

In mips n64 code for example ...

In the end, the speed of C is probably more uniform -- for example, two
C programmers implementing the same algorithm will typically produce
code that runs quite close to the same speed. C++ varies much more
widely. Two C++ programmers implementing the same algorithm might
easily produce code that differs in speed by 10: or even 20:1.

Hey - what do you mean ? I can write bad code in any language .... :-)

[Gernot Frisch]

Thank you for enlightment, sorry for the crap I wrote out of
ignorance.
-Gernot