e57::BlobNode Class Reference

An E57 element encoding an fixed-length sequence of bytes with an opaque format. More...

#include <E57Format.h>

Public Member Functions
	BlobNode ()=delete
	BlobNode (const ImageFile &destImageFile, int64_t byteCount)
	Create an element for storing a sequence of bytes with an opaque format.
	BlobNode (const Node &n)
	Downcast a generic Node handle to a BlobNode handle.
int64_t	byteCount () const
	Get size of blob declared when it was created.
void	checkInvariant (bool doRecurse=true, bool doUpcast=true) const
	Check whether BlobNode class invariant is true.
ImageFile	destImageFile () const
	Get the ImageFile that was declared as the destination for the node when it was created.
void	dump (int indent=0, std::ostream &os=std::cout) const
	Diagnostic function to print internal state of object to output stream in an indented format.
ustring	elementName () const
	Get elementName string, that identifies the node in its parent.
bool	isAttached () const
	Has node been attached into the tree of an ImageFile.
bool	isRoot () const
	Is this a root node.
	operator Node () const
	Upcast a BlobNode handle to a generic Node handle.
Node	parent () const
	Return parent of node, or self if a root node.
ustring	pathName () const
	Get absolute pathname of node.
void	read (uint8_t *buf, int64_t start, size_t count)
	Read a buffer of bytes from a blob.
void	write (uint8_t *buf, int64_t start, size_t count)
	Write a buffer of bytes to a blob.

Detailed Description

An E57 element encoding an fixed-length sequence of bytes with an opaque format.

A BlobNode is a terminal node (i.e. having no children) that holds an opaque, fixed-length sequence of bytes. The number of bytes in the BlobNode is declared at creation time. The content of the blob is stored within the E57 file in an efficient binary format (but not compressed). The BlobNode cannot grow after it is created. There is no ordering constraints on how content of a BlobNode may be accessed (i.e. it is random access). BlobNodes in an ImageFile opened for reading are read-only.

There are two categories of BlobNodes, distinguished by their usage: private BlobNodes and public BlobNodes. In a private BlobNode, the format of its content bytes is not published. This is useful for storing proprietary data that a writer does not wish to share with all readers. Rather than put this information in a separate file, the writer can embed the file inside the E57 file so it cannot be lost.

In a public BlobNode, the format is published or follows some industry standard format (e.g. JPEG). Rather than reinvent the wheel in applications that are already well-served by an existing format standard, an E57 file writer can just embed an existing file as an "attachment" in a BlobNode. The internal format of a public BlobNode is not enforced by the Foundation API. It is recommended that there be some mechanism for a reader to know ahead of time which format the BlobNode content adheres to (either specified by a document, or encoded by some scheme in the E57 Element tree).

The BlobNode is the one node type where the set-once policy is not strictly enforced. It is possible to write the same byte location in a BlobNode several times. However it is not recommended.

See Node class discussion for discussion of the common functions that StructureNode supports.

Class Invariant

A class invariant is a list of statements about an object that are always true before and after any operation on the object. An invariant is useful for testing correct operation of an implementation. Statements in an invariant can involve only externally visible state, or, can refer to internal implementation-specific state that is not visible to the API user. The following C++ code checks externally visible state for consistency and throws an exception if the invariant is violated:

void BlobNode::checkInvariant( bool /*doRecurse*/, bool doUpcast ) const
{
   // If destImageFile not open, can't test invariant (almost every call would throw)
   if ( !destImageFile().isOpen() )
   {
      return;
   }
 
   // If requested, call Node::checkInvariant
   if ( doUpcast )
   {
      static_cast<Node>( *this ).checkInvariant( false, false );
   }
 
   if ( byteCount() < 0 )
   {
      throw E57_EXCEPTION1( ErrorInvarianceViolation );
   }
}
 

See also

Node

Constructor & Destructor Documentation

BlobNode() [1/3]

e57::BlobNode::BlobNode ( )

delete

BlobNode() [2/3]

BlobNode::BlobNode ( const ImageFile &  destImageFile, int64_t  byteCount  )

explicit

Create an element for storing a sequence of bytes with an opaque format.

Parameters

[in]	destImageFile	The ImageFile where the new node will eventually be stored.
[in]	byteCount	The number of bytes reserved in the ImageFile for holding the blob.

The BlobNode class corresponds to the ASTM E57 standard Blob element.

See the class discussion at bottom of BlobNode page for more details.

