Le 2012-02-08 à 09:08:00, IOhannes m zmoelnig a écrit :
another reason is, that with accessor-functions you can more easily stay binary compatible both backward and forward than with directly accessing the struct.
Depends what you think can be changing in the future...
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)
ok... then why not accessors, then. fine.
Has anyone made a list of all (current) globals yet ?
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.
C++ reserved keywords are easy to deal with. They're easy to search-and-replace, or #define away. Some other things are a bit more work, but that's quite tiny compared to most other cases of «translating» between very similar programming languages.
In the eighties, people spent a LOT more time porting software from one version of Microsoft BASIC to another version of Microsoft BASIC that was incompatible simply because it was on a different computer brand.
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.
Well, a good reason to «object» to that is simply that C++11 implementations are not ready for use, and even if they were, they'd be so new that they wouldn't be bundled with Ubuntu, Debian, Fink, MinGW nor XCode.
Apart from the fact that this feature will not really cure the problem and will create new ones.
______________________________________________________________________ | Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC