File: SpecializedPluginPtr.hh

package info (click to toggle)
ignition-plugin 1.2.1%2Bds-1
  • links: PTS, VCS
  • area: main
  • in suites: bookworm
  • size: 728 kB
  • sloc: cpp: 4,712; ansic: 277; ruby: 128; sh: 38; makefile: 12
file content (75 lines) | stat: -rw-r--r-- 2,837 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
/*
 * Copyright (C) 2017 Open Source Robotics Foundation
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 *
 */


#ifndef IGNITION_PLUGIN_SPECIALIZEDPLUGINPTR_HH_
#define IGNITION_PLUGIN_SPECIALIZEDPLUGINPTR_HH_

#include "ignition/plugin/PluginPtr.hh"
#include "ignition/plugin/SpecializedPlugin.hh"

namespace ignition
{
  namespace plugin
  {
    /// \brief This alias allows PluginPtr instances to have high-speed access
    /// to interfaces that can be anticipated at compile time. The plugin does
    /// not have to actually offer the specialized interface in order to get
    /// this performance improvement. This template is variadic, so it can
    /// support arbitrarily many interfaces.
    ///
    /// Usage example:
    ///
    /// Suppose you want to instantiate a plugin that might (or might not) have
    /// some combination of four interfaces which are known at compile time:
    /// `MyInterface1`, `FooInterface`, `MyInterface2`, and `BarInterface`. You
    /// can use SpecializedPluginPtr as shown here:
    ///
    /// \code
    ///     using MySpecialPluginPtr = SpecializedPluginPtr<
    ///         MyInterface1, FooInterface, MyInterface2, BarInterface>;
    ///
    ///     MySpecialPluginPtr plugin = loader->Instantiate(pluginName);
    /// \endcode
    ///
    /// Then, calling the function
    ///
    /// \code
    ///     plugin->QueryInterface<FooInterface>();
    /// \endcode
    ///
    /// will have extremely high speed associated with it. It will provide
    /// direct access to the the `FooInterface*` of `plugin`. If `plugin` does
    /// not actually offer `FooInterface`, then it will return a nullptr, still
    /// at extremely high speed.
    ///
    /// This same rule also applies to `MyInterface1`, `MyInterface2`, and
    /// `BarInterface`, because those interfaces were also provided to
    /// SpecializedPluginPtr<...> at compile time.
    template <typename... SpecInterfaces>
    using SpecializedPluginPtr =
              TemplatePluginPtr< SpecializedPlugin<SpecInterfaces...> >;

    /// \brief This alias creates a specialized PluginPtr whose interfaces are
    /// all const-qualified.
    template <typename... SpecInterfaces>
    using ConstSpecializedPluginPtr =
              TemplatePluginPtr< const SpecializedPlugin<SpecInterfaces...> >;
  }
}

#endif