To answer my own mail, let's just do this whenever using PD_FLOAT_PRECISION:
#ifndef PD_FLOAT_PRECISION #define PD_FLOAT_PRECISION 32 #endif
to make sure code remains compilable against all sorts of Pd. When PD_FLOAT_PRECISION is not defined, it is safe to assume t_float etc are float.
Katja
On Sat, Nov 12, 2011 at 3:30 PM, katja katjavetter@gmail.com wrote:
We now have PD_FLOAT_PRECISION in the Pd-extended API (even though it's value is still fixed at 32) and in Pd-double. This macro is sometimes needed for conditional compilation when making external libs ready for double precision. For example, to call sf_read_float() or sf_read_double() in libsndfile, or in case of a type punning trick which must be defined according to data type.
Libs which use PD_FLOAT_PRECISION for such reason, are no longer compilable against pure-data, libpd, pd-l2ork and other types of pd. This is now the case for creb and smlib, for which I committed double-ready changes this week.
Before I proceed committing to other libs, this issue should discussed with authors and maintainers of pure-data, it's forks, and external libraries. Historically, external libs have always been compilable against Pd flavours other than Pd-extended, no? It would be an awkward experience for anyone unsuspectingly copying a lib's latest revision from pure-data.svn and find it's no longer compatible with Pd other than Pd-extended and Pd-double! Technically, the solution is simple: a line '#define PD_FLOAT_PRECISION 32' in the API's would restore compatibility, when t_float etc. are still typedef'ed as float. It is not so elegant we have to bother many people with our double precision efforts, but it's impossible to develop this in isolation.
Katja