File: Conventions.txt

package info (click to toggle)
openni2 2.2.0.33%2Bdfsg-18
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid, trixie
  • size: 22,240 kB
  • sloc: cpp: 111,183; ansic: 35,511; sh: 10,556; python: 1,313; java: 952; makefile: 575; xml: 12
file content (58 lines) | stat: -rw-r--r-- 3,965 bytes parent folder | download | duplicates (4)
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
/**
@page conventions_cpp C++ API Conventions

@section classes_vs_structs Classes vs. Structs

In general, classes are preferred, along with getX() / setX() methods.
This allows extending the API in the future without breaking compatibility.
In cases of "super-primitives" (like @ref openni::RGB888Pixel), structs are used.

@section return_values Return Values from Methods

- All getters return the value as their return value, and cannot fail, for example: @ref openni::VideoFrameRef::getWidth().
  If the value is a complex type, it will be returned as const reference, for example: @ref openni::Device::getDeviceInfo().
  If a specific property doesn't exist for the specific object, a meaningful value will be returned.
  
- stop / destroy / close methods does not have return values, for example: @ref openni::Device::close().

- All other methods return @ref openni::Status, for example: @ref openni::VideoStream::create().

@section pointers_and_refs Arguments to Methods

- Output arguments, as well as in/out arguments are always passed as a pointer, for example: @ref openni::VideoStream::readFrame().
- Input arguments:
  - Primitives are passed by value, for example: @ref openni::VideoMode::setPixelFormat().
  - Complex types are passed as const reference, for example: @ref openni::VideoStream::create().
  - In the rare cases where the object identity matters, and not it's content, it will be passed as a pointer, for example: @ref openni::OpenNI::addListener().

@section object_lifetime Object Lifetime

Some objects have their lifetime goverened by the user. For example, a @ref openni::VideoStream is created using the @ref openni::VideoStream::create "create()" method
and destroyed by calling @ref openni::VideoStream::destroy "destroy()". In those cases, it is important that they get destroyed in the right order. For example, if
you create a @ref openni::VideoStream on a specific @ref openni::Device, don't close the device before destroying that video stream. In the same manner, all @ref openni::VideoFrameRef
objects should be released before destroying the stream, and <b>all</b> OpenNI objects should be destroyed before calling @ref openni::OpenNI::shutdown().

Other objects are not created by the user, but are actually members of other objects. For example, calling @ref openni::Device::getDeviceInfo() returns a reference
to a @ref openni::DeviceInfo object. Note that once the @ref openni::Device object that was used gets closed, the @ref openni::DeviceInfo reference is no longer valid. Do
not try to use it to access methods of the @ref openni::DeviceInfo object.
  
@section arrays Arrays

Some methods return an array of items. We created a very simple template class, @ref openni::Array, which only holds the pointer to the underlying C array
and the number of elements in that array. Once the array has been released, the elements are no longer accessible. Do not keep a pointer to a specific
item in the array and use it after releasing it.

@section properties_and_commands Properties and Commands

OpenNI has a mechanism for generic properties and commands, both for devices and for streams. Commands are used by calling @ref openni::Device::invoke() or 
@ref openni::VideoStream::invoke() and Properties can be read via @ref openni::Device::getProperty() and @ref openni::VideoStream::getProperty() and written via
@ref openni::Device::setProperty() and @ref openni::VideoStream::setProperty().

Though both might use both primitives and complex types, generally, properties are used to encapsulate a logical data unit (even though complex) while commands are used in the following cases:
- The action requires some arguments (that are not part of the data unit).
- Obtaining a data unit via getProperty() have side effects.
- The operation is expensive enough that you want to communicate it to the user.
- The action has side effects.
- The data unit might be changed over time without an outside request.
  
*/