Base of the drive-profile view hierarchy: a thin, borrowed view over a Device. More...

#include <profile_device.h>

Inheritance diagram for mm::node::ProfileDevice:

Collaboration diagram for mm::node::ProfileDevice:

Public Member Functions
	ProfileDevice (Device &device)
	Binds the view to `device`. The reference must outlive this view.

Device &	device ()
	The underlying generic device this view operates on.

const Device &	device () const

Protected Attributes
Device &	device_
	The borrowed device — the only data member permitted in the whole view chain.

Detailed Description

Base of the drive-profile view hierarchy: a thin, borrowed view over a Device.

A profile (CiA402 and, above it, SOMANET) is not what a device is in storage — every device is a Device, value-stored in DeviceManager. A profile is what you do with a device, using knowledge of its object-dictionary layout. So profile types do not derive from Device nor are they owned by it; they borrow a Device& and are constructed on demand for a single operation (a stack local in an HTTP handler, or a member of a cyclic task scoped to that task's lifetime).

Because these views are never stored base-typed (no vector<ProfileDevice>, no polymorphic container), the inheritance chain SomanetDrive → Cia402Drive → ProfileDevice is a genuine is-a relationship with no slicing or downcasting hazard — the objection that makes inheritance on Device wrong does not apply to a borrowed view.

Invariant: a profile view holds no state beyond this reference. A CiA402 drive's state lives in its statusword on the wire, not in the view; multi-cycle procedure state lives in a cyclic task, not here. Keep subclasses data-free except for behaviour — the day a view needs a persistent data member is the day this borrowed-view model needs rethinking.

Warning: The borrowed Device& must outlive the view. Construct a view, use it, and drop it within a single operation; never cache one across a bus rescan (which rebuilds DeviceManager's device vector and would dangle the reference). A cyclic task re-resolves its Device via DeviceManager::findDevice every cycle for exactly this reason.

Constructor & Destructor Documentation

◆ ProfileDevice()

mm::node::ProfileDevice::ProfileDevice ( Device & device )

inlineexplicit

Binds the view to device. The reference must outlive this view.

Member Function Documentation

◆ device() [1/2]

Device & mm::node::ProfileDevice::device ( )

inline

The underlying generic device this view operates on.

◆ device() [2/2]

const Device & mm::node::ProfileDevice::device ( ) const

inline

Member Data Documentation

◆ device_

Device& mm::node::ProfileDevice::device_

protected

The borrowed device — the only data member permitted in the whole view chain.

The documentation for this class was generated from the following file:

libs/node/profile_device.h

Public Member Functions

Protected Attributes