Re: C++ is slow

From: Alf P. Steinbach (alfps_at_start.no)
Date: 03/06/04 

Date: Sat, 06 Mar 2004 01:17:00 GMT

* Julie <julie@aol.com> schriebt:
> Mike Wahler wrote:
> >
> > "Charles Herman" <cherman@no.spam> wrote in message
> > news:PO62c.120645$Xp.533671@attbi_s54...
> > > I have the following two programs:
> > >
> > > PROG I
> > > void main()
> >
> > int main()
> >
> > If you use anything else besides 'int' return type
> > for main, you have *no* guarantees about the behavior of
> > your program.
> >
> > > {
> > > int *v = new int[NUM];
> > > for (int i = 0; i < NUM; ++i)
> > > v[i] = i;
> >
> > You have a memory leak. You need to free the memory
> > you allocate.
> >
> > > }
> > >
> > > PROG II
> > > class rvector
> > > {
> > > private:
> > > int* vals;
> > > size_t vsize;
> > >
> > > public:
> > > explicit rvector( size_t vSize ) { vals = new int[vsize]; }
> > > ~rvector() { delete [] vals; }
> > >
> > > int& operator[] (size_t idx ) { return vals[idx]; }
> > > };
> > >
> > > void main()
> >
> > And again.
> >
> > > {
> > > rvector v(NUM);
> > > for (i = 0; i < NUM; ++i)
> > > v[i] = i;
> > > }
> > >
> > > I left out some non-germane lines, eg, defining NUM and including header
> > > files.
> >
> > You should always strive to post *compilable* code if at all
> > possible. Then we needn't guess at the rest, which is often
> > the cause of a stated problem.
> >
> > >
> > > I compiled and ran these programs using VC++ 6.0. The second program
> > > required approx 6 times as much time to run as the first. What is
> > happening
> > > in program II that takes so much time?
> >
> > The C++ language is a set of specifications, an abstraction.
> > I has no 'speed', slow or fast. Apparently you find a particular
> > *implementation* of C++, (VC++6.0) "too slow".
> >
> > Recommended actions:
> >
> > Read your documentation to ensure you're using the product correctly,
> > and find it's various 'modes' of operation.
> >
> > If VC++ is deemed unacceptable, use something else.
> >
> > -Mike
>
> Crap. You answered anything but the OP's question.

I think Mike can handle those expletives but.

He did answer all of the OP's questions, pluss pointed out the main flaws
in the code.

To reiterate, whatever happens in the second program that does not happen
in the first is not a language issue, but a question of what the author and
the C++ implementation puts in there (or rather, fails to optimize away).

And Mike pointed that you should always

   first get the code _correct_.

If it doesn't need to be correct then I can show you a program that solves
the traveling salesman problem in 1 microsecond regardless of problem size.

 
> void main, memory leaks, using different compilers, and diatribes about speed
> in the standard don't do a thing for the OP and their perceived differences in
> speed.

Possibly the answers do not enlighten you.

But see above.

If that does not help, then you need to study harder.

> I think that Leor was the only one to infer as to the *real* problem here. I
> didn't see the problem until he pointed it out.

Leor pointed out (and only pointed out) that you should always

   first get the code _correct_.

Which Mike had already done.

It's difficult for me to see how Leor's answer could be perceived as any
"better" than Mike's much more comprehensive answer, but in spite of the
difficulties I think I've found an explanation: a large number of people
just want a cookbook recipe of WHAT TO DO to make something work for them,
immediately, disregarding what problems that might lead to for others.

 
> Let's remember that this isn't
> comp.lang.c++.lets.run.off.the.newbies.as.fast.as.possible.

It's got little to do with newbie status. Like "fourteen" is a state
of mind, not a physical age. 

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Relevant Pages