[vorbis-dev] vorbisfile close and memory callbacks

[Monty]

> This is just wrong, it's not extensive work (far less than the double to
> float changeover :)

...which was absolutely necessary to alleviate pressure on the data cache, not 
just an interface nicety.  And I'm still, a month later, dealing with 
occasional fallout from that change.  Double->float took two hours.  Repairing 
two vital encode algorithms to not choke on the reduced resolution took 
another month.  I've still not cleaned up all the compiler warnings.

But yes, I realize this is probably not a great example.

>  and if i, as a third party library (say i write a
> little audio lib for developer teams to use) override mallc/free, then i
> also override the applications malloc and free that my lib is used in.  When
> writing a library like this it has to be as extensible as possible..

...and you have to draw the extensibility line somewhere because the scale is
continuous between the extremes.  *What do you really want to do*?  Do you want
auditing ability?  Allocation control?  Forgive me, but I don't make changes
based simply on 'trust me: do this' unless the change is obvious to me too.
You understand intimately where you're coming from.  I do not.  A couple
concrete examples could easily change my mind.

> when a stdlib uses resources (like files and memory, there is nothing else)
> developers do want control over it (as the file stuff so far), no other
> stdlib functionality really has this problem.

(Note that I've never had a request for repluggable malloc hooks before, so 
I'm wary of 'like files and memory, there is nothing else'.  Yes, files is a 
constant request.)

Vorbisfile is a bit different as it's actually a large chunk of example code 
that was turned into a library, and the FILE* issue is common to a wide array 
of applications (indeed, I used FILE* only because it's ANSI where 
open/read/write are not, and vorbisfile was an example program).

It is also the case that ogg/vorbis/etc are reference implementations.  They 
are intended to be very solid, reasonably clear, and easy to maintain.  
They're not intended to be everthing to everyone; simply most things to most 
people.

> as i said previously, its an absolute must on console developement .. you do
> want EA's support dont you? :)

I want EA's support and I know you were mostly kidding, but I don't like an 
offer of support as above being used like a threat.  My development resources 
are limited, and I'm trying to serve as many people as I can.

Monty

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.