Container id definitions for the columnar infrastructure. More...

Classes
class	ContainerFreeAccessor
	the backend implementation for AccessorTemplate More...
class	MemoryAccessor
	a help implementation of AccessorTemplate that handles type conversions More...
class	MemoryAccessor< CT, CM >
class	MemoryAccessor< NativeColumn< CT >, CM >
class	MemoryAccessor< RetypeColumn< UT, CT >, CM >
class	MemoryAccessor< OptObjectId< LT, CM >, CM >
class	MemoryAccessor< LinkCastColumn< LT, ELT >, CM >
class	MemoryAccessor< LinkCastColumn< LT, ELT >, ColumnarModeXAOD >
class	MemoryAccessor< OptObjectId< LT >, ColumnarModeArray >
class	MemoryAccessor< LinkCastColumn< LT, ELT >, ColumnarModeXAODArray >
class	MemoryAccessor< std::string, ColumnarModeXAOD >
class	ContainerFreeAccessor< std::string, ColumnAccessMode::input, ColumnarModeArray >
class	MemoryAccessor< std::vector< CT >, CM >
class	ContainerFreeAccessor< std::vector< CT >, ColumnAccessMode::input, ColumnarModeArray >
class	VectorConvertIterator
	an iterator that does converts members using a passed in function More...
class	VectorConvertView
	a range view that does converts members using a passed in function More...
class	MemoryAccessor< ObjectLink< VariantContainerId< CIBase, CIList... >, ColumnarModeXAOD >, ColumnarModeXAOD >
class	ContainerFreeAccessor< ObjectLink< VariantContainerId< CIBase, CIList... >, CM >, CAM, CM >
class	ContainerFreeAccessor< LinkCastColumn< VariantContainerId< CIBase, CIList... >, ELT >, ColumnAccessMode::input, ColumnarModeArray >

Functions
template<typename T>
CLID	clidForType ()
	the CLID of a container type, or 0 when it cannot be determined
template<ContainerIdConcept LT>
CLID	linkTargetClid ()
	the CLID of the xAOD container a link column targets, or 0 if the container id does not provide one
template<typename FunctionType, typename IteratorType>
	VectorConvertIterator (FunctionType &&, IteratorType &&) -> VectorConvertIterator< std::decay_t< FunctionType >, std::decay_t< IteratorType > >
template<typename FunctionType, typename ViewType>
	VectorConvertView (FunctionType &&, ViewType &&) -> VectorConvertView< std::decay_t< FunctionType >, std::decay_t< ViewType > >

Detailed Description

Container id definitions for the columnar infrastructure.

Container ids identify the different "virtual" containers used by the columnar infrastructure. Each container id is represented by a struct (typically named with a Def suffix, e.g. JetDef, ElectronDef, ParticleDef) that describes the container. These structs are defined directly in the columnar namespace and are used as template parameters throughout the columnar code. The user should not be trying to create instances of these structs, but rather use them as identifiers to pass into various columnar templates.

To first order there is one container id for each xAOD type, and there is a direct mapping from container id to xAOD type. And for your code to compile in xAOD mode, your objects will be represented by a pointer to the underlying xAOD type. So to make your code compile in xAOD mode, you need to use the container id that corresponds to the xAOD type you want to use.

In the columnar world we don't really have objects like that, and the container ids are mostly arbitrary (objects in columnar mode are usually represented by integers). However, there are still columns that belong together, share an offset map, and have a common prefix to their names. These columns form a "virtual container" and the container id is used to identify that virtual container.

One important difference between xAOD types and container ids is that a container id is referring to a single container of a type. If you have e.g. two JetContainer instances in your tool, you need to use two different container ids for them. That is because in the columnar world the virtual containers come with completely separate columns, have separate offset maps, etc.

A given container id also only has a meaning within the context of one specific tool instance. If you have multiple instances of a tool they may be connected to different containers/columns each. If a tool has subtools they need to coordinate their container ids as well, making subtools a lot more tightly connected than in the xAOD world.

By default all referenced xAOD objects are const-qualified, as most tools will anyways work on const-qualified objects. In case your tool needs a non-const version of an object there is usually a "mutable" version of the container id available, which gives access to a mutable xAOD object and can be used wherever the corresponding const-qualified container id can be used, i.e. it doesn't introduce a separate container, but a different version of the same container.

Most classes in the columnar infrastructure are templates that take the container id as a template parameter. In part this is to use the correct type in xAOD mode, but it also serves an important role in columnar mode, as it allows to perform a lot of safety checks at compile time. E.g. it allows to guarantee that an ObjectId always refers to a valid entry in the container and that it can only be used with columns that are associated with that container.

For many of the containers there will be type aliases defined for some of the "common" infrastructure types, i.e. ObjectId, ObjectRange, OptObjectId, AccessorTemplate. This is meant to shorten the syntax for classes that users will regularly use in their own code. This is born out of experience during the prototyping stage when I found that the syntax that included all template parameters quickly became unwieldy.

The main motivation for representing container ids as "traits" structs is that it makes it possible to define parametric container ids. It also alleviates the need to have a single list of all container ids in a single place — each package can define its own container id structs as needed.

Function Documentation

◆ clidForType()

template<typename T>

CLID columnar::detail::clidForType ( )

the CLID of a container type, or 0 when it cannot be determined

CLASS_DEF is a no-op when parsed by rootcling (see xAODCore/CLASS_DEF.h), so the traits are unavailable there and this returns 0 during dictionary generation.

Definition at line 101 of file ContainerId.h.

    {
#ifdef __CLING__
      return 0;
#else
      return ClassID_traits<T>::ID();
#endif
    }

◆ linkTargetClid()

template<ContainerIdConcept LT>

CLID columnar::detail::linkTargetClid ( )

the CLID of the xAOD container a link column targets, or 0 if the container id does not provide one

Definition at line 35 of file LinkColumn.h.

    {
      if constexpr (requires { LT::containerClid(); })
        return LT::containerClid();
      else
        return 0;
    }

◆ VectorConvertIterator()

template<typename FunctionType, typename IteratorType>

columnar::detail::VectorConvertIterator	(	FunctionType &&	,
		IteratorType &&	) -> VectorConvertIterator< std::decay_t< FunctionType >, std::decay_t< IteratorType > >

◆ VectorConvertView()

template<typename FunctionType, typename ViewType>

columnar::detail::VectorConvertView	(	FunctionType &&	,
		ViewType &&	) -> VectorConvertView< std::decay_t< FunctionType >, std::decay_t< ViewType > >