What container data structures do all of you actually use?

For me, I'd say: dynamically sized array, hashtable, and hash set. (And string if you count that.)

In the past 8 months, I've used another container type maybe once?

Meanwhile, I remember in school, we had all these classes on all these fancy data structures, I havent seen most of them since.

Arrays and hash tables. I only use/used fancy graphs for undergrad and leetcode

Trash containers.

Data structures are just the man telling you how to handle your data.

Don't fall for that shit.

Yup. Lists (dynamically sized arrays), dictionaries (maps) and sets. 99% of the time.

Nobody uses queues or stacks. Lists are good enough.

Trees are needed in very, very rare cases.

Of source I’m talking about ordinary business logic code. And not some hyper optimized stuff that works with huge data sets.

@Lensflare I was just gonna say that. ”But what about algorithms...”. I agree. In my daily work I pretty much only use lists and sets.

Tbh I would love a job where you’re doing mostly leetcode stuff. It’s fun but sadly most dev jobs aren’t like that.

@devjesus yes mostly crud stuff and debugging someone’s bad code

Also: Ring buffers and statically sized dynamic arrays.

@Geoxion what do you mean statically sized dynamic arrays?

And, I personally have never ever needed a ring buffer

@YADU You probably did and just called it a queue.

@Fast-Nop never needed a queue either. (Have used stuff built on top of queues though.)

@YADU it's an array that has a fixed size, but a variable amount of elements are actually populated.

It's like a vector that has a fixed capacity.

The reason to use this is to avoid heap allocations on embedded devices.

@Geoxion ah ok I've run into those before just not under that name

Whatever best fits what I need at the time.

I mostly write in Ruby now, so custom data structures are pretty rare. But to answer anyway: Hashes, (dynamic) arrays, strings, structs. I also compose my own simple DSLs with classes, such as:

`convert(data).from(:raw).to_trigrams.via(:duck1)`
`convert(data).from(:trigrams).via { block }`

(Total props if you know what I’ve been working on!)

In the tiny bit of C that I’ve written lately: structs and 1-2d arrays. Haven’t needed anything fancier. Oh, I did implement a ring buffer for loop detection awhile ago.

I love my structs.

I put everything into a quoted list in CL such as:

'(you cannot stop us lispers
'(compose-more-shit (we are invincible)))

And have a macro destructure it into oblivion doing a lot of magical shit.

Or even better, I use the facility of Smalltalk to generate DSL's for different purposes that no one else but me would understand.

|muahaha|
muahaha := Generate something: (<structure>);
stupid.

Array, set, map (dictionary), map, map, map, map, map, m a p, m a p, ...

I used to not use so many maps, then at a certain point I met a guy and now I almost overuse it, but geez every time you see a switch - case (or God help you a cascade of if statements) consider using a map, makes it more readable and probably you’ll need to keep it configurable anyway! :)

Most of the work I do involves web APIs, so most of my data structure usage comes from deserializing JSON. Which means arrays and maps. Occasionally sets.

I don't think I've actually used a queue since college. I used a stack once for a small personal project.

And let's not even talk about linked lists.

@piratefox If a dictionary/map is more readable than a switch, depends on the language.
In Swift and Kotlin, I use switch/when more often than dictionaries because they are more flexible and have default non-fallthrough behavior (opposed to Java, C#, C++, ...). And the compiler can check if you have exhausted every case.
I use dictionaries only if I need to store the mapping data. And that is rare because even then, it’s often better to just make a single function which takes a parameter and switches it into a result that is returned. This function can be seen a stored version of the mapping logic and can be reused and passed around. The only thing that you can not do is serialize it into json or something.

Mostly: Arrays/lists, objects/dictionaries and sets

Occassionally/seldomly: hashmaps, trees, stacks, queues and linked-lists