[#BloombergLP-bslma-ConstructionUtil_ConstructionTrait]
= xref:BloombergLP.adoc[BloombergLP]::xref:BloombergLP/bslma.adoc[bslma]::ConstructionUtil_ConstructionTrait
:relfileprefix: ../../
:mrdocs:

Metafunction yielding one of the following three `value` constants:

== Synopsis

Declared in `<bslma_constructionutil.h>`

[source,cpp,subs="verbatim,replacements,macros,-callouts"]
----
template<
    class TARGET_TYPE,
    class ALLOCATOR>
struct ConstructionUtil_ConstructionTrait;
----

== Description

: e_USES_ALLOCATOR_ARG_T_TRAITS `TARGET_TYPE` supports an allocator as: its second constructor argument, after: `bsl::allocator_arg`.:: e_USES_ALLOCATOR_TRAITS `TARGET_TYPE` supports an allocator as: its last constructor argument.:: e_NIL_TRAITS `TARGET_TYPE` does not support an: allocator and/or `ALLOCATOR` is `void*`: `int`, or any other non‐allocator: scalar. The allocator argument to: `construct` will be ignored.

`ALLOCATOR` is compatible with an AA `TARGET_TYPE` if `ALLOCATOR` is convertible to the allocator type expected by `TARGET_TYPE`'s constructors. There are three special cases of incompatible `ALLOCATOR` types:

1. If `TARGET_TYPE` expects an allocator of type `bslma::Allocator *` this metafunction yields either `e_USES_ALLOCATOR_ARG_T_TRAITS` or `e_USES_ALLOCATOR_TRAITS`, even if `ALLOCATOR` is not compatible with `TARGET_TYPE`. The `construct` method will attempt to extract the `bslma::Allocator *` from the allocator using its `mechanism` accessor. If there is no `mechanism` accessor, compilation will fail. 2. Otherwise, if `bslma::UsesBslmaAllocator<TARGET_TYPE>::value` is `true`, this metafunction yields either `e_USES_ALLOCATOR_ARG_T_TRAITS` or `e_USES_ALLOCATOR_TRAITS`, even if `ALLOCATOR` is not compatible with `TARGET_TYPE`, resulting in a compilation error within `construct`. 3. Otherwise, if `ALLOCATOR` is incompatible with `TARGET_TYPE`, then `ALLOCATOR` is ignored and this metafunction yields `e_NIL_TRAITS`, as though `TARGET_TYPE` were not AA.

The first two special cases allow mixing and matching between `bsl::allocator` and `bslma::Allocator *` in both directions, but will fail for other allocator types. The failure is desirable to prevent code accidentally passing an incorrect allocator type.

The third special case is inconsistent with the other two so as to allow third‐party classes that use third‐party allocators to be treated as non‐AA within containers that use BDE allocators.

This metafunction also yields a `type` of 'bsl::integral_constant<value, int>'.

== Type Aliases

[cols="1,4"]
|===
| Name| Description
| xref:BloombergLP/bslma/ConstructionUtil_ConstructionTrait/type.adoc[`type`] 
| Integral constant indicating how `TARGET_TYPE` uses `ALLOCATOR`.
|===


== Enums

[cols="1,4"]
|===
| Name| Description
| xref:BloombergLP/bslma/ConstructionUtil_ConstructionTrait/_04enum.adoc[`Unnamed enum`] 
| Integral constant indicating how `TARGET_TYPE` uses `ALLOCATOR`, one of `ConstructionUtil_Imp::e_NIL_TRAITS`, `ConstructionUtil_Imp::e_USES_ALLOCATOR_TRAITS`, or `ConstructionUtil_Imp::e_USES_ALLOCATOR_ARG_T_TRAITS`.
|===



[.small]#Created with https://www.mrdocs.com[MrDocs]#