bangerth [Thu, 9 Jun 2011 22:19:05 +0000 (22:19 +0000)]
Work around a problem in make 3.82: We define a rule in Makefile.rules how to generate the %/output files, but we define a different rule in mpi/Makefile for the same pattern. This appears to have worked with gmake 3.81, but doesn't any longer with 3.82. Fix this by disabling the first definition if Makefile.rules is included from mpi/Makefile.
bangerth [Thu, 2 Jun 2011 19:08:26 +0000 (19:08 +0000)]
Remove -Woverloaded-virtual from CXXFLAGS.g. We trigger this in
DataPostprocessor and derived classes since we now have two functions with the
same name there but different signatures, but only one of the two has to be
overloaded.
bangerth [Thu, 2 Jun 2011 19:04:18 +0000 (19:04 +0000)]
Remove -Woverloaded-virtual from CXXFLAGS.g. We trigger this in
DataPostprocessor and derived classes since we now have two functions with the
same name there but different signatures, but only one of the two has to be
overloaded.
bangerth [Thu, 2 Jun 2011 18:05:50 +0000 (18:05 +0000)]
Fixed: If an FEValues object was kept around until after the triangulation include source doc
on which it works has been refined or coarsened, and is then reinitialized
with a cell from the refined triangulation, it could compute wrong results or
crash outright. This has now been fixed.
kronbichler [Thu, 2 Jun 2011 15:11:08 +0000 (15:11 +0000)]
In test for whether std::thread with std=c++0x really works: link with libpthread. It is needed for threaded code in general, and the flag will be added in the function DEAL_II_GET_THREAD_FLAGS (no need for change there).
bangerth [Mon, 30 May 2011 00:22:23 +0000 (00:22 +0000)]
<li> Changed: deal.II has a namespace std_cxx1x that was used to
import classes from BOOST that are part of the upcoming C++ 1x standard. On
the other hand, if your compiler supported a sufficiently large subset
of C++ 1x, we had code that simply did
@code
namespace std_cxx1x = std;
@endcode
allowing you to refer to everything that was part of the compiler's namespace
<code>std</code> under the alternative name. This turned out to be untenable
in connection to the changed outlined below for _1, _2, etc. Consequently,
if the compiler used supports C++ 1x, we now selectively import elements of the
compiler's namespace std into namespace std_cxx1x as well. This may lead to
incompatibilities if you are already using elements of the C++ 1x
standard by refering to them through the std_cxx1x namespace and these elements
are not on the list of selectively imported ones.
<br>
(Wolfgang Bangerth, 2011/05/29)
<li> Changed: Previously, placeholder arguments like _1, _2, etc that are used
in conjunction with the std_cxx1x::bind function could be referenced as if
they are part of the global namespace. This was achieved by importing the
corresponding elements of namespace std::placeholders into the global namespace
if your compiler supported this part of the C++ 1x standard, or otherwise using
the BOOST counterparts which are already in the global namespace. However,
this leads to a conflict if one has a C++ 1x enabled compiler (e.g. GCC 4.6)
<i>and</i> #includes certain BOOST headers, since the importation of symbols
into the global namespace now leads to ambiguous names. The only solution to
the problem is to not import names into the global namespace, but rather
import the names from either BOOST or namespace std into the deal.II namespace
std_cxx1x. The downside is that all code that uses _1, _2, etc needs to be
changed to use std_cxx1x::_1, std_cxx1x::_2, etc from now on.
<br>
(Wolfgang Bangerth, 2011/05/29)
</ol>
bangerth [Mon, 30 May 2011 00:16:00 +0000 (00:16 +0000)]
<li> Changed: deal.II has a namespace std_cxx1x that was used to
import classes from BOOST that are part of the upcoming C++ 1x standard. On
the other hand, if your compiler supported a sufficiently large subset
of C++ 1x, we had code that simply did
@code
namespace std_cxx1x = std;
@endcode
allowing you to refer to everything that was part of the compiler's namespace
<code>std</code> under the alternative name. This turned out to be untenable
in connection to the changed outlined below for _1, _2, etc. Consequently,
if the compiler used supports C++ 1x, we now selectively import elements of the
compiler's namespace std into namespace std_cxx1x as well. This may lead to
incompatibilities if you are already using elements of the C++ 1x
standard by refering to them through the std_cxx1x namespace and these elements
are not on the list of selectively imported ones.
<br>
(Wolfgang Bangerth, 2011/05/29)
<li> Changed: Previously, placeholder arguments like _1, _2, etc that are used
in conjunction with the std_cxx1x::bind function could be referenced as if
they are part of the global namespace. This was achieved by importing the
corresponding elements of namespace std::placeholders into the global namespace
if your compiler supported this part of the C++ 1x standard, or otherwise using
the BOOST counterparts which are already in the global namespace. However,
this leads to a conflict if one has a C++ 1x enabled compiler (e.g. GCC 4.6)
<i>and</i> #includes certain BOOST headers, since the importation of symbols
into the global namespace now leads to ambiguous names. The only solution to
the problem is to not import names into the global namespace, but rather
import the names from either BOOST or namespace std into the deal.II namespace
std_cxx1x. The downside is that all code that uses _1, _2, etc needs to be
changed to use std_cxx1x::_1, std_cxx1x::_2, etc from now on.
<br>
(Wolfgang Bangerth, 2011/05/29)
</ol>
bangerth [Mon, 23 May 2011 18:21:21 +0000 (18:21 +0000)]
Fail also in optimized mode if umfpack wasn't configured, rather than silently
producing wrong results. I've seen several people run into this already now...
bangerth [Tue, 17 May 2011 04:50:10 +0000 (04:50 +0000)]
Change the way we include files: Instead of doing #include <base/quadrature.h> we now want to do #include <deal.II/base/quadrature.h>. Keep the old way for backward compatibility.