Add Material objects to C++

[smharper]

This PR is small in terms of migrating functionality, but it will probably be helpful to do small, fast PRs like these given our pace on the C++ rewrite. This PR adds a basic Material class to C++. Right now the only data it owns is the id, but that's enough for C++ to also take control of the cell-material mapping. This change is probably a pre-requisite for moving the rest of geometry.F90 and plot.F90 over to C++.

While I was at it, I also switched most of my old code to our newly-established style for pointers and references.

@paulromano, I also switched your new default arguments to the get_node_value function to true. That's by far the more common case needed for all the XML inputs I've dealt with. Let me know if you want it to stay false. (Also, I tried to figure out where you needed false in #1042, but I couldn't find it.)

[paulromano]

Thanks for this PR @smharper. My only major comment is regarding our use of MATERIAL_VOID and C_NONE (see line comment below).

[paulromano]

Remove

[paulromano]

I would explicitly write std::stoi

[paulromano]

I've been using spaces on both sides of : in a range-for, adopting the style used in the core guidelines.

[paulromano]

If space is reserved for exactly the number of cells there are, why is shrink_to_fit needed?

[smharper]

I was just thinking about the wording of the reserve and shrink_to_fit requirements in the standards. reserve could reserve more space than needed, whereas shrink_to_fit I think is a more strong request for shrinking to the smallest capacity. This is a really small issue though so I'll remove the shrink_to_fit if you think it's unnecessary clutter.

[paulromano]

In practice, reserve(n) will make the capacity exactly n if it's greater than the current capacity. I've confirmed with a little program:

#include <iostream>
#include <vector>

int main() {
  for (int n = 0; n < 100; ++n) {
    std::vector<int> x;
    x.reserve(n);
    std::cout << "n = " << n << ", capacity = " << x.capacity() << '\n';
  }
}

Using g++, icpc, and clang, all give the same results (capacity == n for all n).

[paulromano]

So, in your case, shrink_to_fit will be a no-op; might as well remove it.

[smharper]

Good to know. I'll cut out the unneeded ones.

[paulromano]

I would still prefer these guys to be false by default (i.e., no extra work by default). For any kind of numeric data we are reading from XML, there is generally no reason to lowercase and strip the string. Taking a look at where we are using get_node_value on the develop branch, most cases actually use the false default.

[smharper]

Good point, most of our data is numeric. I've switched back to false.

[paulromano]

This is starting to look a little messy. Is there really a need to have a separate value indicating "no material was specified" as opposed to "void material". Maybe we should adopt the following behavior:

1. <cell> has material attribute but no fill: single material or distributed materials and Cell.fill = -1
2. <cell> has fill attribute but no fill: universe/lattice and Cell.material = -1
3. <cell> has neither material nor fill: void material with both Cell.material = -1 and Cell.fill = -1.

If we want to check "Is this material filled with a universe/lattice" (for example, geometry_aux.cpp:23), that would just be Cell.fill >= 0.

[smharper]

Much cleaner, thanks!

[smharper]

Note, I went with something slightly different than what you've suggested here. Case 3 is prevented (at least when reading from XML) by a fatal_error. For case 2, Cell.material is just left as an empty vector.