pynac may require C++11 in Sage

[Ralf Stephan]

Hello,

with C++11 unique_ptr in a pynac develment version I get in Sage:

gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -fPIC -I/home/ralf/sage/local/include -I/home/ralf/sage/src -I/home/ralf/sage/src/c_lib/include -I/home/ralf/sage/src/sage/ext -I/home/ralf/sage/local/lib/python2.7/site-packages/numpy/core/include -I/home/ralf/sage/local/include/python2.7 -c build/cythonized/sage/symbolic/getitem.cpp -o build/temp.linux-x86_64-2.7/build/cythonized/sage/symbolic/getitem.o -fno-strict-aliasing -w -fno-tree-dominator-opts
In file included from ../local/include/pynac/pseries.h:27:0,
                 from ../local/include/pynac/ginac.h:46,
                 from build/cythonized/sage/symbolic/ginac_wrap.h:11,
                 from build/cythonized/sage/symbolic/getitem.cpp:350:
../local/include/pynac/expairseq.h:161:2: error: ‘unique_ptr’ in namespace ‘std’ does not name a type

pynac master already introduces C++11 code internally (typeid.hash_code() is C+11)

but will require it also for Sage with a pending commit because of included headers

containing the bugfree auto_ptr replacement unique_ptr.

Now, I can maintain a pynac branch with auto_ptr indefinitely but would not like to.

It's not that C++11 is bleeding edge, there is already C++14 (released on December 15,

2014) and C++17.

So, is there any reason not to make C++11 mandatory in Sage? The way to do it is this m4 macro:

https://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx_11.html

Regards,

[Jean-Pierre Flori]

Latest NTL releases also require C++11.

[leif]

On 04/28/2015 10:23 AM, Ralf Stephan wrote:
> So, is there any reason not to make C++11 mandatory in Sage?

This probably "just" implies SAGE_INSTALL_GCC=yes on more platforms.

Anyway, IMHO each package should check whether C++11 is supported.
(We'd still have to deal with that in some extension modules'
extra_compile_args(?) for a while.)


-leif

[Ralf Stephan]

On Tuesday, April 28, 2015 at 6:03:26 PM UTC+2, leif wrote:

On 04/28/2015 10:23 AM, Ralf Stephan wrote:
> So, is there any reason not to make C++11 mandatory in Sage?

(We'd still have to deal with that in some extension modules'
extra_compile_args(?) for a while.)

http://trac.sagemath.org/ticket/18323 

[Ralf Stephan]

On Tuesday, April 28, 2015 at 6:03:26 PM UTC+2, leif wrote:

Anyway, IMHO each package should check whether C++11 is supported.

That may not be sufficient because headers from eg pynac are included

in cythonized files and so errors are generated there. When adding the C++11

switch to the compile flags other files whose headers require pre-C++11

will barf. See the above ticket.

[John Cremona]

On 28 April 2015 at 17:03, leif <not.r...@online.de> wrote:
> On 04/28/2015 10:23 AM, Ralf Stephan wrote:
>> So, is there any reason not to make C++11 mandatory in Sage?
>
> This probably "just" implies SAGE_INSTALL_GCC=yes on more platforms.
>
> Anyway, IMHO each package should check whether C++11 is supported.

eclib does now compile under C++-11 . It did not before because I had
the temerity to call a function rank() which is now not allowed. My
fault for not using my own namespaces, I suppose.

I have not yet made a new spkg for the new version of eclib which does
this, but will do.

John

> (We'd still have to deal with that in some extension modules'
> extra_compile_args(?) for a while.)
>
>
> -leif
>
>

> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

[leif]

Which is what I meant by "(We'd still have to deal with that in some
extension modules' extra_compile_args(?) for a while.)", and that
doesn't exclude fixing some packages w.r.t. deprecated or non-standard
features.

Also, earlier versions of g++ do not *default* to C++11, so we'd
(currently) have to add appropriate flags in module_list.py as well.


-leif

P.S.: While the GCC 4.6 and 4.7 series reached "end of life", there are
still (LTS) releases using these.

[Volker Braun]

+1 to requiring C++11 support.

IMHO that added a number of really nice refinements of the language, if you aren't using it yet for a C++ project then you are making a mistake.

[Thierry Dumont]

Le 29/04/2015 02:28, Volker Braun a écrit :
> +1 to requiring C++11 support.
>
> IMHO that added a number of really nice refinements of the language, if
> you aren't using it yet for a C++ project then you are making a mistake.
>
>
>

+1
I am developing extensively in C++: C++11 offers many interesting
improvements for programming maths; among them:
- auto keyword, very intereseting for generic programming
- an augmented stl with, for example a very complete system of random
generators.
-...

[leif]

On 04/29/2015 08:01 AM, Thierry Dumont wrote:
> Le 29/04/2015 02:28, Volker Braun a écrit :
>> +1 to requiring C++11 support.
>>
>> IMHO that added a number of really nice refinements of the language, if
>> you aren't using it yet for a C++ project then you are making a mistake.
>>
>>
>>
>
> +1
> I am developing extensively in C++: C++11 offers many interesting
> improvements for programming maths; among them:
> - auto keyword, very intereseting for generic programming

'auto' has *always* been a keyword in C (and hence also C++), although
hardly ever used (because it's the /default/ storage class).

In C++11, the meaning changed, in a backwards-incompatible way, so using
'-std=c++11' may actually break existing code (in theory at least).

Just saying...


-leif