/c/ – Pufferüberlauf

B-Bäume! Ohne es gelesen zu haben

>Uses virtual memory tricks to reserve a very large contiguous address range that won't be backed by actual memory unless it's used.

>Pros:
>*Contiguous address space - easy to reason about
>*Doesn't use memory that isn't required

>Non-issues:
>*On 64-bit systems the address space is very large, so you're unlikely to run out

>Cons:
>*Each [array] needs to be freed individually, so you want a small, tractable number.
>*Avoiding interleaving is only practical in certain circumstances. You need as many [arrays] as you have interleaved pushes.

Das ist, was Felix nutzt, wenn es irgendwie geht. Leider heißt es dann "hahaha, ein neuer std::vector? Nicht das Rad neuerfinden, Junge! *gelöscht*" ohne dass sie verstehen, dass es kein std::vector ist. :/

>>161058
man must du boost mehm

>>161059
Wer boost in die Kotbasis bringt, und damit die Kompilierzeiten auf >9000 Sekunden hochdreht, wird gefeuert.

>>161062
Entwicklerzeit ist wichtigerteurer als Kompilierzeit!!1

>>161063
Aber wirklich. Die Vorteile von Boost sind da evident!

Man sehe sich nur das Boost-Geometry-Tutorial an. Es beginnt mit:
>Suppose you need a C++ program to calculate the distance between two points.
und es endet in ... nun ja, man sehe selbst!

>In this design rationale, Boost.Geometry is step by step designed using tag dispatching, concepts, traits, and metaprogramming.
https://www.boost.org/doc/libs/latest/libs/geometry/doc/html/geometry/design.html

Wenn das nicht sinnvoll investierte Entwicklerzeit ist!

>>161062
Felix macht dann immer Mali, während er auf den Kompilierer wartet :3

>>161064
Solange es nicht CGAL ist. Hat jemand von euch schon mal diese Ausgeburt der Hölle verwendet?

>>161075
Ja, dieser Felix (damals noch Jung-Felix) musste mal Steven CGAL benutzen.

Das war ein Teil von Felixens Programmiererfahrung (neben der Erfahrung mit anderen Bibliotheken), dass man C++-Bibliotheken niemals nie nicht aus dem Paketmanager der jeweils benutzten Distro benutzen sollte, sondern bei C++ nur selber kompilieren frei macht. Ansonsten kriegt man einfach zu viele ABI-Probleme. Erst heute weiß Felix, dass pkgconf vollkommen unzureichend für ABI-Kompatibilität ist und sogar ein abweichend eingestellter Sprachstandard (also so etwas wie -std=c++17 vs. -std=c++20) bereits zu ABI-Inkompatibilität führt.

Felix sieht aber gerade, dass sie CGAL zu einer Header-only-Bibliothek umgebaut haben. Der natürliche Lebensweg einer C++-Bibliothek. (Alternativer Lebensweg: Wir machen jetzt eine C-Bibliothek und geben dem Nutzer ein paar Header-Dateien für ein paar C++-RAII-Wrapper mit, die der Nutzer dann direkt selbst seinem Projekt hinzufügt). Einzige Felix bekannte C++-Bibliothek, die ABI-Kompatibilität ernst nimmt, ist scheinbar Qt, zumindest nach ABI compatibility tracker, was auch kein Wunder ist, da das Qt-Projekt selbst den ABI Compliance Checker (ABICC) verwendet.

>>161085
ABI-Kompatibilität ist nicht mal das Hauptproblem. Das Hauptproblem ist, dass die Beispiele überall auto verwenden, sodass für den Leser völlig unklar ist, um welchen Typ es sich eigentlich handelt. Und selbst VS IntelliSense und ähnliches sind damit überfordert, es herauszufinden. Wenn du nicht zufällig einen Experten kennst, der einen Beispielcode hat, denn du abwandeln kannst, bist du völlig aufgeschmissen.

Das ganze ist so generisch, dass es nicht mehr verständlich ist. Natürlich alles "Zero Cost Abstractions". Wenig überraschend schneidet die Bibliothek dann auch bei allen Benchmarks mit weitem Abstand (Größenordnungen) schlechter ab als die Konkurrenz.

>>161086
Auch: Curiosly recurring templates [0]

[0] https://en.wikipedia.org/wiki/Curiously_recurring_template_pattern

>>161085
> bereits

>>161086
Fickend dies. Es ist so schlimm wie Python

>>161090
>> bereits
Felix fand es überraschend, dass sich plötzlich die Größe von ein paar eigenen structs (also noch nicht einmal aus der Standardbibliothek) ändert, nur weil man das Sprachstandard-Jahr -std=c++XY verändert. Was auch eine reale Gefahr ist, weil der Programmierer das noch nicht einmal selbst manuell verändern muss, als dass GCC 16 gerade zu C++20 (bzw. GNU++20) als Voreinstellung gewechselt ist. Damit kann man sich nur durch eine Aufdatierung des Kompilierers bereits eine ABI-Inkompatibilität reinholen, wenn man gegen die C++-Devel-Pakete aus dem Paketmanager linkt.

>>161090
C-Frickelfelix bekommt mit Python wesentlich besser zurecht als mit C++. Nur sagend.