Changeset 98da9e8

Timestamp:

Mar 22, 2026, 9:31:28 PM (9 hours ago)

Author:

Peter A. Buhr <pabuhr@…>

Branches:

master

Parents:

8d764d4f

Message:

final proofread of conclusion

File:

• doc/theses/mike_brooks_MMath/conclusion.tex (modified) (3 diffs)

doc/theses/mike_brooks_MMath/conclusion.tex

@@ -6 +6 @@
 Accomplishing this goal in C is difficult because these features are poorly designed.
 In contrast, \CFA's advanced type system and language features plus my critical design choices made it possible to provide better support with significant safety.
-The result is application code that is easier to write, understand, maintain, and safer from hacker attach-vectors.
+The result is application code that is easier to write, understand, maintain, and significantly safer from hacker attach-vectors.
+Finally, the performance sections for each container demonstrated that safety does not have to reduce performance, \ie rolling-your-own container is now an excuse not a reason.
 
-\section{Lists}
-
-The key takeaway for lists is that intrusive lists can be made easy to use, performant by eliminating implicit memory allocation, and able to simulate wrapped lists, whereas wrapped lists cannot simulate intrusive lists.
 
 \section{Arrays}
@@ -18 +16 @@
 Array overruns are no longer possible because all subscripting is checked, as in other modern languages.
 Subscript checking can be implicitly elided when the compiler is given sufficient information to determine the subscript variable is always in bounds, giving performant execution.
+Indirectly, simple and complex VLA's reduce heap allocation resulting in better performance (up to an order of magnitude in comparisons with @std::vector@) and no contention in concurrent programs.
+Any reduction of dynamic allocation is always a safety benefit.
+Finally, language subarray slicing of higher-dimensional arrays is also a powerful and safety critical feature versus programmers attempting it themselves.
 
-Safe, complex VLA's is another important feature because it replaces unsafe explicit dynamic allocation.
-As well, VLA's reduce heap contention in concurrent programs.
 
-Finally, the ability to slice a higher-dimensional array into subarrays is also a powerful and safety critical feature.
+\section{Lists}
+
+The key takeaway for lists is that intrusive lists can be made easy to use, performant by eliminating implicit memory allocation, and able to simulate wrapped lists, whereas wrapped lists cannot simulate intrusive lists.
+As well, the \CFA list-API eliminates many frustrating and error-prone requirements with \CC STL lists, \eg, a node can be returned and removed in a single operation (no 2-step @front@/@pop@), and an arbitrary node can be added/removed without the need for an iterator.
+As for \CC, the \CFA list API is powerful enough to reduce almost all common C list errors, substantially increasing program safety.
 
 
 \section{Strings}
 
-The key takeaway for strings is that providing powerful and safe block operations for manipulating strings is more important than ultra-level performance.
+The key takeaway for strings is that providing powerful and safe block-operations for manipulating strings is more important than ultra-level performance.
 Manipulating strings is always going to be expensive because of their dynamic variable sizing, as the hardware rarely has string-level operations, possibly only move and compare.
-This work designs an expressive set of safe string operations for composing, comparing, and decomposing arbitrary length strings, include complex reading and printing operations.
-
-Creating bespoke storage management for strings has the advantage of faster, more compact storage management due to string sharing, at the cost of additional external fragmentation between the string and general heaps.
+The new \CFA string API is a very expressive set of safe string operations for composing, comparing, and decomposing arbitrary length strings, include complex reading and printing operations.
+All low-level mechanisms for working with string, in any programming language, are error-prone in correctness and safety (back to working with arrays).
+Providing string lengths is also a significant safety improvement, while still working with compiler null-terminate string constants (as for \CC).
+As well, overloading C string operations to work with \CFA strings provides a safe vector for updating existing C programs manipulating strings.
+Finally, creating bespoke storage management for strings has the advantage of faster, more compact storage management due to string sharing, at the cost of additional external fragmentation between the string and general heap.
 With the large amounts of available memory, this approach is a viable tradeoff.
-
 
 
@@ -40 +44 @@
 All three forms of containers presented in this work are in their nascence, both in design and implementation.
 This work provides the foundation for future \CFA students to add more functionality along with robust and performant implementations.
-
+Completing the syntax change from @array@ to C-style for dimensions and subscripts is possibly the most important first step to fit with C-programmer expectation resulting in faster adoption.
+Also, adding a panoply of additional intrusive lists, \eg stack, queue, dequeue, \etc, is needed to complement the @list@ structure.
+I left all the infrastructure to accomplish these task, they just need time to complete.