Until C++ supports 'concepts' the only way to support construction from
two iterators is to provide a constructor of the form:
template<class InputIterator>
List(InputIterator first, InputIterator last);
which for some types conflicts with
//- Construct with given size and value for all elements
List(const label, const T&);
e.g. to construct a list of 5 scalars initialized to 0:
List<scalar> sl(5, 0);
causes a conflict because the initialization type is 'int' rather than
'scalar'. This conflict may be resolved by specifying the type of the
initialization value:
List<scalar> sl(5, scalar(0));
The new initializer list contructor provides a convenient and efficient alternative
to using 'IStringStream' to provide an initial list of values:
List<vector> list4(IStringStream("((0 1 2) (3 4 5) (6 7 8))")());
or
List<vector> list4
{
vector(0, 1, 2),
vector(3, 4, 5),
vector(6, 7, 8)
};
Oriented somewhat on dictionary methods.
Return the argument string associated with the named option:
Info<< "-foo: " << args.option("foo") << nl;
Return true if the named option is found
if (args.optionFound("foo")) ...
Return an IStringStream to the named option
old: value = readScalar(IStringStream(args.options()["foo"])());
newer: value = readScalar(args.optionLookup("foo")());
also: List<scalar> lst(args.optionLookup("foo")());
Read a value from the named option
newest: value = args.optionRead<scalar>("foo");
Read a value from the named option if present.
old: if (args.options().found("foo"))
{
value = readScalar(IStringStream(args.options()["foo"])());
}
new: args.optionReadIfPresent("foo", value);
Read a List of values from the named option
patches = args.optionReadList<word>("patches");
Didn't bother adding optionReadListIfPresent<T>(const word&), since it
probably wouldn't be common anyhow.
- Read a bracket-delimited list, or handle a single value as list of size 1.
Mostly useful for handling command-line arguments.
eg,
if (args.options().found("patches"))
{
patches = readList<word>(IStringStream(args.options()["patches"])());
}
can handle both of these:
-patches patch0
-patches \( patch1 patch2 patch3 \)
- The capitalization is consistent with most other template classes, but
more importantly frees up xfer() for use as method name without needing
special treatment to avoid ambiguities.
It seems reasonable to have different names for transfer(...) and xfer()
methods, since the transfer is occuring in different directions.
The xfer() method can thus replace the recently introduced zero-parameter
transfer() methods.
Other name candidates (eg, yield, release, etc.) were deemed too abstract.
- this should provide a slightly more naturally means to using transfer
constructors, for example
labelList list2(list1.transfer());
vs. labelList list2(xferMove(list1));
- returns a plain list where appropriate (eg, DynamicList, SortableList)
for example
labelList list2(dynList1.transfer());
vs. labelList list2(xferMoveTo<labelList>(dynList1));
