[PD-dev] per-thread storage in Pd in support of pdlib - discussion?

[IOhannes m zmoelnig]

-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8yLWIACgkQkX2Xpv6ydvQ0WQCfZhPu9t9QQkH9JpNxBBAXTIj/
WZgAn0B+LDuech7oIf4DUw8Ktt1R7Gif
=n9ct
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20120208/833b13df/attachment.bin>