← Home ← Back to /g/

Thread 107005635

55 posts 14 images /g/
Anonymous No.107005635 [Report] >>107005664 >>107005674 >>107005732 >>107005734 >>107005740 >>107005779 >>107005919 >>107005927 >>107006341 >>107006479 >>107007372 >>107007374 >>107007688 >>107008700
Stop using linked lists.
Anonymous No.107005664 [Report]
>>107005635 (OP)
can't handle going forward as well as backward?
Anonymous No.107005674 [Report] >>107005725 >>107008315
>>107005635 (OP)
dat O(1) insertion & removal though
Anonymous No.107005725 [Report] >>107005868 >>107006203 >>107006251 >>107008315
>>107005674
dat O(n) getting to the node you want though
Anonymous No.107005732 [Report] >>107005759
>>107005635 (OP)
>computer frankenstein can't fathom a scenario where an object exists in multiple sorted collections at once
imagine my shock
Anonymous No.107005734 [Report] >>107005819
>>107005635 (OP)
Stop using std::atomic everywhere and introducing stupid bugs because you think you are smart, lock the damn mutex.
Anonymous No.107005740 [Report]
>>107005635 (OP)
ok.
Anonymous No.107005759 [Report] >>107005841
>>107005732
just make those collections std::vectors
Anonymous No.107005779 [Report] >>107005796 >>107007919
>>107005635 (OP)
what I don't understand is why so many of these big investment banks seem to need his expertise. like, why does jp morgan need bjarne? if it were companies like google it would be more obvious, but I always associated investment banks more with spreadsheets than with... high performance computing? what are these guys cooking?
Anonymous No.107005788 [Report]
https://www.rfleury.com/p/in-defense-of-linked-lists

use linked lists
Anonymous No.107005791 [Report] >>107006222 >>107006246 >>107006270
i use red black trees :)
Anonymous No.107005796 [Report] >>107005845
>>107005779
high frequency trading
https://www.youtube.com/watch?v=sX2nF1fW7kI
Anonymous No.107005819 [Report] >>107005835
>>107005734
>filtered by atomics
yep, they really are hard
Anonymous No.107005835 [Report]
>>107005819
nice bait
Anonymous No.107005841 [Report] >>107005852 >>107006005
>>107005759
why complicate a data structure that's so simple? if the only problem with linked lists is cache efficiency then they're perfectly fine. if i was worried about cache efficiency i wouldn't be using c++ lol. there's a reason it can only be used for systems programming as an extreme subset.
Anonymous No.107005845 [Report]
>>107005796
fuck, wrong link
https://www.youtube.com/watch?v=NH1Tta7purM
Anonymous No.107005852 [Report] >>107005908
>>107005841
>if i was worried about cache efficiency i wouldn't be using c++ lol
what would you be using instead?
Anonymous No.107005865 [Report]
True, if you’re not optimizing for cache hit rate then all the hardware in the world won’t save you
Anonymous No.107005868 [Report]
>>107005725
Skip lists solve that. Though at that point, you're basically looking at a poor man's RB or AVL tree anyway.
Anonymous No.107005908 [Report] >>107005934
>>107005852
most likely c. i do application level programming because i like c++, perl, etc. if i was forced to do anything lower level c has the biggest ecosystem and near universal support. i would prefer to simply get it over with and get back to the stuff i enjoy.
Anonymous No.107005919 [Report]
>>107005635 (OP)
Bjarne Stroustrup deserves time in Guantanamo Bay.

https://www.rfleury.com/p/in-defense-of-linked-lists
Anonymous No.107005924 [Report]
use case?
Anonymous No.107005927 [Report] >>107006291
>>107005635 (OP)
I can't even remember the last time I used one outside of interviews. definitely not in the last 15 years.
Anonymous No.107005934 [Report] >>107006003
>>107005908
what's stopping you to do that in c++?
Anonymous No.107006003 [Report]
>>107005934
worse ecosystem, less supported, and being forced to use a small and strict subset of c++. it's honestly just easier to use c at that level instead of trying to cram c++ into a space it's simply not built for. if i was forced to write a web app i would use python, it's not my favorite but it fits best and lets me get the work over with quickly so i can get back to doing something i don't hate.
Anonymous No.107006005 [Report]
>>107005841
There is a big correlation between people that say “use std::vector” and “cache efficiency” and people that don’t know what cache or efficiency really mean, and, if you profiled their code, things like cache efficiency aren’t in their top 10,000 list of performance problems especially when they’re doing shit like unknowingly and effectively new()ing bools with multithreaded stdlibs.
Anonymous No.107006203 [Report]
>>107005725
1) There are other, faster ways to get to the nodes of interest.
2) Many uses for linked lists don't involve searching at all (e.g. fibonacci heaps, suspended contexts).
3) Linked lists are the simplest form of the more general graph data structure, if you can't handle lists then you aren't gonna be able to handle the more interesting flavors of graphs.
Anonymous No.107006222 [Report] >>107006246 >>107006404
>>107005791
AVL trees are faster in practice though.
Anonymous No.107006246 [Report]
>>107005791
>>107006222
Where is std::avl or std::rb then?
Anonymous No.107006251 [Report]
>>107005725
Depends. If the list is intrusive, you may already be holding a reference to the element you want anyway, at that point you can just call something like remove(x); and it will just work in constant time even on a list with a gazillion elements. Of course, if you need frequent fast out of nowhere, use an array instead.

