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,

 

[Ron Natalie]

Why is C++ a powerful language?
Yes.

Does it fit for engineering purpose? I
mean, for doing matrices manipulation, numerical computing, solving
equations,

You'll need a good math library, the standard libraries for C and C++
are notably lacking in rigorous numerical functions (like matrices,
etc..) but there are some out there.

eventually, for file streaming.

This sort of operatal application is what C and C++ excel at.

Should I migrate
direct for C++, by-passing the C?

If you're working on an implementation that has a good C++ compiler]
existant (and most "general purpose" processosrs do), I would say yes.
There's no real advantage of C and a lot of strong reasons to do C++.
The performance is going to be the same, but the code will be easier
and more maintainable in C++.

The only argument for C is for certain embedded implementations where
only a minimal C implentation is practica.

 

[Victor Bazarov]

Why is C++ a powerful language?

Because it was designed as such.

Does it fit for engineering purpose?

It does. Or, rather, it is. Whatever.

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?

I don't know if you should _migrate_ (from where?), but if you do migrate,
you do not need to study C as a pre-requisite. Knowing the differences
between them helps, and knowing C as a language can be useful sometimes,
but you can definitely pick that all up along the migration path.

V

 

[Gernot Frisch]

Why is C++ a powerful language?

It's getting compiled to "C" and not much is getting added. (Pointers
to functions of structures, which are classes in C++ ...)

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?

lol. You can write C++ programs, and if speed is a problem, you can
use C functions in your classes like:

// esternal "C" compiling of this function
extern"C"
{
DoExternFastMath()
{}
}

// C++ class wrapper that calls a fast function
class A
{

inline DoSomeFastMath()
{
DoExternFastMath();
}
}

You can write crappy C++ code, you can do this in C, in FORTRAN and in
ASM.
If you need samples about slow and buggy, code, let me know. I've got
lot's if it

-Gernot

 

[Victor Bazarov]

It's getting compiled to "C"

What are you talking about?

and not much is getting added. (Pointers
to functions of structures, which are classes in C++ ...)




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.

[...]

 

[Gernot Frisch]

I don't know if you should _migrate_ (from where?), but if you do

migrate,
you do not need to study C as a pre-requisite. Knowing the
differences
between them helps, and knowing C as a language can be useful
sometimes,
but you can definitely pick that all up along the migration path.

Indeed, I read the book "Teach yourself "C" in 21 days" (in 5 days)
and there was a small topic about C++ in the end. So, I wrote "C++"
like:
for (int i; ...)
and
class A
{
public:
void foo();
}

until I got a job, doing C++ programming. Where suddenly I had to
reqrite a template list container. It looked so cryptic to me back
then...
If I can give one advice: Start C++ by learning C++. Noothing more,
nothing less. Every other thing you learn dueing your learning process
will spoil your code-style and result in curses when maintaining old
code.

Just my 0.02$,
Gernot

 

[Gernot Frisch]

What are you talking about?

class A
{
void foo();
}

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

am I wrong??

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.

 

[Victor Bazarov]

What are you talking about?

class A
{
void foo();
} ;

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

am I wrong??

Hell, yes. What vtable? In fact, in most cases there would be no 'foo'
because the function can never be called -- it's private and the class
has no other members or friends. So, there will be no function _at_all_.

Well, using class functions will result in a vtable lookup for the
function.

No, it won't. I guess it's back to textbooks for you. Or just compile
your program to get an ASM output and analyse it.

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.

<shrug>

 

[Karl Heinz Buchegger]

What are you talking about?

class A
{
void foo();
}

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

am I wrong??

Yes and no.
It could be that way, it need not be that way.
Actually: Nowhere it is written down, that C++ *has to be compiled* to C.
It can be done, it has been done, but most compilers actually don't do it.

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

Only in the case of polymorphism (if I assume at the moment that the
compiler is indeed using a vtable for virtual functions). Ordinary
function calls are resolved the same way as C functions would.

But in case of virtual functions: Well, you don't make functions
virtual just for fun. There is a reason for it. And the reason is
polymorphism. Now if you try to implement polymorphism in C (that
is without virtual functions) you end up with something either
very similar to what the C++ compiler does or with something that
is
a) harder to maintain
b) slower then what the C++ compiler can do.

So in case of ordinary function calls there is no difference to C.
In case of polymorphic function calls, C++ can do better then an
average C programmer does. At best C++ and C are on an equal scale,
but C++ is never slower then C.

 

[Mike Wahler]

What are you talking about?

class A
{
void foo();
}

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

am I wrong??

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.

Oh, my goodness. Which C++ books have you been reading?
You have some serious misconceptions. I suggest a visit
to www.accu.org and a perusal of the book reviews, followed
by selection and study of one or more of the recommended
books.

-Mike

 

[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.

 

[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.

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..let'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]

What are you talking about?

class A
{
void foo();
}

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

am I wrong??

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.learn.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]

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]

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.learn.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