The E57 Foundation Implementation may pre-allocate disk space in the ImageFile to store the declared length of the blob. The disk must have enough free space to store byteCount bytes of data. The data of a newly created BlobNode is initialized to zero.

The destImageFile indicates which ImageFile the BlobNode will eventually be attached to. A node is attached to an ImageFile by adding it underneath the predefined root of the ImageFile (gotten from ImageFile::root). It is not an error to fail to attach the BlobNode to the destImageFile. It is an error to attempt to attach the BlobNode to a different ImageFile.

Precondition

The destImageFile must be open (i.e. destImageFile.isOpen() must be true).

The destImageFile must have been opened in write mode (i.e. destImageFile.isWritable() must be true).

byteCount >= 0

Exceptions

ErrorBadAPIArgument
ErrorImageFileNotOpen
ErrorFileReadOnly
ErrorInternal	All objects in undocumented state

See also

Node, BlobNode::read, BlobNode::write

BlobNode() [3/3]

BlobNode::BlobNode ( const Node &  n )

explicit

Downcast a generic Node handle to a BlobNode handle.

Parameters

[in]

n

The generic handle to downcast.

The handle n must be for an underlying BlobNode, otherwise an exception is thrown. In designs that need to avoid the exception, use Node::type() to determine the actual type of the n before downcasting. This function must be explicitly called (c++ compiler cannot insert it automatically).

Exceptions

ErrorBadNodeDowncast

See also

Node::type(), BlobNode::operator Node()

Member Function Documentation

byteCount()

int64_t BlobNode::byteCount

(

)

const

Get size of blob declared when it was created.

Precondition

The destination ImageFile must be open (i.e. destImageFile().isOpen()).

Postcondition

No visible state is modified.

Returns

The declared size of the blob when it was created.

Exceptions

ErrorImageFileNotOpen
ErrorInternal	All objects in undocumented state

See also

BlobNode::read, BlobNode::write

checkInvariant()

void BlobNode::checkInvariant	(	bool	doRecurse = true,
		bool	doUpcast = true
	)		const

Check whether BlobNode class invariant is true.

Parameters

[in]	doRecurse	If true, also check invariants of all children or sub-objects recursively.
[in]	doUpcast	If true, also check invariants of the generic Node class.

This function checks at least the assertions in the documented class invariant description (see class reference page for this object). Other internal invariants that are implementation-dependent may also be checked. If any invariant clause is violated, an ErrorInvarianceViolation E57Exception is thrown.

Checking the invariant recursively may be expensive if the tree is large, so should be used judiciously, in debug versions of the application.

Postcondition

No visible state is modified.

Exceptions

ErrorInvarianceViolation

or any other E57 ErrorCode

destImageFile()

ImageFile BlobNode::destImageFile

(

)

const

Get the ImageFile that was declared as the destination for the node when it was created.

