MantisBT - Doomseeker
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003803Doomseeker[All Projects] Epicpublic2020-06-07 02:282020-06-08 02:06
ReporterWubTheCaptain 
Assigned To 
PrioritynoneSeverityfeatureReproducibilityN/A
StatusconfirmedResolutionopen 
PlatformOSOS Version
Product Version1.3 
Target VersionFixed in Version 
Summary0003803: C++11 support
DescriptionSome child issues which feature C++11 features to replace the old C++98 features in use by Doomseeker.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0003794closed WubTheCaptain qt-json is older than aa0930a (stray #include <iostream>) 
related to 0003598closed Zalewa Change Windows compiler 
parent of 0003801closed WubTheCaptain new/delete used instead of std::unique_ptr/std::make_unique 
parent of 0003800acknowledged  C-style arrays in C++ source files 
parent of 0003805closed WubTheCaptain CXX_STANDARD needs to be updated for C++11 
parent of 0003807confirmed  Some for(...; ...; ...) loops are not range-based loops (C++11), but C-style 
parent of 0003812acknowledged  Some null pointer constants use 0 instead of the C++11 nullptr keyword 
parent of 0003813confirmed  C style "typedef" is used instead of C++ style "using" keyword (C++11) 
Not all the children of this issue are yet resolved or closed.
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2020-06-07 02:28WubTheCaptainNew Issue
2020-06-07 02:29WubTheCaptainRelationship addedparent of 0003801
2020-06-07 02:29WubTheCaptainRelationship addedparent of 0003800
2020-06-07 02:29WubTheCaptainRelationship addedrelated to 0003794
2020-06-07 02:31WubTheCaptainSummaryC+11 support => C++11 support
2020-06-07 02:32WubTheCaptainRelationship addedrelated to 0003598
2020-06-07 02:50WubTheCaptainRelationship addedparent of 0003805
2020-06-07 03:00WubTheCaptainProduct Version1.3.1 => 1.3
2020-06-07 03:29WubTheCaptainRelationship addedparent of 0003807
2020-06-07 04:51WubTheCaptainRelationship addedparent of 0003812
2020-06-07 05:03WubTheCaptainRelationship addedparent of 0003813
2020-06-07 05:07WubTheCaptainNote Added: 0021365
2020-06-07 20:33Pol MNote Added: 0021387
2020-06-07 20:33Pol MStatusnew => feedback
2020-06-07 22:38WubTheCaptainNote Added: 0021397
2020-06-07 22:38WubTheCaptainStatusfeedback => new
2020-06-07 22:51Pol MNote Added: 0021398
2020-06-07 23:04WubTheCaptainStatusnew => confirmed
2020-06-08 00:31Blzut3Note Added: 0021401
2020-06-08 02:06Pol MNote Added: 0021411

Notes
(0021365)
WubTheCaptain   
2020-06-07 05:07   
Interestingly, nullptr keyword has been used for a long time. It's a C++11 feature. Wonderful if it's been supported by some older Microsoft compilers, before the switch to MinGW.
(0021387)
Pol M   
2020-06-07 20:33   
We are already using the C++11 standard
(0021397)
WubTheCaptain   
2020-06-07 22:38   
Quote from Pol M
We are already using the C++11 standard

Yes, but as seen from child issues this can be further improved.
(0021398)
Pol M   
2020-06-07 22:51   
Quote from Wub

Yes, but as seen from child issues this can be further improved.

C++ introduces new ways of doing the same things but better each version. That does not mean that necessarily all the code that did things the old way needs to be changed :)
That said, sure, let's adapt your proposed changes :D
(0021401)
Blzut3   
2020-06-08 00:31   
Generally speaking old code bases don't find and replace everything when a new standard comes out since 1) it's usually fixing non-broken code. 2) Needlessly points git blame to an unhelpful commit.

Almost everything you point out isn't wrong, and is indeed how code should be written going forward. But is this solving something? Now I've been busy with other stuff so I'm not going to tell you all not to do this if it's something that motivates you all, but do consider that such refactors are unusual.
(0021411)
Pol M   
2020-06-08 02:06   
I completely agree with Blzut, but if Wub is committed to doing these changes I won't be stopping nobody since right now there is no merge issues that could appear. I'll state that 0003801, 0003807, 0003813 and 0003800 are clear cases of what Blzut explains, then there's 0003811 that theoretically allows for optimizations but any mothern compiler can see through these so it's a bit on the limbo and then there's most (not saying all) of the others that do have some value either by making the code safer, objectively more readable, or are simply better.