You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: user-guide/modules/ROOT/pages/glossary.adoc
+31-13Lines changed: 31 additions & 13 deletions
Original file line number
Diff line number
Diff line change
@@ -33,7 +33,8 @@ Where terms apply specifically to one technology, such as _Quantum Computing_ or
33
33
34
34
*ASIO* : Asynchronous Input/Output - refer to boost:asio[]
35
35
36
-
*AST* : Abstract Syntax Tree - a data structure used in compilers to represent the structure of code in a hierarchical, tree-like form. It's a crucial intermediate step in parsing code for tasks like analysis, compilation, and optimizations.
36
+
[[ast]]
37
+
*AST* : Abstract Syntax Tree - a data structure used in compilers to represent the structure of code in a hierarchical, tree-like form. It's a crucial intermediate step in parsing code for tasks like analysis, compilation, and optimizations. See also, <<multiple-dispatch, Multiple Dispatch>>.
37
38
38
39
*ATM* : _At The Moment_
39
40
@@ -45,6 +46,7 @@ Where terms apply specifically to one technology, such as _Quantum Computing_ or
45
46
46
47
*Bikeshedding* or *BS* : _Focusing on trivial issues_
47
48
49
+
[[bloom-filter]]
48
50
*Bloom Filter* : A space-efficient, fast, and probabilistic structure that can tell you if an item is _definitely not in a database_ or is _possibly in the database_. For example, say you have a database of bad actors that is used to help prevent fraudulent access to a financial web app. A bloom filter can be used to tell if a new transaction _definitely_ does not come from this set, so proceed normally, or _possibly comes from this set_ in which case a deeper investigation into its validity (a full search of the bad actors) should be carried out. The following diagram shows the flow of control:
49
51
50
52
image::bloom-filter.png[Bloom filter]
@@ -56,7 +58,7 @@ Bloom filters are stealthy players in many performance-critical applications. Th
56
58
* Database engines, to avoid unnecessary disk reads during key lookup - anything to avoid a full-text search.
57
59
* Bioinformatics, to reduce the number of comparisons between huge DNA sequences.
58
60
59
-
Databases used with bloom filters have the entries hashed (see *Hash Functions*) before they are stored.
61
+
Databases used with bloom filters have the entries hashed (see <<hash-functions, Hash Functions>> ) before they are stored.
60
62
61
63
A Boost.Bloom library is currently in the formal review process.
62
64
@@ -136,9 +138,11 @@ Note:: The Bloom filter is named after its inventor, Burton Howard Bloom, who de
136
138
137
139
*GIL* : Generic Image Library - boost:gil[] is a library designed for image processing, offering a flexible way to manipulate and process images.
138
140
141
+
[[h]]
139
142
== H
140
143
141
-
*Hash Functions* : A hash function takes a string and converts it into a number. Often used in fraud detection to store details such as: email addresses (normalized/lowered), credit card fingerprints (not full PANs as this might expose sensitive data, usually the last four digits or a _tokenized_ version of the numbers), device IDs, IP and user-agent strings, phone numbers (E.164 format), and usernames / login handles. Once hashed, these numbers can be stored in a database and searched for patterns to create *Bloom Filters* (to detect fake accounts) as well as searched on a per-item basis. Commonly used hash algorithms include:
144
+
[[hash-functions]]
145
+
*Hash Functions* : A hash function takes a string and converts it into a number. Often used in fraud detection to store details such as: email addresses (normalized/lowered), credit card fingerprints (not full PANs as this might expose sensitive data, usually the last four digits or a _tokenized_ version of the numbers), device IDs, IP and user-agent strings, phone numbers (E.164 format), and usernames / login handles. Once hashed, these numbers can be stored in a database and searched for patterns to create <<bloom-filter,Bloom Filters>> (to detect fake accounts) as well as searched on a per-item basis. Commonly used hash algorithms include:
142
146
143
147
* *MurmurHash3 / MurmurHash2*, which is fast, multithreaded, but non-cryptographic. It has excellent _avalanche_ properties (small input changes can lead to big output changes) and is used in many real-time systems due to speed and low collision rate. Redis Bloom, Apache Hadoop, and Apache Hive use it for sketch-based analytics.
144
148
@@ -169,7 +173,7 @@ Terms related to hashing include:
169
173
170
174
* *Salting* - the process of adding a unique, random value to input data before hashing it, to prevent attackers from using precomputed hash tables (like _rainbow tables_) to reverse-engineer the original input.
171
175
172
-
Note:: For uses of hash functions in Boost libraries, refer to boost:hash2[] and the Boost.Bloom library currently in the formal review process.
176
+
Note:: For uses of hash functions in Boost libraries, refer to boost:hash2[], and the proposed Boost.Bloom library.
173
177
174
178
*HCF* : _Halt and Catch Fire_ - a bug that crashes everything, usually exaggerated
175
179
@@ -258,14 +262,21 @@ Note:: For uses of hash functions in Boost libraries, refer to boost:hash2[] and
258
262
259
263
*MFW* : _My Face When_ - used humorously or sarcastically depending heavily on the accompanying context or image.
260
264
261
-
*MIR, MLIR* : Mid-level Intermediate Representation - an intermediate form of code that is generated by the compiler during the compilation process, designed to be easier for the compiler to analyze and optimize. In particular, this mid-level code aids with *borrowchecking*, incremental compilation and ensuring safety (type, memory, etc.) issue.
265
+
*MIR, MLIR* : Mid-level Intermediate Representation - an intermediate form of code that is generated by the compiler during the compilation process, designed to be easier for the compiler to analyze and optimize. In particular, this mid-level code aids with <<borrow-checking, Borrow Checking>>, incremental compilation and ensuring safety (type, memory, etc.) issue.
262
266
263
267
*MOC* : In the context of Qt and pass:[C++], this refers to the Meta-Object Compiler - a tool that processes Qt's extensions to pass:[C++], such as signals and slots (a mechanism for event-driven programming) and other meta-object features (like introspection and dynamic properties). The MOC generates additional pass:[C++] code that enables these features to work seamlessly.
264
268
265
269
*MPI* : Message Parsing Interface - refer to boost:mpi[]
266
270
267
271
*MPL* or *MP11* : Metaprogramming Libraries - refer to boost:mpl[] and the later boost:mp11[]
268
272
273
+
[[multiple-dispatch]]
274
+
*Multiple Dispatch* : Refers to the ability of a function or method to _dynamically_ select its implementation based on the runtime types of multiple arguments, rather than just the type of the receiver (`this`) or a single argument. While pass:[C++] natively supports _single dispatch_ (via virtual functions), it does not have built-in multiple dispatch like some languages (for example, https://julialang.org/[Julia] or https://lisp-lang.org/[Common Lisp]). However, it can be emulated in pass:[C++] using design patterns like the _visitor pattern_, double dispatch, or external libraries. This technique is useful when the behavior of a function genuinely depends on the combination of several objects' dynamic types - for example, a complex collision between multiple object types. See <<open-methods, Open Methods>>.
275
+
276
+
* *Single Dispatch* is the most common form of dispatch in pass:[C++] and many languages — it means that the method or function to call is determined only by the type of the first (usually the calling) object at runtime, typically using virtual functions. For example, when you call `shape->draw()`, the `draw()` method selected depends only on the runtime type of shape, not on the types of any other arguments.
277
+
278
+
* *Visitor Pattern* : a design pattern that lets you separate an algorithm from the objects it operates on — by letting you “visit” objects and perform operations on them without modifying their classes. It allows you to add new operations to a group of existing object types without changing those types, by defining a `Visitor` class that implements the operation for each type. It's commonly used to achieve double dispatch and to apply operations across complex object structures like trees or <<ast, ASTs>>.
279
+
269
280
*MVP* : Model-View-Presenter
270
281
271
282
== N
@@ -274,7 +285,7 @@ Note:: For uses of hash functions in Boost libraries, refer to boost:hash2[] and
274
285
275
286
*NIMBY* : _Not In My Back Yard_ - when a programmer doesn't want to deal with a particular issue
276
287
277
-
*NLL* : Non-Lexical Lifetimes - an NLL borrowchecker in the https://www.rust-lang.org/[Rust] language that uses a more precise, dataflow-based analysis to determine when a borrow starts and ends, based on the actual usage of the variables. This allows for more flexible and intuitive borrowing rules.
288
+
*NLL* : Non-Lexical Lifetimes - an NLL <<borrow-checking, borrow checker>> in the https://www.rust-lang.org/[Rust] language that uses a more precise, dataflow-based analysis to determine when a borrow starts and ends, based on the actual usage of the variables. This allows for more flexible and intuitive borrowing rules.
278
289
279
290
*NTTP* : Non-Type Template Parameter
280
291
@@ -284,9 +295,10 @@ Note:: For uses of hash functions in Boost libraries, refer to boost:hash2[] and
284
295
285
296
*OOB* : Out of Bounds or Out of Band - meaning irrelevant
286
297
287
-
*OOP* : Object-Oriented Programming
298
+
*OOP* : Object-Ori
288
299
289
-
*Open-Methods* : Refers to a language mechanism that allows you to define new behaviors (essentially, methods) for existing types _without_ modifying those types. pass:[C++] doesn't natively support open methods in the way that some dynamic languages (like Common Lisp) do. Keys to the purpose of open methods are the _Open/Closed Principle_ (OCP) - where a software entity (class, module, function, etc.) should be open for extension but closed for modification - and _multiple dispatch_. In _single dispatch_ method resolution is based on the runtime type of a single object, usually the one the method is called on. With multiple dispatch method resolution is based on the runtime types of two or more arguments. pass:[C++] supports single dispatch via virtual functions, multiple dispatch has to be simulated and typically coded into a library.
300
+
[[open-methods]]
301
+
*Open-Methods* : Refers to a language mechanism that allows you to define new behaviors (essentially, methods) for existing types _without_ modifying those types. pass:[C++] doesn't natively support open methods in the way that some dynamic languages (like Common Lisp) do. Keys to the purpose of open methods are the _Open/Closed Principle_ (OCP) - where a software entity (class, module, function, etc.) should be open for extension but closed for modification - and _multiple dispatch_. In _single dispatch_ method resolution is based on the runtime type of a single object, usually the one the method is called on. With multiple dispatch method resolution is based on the runtime types of two or more arguments. pass:[C++] supports single dispatch via virtual functions, <<multiple-dispatch, Multiple Dispatch>> has to be simulated and typically coded into a library.
290
302
291
303
The main advantage of open methods is that they help prevent bugs when modifying stable code. For example, when a new file format becomes popular, code can be extended to support it without modifying the existing code. In simple terms, they allow for safer scaling of software. Another specific use is you can add behavior involving multiple types, for example adding collision handling between type `A` and type `B` that is to date unsupported in your code.
292
304
@@ -298,7 +310,8 @@ An open-method library is currently in the Boost formal review process.
298
310
299
311
*PFR* : A library to perform basic reflection - refer to boost:pfr[]
300
312
301
-
*Phi function* : a construct used in Static Single Assignment (see *SSA*) form to resolve multiple possible values for a variable when control flow converges in a program. It selects a value based on the control flow path taken to reach the convergence point. Phi functions are not visible to developers — they exist in the intermediate representation (IR) of compilers working with low-level code optimizations.
313
+
[[phi-function]]
314
+
*Phi Function* : a construct used in Static Single Assignment (see <<ssa, SSA>>) form to resolve multiple possible values for a variable when control flow converges in a program. It selects a value based on the control flow path taken to reach the convergence point. Phi functions are not visible to developers — they exist in the intermediate representation (IR) of compilers working with low-level code optimizations.
302
315
303
316
*PICNIC* : _Problem In Chair, Not In Computer_
304
317
@@ -333,7 +346,7 @@ An open-method library is currently in the Boost formal review process.
333
346
334
347
*Qt* : This is a widely-used pass:[C++] framework for cross-platform GUI applications. While not an acronym, it's often capitalized as Qt in discussions. Qt is known for its rich set of libraries and tools to develop not only graphical applications but also applications that require network handling, file I/O, and more.
335
348
336
-
*Quantum Computing* : Unlike classical computing based on bits which must have a value of 0 or 1, quantum computing is based on _qubits_ (see definition below) that can exist in multiple states at the same time. Still in the research phase, this technology can dramatically improve the performance of certain algorithms - especially those we currently call "brute-force" computing - in fields such as cryptography, chemistry simulation, graph traversing, and no doubt many others as new algorithms are discovered. We can currently simulate quantum algorithms in pass:[C++] - refer to xref:task-quantum-computing.adoc[]. There is a mass of new terminology to grasp - many of which have completely different meanings outside of quantum computing - including:
349
+
*Quantum Computing* : Unlike classical computing based on bits which must have a value of 0 or 1, quantum computing is based on <<qubit, qubits>> that can exist in multiple states at the same time. Still in the research phase, this technology can dramatically improve the performance of certain algorithms - especially those we currently call "brute-force" computing - in fields such as cryptography, chemistry simulation, graph traversing, and no doubt many others as new algorithms are discovered. We can currently simulate quantum algorithms in pass:[C++] - refer to xref:task-quantum-computing.adoc[]. There is a mass of new terminology to grasp - many of which have completely different meanings outside of quantum computing - including:
337
350
338
351
* *Bloch Sphere* : a geometric representation of a single qubit's state as a point on the surface of a unit sphere, useful for visualizing superposition and phase.
339
352
+
@@ -362,6 +375,7 @@ A classification of current quantum devices with dozens to hundreds of qubits th
362
375
363
376
* *QASM (Quantum Assembly Language)* : a low-level language for describing quantum circuits and operations, often used to interface with quantum simulators and hardware.
364
377
378
+
[[qubit]]
365
379
* *Qubit* : the basic unit of quantum information, capable of existing in a superposition of 0 and 1, unlike a classical bit which is strictly one or the other.
366
380
367
381
* *Qubit Connectivity (Topology)* : the layout that defines which qubits in a quantum computer can directly interact, affecting how efficiently quantum circuits can be executed.
@@ -408,17 +422,20 @@ _This diagram shows the basic process of quantum teleportation, where the unknow
408
422
409
423
*RTTI* : Run-Time Type Information
410
424
411
-
*RUST* : https://www.rust-lang.org/[Rust] is a relatively new programming language incorporating memory-safety, thread-safety and type-safety constructs. This language provides many of the concepts proposed for *Safe pass:[C++]*.
425
+
*RUST* : https://www.rust-lang.org/[Rust] is a relatively new programming language incorporating memory-safety, thread-safety and type-safety constructs. This language provides many of the concepts proposed for <<safecpp, Safe pass:[C++]>>.
412
426
413
427
*Rustaceans* : Aficionados of the https://www.rust-lang.org/[Rust] programming language
414
428
415
429
[[s]]
416
430
== S
417
431
432
+
[[safecpp]]
418
433
*Safe pass:[C++]* : There are memory-safe discussions and initiatives going on in the wider pass:[C++] development world, though it seems like it's a tough nut to crack. The https://safecpp.org/P3390R0.html[Safe pass:[C++]] proposal is currently in a state of indefinite hiatus. Key concepts of _memory-safety_, and it's partners _type-safety_ and _thread-safety_, include:
419
434
420
435
* *Borrowing* : this refers to a feature of an ownership system that allows a variable to grant temporary access to its data without giving up ownership. _Immutable borrowing_ allows others to read but not modify data. Multiple immutable borrows are allowed at the same time. With _mutable borrowing_ others can modify the data, but only one mutable borrow is allowed at any one time (to prevent data races), and the owner cannot modify the value until the borrow ends. Borrowing enforces lifetimes - so borrowed references do not outlive the original data.
421
-
* *Borrow checking* : a kind of compile-time analysis that prevents using a reference after an object has gone out of scope.
436
+
437
+
[[borrow-checking]]
438
+
* *Borrow Checking* : a kind of compile-time analysis that prevents using a reference after an object has gone out of scope.
422
439
* *Choice types* : a _choice type_ is similar to an enum, but contains a type-safe selection of alternative types.
423
440
* *Explicit mutation* : all mutations are explicit, so there are no uncertain side-effects.
424
441
* *Interior mutability* : types with interior mutability implement deconfliction strategies to support shared mutation, without the risk of data races or violating exclusivity.
@@ -437,7 +454,8 @@ _This diagram shows the basic process of quantum teleportation, where the unknow
*SSA* : Static Single Assignment - a property of intermediate representations (IRs) used in compilers. SSA is a popular technique in modern compilers to make optimizations and analysis simpler and more efficient. Each variable is assigned exactly once and is immutable after assignment. If a variable is updated, a new variable is created instead. Refer also to *Phi functions*.
457
+
[[ssa]]
458
+
*SSA* : Static Single Assignment - a property of intermediate representations (IRs) used in compilers. SSA is a popular technique in modern compilers to make optimizations and analysis simpler and more efficient. Each variable is assigned exactly once and is immutable after assignment. If a variable is updated, a new variable is created instead. Refer also to <<phi-function, Phi Functions>>.
Copy file name to clipboardExpand all lines: user-guide/modules/ROOT/pages/release-process.adoc
+3-3Lines changed: 3 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -11,9 +11,9 @@ Official repository: https://github.com/boostorg/website-v2-docs
11
11
Boost libraries are released together and publicly three times per year:
12
12
13
13
[circle]
14
-
* 2nd April
15
-
* 2nd August
16
-
* 2nd December
14
+
* Second week of April
15
+
* Second week of August
16
+
* Second week of December
17
17
18
18
Each release will contain updates to existing libraries, and some releases will contain new libraries. The release is built from the Boost GitHub site: https://github.com/boostorg/boost.
0 commit comments