diff --git a/docs/fpp-spec.html b/docs/fpp-spec.html index bde461363..eaf573c4b 100644 --- a/docs/fpp-spec.html +++ b/docs/fpp-spec.html @@ -10527,7 +10527,7 @@

22.4. Translation Tools

diff --git a/docs/fpp-users-guide.html b/docs/fpp-users-guide.html index 107757268..66aeaef57 100644 --- a/docs/fpp-users-guide.html +++ b/docs/fpp-users-guide.html @@ -610,6 +610,7 @@

The F Prime Prime (FPP) User’s Guide, v2.2.0

  • 11.3.2. Writing Init Specifiers
  • +
  • 11.4. Generation of Names
  • 12. Defining Topologies @@ -7105,7 +7106,9 @@

    11.2. Specif type if its qualified C++ class name matches the qualified name of the FPP component. For example, the C++ class name A::B matches the FPP component -name A.B.

    +name A.B. +More generally, modules in FPP become namespaces in C++, so +dot qualifiers in FPP become double-colon qualifiers in C++.

    If the names do not match, then you must provide the type @@ -7513,7 +7516,7 @@

    11 cmdSeq.allocateBuffer( 0, Allocation::mallocator, - ConfigConstants::cmdSeq::BUFFER_SIZE + ConfigConstants::SystemReference_cmdSeq::BUFFER_SIZE ); """ @@ -7527,7 +7530,17 @@

    11

    The code for configConstants provides a constant BUFFER_SIZE that is used in the configComponents phase. -The code for configComponents calls allocateBuffer, passing +The code generator places this code snippet in the +namespace ConfigConstants::SystemReference_cmdSeq. +Notice that the second part of the namespace uses the +fully qualified name SystemReference::cmdSeq, and it replaces +the double colon :: with an underscore _ to generate +the name. +We will explain this behavior further in the section on +generation of names.

    +
    +
    +

    The code for configComponents calls allocateBuffer, passing in an allocator object that is declared elsewhere. (In the section on implementing deployments, we will explain where this allocator @@ -7584,6 +7597,67 @@

    11

    +
    +

    11.4. Generation of Names

    +
    +

    FPP uses the following rules to generate the names associated with +component instances. +First, as explained in the section on +specifying the implementation, +a component type M.C in FPP becomes the type M::C in C++. +Here C is a C++ class defined in namespace M that +implements the behavior of component C.

    +
    +
    +

    Second, a component instance I defined in module N becomes +a C++ variable I defined in namespace N. +For example, this FPP code

    +
    +
    +
    +
    module N {
    +
    +  instance i: M.C base id 0x100
    +
    +}
    +
    +
    +
    +

    becomes this code in the generated C++:

    +
    +
    +
    +
    namespace N {
    +
    +  M::C i;
    +
    +}
    +
    +
    +
    +

    So the fully qualified name of the instance is N.i in FPP and N::i +in C++.

    +
    +
    +

    Third, all other code related to instances is generated in the namespace of the +top-level implementation. +For example, in the System Reference example from the previous section, +the top-level implementation is in the namespace SystemReference, so +the code for configuring constants is generated in that namespace. +We will have more to say about the top-level implementation in +the section on implementing deployments.

    +
    +
    +

    Fourth, when generating the name of a constant associated with an instance, +FPP uses the fully-qualified name of the instance, and it replaces +the dots (in FPP) or the colons (in C++) with underscores. +For example, as discussed in the previous section, the configuration +constants for the instance SystemReference::cmdSeq are placed in +the namespace ConfigConstants::SystemReference_cmdSeq. +This namespace, in turn, is placed in the namespace SystemReference +according to the previous paragraph.

    +
    +
    @@ -12278,8 +12352,8 @@

    @@ -12345,21 +12419,21 @@