Please change all longs to int, and never use them in the future :) They arent needed as on most platforms they are the same size. (which is the assumption made in the ogg code anyway) The reason for this is i will have vorbis support on playstation 2, but long is 64 bits, and they are excruciatingly slow. cheers Brett Paterson --- >8 ---- List archives: xiph.org/archives Ogg project homepage: xiph.org/ogg To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> Please change all longs to int, and never use them in the future :)Pardon me for being blunt, but 'no'. That breaks far more than it fixes.> They arent needed as on most platforms they are the same size. (which is the assumption made in the ogg code anyway)Not true.> The reason for this is i will have vorbis support on playstation 2, but long is 64 bits, and they are excruciatingly slow.On some platforms, int is 16 bits, and this would break the code badly. It's true that my usage of long/int is slightly sloppy (I do use longs in many unneccessary places) but there are just as many places where using int will break things. We'll need to work a bit harder on a solution; the only reliable solution may well be to hardwire more Ogg types in autoconf... Monty --- >8 ---- List archives: xiph.org/archives Ogg project homepage: xiph.org/ogg To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
>Please change all longs to int, and never use them in the future :) >They arent needed as on most platforms they are the same size. (which is >the assumption made in the ogg code anyway) >The reason for this is i will have vorbis support on playstation 2, but >long is 64 bits, and they are excruciatingly slow.Why not typedef something like UInt32/SInt32 so you get exactly what you want on any platform? For Playstation 2, you can use typedef int SInt32 and other platforms with 32-bit longs, it can be typedef long SInt32. The same goes for char, short, and long long (SInt8, SInt16, and SInt64 respectively). An even better solution in some cases is to use purposefully named types (e.g. VorbisByteCount) as those types don't imply size and can grow as needed. Personally, I think it's better to never use native C data types directly as their size is not constant. The problem you ran into is a good example of why typedefs should be used instead. --- >8 ---- List archives: xiph.org/archives Ogg project homepage: xiph.org/ogg To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
>Then you shoot yourself in the foot on any platform where that size is not >most >efficient. What I was thinking was a type that meant 'equal to or greater >than >word width n'. Ogg doesn;t need 32 bits for long, it need *at least* 32 >bits. >This is a subtle difference from your suggestion, but an extremely important >one. > >C is the way it is for a reason, even if the decided upon spec turned out >to be >'not entirely sufficient'. Forcing an Alpha to use 32 bit ints, for example, >is a good way to kill integer performace (as Windows NT for Alpha partially >demostrates).I agree. Using the native integer size via a typedef that is documented as providing at least the necessary size (but possibly more) would seem to provide a good solution for both compatibility and performance. --- >8 ---- List archives: xiph.org/archives Ogg project homepage: xiph.org/ogg To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Taral <taral@taral.net> writes:> On 11 Sep, Monty wrote: > >> Personally, I think it's better to never use native C data types directly > >> as their size is not constant. The problem you ran into is a good example > >> of why typedefs should be used instead. > > C is the way it is for a reason, even if the decided upon spec > > turned out to be 'not entirely sufficient'. Forcing an Alpha to > > use 32 bit ints, for example, is a good way to kill integer > > performace (as Windows NT for Alpha partially demostrates). > How about using int_min32 or something that guarantees a type which has > 32 bits or more and is efficient on the platform?In C99 <stdint.h>, there's a data type called int_fast32_t. It's defined as the fastest integer data type with at least 32 bits of precision. (No, <stdint.h> isn't available on all platforms, but maybe new typedefs could be modelled after it.) --- >8 ---- List archives: xiph.org/archives Ogg project homepage: xiph.org/ogg To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.