Just so we know what we're discussing here: What do you mean by 'good
support'?
It's not in the C++03 standard, so to get it we will need to enable C++11.
This does not compile with gcc 4.4.7 on our cluster unless passing
-std=c++0x:
#include <memory>
int main()
{
std::shared_ptr<int> p;
return 0;
}
Martin
On 29 January 2014 15:36, Garth N. Wells <[email protected]> wrote:
> On 2014-01-29 14:20, Anders Logg wrote:
>
>> On Wed, Jan 29, 2014 at 02:18:08PM +0000, Garth N. Wells wrote:
>>
>>> On 2014-01-29 13:42, Johan Hake wrote:
>>> >On Wed, Jan 29, 2014 at 10:44 AM, Garth N. Wells <[email protected]>
>>> >wrote:
>>> >
>>> >>On 2014-01-29 09:35, Johan Hake wrote:
>>> >>
>>> >>On Wed, Jan 29, 2014 at 9:52 AM, Garth N. Wells <[email protected]>
>>> >>wrote:
>>> >>
>>> >>On 2014-01-28 21:06, Anders Logg wrote:
>>> >>On Tue, Jan 28, 2014 at 08:33:38PM +0100, Johan Hake wrote:
>>> >>
>>> >>On Tue, Jan 28, 2014 at 8:24 PM, Martin Sandve Alnæs
>>> >><[email protected]>
>>> >>wrote:
>>> >>
>>> >> What if we move ufc.h to dolfin? Keeping the ufcutils module
>>> >>in ffc. Then
>>> >> we can maybe write a test that checks if a given ffc
>>> >>generates ufc code
>>> >> that implements the ufc interface of a given dolfin.
>>> >>
>>> >>Sounds like a good idea! Then we could incorporate the CMake
>>> >>configure process
>>> >>into DOLFIN CMake. We have also loosely talked about removing UFC
>>> >>and
>>> >>eventually generate DOLFIN code, which resonates with moving UFC to
>>> >>DOLFIN.
>>> >>
>>> >>I am not convinced this is a good idea:
>>> >>
>>> >> I'm not convinced either - doesn't seem like a natural split. How
>>> >>about:
>>> >>
>>> >> 1. We try letting distutils take care of building the SWIG
>>> >>wrappers
>>> >>in place of CMake:
>>> >>
>>> >>
>>> >>
>>> >http://docs.python.org/2/distutils/setupscript.html#
>>> extension-source-files
>>> >>[1]
>>> >>[2]
>>> >>
>>> >> or;
>>> >>
>>> >>This was the case before we added shared_ptr to ufc. Then we
>>> >>decided
>>> >>to add boost and a proper configure system was needed for that. Not
>>> >>sure we want to go back to distutils.
>>> >
>>> > Maybe we should switch to std::shared_ptr, in which case we won't
>>> >need Boost and compilation will be easy.
>>> >
>>> > Yes but logic wrt what namespace that should be used needs to be
>>> >included std::tr1:: or just std::, that might be trivial but the
>>> >amount of configuration that can be done for the extension module is
>>> >very limited in distutils.
>>> >
>>>
>>> I'd advocate for using std::shared_ptr. It's been in gcc since 4.3
>>> (March 2008) and is available for all the major compilers.
>>>
>>
>> You mean a switch to std::shared_ptr throughout DOLFIN?
>>
>>
> Yes.
>
> Are there any important-to-support systems on which this would be a
> problem? All the systems I use have good support for std::shared_ptr.
>
> Garth
>
>
> --
>> Anders
>>
>>
>> >>One option could be to hide the CMake logic within the setup.py
>>> >>file.
>>> >>We could define special build target for ufc configuration and
>>> >>compilation and passsing the arguments to a cmake call. It sounds
>>> >>doable but could probably be quite convoluted...
>>> >>
>>> >>2. UFC just provides the SWIG .i files, and lets the library
>>> >>wanting
>>> >>the SWIG wrappers do the compilation?
>>> >>
>>> >>It is somewhat strange to let another library generate a python
>>> >>extension module.
>>> >
>>> > It will compile the module - the interface code will be in UFC.
>>> >
>>> >Yes, I see that. Should dolfin also be responsible to compile the
>>> >extension modules? That is now done in ufc/utils/build.py.
>>> >
>>> >Johan
>>> >
>>> >
>>> >
>>> >>Garth
>>> >>
>>> >>Johan
>>> >>
>>> >>
>>> >>
>>> >>Garth
>>> >>
>>> >>+ Only DOLFIN uses ufc.h anyway
>>> >>+ Simplifies build system(s)
>>> >>+ More flexibility when changing the code generation interface
>>> >>
>>> >>- No clear versioning that tells us which interface FFC and
>>> >>DOLFIN
>>> >> talk through
>>> >>
>>> >>- UFC was once introduced to solve a problem we had which was
>>> >>that
>>> >> changes were often made to both FFC and DOLFIN and users
>>> >>needed
>>> >> to know which version matched.
>>> >>
>>> >
>>> > Links:
>>> > ------
>>> > [1] http://fenicsproject.org/mailman/listinfo/fenics [2]
>>> > [2]
>>> >http://docs.python.org/2/distutils/setupscript.html#
>>> extension-source-files
>>> >[1]
>>> >
>>> >
>>> >
>>> >Links:
>>> >------
>>> >[1] http://docs.python.org/2/distutils/setupscript.html#
>>> extension-source-files
>>> >[2] http://fenicsproject.org/mailman/listinfo/fenics
>>> _______________________________________________
>>> fenics mailing list
>>> [email protected]
>>> http://fenicsproject.org/mailman/listinfo/fenics
>>>
>> _______________________________________________
> fenics mailing list
> [email protected]
> http://fenicsproject.org/mailman/listinfo/fenics
>
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
