-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-02-08 00:36, Mathieu Bouchard wrote:
I mean that this context could be accessed directly if there's no reason to use accessors. But if locking has to be done before and after accessing (some of) those members, then it's nice to have a shortcut.
another reason is, that with accessor-functions you can more easily stay binary compatible both backward and forward than with directly accessing the struct. sure you can do something like that with structs as well (typecast to different structs depending on the version of the Pd-host), but with accessors it comes for free (well, at least backwards compatibility)
this will obviously break API compatibility... a possible workaround would be to add a new function "t_pdcontext*make_current(t_pdcontext*)" that would change the running
how many of these variables are there ? That could be a lot of variables to be swapped around.
right, peter already convinced me, that having a single legacy context that is used directly is more appropriate.
e.g. c++11 (c++? ever tried to compile Pd with a c++ compiler?)
I did. I don't recall significant difficulties... it might have been
i guess i was exaggerating the use of C++ reserved keywords as variable names and the like. sure, this is easy to fix. but the original suggestion sounded to me like: 'a solution for all our problems is to switch to new C++ features in a "CC=g++ -fdo-what-i-want" manner', and i wanted to object to that.
fgamsdr IOhannes