- UNINSTALL DOSBOX INSTALL
- UNINSTALL DOSBOX PATCH
- UNINSTALL DOSBOX SOFTWARE
- UNINSTALL DOSBOX CODE
- UNINSTALL DOSBOX ISO
So again the analyser is too limited or our code too messy to follow.
UNINSTALL DOSBOX ISO
(fstype can be fat,iso,none (checked above) and when the image is created it is branched through an "else" (which is actually fstype=none as fat and iso are checked before) and the deletion code (that the analyser skips is guarded by fstype=none).
UNINSTALL DOSBOX SOFTWARE
You couldn't find one ? Ha, I am stuck with much older software for various reasons, so think in that direction :)Īnyway, no reason to change to requirements over fixing a memory leak that can't happen, but the analyzer can't figure that out. I added it to my local tree and it will end up in dosbox, when commit something approriate. But it has no hurry as our code is fine in that instance.
UNINSTALL DOSBOX PATCH
You don't need to submit a new patch for that. Although maybe the virtual function could change the this pointer. So it is easier to always give a warning if they see a class with a virtual function, without virtual destructor being deleted. The pointers are even static, but I have to admit that the correct check would quite the nightmare to implement. The warning program is being too sensitive and/or too limited to check that the class being deleted matches the polymorphic class. I read the comment and hence me asking why it generates a warning as there is nothing wrong with the dosbox code.
UNINSTALL DOSBOX INSTALL
Or you could install Linux on that old machine and use DOSBox 0.75.x just fine. If it's totally not acceptable, then please state if I should target C++03, C++98 or something older in future patches? Also, please note that Visual Studio does not support enforcing anything older than C++14 at all - so sticking to old standard will be an inconvenience to future contributors, and this topic will keep coming back.ĭo you know if current trunk version of DOSBox works on PPC OSX? When was the last time it was tested? I am arguing for using new standard only for DOSBox >= 0.75.x, you would still be able to compile and use 0.74.x branch to emulate games from 25+ years ago on a machine from 15+ years ago. I would ask you to reconsider C++11 support (it makes the language much nicer to use - and you wouldn't need to keep removing C++11 features from code merged from other projects). Which IDE is it exactly? I am genuinely curious as I couldn't find one. Should I upload a revised version of this patch? If you prefer to have user defined empty destructor in there, it's fine by me - I care about removing these warnings. cpp : 161 : 18 : warning : deleting object of polymorphic class type ‘ saa1099_device ’ which has non - virtual destructor might cause undefined behavior 161 | delete device | ^ cpp : 160 : 18 : warning : deleting object of polymorphic class type ‘ saa1099_device ’ which has non - virtual destructor might cause undefined behavior 160 | delete device | ^ gameblaster. cpp : In destructor ‘ virtual CMS :: ~ CMS () ’ : gameblaster. Patch 6: using =default to mark destructor as virtual, without actually introducing empty user-defined constructor in there, thus vtable should stay the same as it is now, but compiler will ensure correct behaviour for subclasses (there is no way to ensure this compiler behaviour pre C++11 AFAIK).Īh, forgot to mention it with the submission - I intend these changes only for trunk and not to be backported to 0.74 branch. Patch 5: using to prevent memory leak, even if later someone will introduce new return statements in this function. In this particular patch series, patches 1, 2, 3 do not depend on C++11, while patches 5 and 6 do. For example: I had my changes working just fine on my local machine using the default compiler for my distro (GCC9) just to discover, that my changes do not compile in older Steam Runtime environment (GCC5.4) and it was not because of lack of support in the compiler - it was because of missing compiler flag enabling said support :).
Also, autoconf-archive in Ubuntu 16.04 does not supply the macro for C++14 (compiler supports it, just autoconf packages are outdated there - they support C++11 though - it was 5 year old at the time).īy not setting baseline standard in the code, it is harder to maintain cross-compiler support nowadays.
C++11, not C11 (these are different standards) every modern compiler uses C++14 as the default C++ standard nowadays - I thought about setting it to C++14, but some really, really, old compilers might not support it (I couldn't find one, but I bet someone would) - I think using 8-year old version of the language is reasonable in 2019.
0 kommentar(er)
