Are there any data structures like hash set,btree or so forth implemented with monkeyc?

Unfortunately, no.

I agree that it would sometimes be handy to have more containers to choose from, but implementing them in MonkeyC is probably not a great idea. Even a simple linked-list implementation is pretty expensive in terms of memory use. Most developers can easily get by with the provided Array and Dictionary types and they choose to skip writing their own container/collection code so they can use the saved memory for functionality in their app.

Given that MonkeyC has previously been memory constrained, you wouldn't typically have enough data to get much benefit from a more sophisticated collection anyway. i.e., a linear search through a 30 element array is fast enough to not justify using a btree.

Of course you could write interface wrappers around the existing containers to abstract functionality (implement Set as a wrapper around Array), but again most guys aren't writing this type of code.

When I first started with ConnectIQ I did write a few containers. I think I had a set, a deque, and a list, but they were just for play. I never actually used them for anything. I might be able to find the code if it would be of use.

Thanks, Travis. Yes，the containers are so heavy to use in the Garmin runtime environment. The dictionary and array can handle most of the problems. I am just wondering about the existence. 

Travis.ConnectIQ said:

Given that MonkeyC has previously been memory constrained

I'd say that Monkey C is still memory constrained, given that watches like FR245 (non-music), VA4, Venu and Fenix 6 (non-pro) still have 32 KB of available memory for a data field (i.e. the same amount as the VAHR, released in 2016.) And the 64 KB available to the FR245 Music for data fields is better, but not amazingly huge.

If I wanted to write a data field that requires at least 64 KB (which I have), I would be excluding a lot of expensive "high-end" current-gen Garmins (which I did).

I agree with the sentiment though.

Personally, I only write containers / abstract data types in Monkey C when I absolutely have to. For one data field I implemented a circular queue, but instead of making it class/object-based (which was incredibly memory inefficient), I simply had static functions which passed around an array to each other. Bad for maintenance/comprehension/sharing, but good for memory usage.

I agree with Travis that in most cases there's just no point. In Monkey C, I would also never use a dictionary unless I absolutely have to (i.e. if a Monkey C API call requires one to be passed in.)

Not only memory is an issue, but I experimented with doing binary trees a while back, and recursion kind of goes hand in hand with that.  After only a few recursive calls, I'd run out of stack space. (it was 4-5 if I recall)

Oh. Thanks, Jim. I will avoid using recursive invocation in my programs.

That still is a limit.  How big a stack could you need for a very lopsided tree?

Of course it's still a limit, but now you're limited by available app memory rather than the size of Garmin's stack.

My point was that if you *absolutely need* a recursive algorithm, you could rewrite it if you had to.