Archived issue #0032957

[REGRESSION] Coding - problem compile OCCT using vc12 due to `noexcept`

Open CASCADEOCCT:Codingclosed22 public notes

Search issues

Description

Steps to reproduce

Not required

Public activity

22 archived notes

Participants are labeled by their role within this record.

01Commenter 2
Branch [archived branch] has been created by Participant.

[revision removed]


Detailed log of new commits:

Author: ddzama
Date: Tue May 24 11:22:26 2022 +0300

    Employ Standard_Noexcept

Author: ddzama
Date: Fri Jun 3 04:56:33 2022 +0300

    0032957: add /Zc:__cplusplus option to MSVC

Author: ddzama
Date: Tue May 24 11:12:23 2022 +0300

    Add Standard_Noexcept.hxx
02Commenter 2
Branch [archived branch] has been updated forcibly by Participant.

[revision removed]
03Commenter 2
Branch [archived branch] has been updated forcibly by Participant.

[revision removed]
04Commenter 2
Branch [archived branch] has been updated forcibly by Participant.

[revision removed]
05Commenter 2
Branch [archived branch] has been updated forcibly by Participant.

[revision removed]
06Commenter 3
07Commenter 5
Commenter 6

> 0032957: Add Standard_Noexcept.hxx

It doesn't look worthwhile declaring this temporary compatibility macros within a separate header file.
Other similar macros are currently defined within `Standard_Macro.hxx`.

> 0032957: Employ Standard_Noexcept

This commit should be merged with the one introducing new macros.

> 0032957: add /Zc:__cplusplus option to MSVC

This change should be suggested as a separate integration ticket.
Moreover, commit description doesn't clarify why this change is required / preferable at all.
I'm not sure that we want adding this flag at all.

+# So, it should compiles with c++11/c++14 language standard.

`should be compiled`.

+# Current Qt version is incompatible with c++20.

Which exactly `current version` is mentioned here?
Please be more specific in the code, not just in git commit description.

because of incomatibility of 5.11.2 version of Qt library interface with C++20 standard.

`incomatibility` misprint.
Qt 5 is NOT the latest version of this library, users are already using Qt 6 in some projects.

+set_property(TARGET ${PROJECT_NAME} PROPERTY CXX_STANDARD 11)
\ No newline at end of file

Please add suggested newlines.
These repetitive hacks in individual projects looks fragile - it would be better unifying this somehow.
08Commenter 3
Commenter 3, about

> 0032957: add /Zc:__cplusplus option to MSVC

This change should be suggested as a separate integration ticket.
Moreover, commit description doesn't clarify why this change is required / preferable at all.
I'm not sure that we want adding this flag at all.

This options set macro variable __cplusplus enabled in MSVC since 2015 (vc14). This definition macro define information about currently used c++ standard.
Unfortunately, this is just a rudiment of this ticket.
And maybe it is worth to get rid of it, at least in this ticket.
09Commenter 2
Branch [archived branch] has been updated forcibly by Participant.

[revision removed]
10Commenter 2
Branch [archived branch] has been updated forcibly by Participant.

[revision removed]
11Commenter 2
Branch [archived branch] has been updated forcibly by Participant.

[revision removed]
12Commenter 3
Commenter 3, Commenter 4 - i update this branch - please review it.

Jenkins tests results:

http://jenkins-test-occt.nnov.opencascade.com/view/occt-CR32887-occ-pr-CR32887-by-ddzama/view/COMPARE/
13Commenter 3
Commenter 3, please do not take into account occ products last commit of branch CR32887 - it's part of other ticket.
14Commenter 5
Commenter 6,
+//! if noexcept is accessible, Standard_Noexcept is "noexcept" and "throw()" otherwise.
+#ifdef _MSC_VER
+  #if _MSC_VER >= 1900
+    #define Standard_Noexcept noexcept
+  #else
+    #define Standard_Noexcept throw()
+  #endif

Does it make any sense to put "throw()" as fallback? Wouldn't be an empty macros better in this context?
15Commenter 3
Commenter 3, sorry, i thought about it: see, in this context yes, but if user will use Standard_Noexcept for his particular case, it will mislead him about what does it mean.
Because 'throw()' is a synonim of 'noexcept' for c++ standards before c++11. And normal support of noexcept qualifier starts from vc140.
16Commenter 3
Commenter 3, maybe create clone of this macros Standard_Noexcept_Desirable with such definition:
  #if _MSC_VER >= 1900
    #define Standard_Noexcept_Desirable noexcept
  #else
    #define Standard_Noexcept_Desirable
  #endif
for cases when we just want to suppress visual studio compiler warnings, as in out case?
17Commenter 5
Commenter 6, OK, let's keep it simple.

Please raise
- OCCT: last commit in branch CR32957;
- OCC Products: none.
18Commenter 2
Branch [archived branch] has been updated forcibly by Participant.

[revision removed]
19Commenter 3
Commenter 3,
OCCT Branch [archived branch] has been rebased on master,
OCC Pr branch alreaby based on master.
20Commenter 20
Combination -
OCCT branch : [archived branch]
master SHA - changes and them, and you can discard any commits you make in this
[revision removed]
changes and them, and you can discard any commits you make in this
[revision removed]
Products branch : [archived branch] SHA - [revision removed]
was compiled on Linux, MacOS and Windows platforms and tested in optimize mode.

Number of compiler warnings:
No new/fixed warnings

Regressions/Differences/Improvements:
No regressions/differences

CPU differences:
Debian80-64:
OCCT
Total CPU difference: 18736.06000000064 / 18724.320000000742 [+0.06%]
Products
Total CPU difference: 11972.270000000151 / 11976.950000000106 [-0.04%]
Windows-64-VC14:
OCCT
Total CPU difference: 20773.21875 / 20769.1875 [+0.02%]
Products
Total CPU difference: 13548.546875 / 13536.125 [+0.09%]


Image differences :
No differences that require special attention

Memory differences :
No differences that require special attention
21Commenter 2
Branch [archived branch] has been deleted by Participant.

[revision removed]
22Commenter 7
Commenter 6, after quick review of the Standard_Macro I find only Standard_[UPPERCASE] macros.
Why did you choose the current naming type?

Related records