Project

General

Profile

Feature #82

C++11 compatibility questions

Added by John Abbott about 12 years ago. Updated over 1 year ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Portability
Target version:
Start date:
26 Jan 2012
Due date:
% Done:

100%

Estimated time:
1.99 h
Spent time:

Description

THIS HAS BEEN SUPERSEDED BY ISSUE #1225

When CoCoALib is converted to C++11 several aspects of the code will have to be reconsidered.
The purpose of this task is simply to gather a list of these aspects.


Related issues

Related to CoCoA-5 - Design #83: C++11 compatibility questionsIn Progress2012-01-26

Related to CoCoALib - Design #581: C++14: MachineIntClosed2014-07-04

Related to CoCoALib - Feature #1010: C++11: Mario's Hilbert scheme codeNew2017-02-20

Related to CoCoALib - Design #710: Update normaliz interface?In Progress2015-05-17

Related to CoCoALib - Design #999: configuration: include -std=c++03 by default?Closed2017-01-18

Related to CoCoALib - Support #887: My first compilations with clangClosed2016-05-31

Related to CoCoALib - Design #1166: C++11: allows large integer literals (in NumTheory-prime.C)Closed2018-03-12

Related to CoCoALib - Design #894: strict enum types: C++11 extensionIn Progress2016-06-21

Related to CoCoALib - Design #891: Replace auto_ptr in preparation for C++11?Closed2016-06-17

Related to CoCoALib - Bug #867: Compilation Error: C++11 and old GMP-VersionClosed2016-04-13

Related to CoCoALib - Support #861: Janet basis code: TmpJB files give some problems with C++11 (using CLANG/LLVM)Closed2016-03-31

Related to CoCoALib - Design #1225: Move to C++14 (skipping C++11)In Progress2018-09-06

Related to CoCoALib - Design #1242: C++14: Use type auto where appropriateIn Progress2019-02-08

History

#1 Updated by Anna Maria Bigatti about 11 years ago

  • Category set to Portability

#2 Updated by Anna Maria Bigatti almost 10 years ago

  • Target version set to CoCoALib-0.99533 Easter14

#3 Updated by John Abbott almost 10 years ago

  • Target version changed from CoCoALib-0.99533 Easter14 to CoCoALib-1.0

Probably several "efficient" procedures can be eliminated.

  • add, sub, mul, div for RingElem
  • add "move" style ctors to many types
  • eliminate CoCoAVector (see issue #357)

#4 Updated by John Abbott almost 9 years ago

It seems that a few things noted in issue #83 should actually be in this issue.

Apparently C++11 has a way of finding out the name of the function you are in: __func__ behaves like a local variable (of type const char* const). This may be useful when calling CoCoA_ERROR, but note that the standard does not say much about the actual value of the string (so our current manual approach is possibly safer, or at least consistent across different platforms).

#5 Updated by John Abbott almost 8 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10

Mario has found a web page which explains that the preprocessor flag __cpluscplus has a numerical value indicating which version of C++ is supported by the compiler. This appears to be an official part of C++ (but perhaps there is some doubt as to how well it is supported by compilers).

Old C++ corresponds to the value 199711L -- L is needed in case preprocessor is 16bit (I guess).
g++ with the flag -std=c++11 gives the value 201103.

This suggests that we can do something like:

#if __cplusplus < 201100L
 // old code
#else
 // new code
#endif

NOTE I have just made a modification to debug_new.C and it appears to have worked as hoped. :-)

#6 Updated by John Abbott about 7 years ago

  • Related to Feature #1010: C++11: Mario's Hilbert scheme code added

#7 Updated by John Abbott about 7 years ago

How does this issue differ from issue #83?

#8 Updated by John Abbott over 6 years ago

  • Related to Design #710: Update normaliz interface? added

#9 Updated by John Abbott over 6 years ago

  • Related to Design #999: configuration: include -std=c++03 by default? added

#10 Updated by John Abbott over 6 years ago

  • Related to Support #887: My first compilations with clang added

#11 Updated by John Abbott about 6 years ago

  • Related to Design #1166: C++11: allows large integer literals (in NumTheory-prime.C) added

#12 Updated by John Abbott almost 6 years ago

  • Related to Design #894: strict enum types: C++11 extension added

#13 Updated by John Abbott almost 6 years ago

  • Related to Design #891: Replace auto_ptr in preparation for C++11? added

#14 Updated by John Abbott almost 6 years ago

  • Related to Bug #867: Compilation Error: C++11 and old GMP-Version added

#15 Updated by John Abbott almost 6 years ago

  • Related to Support #861: Janet basis code: TmpJB files give some problems with C++11 (using CLANG/LLVM) added

#16 Updated by John Abbott almost 6 years ago

I read somewhere on the internet that it is probably better to jump straight to C++14 rather than to C++11; the argument was that C++14 tied up various loose ends which C++11 had. I do not recall the source, but believe it was reliable.

#17 Updated by John Abbott over 5 years ago

  • Related to Design #1225: Move to C++14 (skipping C++11) added

#18 Updated by John Abbott about 5 years ago

  • Related to Design #1242: C++14: Use type auto where appropriate added

#19 Updated by Anna Maria Bigatti about 5 years ago

Warning with clang:

toric.C:2551:3: warning: 'register' storage class specifier is deprecated and
      incompatible with C++1z [-Wdeprecated-register]
  register  int n, i, BPLen, BLen;
  ^~~~~~~~~

#20 Updated by John Abbott about 3 years ago

  • Target version changed from CoCoALib-1.0 to CoCoALib-0.99850
  • % Done changed from 10 to 20

Do we have progress to report?

#21 Updated by Anna Maria Bigatti almost 3 years ago

John Abbott wrote:

Do we have progress to report?

removed (unused) keyword register from toric.C

#22 Updated by John Abbott over 2 years ago

  • Description updated (diff)

#23 Updated by John Abbott about 2 years ago

  • % Done changed from 20 to 60

#24 Updated by John Abbott over 1 year ago

  • Status changed from In Progress to Closed
  • Assignee set to John Abbott
  • % Done changed from 60 to 100
  • Estimated time set to 1.99 h

There is a big bold comment in the main descr saying that this issue has been superseded by #1225.
For this reason I am closing this issue; also I am not sure how it differs from #82

Also available in: Atom PDF