@ -61,7 +61,7 @@ being device-compatible. We follow the previous example in a similar fashion.
..code-block:: cpp
..code-block:: cpp
class intPair {
class intPair {
DEVICE_CLASS(intPair)
DEVICE_COPY(intPair)
public:
public:
int x, y;
int x, y;
@ -92,11 +92,13 @@ being device-compatible. We follow the previous example in a similar fashion.
return 0;
return 0;
}
}
In this example, we create a class called ``intPair``, which is then made available on the device through
In this example, we create a class called ``intPair``, and enable device-copying functions through
the ``DEVICE_CLASS(name)`` macro. Specifically, that macro introduces a few functions, like
the ``DEVICE_COPY(name)`` macro. This is not necessary for a class or struct to be available on the device, as we can always pass objects through the kernel function arguments. This is useful to prevent constant copying, and potentially separating class copies between host and device.
``allocateDevice()``, ``updateDevice()``, ``updateHost()``, and ``that()``. The ``that()`` function
returns a pointer to the copy on the device. As a result, the programmer **must** define a destructor
The aforementioned macro introduces a few functions, like
that frees the pointer using ``CudaTools::free(that)``. For more details, see :ref:`here <Device Class>`.
``allocateDevice()``, ``freeDevice()``, ``updateDevice()``, ``updateHost()``, and ``that()``.
The ``that()`` function returns a pointer to the copy on the device. As a result when using this, the programmer
**must** define a destructor that frees the pointer using ``freeDevice()``. For more details, see :ref:`here <Device Copy>`.
..warning::
..warning::
The ``updateDevice()`` and ``updateHost()`` in most cases will need to be explicitly called
The ``updateDevice()`` and ``updateHost()`` in most cases will need to be explicitly called