[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/g/ - Technology


Thread archived.
You cannot reply anymore.


[Advertise on 4chan]


File: maxresdefault.jpg (79 KB, 1280x720)
79 KB
79 KB JPG
Stop using linked lists.
>>
File: 1761356556841.jpg (26 KB, 468x398)
26 KB
26 KB JPG
>>107005635
can't handle going forward as well as backward?
>>
>>107005635
dat O(1) insertion & removal though
>>
>>107005674
dat O(n) getting to the node you want though
>>
>>107005635
>computer frankenstein can't fathom a scenario where an object exists in multiple sorted collections at once
imagine my shock
>>
>>107005635
Stop using std::atomic everywhere and introducing stupid bugs because you think you are smart, lock the damn mutex.
>>
>>107005635
ok.
>>
>>107005732
just make those collections std::vectors
>>
>>107005635
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?
>>
File: file.png (176 KB, 400x400)
176 KB
176 KB PNG
https://www.rfleury.com/p/in-defense-of-linked-lists

use linked lists
>>
i use red black trees :)
>>
>>107005779
high frequency trading
https://www.youtube.com/watch?v=sX2nF1fW7kI
>>
>>107005734
>filtered by atomics
yep, they really are hard
>>
>>107005819
nice bait
>>
>>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.
>>
>>107005796
fuck, wrong link
https://www.youtube.com/watch?v=NH1Tta7purM
>>
>>107005841
>if i was worried about cache efficiency i wouldn't be using c++ lol
what would you be using instead?
>>
True, if you’re not optimizing for cache hit rate then all the hardware in the world won’t save you
>>
>>107005725
Skip lists solve that. Though at that point, you're basically looking at a poor man's RB or AVL tree anyway.
>>
>>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.
>>
>>107005635
Bjarne Stroustrup deserves time in Guantanamo Bay.

https://www.rfleury.com/p/in-defense-of-linked-lists
>>
use case?
>>
>>107005635
I can't even remember the last time I used one outside of interviews. definitely not in the last 15 years.
>>
>>107005908
what's stopping you to do that in c++?
>>
>>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.
>>
>>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.
>>
>>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.
>>
>>107005791
AVL trees are faster in practice though.
>>
>>107005791
>>107006222
Where is std::avl or std::rb then?
>>
>>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.
>>
>>107005791
Not just reds and blacks but spics should also hang from trees
>>
>>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.
>>
>>107005635
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.
>>
>>107006222
I prefer treaps, personally.
>>
>>107005635
every data structure is a "linked list", if the lists weren't linked then there would be no way to reference or find data
>>
>>107006341
>and never profiled how costly something like realloc() is.
Ironically, std::vector doesn't use realloc, not even for built-in types.
>>
Sometimes I find using a vector becomes more trouble than its worth.
>>
>>107005635
ENTER
https://www.rfleury.com/p/in-defense-of-linked-lists
>>
File: 1738893667475606.gif (79 KB, 338x370)
79 KB
79 KB GIF
>>107005635
If it can't be done with arrays it shouldn't be done at all.
>>
>>107006404
As do I actually.
>>
>>107007374
> arrays
Spoken like a true fortran aficionado.

Amount of vector processing operations applied to modern programmer’s use of vectors? Zero.
>>
>>107005635
Why?
>>
>>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.
>>
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.
>>
File: 1761008418081124.jpg (109 KB, 1013x1005)
109 KB
109 KB JPG
I make every kind of dynamically-growing structure with linked lists insertable at both ends
>>
File: Scott_Meyers.jpg (61 KB, 500x752)
61 KB
61 KB JPG
>>107007919
Looks like someone needs to talk with their local C++ mentor!
>>
File: 7nkpsgt76c721.jpg (41 KB, 750x486)
41 KB
41 KB JPG
>>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?
>>
I use lists of linked arrays.

>>107008315
Holy shit that eye misalignment.
>>
>>107008323
One eye on the previous node and one on the next
>>
>>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;
};
>>
>>107005635
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?
>>
>>107008590
Kek.
>>
>>107008688
thanks for humoring my thought
>>
(n (o ()))



[Advertise on 4chan]

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.