Re: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many

On Tue, 2005-06-07 at 19:20, Dave Robillard wrote:
> On Mon, 2005-06-06 at 15:45 -0500, Jan Depner wrote:
> > On Sun, 2005-06-05 at 23:53, Dave Robillard wrote:
> > > On Sun, 2005-05-06 at 05:14 -0500, Jan Depner wrote:
> > > > On Sun, 2005-06-05 at 08:08, fons adriaensen wrote:
> > > >
> > > > > My aproach to C++ is very simple: I use it as 'C with classes'. No streams, no
> > > > > STL, no other nonsense. Gives me the best of both worlds - clean objects and
> > > > > low level.
> > > >
> > > >
> > > > Good answer. I've often wondered why anyone would use vectors.
> > >
> > > Because they dynamically resize, easily, and are generally much simpler
> > > to work with, perhaps? :)
> > >
> >
> > C arrays dynamically resize easily (with realloc), are just as
> > simple to work with, and they're way faster. I'll take efficiency over
> > ease of use in most cases.
>
> - No (optional) bounds checking
>
> - Not even remotely as simple to work with for many things (ie
> vector.push_back(foo), the various inserting & removing functions ...
> Vectors are really much, much more convenient.
>
> - "Way faster" is a bit vague. vector[2] and array[2] will perform the
> exact same operation, assuming you have optimization on
>
>
> "Premature optimization is the root of all evil". Using C arrays and
> strings for no reason when a much more robust higher level type would
> suffice is /just as stupid/ as always using slow high-level operations
> in time critical code.
>
> It's like arguing about, say, assembly vs. perl. Anyone who says one
> side is (always) "better" is automatically wrong. :)
>

    True. I usually try to use the right tool for the job.
Unfortunately, with the data I work with, the right tool is almost
always the fastest tool.

Jan
Received on Wed Jun 8 12:15:05 2005