vector: Fix for compilers not compatible with CWG defect 945

[Kojoley]

Closes #160 (I believe).
Reject the PR if you are not going to add support for compilers that do not support CWG defect 945 (c++11 in clang 3.0, gcc 4.6?). Also, I am not sure this is enough and there are no other problems with them.

[djowel]

I'm not sure if we should support such compilers. However, this is such an easy workaround that it's probably worth having. I'm on the fence. I'll leave it up to @Flast to decide.

[Flast]

this is such an easy workaround that it's probably worth having

Yes, it's trivial. I have no reason for rejecting this.

[Flast]

Ah, it's assigned to me. OK, I'll merge.

[Flast]

Thank you, both!

[djowel]

Thank you, both!

It's always good to know Spirit, Fusion and Phoenix are in very capable hands.

[prudhomm]

@Flast I don't think it is such as simple change. It breaks my c++14 code and reverting back to the previous one fixes it.

[prudhomm]

@Kojoley @djowel @Flast I get this kind of errors:

/home/feelpp/feelpp/feel/feeldiscr/functionspace.hpp:5358:31: error: field has incomplete type 'Feel::FunctionSpace<Feel::Mesh<Simplex<3, 2, 3> >,
      Feel::detail::bases<Feel::Lagrange<1, Scalar, Feel::Continuous, PointSetEquiSpaced, 0> >, double, Feel::Periodicity<Feel::NoPeriodicity>, Feel::mortars<Feel::NoMortar>
      >::functionspace_vector_type' (aka 'vector<boost::shared_ptr<Feel::FunctionSpace<Feel::Mesh<Simplex<3, 2, 3> >, Feel::detail::bases<Feel::Lagrange<1, Scalar,
      Feel::Continuous, PointSetEquiSpaced, 0> >, double, Feel::Periodicity<Feel::NoPeriodicity>, Feel::mortars<Feel::NoMortar> > > >')
    functionspace_vector_type M_functionspaces;
                              ^
/usr/include/boost/fusion/container/vector/vector.hpp:250:61: note: in instantiation of template class 'Feel::FunctionSpace<Feel::Mesh<Simplex<3, 2, 3> >,
      Feel::detail::bases<Feel::Lagrange<1, Scalar, Feel::Continuous, PointSetEquiSpaced, 0> >, double, Feel::Periodicity<Feel::NoPeriodicity>, Feel::mortars<Feel::NoMortar> >'
      requested here
            auto at_impl(J) -> decltype(at_detail<J::value>(&std::declval<vector_data&>()))                                                      ^

This is open-source code here and I can produce the relevant code.
it also produces some weird error messages at some simple mpl/fusion code like

/usr/include/boost/mpl/fold.hpp:34:44: error: no member named 'value' in 'boost::mpl::O1_size<boost::fusion::vector<boost::shared_ptr<Feel::FunctionSpace<Feel::Mesh<Hypercube<3,
      1, 3> >, Feel::detail::bases<Feel::Lagrange<1, Scalar, Feel::Continuous, PointSetEquiSpaced, 0> >, double, Feel::Periodicity<Feel::NoPeriodicity>,
      Feel::mortars<Feel::NoMortar> > > > >'
          ::boost::mpl::O1_size<Sequence>::value
          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^

the c++ code looks like

typedef typename mpl::transform<functionspace_vector_type, ChangeMeshSupport<mpl::_1>, mpl::back_inserter<fusion::vector<> > >::type mesh_support_vector_type;

where ChangeMeshSupport is a very simple class.
I was looking initially into this, but the culprit was the change you committed and which produced the first error I reported

[prudhomm]

so basically the code cannot use boost starting from 1.67 due to this since it relies heavily on fusion

[Kojoley]

It is very strange, I do not see any problems in Regression. What is your compiler? Do you have a MWE?

[prudhomm]

clang >= 4

[prudhomm]

@Kojoley could it be possible to have boost macros to change the PR and detect the supported vs unsupported compilers and select the corresponding implementation ?

[Kojoley]

I am fine with reverting the PR (since it targeted somewhat outdated compilers), however I do not understand how it broke.
Do you inherit from fusion types and may be overload address-of operator?

[prudhomm]

indeed I sometimes have class inheriting from fusion types

[Flast]

Sorry for late reply.

@prudhomm can you show me reproducible code (minimal is better but not required)?