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 @@
diff --git a/docs/users-guide/Defining-Component-Instances.adoc b/docs/users-guide/Defining-Component-Instances.adoc
index 850bedb9e..f7b8aa0cc 100644
--- a/docs/users-guide/Defining-Component-Instances.adoc
+++ b/docs/users-guide/Defining-Component-Instances.adoc
@@ -339,6 +339,8 @@ type if its qualified {cpp} class name matches the qualified
name of the FPP component.
For example, the {cpp} class name `A::B` matches the FPP component
name `A.B`.
+More generally, modules in FPP become namespaces in {cpp}, so
+dot qualifiers in FPP become double-colon qualifiers in {cpp}.
If the names do not match, then you must provide the type
associated with the implementation.
@@ -669,7 +671,7 @@ instance cmdSeq: Svc.CmdSequencer base id 0x0700 \
cmdSeq.allocateBuffer(
0,
Allocation::mallocator,
- ConfigConstants::cmdSeq::BUFFER_SIZE
+ ConfigConstants::SystemReference_cmdSeq::BUFFER_SIZE
);
"""
@@ -682,6 +684,15 @@ instance cmdSeq: Svc.CmdSequencer base id 0x0700 \
The code for `configConstants` provides a constant `BUFFER_SIZE`
that is used in the `configComponents` phase.
+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
+<>.
+
The code for `configComponents` calls `allocateBuffer`, passing
in an allocator object that is declared elsewhere.
(In the section on
@@ -734,3 +745,59 @@ For more examples of init specifiers in action, see the rest of
the file `SystemReference/Top/instances.fpp` in the F Prime repository.
In particular, the init specifiers for the `comDriver` instance
use the `state` value that we just mentioned.
+
+=== Generation of Names
+
+FPP uses the following rules to generate the names associated with
+component instances.
+First, as explained in the section on
+<>,
+a component type `M.C` in FPP becomes the type `M::C` in {cpp}.
+Here `C` is a {cpp} class defined in namespace `M` that
+implements the behavior of component `C`.
+
+Second, a component instance _I_ defined in module _N_ becomes
+a {cpp} variable _I_ defined in namespace _N_.
+For example, this FPP code
+
+[source,fpp]
+--------
+module N {
+
+ instance i: M.C base id 0x100
+
+}
+--------
+
+becomes this code in the generated {cpp}:
+
+[source,c++]
+----
+namespace N {
+
+ M::C i;
+
+}
+----
+
+So the fully qualified name of the instance is `N.i` in FPP and `N::i`
+in {cpp}.
+
+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 <>.
+
+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 {cpp}) 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.
diff --git a/docs/users-guide/Writing-C-Plus-Plus-Implementations.adoc b/docs/users-guide/Writing-C-Plus-Plus-Implementations.adoc
index 03cc88938..1f32de3b6 100644
--- a/docs/users-guide/Writing-C-Plus-Plus-Implementations.adoc
+++ b/docs/users-guide/Writing-C-Plus-Plus-Implementations.adoc
@@ -286,8 +286,8 @@ if (state.hostName != nullptr && state.portNumber != 0) {
comDriver.startSocketTask(
name,
true,
- ConfigConstants::comDriver::PRIORITY,
- ConfigConstants::comDriver::STACK_SIZE
+ ConfigConstants::SystemReference_comDriver::PRIORITY,
+ ConfigConstants::SystemReference_comDriver::STACK_SIZE
);
}
"""
@@ -341,21 +341,21 @@ namespace SystemReference {
// Health ping entries
namespace PingEntries {
- namespace blockDrv { enum { WARN = 3, FATAL = 5 }; }
- namespace chanTlm { enum { WARN = 3, FATAL = 5 }; }
- namespace cmdDisp { enum { WARN = 3, FATAL = 5 }; }
- namespace cmdSeq { enum { WARN = 3, FATAL = 5 }; }
- namespace eventLogger { enum { WARN = 3, FATAL = 5 }; }
- namespace fileDownlink { enum { WARN = 3, FATAL = 5 }; }
- namespace fileManager { enum { WARN = 3, FATAL = 5 }; }
- namespace fileUplink { enum { WARN = 3, FATAL = 5 }; }
- namespace imageProcessor { enum {WARN = 3, FATAL = 5}; }
- namespace prmDb { enum { WARN = 3, FATAL = 5 }; }
- namespace processedImageBufferLogger { enum {WARN = 3, FATAL = 5}; }
- namespace rateGroup1Comp { enum { WARN = 3, FATAL = 5 }; }
- namespace rateGroup2Comp { enum { WARN = 3, FATAL = 5 }; }
- namespace rateGroup3Comp { enum { WARN = 3, FATAL = 5 }; }
- namespace saveImageBufferLogger { enum {WARN = 3, FATAL = 5}; }
+ namespace SystemReference_blockDrv { enum { WARN = 3, FATAL = 5 }; }
+ namespace SystemReference_chanTlm { enum { WARN = 3, FATAL = 5 }; }
+ namespace SystemReference_cmdDisp { enum { WARN = 3, FATAL = 5 }; }
+ namespace SystemReference_cmdSeq { enum { WARN = 3, FATAL = 5 }; }
+ namespace SystemReference_eventLogger { enum { WARN = 3, FATAL = 5 }; }
+ namespace SystemReference_fileDownlink { enum { WARN = 3, FATAL = 5 }; }
+ namespace SystemReference_fileManager { enum { WARN = 3, FATAL = 5 }; }
+ namespace SystemReference_fileUplink { enum { WARN = 3, FATAL = 5 }; }
+ namespace SystemReference_imageProcessor { enum {WARN = 3, FATAL = 5}; }
+ namespace SystemReference_prmDb { enum { WARN = 3, FATAL = 5 }; }
+ namespace SystemReference_processedImageBufferLogger { enum {WARN = 3, FATAL = 5}; }
+ namespace SystemReference_rateGroup1Comp { enum { WARN = 3, FATAL = 5 }; }
+ namespace SystemReference_rateGroup2Comp { enum { WARN = 3, FATAL = 5 }; }
+ namespace SystemReference_rateGroup3Comp { enum { WARN = 3, FATAL = 5 }; }
+ namespace SystemReference_saveImageBufferLogger { enum { WARN = 3, FATAL = 5 }; }
}
}