Unfortunately, linked lists really shine only when they are intrusive, which means that a "generic" implementation is inevitably going to sacrifice something. Resizeable arrays don't have this problem.
Anonymous No.107006270 [Report]
>>107005791
Not just reds and blacks but spics should also hang from trees
Anonymous No.107006291 [Report]
>>107005927
I used one just the other day to keep track of a bunch of hairy allocations and file handle opens, then free’d/closed them all at some point later, marking the list node as empty. Then, at the end of the run, I check to see if they’re all freed in the list. If they aren’t I warn (I have a bug). The list is only tracked for diagnostic purposes.
Anonymous No.107006341 [Report] >>107007066
>>107005635 (OP)
Let me know when stacks and heaps (which can also be walked) are replaced be “vectors” by a similar retard that doesn't understand where modern bloat is, doesn't write real code with memory constraints and depends on a multi-TB swap file on his SSD which will die within the year, and never profiled how costly something like realloc() is.
Both this guy, and C++ are both finished.
Anonymous No.107006404 [Report] >>107007649
>>107006222
I prefer treaps, personally.
Anonymous No.107006479 [Report]
>>107005635 (OP)
every data structure is a "linked list", if the lists weren't linked then there would be no way to reference or find data
Anonymous No.107007066 [Report]
>>107006341
>and never profiled how costly something like realloc() is.
Ironically, std::vector doesn't use realloc, not even for built-in types.
Anonymous No.107007350 [Report]
Sometimes I find using a vector becomes more trouble than its worth.
Anonymous No.107007372 [Report]
>>107005635 (OP)
ENTER
https://www.rfleury.com/p/in-defense-of-linked-lists
Anonymous No.107007374 [Report] >>107007684
>>107005635 (OP)
If it can't be done with arrays it shouldn't be done at all.
Anonymous No.107007649 [Report]
>>107006404
As do I actually.
Anonymous No.107007684 [Report]
>>107007374
> arrays
Spoken like a true fortran aficionado.

Amount of vector processing operations applied to modern programmer’s use of vectors? Zero.
Anonymous No.107007688 [Report]
>>107005635 (OP)
Why?
Anonymous No.107007919 [Report] >>107008312
>>107005779
Because C++ "expertise" is a grift. It helps obfuscate the actual C under the covers, thus complicating what is happening and that's where the "experts" can wade in and sell their expertise.
Anonymous No.107008266 [Report]
anyone who regurgitates "linked lists are bad cause of cache!" is a retard who doesnt know anything, even if in the particular case they're correct.
Anonymous No.107008306 [Report]
I make every kind of dynamically-growing structure with linked lists insertable at both ends
Anonymous No.107008312 [Report]
>>107007919
Looks like someone needs to talk with their local C++ mentor!
Anonymous No.107008315 [Report] >>107008323 >>107008688
>>107005674
>>107005725
How about a linked list that as it dynamically creates new nodes, stores a table of indices for its elements so you can directly index to the nodes you want?
Anonymous No.107008323 [Report] >>107008590
I use lists of linked arrays.

>>107008315
Holy shit that eye misalignment.
Anonymous No.107008590 [Report] >>107008722
>>107008323
One eye on the previous node and one on the next
Anonymous No.107008688 [Report] >>107008758
>>107008315
>How about a linked list that as it dynamically creates new nodes, stores a table of indices for its elements so you can directly index to the nodes you want?

I've done that for a custom allocator, it was much faster than a simple linked list but despite taking a lot of space and being a complete mess, even in the best case, it was two times slower than malloc. Had to actually have 3 different hash tables to make the coalescence of adjacent nodes O(1). Searching for a free node capable of storing given size was still O(n).
struct FL_Chunk {
void *base;
void *end;
struct FL_Chunk *prev;
struct FL_Chunk *next;
};


struct FL_Slot {
struct FL_Chunk *chunk;
struct FL_Slot *prev;
struct FL_Slot *next;
};


struct FL_Page {
void *memory;
size_t capacity;
size_t curr_size;
ullong num_chunks_max;
struct Pool *pool_chunks;
struct FL_Chunk *list_chunks_used;
struct FL_Chunk *list_chunks_free;
struct Pool *pool_slots;
struct FL_Slot **table_bases;
struct FL_Slot **table_ends;
struct FL_Slot **table_used;
ullong num_chunks_used;
ullong num_chunks_free;
struct FL_Page *next;
};


struct FL {
bool is_extendable;
size_t alignment;
struct FL_Page *page;
};
Anonymous No.107008700 [Report]
>>107005635 (OP)
did the retard in picrel think that was an original idea, or are you a sophomore who discovered linked lists last month, and now you're past it?
Anonymous No.107008722 [Report]
>>107008590
Kek.
Anonymous No.107008758 [Report]
>>107008688
thanks for humoring my thought
Anonymous No.107008875 [Report]
(n (o))
Anonymous No.107008880 [Report]
(n (o ()))