Re: The bug where terminal and xcode ran "different"
Re: The bug where terminal and xcode ran "different"
- Subject: Re: The bug where terminal and xcode ran "different"
- From: John Daniel <email@hidden>
- Date: Sun, 11 Feb 2007 10:52:40 -0600
On Feb 11, 2007, at 3:48 AM, Rob Probin wrote:
Hi Theodore,
I'm not trying to flame or troll here.
But they are unavoidable when you are writing high performance
stuff, because in these cases
you can't rely on vectors or other easy stuff to "do the right
thing", speedwise.
I thought that the C++ containers had specific dynamics for
specific operations?
They do. In fact, a vector is supposed to be just as efficient as an
array. The vector::iterator family of typedefs is "implementation
defined" so that an optimized library can just use a pointer as an
iterator.
I wonder if anyone knows how good a job the gcc shipping with xcode
does at optimized versions of these?
You may get a flame war on that one. I have no idea. What I've
"heard" is that GCC is "pretty good" and commercial compilers such as
Intel's are "better". But really, that isn't the point behind the C++
standard library. The point is to be able to write your code fairly
quickly and not have to worry about malloc details and pointer
arithmetic. Chances are, it will be plenty fast enough. If not, you
can optimize an already working product. Otherwise, you are in the
world of "premature optimization", which is considered to be a bad
idea by just about everybody.
As far as C++ goes, the general idea is that you are supposed to
write fairly simple, straightforward code (as much as can be done
with the STL) and let the compiler do the optimizations for you. One
particular, counter-intuitive optimization is the return-value
optimization. This is when, if you need to create a new object (such
as a container or matrix), you create it and return the whole thing,
by value, on the stack. Ideally, your return statement should look
like "return Matrix(<whatever>);". C++ is quite good at creating very
efficient code in this case.
Write the C++ code, using real types (albeit "typedef"-ed) and the
compiler will generate pretty efficient code. I ran a test a few
years ago on an older Solaris compiler where such code was only 5-10%
slower than using pointers. Then, if even that isn't good enough, you
can change your typedef to be a pointer type. You will, of course,
have some code to change, but all your core logic will stay the same.
And you can tell vector to reserve space - a very similar technique
to mallocing a large section of memory?
You can. And it is also supposed to be fairly efficient if it does
need to resize. But if you are resizing frequently, a vector isn't
the best choice.
Also, you can always derive your own classes from the standard
libraries if you want and optimize those operations.
Are people using C++ containers for high-performance stuff (on xcode)?
I always have - on Xcode and other compilers. The C++ library in
early ProjectBuilder/Xcode versions was obsolete so I had to use
STLPort. But now I use plain pure GCC in Xcode and it works fine. GDB
doesn't like C++ very much, but that's not Apple's fault.
I have seen very few people who write STL-based templatized code like
I do. I assume they are out there somewhere, but I've met very few.
There are still lots of C people who won't even consider using C++.
In my experience, most C++ people are still stuck in OO design (I say
"stuck" because their code still isn't done :). I wouldn't put too
much effort into evangelizing. If someone wants to use C/malloc/etc.
you probably aren't going to change their mind at this point. After
all, people should use what they like the best. I like C++. Others
like Java. Help 'em if you can, move along otherwise.
John
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden