By inbuilt, I mean those provided with the SDK....

i'm not a pro there, but i guess if they are inbuilt that's for a reason... it might be useful in cases of special operations, like pattr saving etc.

Cheers Nicolas... you seem to be answering all my questions :) You should write an FAQ ;)

JUCE does indeed look interesting!

Hi there,

if you are writing your external from scratch and you intend to use it only in Max/MSP I strongly recommend you use the built-in data structures for several reasons: 1 - Thread safety 2 - They are optimized for the Max message passing signature(t_symbol *sym, long argc, t_atom *argv) 3 - Some of them (i.e. t_hashtab) are able to send notifications as elements are added and deleted. 4 - You never have to worry about those data structures not being compatible with future versions of Max/MSP. 5 - I suspect that under the hood of the built-in data structures the C74 team takes care of other subtle issues specific to the Max/MSP environment.

Of course - as Nicolas pointed out - if your situation is such that you need to reuse your code in other environments or you are porting to Max/MSP code based on data structures from different libraries (STL, Boost, Juce, etc...) then you can't use the built-ins and the choice is really a no-brainer.

Personally, all the externals I write do use the built-in data structures. Never had a problem, and the fact that they are closed source was never an impediment for proper debugging. In the vast majority of cases I think it's a design mistake not to use the built-in data structures if you have the choice to do so.

My 2 cents...

- Luigi

The Max API data structures are also convenient if you're using plain-vanilla C, which the SDK is actually designed for.

They are possibly also more efficient than the C++ ersatz things, being more special-purpose designed for Max atoms and stuff like that. But that's only a wild guess (and probably partly based on my disillusionment with the C++ claim to be the best thing since sliced toast).