AudioMatt

Noob here so this is going to sound brutally stupid but I have to ask. So much of the documentation is dedicated to things with descriptions:

This struct is provided for debugging convenience, but should be considered opaque and is subject to change without notice.

Does this really mean I should never ever use these things in a final project and instead provide my own atom arrays, linked lists, hashmaps etc? I don't really get why you'd document them so well and then tell me not to use them... and it would save me a ton of time.

I spent 5 hours yesterday writing some code to parse text into atoms... that.. was... annoying.

Sorry, I'm just starting out. plenty more idiotic questions to come.

Noob here so this is going to sound brutally stupid but I have to ask.  So much of the documentation is dedicated to things with descriptions:

This struct is provided for debugging convenience, but should be considered opaque and is subject to change without notice. 

Does this really mean I should never ever use these things in a final project and instead provide my own atom arrays, linked lists, hashmaps etc?  I don't really get why you'd document them so well and then tell me not to use them... and it would save me a ton of time.

Sorry, I'm just starting out.  plenty more idiotic questions to come.
-matt


dumbest-c-question-ever

It's perfectly ok to use atomarrays etc., as long as you don't access directly the structure fields. What the doc is telling you is that at some point the data structure might change: so if you want your code to remain valid with future releases of Max and the SDK you should only access the structure through the provided functions. So, for example, you should not traverse a t_linklist by directly surfing its elements through their next and prev fields, but you can safely do it through linklist_next(), linklist_prev(), linklist_funall & co.

Actually the SDK might as well not give you the structure fields, but the c74 guys chose to make them visible (thanks buddies!) in order to make debugging easier - this is what the "debugging convenience" thing means.

This is what I was hoping. basically they're treating them like objects in that the getters/setters stay the same but the internal structure can be updated.

Andrea,
This is what I was hoping.  basically they're treating them like objects in that the getters/setters stay the same but the internal structure can be updated.  

Dumbest C Question Ever.