The first argument of the constructors of each of the 8 types of nodes is an ImageFile that indicates which ImageFile the node will eventually be attached to. This function returns that constructor argument. It is an error to attempt to attach the node to a different ImageFile. However it is not an error to not attach the node to any ImageFile (it's just wasteful). Use Node::isAttached to check if the node actually did get attached.

Postcondition

No visible object state is modified.

Returns

The ImageFile that was declared as the destination for the node when it was created.

See also

Node::isAttached, StructureNode::StructureNode(), VectorNode::VectorNode(), CompressedVectorNode::CompressedVectorNode(), IntegerNode::IntegerNode(), ScaledIntegerNode::ScaledIntegerNode(), FloatNode::FloatNode(), StringNode::StringNode(), BlobNode::BlobNode()

dump()

void BlobNode::dump	(	int	indent = 0,
		std::ostream &	os = std::cout
	)		const

Diagnostic function to print internal state of object to output stream in an indented format.

Parameters

[in]	indent	Number of spaces to indent all the printed lines of this object.
[in]	os	Output stream to print on.

All objects in the E57 Foundation API (with exception of E57Exception) support a dump() function. These functions print out to the console a detailed listing of the internal state of objects. The content of these printouts is not documented, and is really of interest only to implementation developers/maintainers or the really adventurous users. In implementations of the API other than the Reference Implementation, the dump() functions may produce no output (although the functions should still be defined). The output format may change from version to version.

Postcondition

No visible object state is modified.

Exceptions

No	E57Exceptions

elementName()

ustring BlobNode::elementName

(

)

const

Get elementName string, that identifies the node in its parent.

The elementName is a string associated with each parent-child link between nodes. For a given parent, the elementName uniquely identifies each of its children. Thus, any node in a tree can be identified by a sequence of elementNames that form a path from the tree's root node (see Node::pathName for more details).

Three types of nodes (the container node types) can be parents: StructureNode, VectorNode, and CompressedVectorNode. The children of a StructureNode are explicitly given unique elementNames when they are attached to the parent (using StructureNode::set). The children of VectorNode and CompressedVectorNode are implicitly given elementNames based on their position in the list (starting at "0"). In a CompressedVectorNode, the elementName can become quite large: "1000000000" or more. However in a CompressedVectorNode, the elementName string is not stored in the file and is deduced by the position of the child.

Precondition

The destination ImageFile must be open (i.e. destImageFile().isOpen()).

Postcondition

No visible state is modified.

Returns

The element name of the node, or "" if a root node.

Exceptions

ErrorImageFileNotOpen
ErrorInternal	All objects in undocumented state

See also

Node::pathName, Node::parent, Node::isRoot

isAttached()

bool BlobNode::isAttached

(

)

const

Has node been attached into the tree of an ImageFile.

Nodes are attached into an ImageFile tree by inserting them as children (directly or indirectly) of the ImageFile's root node. Nodes can also be attached to an ImageFile if they are used in the codecs or prototype trees of an CompressedVectorNode that is attached. Attached nodes will be saved to disk when the ImageFile is closed, and restored when the ImageFile is read back in from disk. Unattached nodes will not be saved to disk. It is not recommended to create nodes that are not eventually attached to the ImageFile.

Precondition

The destination ImageFile must be open (i.e. destImageFile().isOpen()).

Postcondition

No visible object state is modified.

Returns

true if node is child of (or in codecs or prototype of a child CompressedVectorNode of) the root node of an ImageFile.

Exceptions

ErrorImageFileNotOpen
ErrorInternal	All objects in undocumented state

See also

Node::destImageFile, ImageFile::root

isRoot()

bool BlobNode::isRoot

(

)

const

Is this a root node.

A root node has itself as a parent (it is not a child of any node). Newly constructed nodes (before they are inserted into an ImageFile tree) start out as root nodes. It is possible to temporarily create small trees that are unattached to any ImageFile. In these temporary trees, the top-most node will be a root node. After the tree is attached to the ImageFile tree, the only root node will be the pre-created one of the ImageTree (the one returned by ImageFile::root). The concept of attachment is slightly larger than that of the parent-child relationship (see Node::isAttached and CompressedVectorNode::CompressedVectorNode for more details).

Precondition

The destination ImageFile must be open (i.e. destImageFile().isOpen()).

Postcondition

No visible state is modified.

Returns

true if this node is a root node.

Exceptions

ErrorImageFileNotOpen
ErrorInternal	All objects in undocumented state

See also

Node::parent, Node::isAttached, CompressedVectorNode::CompressedVectorNode

operator Node()

BlobNode::operator Node

(

)

const

Upcast a BlobNode handle to a generic Node handle.

An upcast is always safe, and the compiler can automatically insert it for initializations of Node variables and Node function arguments.

Returns

A smart Node handle referencing the underlying object.

Exceptions

No	E57Exceptions.

See also

Explanation in Node, Node::type(), BlobNode(const Node&)

parent()

Node BlobNode::parent

(

)

const

Return parent of node, or self if a root node.

Nodes are organized into trees (acyclic graphs) with a distinguished node (the "top-most" node) called the root node. A parent-child relationship is established between nodes to form a tree. Nodes can have zero or one parent. Nodes with zero parents are called root nodes.

In the API, if a node has zero parents it is represented by having itself as a parent. Due to the set-once design of the API, a parent-child relationship cannot be modified once established. A child node can be any of the 8 node types, but a parent node can only be one of the 3 container node types (TypeStructure, TypeVector, and TypeCompressedVector). Each parent-child link has a string name (the elementName) associated with it (See Node::elementName for more details). More than one tree can be formed at any given time. Typically small trees are temporarily constructed before attachment to an ImageFile so that they will be written to the disk.

Warning

User algorithms that use this function to walk the tree must take care to handle the case where a node is its own parent (it is a root node). Use Node::isRoot to avoid infinite loops or infinite recursion.

Precondition

The destination ImageFile must be open (i.e. destImageFile().isOpen()).

Postcondition

No visible state is modified.

Returns

A smart Node handle referencing the parent node or this node if is a root node.

Exceptions

ErrorImageFileNotOpen
ErrorInternal	All objects in undocumented state

See also

Node::isRoot, Node::isAttached, CompressedVectorNode::CompressedVectorNode, Node::elementName

pathName()

ustring BlobNode::pathName

(

)

const

Get absolute pathname of node.

Nodes are organized into trees (acyclic graphs) by a parent-child relationship between nodes. Each parent-child relationship has an associated elementName string that is unique for a given parent. Any node in a given tree can be identified by a sequence of elementNames of how to get to the node from the root of the tree. An absolute pathname string that is formed by arranging this sequence of elementNames separated by the "/" character with a leading "/" prepended.

Some example absolute pathNames: "/data3D/0/points/153/cartesianX", "/data3D/0/points", "/cameraImages/1/pose/rotation/w", and "/". These examples have probably been attached to an ImageFile. Here is an example absolute pathName of a node in a pose tree that has not yet been attached to an ImageFile: "/pose/rotation/w".

A technical aside: the elementName of a root node does not appear in absolute pathnames, since the "path" is between the staring node (the root) and the ending node. By convention, in this API, a root node has the empty string ("") as its elementName.

Precondition

The destination ImageFile must be open (i.e. destImageFile().isOpen()).

Postcondition

No visible state is modified.

Returns

The absolute path name of the node.

Exceptions

ErrorImageFileNotOpen
ErrorInternal	All objects in undocumented state

See also

Node::elementName, Node::parent, Node::isRoot

read()

void BlobNode::read	(	uint8_t *	buf,
		int64_t	start,
		size_t	count
	)

Read a buffer of bytes from a blob.

Parameters

[in]	buf	A memory buffer to store bytes read from the blob.
[in]	start	The index of the first byte in blob to read.
[in]	count	The number of bytes to read.

The memory buffer buf must be able to store at least count bytes.

The data is stored in a binary section of the ImageFile with checksum protection, so undetected corruption is very unlikely. It is an error to attempt to read outside the declared size of the Blob. The format of the data read is opaque (unspecified by the ASTM E57 data format standard). Since buf is a byte buffer, byte ordering is irrelevant (it will come out in the same order that it went in). There is no constraint on the ordering of reads. Any part of the Blob data can be read zero or more times.

Precondition

The destination ImageFile must be open (i.e. destImageFile().isOpen()).

buf != NULL

0 <= start < byteCount()

0 <= count

(start + count) < byteCount()

Exceptions

ErrorBadAPIArgument
ErrorImageFileNotOpen
ErrorSeekFailed
ErrorReadFailed
ErrorBadChecksum
ErrorInternal	All objects in undocumented state

See also

BlobNode::byteCount, BlobNode::write

write()

void BlobNode::write	(	uint8_t *	buf,
		int64_t	start,
		size_t	count
	)

Write a buffer of bytes to a blob.

Parameters

[in]	buf	A memory buffer of bytes to write to the blob.
[in]	start	The index of the first byte in blob to write to.
[in]	count	The number of bytes to write.

The memory buffer buf must store at least count bytes.

The data is stored in a binary section of the ImageFile with checksum protection, so undetected corruption is very unlikely. It is an error to attempt to write outside the declared size of the Blob. The format of the data written is opaque (unspecified by the ASTM E57 data format standard). Since buf is a byte buffer, byte ordering is irrelevant (it will come out in the same order that it went in). There is no constraint on the ordering of writes. It is not an error to write a portion of the BlobNode data more than once, or not at all. Initially all the BlobNode data is zero, so if a portion is not written, it will remain zero. The BlobNode is one of the two node types that must be attached to the root of a write mode ImageFile before write operations can be performed (the other type is CompressedVectorNode).

Precondition

The destination ImageFile must be open (i.e. destImageFile().isOpen()).

The associated destImageFile must have been opened in write mode (i.e. destImageFile().isWritable()).

The BlobNode must be attached to an ImageFile (i.e. isAttached()).

buf != NULL

0 <= start < byteCount()

0 <= count

(start + count) < byteCount()

Exceptions

ErrorBadAPIArgument
ErrorImageFileNotOpen
ErrorFileReadOnly
ErrorNodeUnattached
ErrorSeekFailed
ErrorReadFailed
ErrorWriteFailed
ErrorBadChecksum
ErrorInternal	All objects in undocumented state

See also

BlobNode::byteCount, BlobNode::read

---

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

• E57Format.h
• BlobNode.cpp