8 Jun
2005
8 Jun
'05
10:08 a.m.
On Wed, Jun 08, 2005 at 07:19:56AM -0400, Paul Davis wrote:
the nice thing about a
design pattern like STL containers is that you can toggle back and
forth between any all of them with almost no work. i can't count how
many times in ardour i have changed:
typedef vector<Foo> Foos;
to
typedef list<Foo> Foos;
or some other STL container. 95% of the time, thats the only change in
the code i have to make.
Valid point, there are occasions where you can do this sort of thing.
But when we are talking about large data sets and heavy use, it could
lead to some nasty surprises. For small data sets, it doesn't matter
much.
if you really know and understand all the
parameters of the software design up front, this isn't useful, but i
haven't written a single piece of software where this claim was true :)
Don't tell me you've been switching ardour's audio buffers between vectors
and lists ... :-)
b) (repeat) i have no doubt that there are many areas
where ardour
(for example) contains code much, much slower than the equivalent in
SAWstudio, which is written in 90%+ assembler. however, on a project
whose development alone takes many years and has seen a 7-9 fold speed
up in processor speeds, i would rather concentrate on algorithmic
design (for example, avoiding silly arbitrary limits, ensuring maximal
flexibility even if its not intended to be exposed to the user
etc). i'll leave "making things as fast as possible" to intel, AMD and
the gcc team.
Again, valid point. But algorithmic design IMHO includes the selection
of the right data structures and interfaces in function of the required
data / time complexity.
As to assembler, I've no problem with it per se - you can write well
structured object oriented code even in assembly. I think it's use is
warranted in two cases:
- It makes a significant difference in speed, and this is important,
- The algorithm can be expressed more clearly or easily in assembler
than in any high level language. [1]
In both cases, we're probably talking about small routines anyway.
[1] This includes the case where you can't write it in C at all. For
example we're using here a very small RT 'nanokernel' running on the
ARM for our embedded applications. It's less than 100 statements, and
none of it could ever be written in C. Yet the API is entirely made
up of C++ classes (threads, message boxes, semaphores,...) and there
is virtually nothing in between the two.
--
FA