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 20:23:46 -0600
On Feb 11, 2007, at 11:41 AM, Theodore H. Smith wrote:
That's interesting. But the only thing that will convince me is a
test :) Running on my computer.
I'm not sure any test will be all that conclusive. I have seen
instances where C++ was faster than C, and vice versa. At one time, I
couldn't stand the STL. It wouldn't compile, and if it did, I
couldn't debug it. But everyone (the Meyers, Stroustrups, and
Josuttis's of the world) kept saying I should use it. I tried it
again on a very large, very difficult refactoring project. This was
code that had to handle millions of data points, not leak memory, and
not tombstone the machine. I was able to manage very complex data
structures with the STL. I would compile it, and it would just work.
I was sold. And this was with VC++ 5.0 no less.
I'm not so certain. I tend to avoid return by value in C++ because C
++ has really broken good OOP here. I prefer to create my objects
on the stack and then fill my matrixes (or whatever it is) in a
different function. RBV is OK for certain types like numbers or
strings...
For some of us "good OOP" is a contradiction in terms:) Even though I
use a smiley face there, I'm not really joking. For most of my
career, I've worked for huge companies with literally unlimited
resources - and they couldn't get OOP to work well. I like to tell
people I work in 100% C++, but never use the keywords "new" or
"virtual". That's an exaggeration, of course, but on my own code, I
have to justify the use of "new" or "virtual". OO is OK only in
moderation.
For the most part I'll be using stl classes. But what about for
when you want to write the highest performance stuff? For example,
can I assume that a vector stores it's data linearly in RAM? if so,
I could use the vector to allocate the memory, and then just access
it with a pointer. The best of both I'd say! Either that or make a
class which does exactly the same thing.
Then a vector should be exactly what you want. But the really great
thing about C++ is that, if you write templatized code and work with
iterators instead of containers, then if you need to port your code
to an environment where you have to use a deque or a list, it will be
very easy to modify. You don't always know what the end result will
look like. C++/STL encourages you to write "generic" code. Changing
fundamental data structures in C++ is no big deal.
If you want to really learn how to use the STL, I always recommend
"The C++ Standard Library - A Tutorial and Reference" by Nicolai
Josuttis.
Now that I think about it, I think that idea might be a bit silly.
Maybe an idea to use STL even within high performance code? I
suppose STL should be available everywhere Iw ant to go these days
right?
It should be, but it isn't. Plus, STL knowledge isn't all that
common. While it is great fun to evangelize, you don't want to write
code that no one else you work with can understand.
I'm writing some fuzzy search algorithm, it can do spell check and
a lot more than that because it's as general as Smith-Waterman.
I've already made one that does levensthtein-like searches across
database, a few years ago. Now I want to upgrade the algorithm to
do Smith-Waterman-like searches across a database. I want to squeek
out every last drop of CPU here. So doing my reading and writing to
the RAM, using pointers is a MUST.
It uses 2D arrays, and data consequtiveness is also a must. I can't
have my data scattered all over the RAM, that will kill caching.
Such considerations are much easier to manage when I do my own
pointer arithmetic, unfortunately. Unless I can get a class whose
implementation is guaranteed to work as I wanted it. But that's
probably not STL, and definitely NOT making a vector of vectors.
For this case I really think pointer math is the way to go. Also,
with the huge number of variables my code is using, using pointer
math helps keep stuff in the registers by reducing variable count.
But the details of how my RAM is allocated and managed, I don't
really care about as long as it's neat.
If there is one thing the STL isn't, is easy to learn. It certainly
isn't a good idea to jump in with a large project. It is something
you have to work up to. But you can use vectors to manage your memory
for you. You can also use all of the STL algorithms. They are all
designed to work on iterators and iterators are designed to work like
pointers. If an STL algorithm asks for an "iterator" template, you
can almost always pass a pointer and it will work. Those might be two
good places to start.
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