[src\C4Application.cpp:57]: (warning) Member variable 'C4Application::pGameTimer' is not initialized in the constructor.
[src\C4Application.cpp:780]: (warning) Member variable 'C4ApplicationGameTimer::fRecursing' is not initialized in the constructor.
[src\control\C4Control.cpp:455]: (error) Possible null pointer dereference: pSyncCheck - otherwise it is redundant to check if pSyncCheck is null at line 456
[src\control\C4GameParameters.cpp:370]: (warning) Member variable 'C4GameParameters::IsNetworkGame' is not initialized in the constructor.
[src\control\C4GameParameters.cpp:370]: (warning) Member variable 'C4GameParameters::AllowDebug' is not initialized in the constructor.
[src\control\C4PlayerControl.h:184]: (warning) Member variable 'C4PlayerControlAssignment::fComboIsSequence' is not initialized in the constructor.
[src\control\C4Control.h:140]: (warning) Member variable 'C4ControlScript::fUseVarsFromCallerContext' is not initialized in the constructor.
[src\control\C4Control.h:275]: (warning) Member variable 'C4ControlClientUpdate::eType' is not initialized in the constructor.
[src\control\C4Control.h:324]: (warning) Member variable 'C4ControlJoinPlayer::fByRes' is not initialized in the constructor.
[src\control\C4Control.h:354]: (warning) Member variable 'C4ControlEMMoveObject::eAction' is not initialized in the constructor.
[src\control\C4Control.h:381]: (warning) Member variable 'C4ControlEMDrawTool::eAction' is not initialized in the constructor.
[src\control\C4Control.h:381]: (warning) Member variable 'C4ControlEMDrawTool::fIFT' is not initialized in the constructor.
[src\control\C4Control.h:429]: (warning) Member variable 'C4ControlRemovePlr::fDisconnected' is not initialized in the constructor.
[src\control\C4PlayerControl.cpp:332]: (performance) Possible inefficient checking for 'KeyCombo' emptiness.
[src\control\C4PlayerInfoConflicts.cpp:152]: (warning) Member variable 'C4PlayerInfoListAttributeConflictResolver::pResolvePacket' is not initialized in the constructor.
[src\control\C4PlayerInfoConflicts.cpp:152]: (warning) Member variable 'C4PlayerInfoListAttributeConflictResolver::fAnyChange' is not initialized in the constructor.
[src\control\C4PlayerInfoConflicts.cpp:152]: (warning) Member variable 'C4PlayerInfoListAttributeConflictResolver::pResolveInfo' is not initialized in the constructor.
[src\control\C4PlayerInfoConflicts.cpp:152]: (warning) Member variable 'C4PlayerInfoListAttributeConflictResolver::fCurrentConflict' is not initialized in the constructor.
[src\control\C4PlayerInfoConflicts.cpp:152]: (warning) Member variable 'C4PlayerInfoListAttributeConflictResolver::fOriginalConflict' is not initialized in the constructor.
[src\control\C4PlayerInfoConflicts.cpp:152]: (warning) Member variable 'C4PlayerInfoListAttributeConflictResolver::fAlternateConflict' is not initialized in the constructor.
[src\control\C4PlayerInfoConflicts.cpp:152]: (warning) Member variable 'C4PlayerInfoListAttributeConflictResolver::pLowPrioOriginalConflictPacket' is not initialized in the constructor.
[src\control\C4PlayerInfoConflicts.cpp:152]: (warning) Member variable 'C4PlayerInfoListAttributeConflictResolver::pLowPrioAlternateConflictPacket' is not initialized in the constructor.
[src\control\C4Record.cpp:638]: (performance) Prefer prefix ++/-- operators for non-primitive types.
[src\control\C4Record.cpp:671]: (performance) Prefer prefix ++/-- operators for non-primitive types.
[src\control\C4Record.cpp:685]: (performance) Prefer prefix ++/-- operators for non-primitive types.
[src\control\C4Record.cpp:808]: (performance) Prefer prefix ++/-- operators for non-primitive types.
[src\control\C4Record.cpp:838]: (performance) Prefer prefix ++/-- operators for non-primitive types.
[src\control\C4Record.cpp:842]: (performance) Prefer prefix ++/-- operators for non-primitive types.
[src\control\C4Record.cpp:852]: (performance) Prefer prefix ++/-- operators for non-primitive types.
[src\control\C4Record.cpp:935]: (performance) Prefer prefix ++/-- operators for non-primitive types.
[src\control\C4Record.cpp:1233]: (performance) Prefer prefix ++/-- operators for non-primitive types.
[src\editor\C4Console.cpp:266]: (style) Variable 'fOkay' is assigned a value that is never used
[src\editor\C4ConsoleGUICommon.h:20]: (warning) Member variable 'C4ConsoleGUI::Editing' is not initialized in the constructor.
[src\editor\C4ConsoleGUICommon.h:20]: (warning) Member variable 'C4ConsoleGUI::fGameOpen' is not initialized in the constructor.
[src\editor\C4ConsoleGUICommon.h:20]: (warning) Member variable 'C4ConsoleGUI::PropertyDlgObject' is not initialized in the constructor.
[src\editor\C4ConsoleWin32.cpp:897]: (performance) Prefer prefix ++/-- operators for non-primitive types.
[src\editor\C4EditCursor.cpp:621]: (style) Variable 'fObjectSelected' is assigned a value that is never used
[src\game\landscape\C4LandscapeRender.cpp:212]: (style) Variable 'pSurface' is assigned a value that is never used
[src\game\landscape\C4LandscapeRender.cpp:405]: (style) Variable 'iMat' is assigned a value that is never used
[src\game\landscape\C4MapCreatorS2.cpp:799]: (style) Exception should be caught by reference.
[src\game\landscape\C4MapCreatorS2.cpp:815]: (style) Exception should be caught by reference.
[src\game\object\C4ObjectPtr.h:32]: (warning) Member variable 'C4ObjectPtr::fDenumerated' is not initialized in the constructor.
[src\game\object\C4ObjectPtr.h:32]: (warning) Member variable 'C4ObjectPtr::data' is not initialized in the constructor.
[src\game\object\C4ObjectPtr.h:61]: (style) 'C4ObjectPtr::operator=' should return 'C4ObjectPtr &'
[src\game\object\C4Sector.h:41]: (warning) Member variable 'C4LSector::x' is not initialized in the constructor.
[src\game\object\C4Sector.h:41]: (warning) Member variable 'C4LSector::y' is not initialized in the constructor.
[src\game\object\C4Sector.h:96]: (warning) Member variable 'C4LArea::xL' is not initialized in the constructor.
[src\game\object\C4Sector.h:96]: (warning) Member variable 'C4LArea::yL' is not initialized in the constructor.
[src\game\object\C4Sector.h:96]: (warning) Member variable 'C4LArea::dpitch' is not initialized in the constructor.
[src\game\script\C4GameScript.cpp:1270]: (warning) Member variable 'C4ValueCompiler::iDepth' is not initialized in the constructor.
[src\game\script\C4GameScript.cpp:1270]: (warning) Member variable 'C4ValueCompiler::iMatchStart' is not initialized in the constructor.
[src\game\script\C4GameScript.cpp:1270]: (warning) Member variable 'C4ValueCompiler::iMatchCount' is not initialized in the constructor.
[src\gui\C4Gui.h:1799]: (portability) Extra qualification 'ContextMenu::' unnecessary and considered an error by many compilers.
[src\gui\C4Gui.h:2753] -> [src\C4Prototypes.h:149]: (style) Typedef 'C4GUIScreen' hides typedef with same name
[src\gui\C4Gui.h:1844]: (style) The class 'ComboBox_FillCB' does not have a constructor.
[src\gui\C4ChatDlg.cpp:618]: (style) Variable 'pIRCChan' is assigned a value that is never used
[src\gui\C4GameOverDlg.cpp:171]: (style) Variable 'szNetResult' is assigned a value that is never used
[src\gui\C4KeyboardInput.cpp:597]: (style) Variable 'shift_idx' is assigned a value that is never used
[src\gui\C4LoaderScreen.cpp:153]: (information) The scope of the variable 'iLogBoxMargin' can be reduced
[src\gui\C4LoaderScreen.cpp:158]: (information) The scope of the variable 'fLogBoxFontZoom' can be reduced
[src\gui\C4PlayerInfoListBox.cpp:1365]: (style) Variable 'fAnyPlayers' is assigned a value that is never used
[src\gui\C4PlayerInfoListBox.cpp:1391]: (style) Variable 'fAnyPlayers' is assigned a value that is never used
[src\gui\C4StartupOptionsDlg.cpp:278]: (error) Possible null pointer dereference: assignment - otherwise it is redundant to check if assignment is null at line 276
[src\gui\C4StartupOptionsDlg.cpp:365]: (style) Variable 'pUseFont' is assigned a value that is never used
[src\gui\C4Viewport.cpp:682]: (error) Possible null pointer dereference: pPlr - otherwise it is redundant to check if pPlr is null at line 691
[src\gui\C4Viewport.cpp:686]: (error) Possible null pointer dereference: pPlr - otherwise it is redundant to check if pPlr is null at line 691
[src\gui\C4Viewport.cpp:702]: (error) Possible null pointer dereference: pPlr - otherwise it is redundant to check if pPlr is null at line 691
[src\gui\C4Viewport.cpp:704]: (error) Possible null pointer dereference: pPlr - otherwise it is redundant to check if pPlr is null at line 691
[src\lib\C4RTF.cpp:29]: (warning) Member variable 'C4RTFFile::fSkipDestIfUnknownKeyword' is not initialized in the constructor.
[src\lib\StdBuf.h:52]: (warning) Member variable 'StdBuf::pMData' is not initialized in the constructor.
[src\lib\StdBuf.h:52]: (warning) Member variable 'StdBuf::szString' is not initialized in the constructor.
[src\lib\StdBuf.h:57]: (warning) Member variable 'StdBuf::szString' is not initialized in the constructor.
[src\lib\StdBuf.h:89]: (warning) Member variable 'StdBuf::szString' is not initialized in the constructor.
[src\lib\StdBuf.h:340]: (warning) Member variable 'StdBuf::szString' is not assigned a value in 'StdBuf::operator='
[src\lib\StdCompiler.h:53]: (warning) Member variable 'StdCompiler::pWarnData' is not initialized in the constructor.
[src\lib\StdCompiler.h:692]: (warning) Member variable 'NameNode::Section' is not initialized in the constructor.
[src\lib\StdCompiler.h:692]: (warning) Member variable 'NameNode::Pos' is not initialized in the constructor.
[src\lib\C4Real.h:129]: (style) 'C4Fixed::operator=' should return 'C4Fixed &'
[src\lib\C4Stat.cpp:132]: (error) Mismatching allocation and deallocation: bHS
[src\lib\Standard.cpp:78]: (information) The scope of the variable 'xincr' can be reduced
[src\lib\Standard.cpp:78]: (information) The scope of the variable 'yincr' can be reduced
[src\lib\StdBuf.cpp:231]: (style) Variable 'pPos' is assigned a value that is never used
[src\lib\StdCompiler.cpp:850]: (error) Using sizeof with a numeric constant as function argument might not be what you intended.
[src\lib\StdCompiler.cpp:415]: (warning) Member variable 'StdCompilerINIRead::pName' is not initialized in the constructor.
[src\lib\StdCompiler.cpp:415]: (warning) Member variable 'StdCompilerINIRead::pPos' is not initialized in the constructor.
[src\lib\StdCompiler.cpp:415]: (warning) Member variable 'StdCompilerINIRead::pReenter' is not initialized in the constructor.
[src\lib\StdMarkup.cpp:38]: (information) The scope of the variable 'iParLen' can be reduced
[src\lib\StdMesh.cpp:123]: (error) Possible null pointer dereference: svp - otherwise it is redundant to check if svp is null at line 122
[src\lib\StdMesh.cpp:126]: (error) Possible null pointer dereference: id - otherwise it is redundant to check if id is null at line 124
[src\lib\StdMesh.h:89]: (style) The class 'StdMeshMatrix' does not have a constructor.
[src\lib\StdMesh.h:151]: (warning) Member variable 'StdMeshBone::Index' is not initialized in the constructor.
[src\lib\StdMesh.h:151]: (warning) Member variable 'StdMeshBone::ID' is not initialized in the constructor.
[src\lib\StdMesh.h:151]: (warning) Member variable 'StdMeshBone::Transformation' is not initialized in the constructor.
[src\lib\StdMesh.h:151]: (warning) Member variable 'StdMeshBone::InverseTransformation' is not initialized in the constructor.
[src\lib\StdMesh.h:214]: (warning) Member variable 'StdMeshAnimation::Length' is not initialized in the constructor.
[src\lib\StdMesh.h:420]: (performance) Possible inefficient checking for 'IDs' emptiness.
[src\lib\StdMeshLoaderBinaryChunks.h:385]: (warning) Member variable 'ChunkMesh::bounds' is not initialized in the constructor.
[src\lib\StdMeshLoaderBinaryChunks.h:409]: (warning) Member variable 'ChunkSubmesh::hasSharedVertices' is not initialized in the constructor.
[src\lib\StdMeshLoaderBinaryChunks.h:286]: (warning) Member variable 'ChunkBase<ChunkID>::size' is not initialized in the constructor.
[src\lib\StdMeshMaterial.h:335]: (style) 'Iterator::operator=' should return 'Iterator &'
[src\lib\StdMeshLoaderXml.cpp:347]: (error) Possible null pointer dereference: bone - otherwise it is redundant to check if bone is null at line 342
[src\lib\texture\C4Surface.cpp:117]: (information) The scope of the variable 'max_scale' can be reduced
[src\netio\TstC4NetIO.cpp:46]: (style) The class 'MyCBClass' does not have a constructor.
[src\network\C4NetIO.cpp:2066]: (style) Variable 'fSuccess' is assigned a value that is never used
[src\network\C4NetIO.cpp:2609]: (warning) Redundant assignment of "iRIMCPacketCounter" to itself
[src\network\C4NetIO.cpp:276]: (warning) Member variable 'C4NetIOTCP::Pipe' is not initialized in the constructor.
[src\network\C4NetIO.cpp:1296]: (warning) Member variable 'C4NetIOSimpleUDP::Pipe' is not initialized in the constructor.
[src\network\C4NetIO.cpp:1296]: (warning) Member variable 'C4NetIOSimpleUDP::fMCLoopback' is not initialized in the constructor.
[src\network\C4NetIO.cpp:1296]: (warning) Member variable 'C4NetIOSimpleUDP::pCB' is not initialized in the constructor.
[src\network\C4NetIO.cpp:1788]: (warning) Member variable 'C4NetIOUDP::pCB' is not initialized in the constructor.
[src\network\C4NetIO.cpp:2477]: (warning) Member variable 'Peer::fConnFailCallback' is not initialized in the constructor.
[src\network\C4NetIO.cpp:2477]: (warning) Member variable 'Peer::iLastPacketAsked' is not initialized in the constructor.
[src\network\C4NetIO.cpp:2477]: (warning) Member variable 'Peer::iLastMCPacketAsked' is not initialized in the constructor.
[src\network\C4NetIO.cpp:2477]: (warning) Member variable 'Peer::iTimeout' is not initialized in the constructor.
[src\network\C4NetIO.cpp:2477]: (warning) Member variable 'Peer::iRetries' is not initialized in the constructor.
[src\network\C4NetIO.cpp:1788]: (warning) Member variable 'C4NetIOUDP::hDebugLog' is not initialized in the constructor.
[src\network\C4Network2Client.h:62]: (style) 'C4Network2Address::operator=' should return 'C4Network2Address &'
[src\network\C4Network2IRC.cpp:64]: (warning) Member variable 'C4Network2IRCUser::Next' is not initialized in the constructor.
[src\network\C4Network2IRC.cpp:72]: (warning) Member variable 'C4Network2IRCChannel::Next' is not initialized in the constructor.
[src\network\C4Network2IRC.cpp:188]: (warning) Member variable 'C4Network2IRCClient::pLogLastRead' is not initialized in the constructor.
[src\network\C4Network2Players.cpp:273]: (style) Variable 'pSaveInfo' is assigned a value that is never used
[src\network\C4Packet2.cpp:433]: (warning) Member variable 'C4PacketConnRe::fOK' is not initialized in the constructor.
[src\network\C4Packet2.cpp:433]: (warning) Member variable 'C4PacketConnRe::fWrongPassword' is not initialized in the constructor.
[src\platform\C4MusicSystem.cpp:235]: (style) Variable 'szExt' is assigned a value that is never used
[src\platform\C4SoundLoaders.h:39]: (warning) Member variable 'SoundInfo::sample_length' is not initialized in the constructor.
[src\platform\C4SoundLoaders.cpp:139]: (style) Unused variable: spaceToEOF
[src\platform\C4Video.cpp:263]: (style) Variable 'iWidth' is assigned a value that is never used
[src\platform\C4ViewportWindow.cpp:255]: (style) Variable 'fMinimized' is assigned a value that is never used
[src\platform\C4ViewportWindow.cpp:256]: (style) Variable 'fMaximized' is assigned a value that is never used
[src\platform\StdWindow.h:253] -> [src\platform\StdApp.h:36]: (style) Struct 'Display' hides typedef with same name
[src\platform\StdD3D.cpp:834]: (information) The scope of the variable 'sp' can be reduced
[src\platform\StdD3D.cpp:890]: (information) The scope of the variable 'sp' can be reduced
[src\platform\StdDDraw2.cpp:611]: (style) Variable 'scaleX2' is assigned a value that is never used
[src\platform\StdDDraw2.cpp:612]: (style) Variable 'scaleY2' is assigned a value that is never used
[src\platform\StdFile.cpp:813]: (error) Resource leak: d
[src\platform\StdFont.cpp:504]: (information) The scope of the variable 'iCharWdt' can be reduced
[src\platform\StdFont.cpp:660]: (information) The scope of the variable 'iCharWdt' can be reduced
[src\platform\StdGLCtx.cpp:435]: (style) Variable 'i' is assigned a value that is never used
[src\platform\StdRegistry.cpp:77]: (style) Variable 'qerr' is assigned a value that is never used
[src\platform\StdRegistry.cpp:133]: (style) Variable 'qerr' is assigned a value that is never used
[src\platform\StdSDLApp.cpp:43]: (warning) Member variable 'CStdApp::KeyMask' is not initialized in the constructor.
[src\platform\StdSDLApp.cpp:43]: (warning) Member variable 'CStdApp::dpy' is not initialized in the constructor.
[src\platform\StdSDLApp.cpp:43]: (warning) Member variable 'CStdApp::xf86vmode_major_version' is not initialized in the constructor.
[src\platform\StdSDLApp.cpp:43]: (warning) Member variable 'CStdApp::xf86vmode_minor_version' is not initialized in the constructor.
[src\platform\StdSDLApp.cpp:43]: (warning) Member variable 'CStdApp::xrandr_major_version' is not initialized in the constructor.
[src\platform\StdSDLApp.cpp:43]: (warning) Member variable 'CStdApp::xrandr_minor_version' is not initialized in the constructor.
[src\platform\StdScheduler.cpp:343]: (warning) Member variable 'StdSchedulerThread::fRunThreadRun' is not initialized in the constructor.
[src\platform\StdScheduler.cpp:343]: (warning) Member variable 'StdSchedulerThread::fWait' is not initialized in the constructor.
[src\platform\StdScheduler.cpp:343]: (warning) Member variable 'StdSchedulerThread::iThread' is not initialized in the constructor.
[src\platform\StdScheduler.cpp:459]: (warning) Member variable 'StdThread::iThread' is not initialized in the constructor.
[src\platform\StdXPrivate.h:162]: (warning) Member variable 'CStdAppPrivate::xrandr_oldmode' is not initialized in the constructor.
[src\platform\StdXPrivate.h:162]: (warning) Member variable 'CStdAppPrivate::xrandr_rot' is not initialized in the constructor.
[src\platform\StdXPrivate.h:162]: (warning) Member variable 'CStdAppPrivate::xrandr_event' is not initialized in the constructor.
[src\platform\StdXPrivate.h:162]: (warning) Member variable 'CStdAppPrivate::wdt' is not initialized in the constructor.
[src\platform\StdXPrivate.h:162]: (warning) Member variable 'CStdAppPrivate::hgt' is not initialized in the constructor.
[src\platform\StdXPrivate.h:59]: (warning) Member variable 'CGLibProc::timeout' is not initialized in the constructor.
[src\platform\StdXPrivate.h:59]: (warning) Member variable 'CGLibProc::max_priority' is not initialized in the constructor.
[src\script\C4AulDebug.cpp:329]: (information) The scope of the variable 'varIndex' can be reduced
[src\script\C4AulDebug.cpp:36]: (warning) Member variable 'C4AulDebug::eState' is not initialized in the constructor.
[src\script\C4AulDebug.cpp:36]: (warning) Member variable 'C4AulDebug::iStepCallDepth' is not initialized in the constructor.
[src\script\C4AulDebug.cpp:44]: (performance) Prefer prefix ++/-- operators for non-primitive types.
[src\script\C4AulDebug.cpp:319]: (performance) Prefer prefix ++/-- operators for non-primitive types.
[src\script\C4AulDebug.cpp:506]: (performance) Prefer prefix ++/-- operators for non-primitive types.
[src\script\C4AulExec.h:43]: (warning) Member variable 'C4AulExec::fProfiling' is not initialized in the constructor.
[src\script\C4AulExec.h:43]: (warning) Member variable 'C4AulExec::pProfiledScript' is not initialized in the constructor.
[src\script\C4AulExec.h:43]: (warning) Member variable 'C4AulExec::Contexts' is not initialized in the constructor.
[src\script\C4AulParse.cpp:127]: (warning) Member variable 'C4AulParseState::Idtf' is not initialized in the constructor.
[src\script\C4AulParse.cpp:127]: (warning) Member variable 'C4AulParseState::cStr' is not initialized in the constructor.
[src\script\C4AulParse.cpp:127]: (warning) Member variable 'C4AulParseState::Type' is not initialized in the constructor.
[src\zlib\gzio.c:26]: (style) struct or union member 'internal_state::dummy' is never used
[src\zlib\gzio.c:158]: (error) Memory leak: s.path
[src\zlib\gzio.c:526]: (error) Uninitialized variable: c
I uploaded the patch file to a free file hoster:
cppcheck.patch
> + //FIXME: double negation?
What is there to fix about it? That's an explicit bool conversion (e.g. from windows BOOLs). I use that construct all the time.
> - catch (C4MCParserErr err)
> + catch (C4MCParserErr& err)
I don't get the difference - wouldn't it have to copy stuff behind the scenes anyway? And a *non-constant* reference to what is most likely a RHS object? That type of thing has bitten us before...
>- for(x = 0; x < To.Wdt; x++) {
>+ for(x = 0; x < To.Wdt; ++x) {
What?
>- int iMat = pSource->_GetMat(To.x+x, To.y+y);
>+ pSource->_GetMat(To.x+x, To.y+y);
What about "I foresee that this variable will be used in future revisions"? :)
> - szNetResult = LoadResStr("IDS_TEXT_LEAGUEWAITINGFOREVALUATIO");
> + LoadResStr("IDS_TEXT_LEAGUEWAITINGFOREVALUATIO");
That seems a bit inconsequential (LoadResStr doesn't have side effects, that's for sure). And Sven should have a look at whether not doing anything with the network status there was actually his intention.
>- const char *szExt = GetExtension(szFile);
>+ GetExtension(szFile);
> // get type
> switch (GetMusicFileTypeByExtension(GetExtension(szFile)))
Maybe just use "szExt" in the line below?
Judging from your list, those "not initialized" lines seem like the most likely candidates for actual bugs.
You should always use prefix in/decrement. x++ is x = x + 1 which means that a temporary copy of x needs to be created which is then raised by one and copy over to the original adress. While ++x is just "Go to address of x and raise by one". While this doesn't really affect ints and similar, it will however get very cpu consuming if in/decrementing non-primitive types. So you should always use prefix for a simple reason: to not get used to postfix, even on primitives (even Stroustrup, the C++ inventor, will tell you this, He even says that the language should from a programmers POV really be called ++C instead - but it doesn't because C++ simply sounds better).
I removed some unused variables (why waste memory and cpu time for them?), but not the function calls that assigned them a value, because maybe these calls were needed (as I said, I did not set up a build environment and tested things and checking what these functions do, that's why I only did the easy hacks now).
You should never create variables because "you maybe need them in 100 years". You will forget about (most of) them (->wasting memory and cpu time to create them at runtime).
BOOL is just "typedef int BOOL", the proper way of converting an int to bool is this:
bool b = (BOOLvar != 0);
Bye.
As a matter of public service, I'm now going to point out some misunderstandings about compilers and coding style contained in the post I'm answering to. Don't take this personally.
> While this doesn't really affect ints and similar
In fact it doesn't affect them at all. The compilers are smart enough to treat both variants the same way, and the chance of the integers being replaced with more complex objects with custom operators is small, and even then inlining probably takes care it it. Changing them around won't help the original person who wrote them the other way around, so it's better to avoid the noise in the version history.
>why waste memory and cpu time for them?
Indeed, and the compiler doesn't. Those variables are left there as a sort of todo list for someone to investigate whether the function call is still needed.
The proper way of converting an int to a bool is not to use an int in the first place. If you can't do that, !! is as good as != 0, and both are inferior to eliminating the bool and using if(foo) or similar.
How do you intend to get new code contributors if you cut them off from the beginning? You can't expect everyone to do big feature contributions from the start. You should allow small contributions and clean up tasks if this helps people to get into the project.
> Indeed, and the compiler doesn't.
What's "the compiler"? There exists a lot of different compilers with a lot of different optimization techniques that can be switched on and off.
Initially I thought OpenClonk is a very good open source project (you have a really good and clean website with all needed informations). But seeing that you don't even have a code style plan and cut off easy beginner tasks and don't like the use of static analysis tools to find possible flaws it seems I have to revise my opinion about OpenClonk: While your code base and licence is open, the actual development process seems not to be "open" (as in "we don't want anything from you if you don't completly take over our opinions about the development process!").
Development requires discussion, and if you think you're being personally insulted because your contributions aren't immediately included you need to grow up.
Bashing a well-meant effort into the trashcan without some thanks or constuctive arguments and no word about the good parts is no "discussion".
Sorry to say that, but the OC community looks unfriendly to me. Of course, you are doing great work on the game, no doubt, but I don't like the whole "atmosphere". I know other open source projects to which I contributed similar work, but OpenClonk was the first that reacted instantly negative to it.
>"What about a welcoming word? A thanks? What about "Thanks for your effort, but I see some problems here: This and that, but the rest looks fine. Thanks again. :) " ?
We didn't react negatively to you, you submitted something and under the presumption that you knew what you were talking about the engine programmers started talking straight towards the business of the matter.
Why you perceived critique as insulting is unknown to me. Because the programmers skipped pleasantries and went straight to discussion? The atmosphere of development is hardly elitist as you seem to perceive; we've had plenty of people who just randomly came in and fixed or improved something (check the about menu in the game for a list!). But you can't honestly expect just because it's open-source everything you contribute will automatically be included without others reviewing your work. I also have had people contribute do work in the content/art area that I have reviewed before adding.
If you want to contribute to OC, no one is stopping you; in fact, we need more developers as it is! But when you contribute something, expect to receive criticism. Even in something as casual as open-source hobby development there is a degree of professionalism that is expected.
Okt 02 20:45:37 <PeterW> And left me wondering whether I'd have avoided that with a simple "First of all, thanks for looking at OpenClonk! Most of the issues you raise are valid, but I have a few doubts about how to fix them..."
Okt 02 20:45:52 <PeterW> It just feels so silly :/
Okt 02 21:01:31 <maikel`> being nice feels silly?
Okt 02 21:01:35 <maikel`> I agree
Okt 02 21:01:39 * maikel` ist jetzt bekannt als Maikel
Okt 02 21:02:38 <PeterW> I don't know. I always feel like cutting right to the chase is the right thing to do with someone you think knows what he's doing.
Okt 02 21:03:15 <PeterW> If I didn't believe in it, I wouldn't respond.
Oh well. Günther has btw started doing some patches based on your observations, if I understood him correctly.
Edit: That's the thing about internet communication. My first reaction was "hey, sounds like a nice idea". Then I looked at the patches and couldn't help but feel disappointed at how much work this still needed to get useful. That's what my post reflects.
Before that gets lost: I still think that we should hunt down those missing initializations. Some warnings in the network code don't sound right. If our Mr. or Ms. Anonymous doesn't want to work with us anymore, we should probably look into getting this tool of his installed ourselves for that reason alone.
http://wiki.openclonk.org/w/Style_Guidelines !
> Why should I contibute feature code if nobody of the team seems to care about code style?
Part of our coding style is "do not fix warnings from automated analyzers without understanding the root cause". Your patch simply hid some problems with the code, making them harder to find. If you don't understand why that's bad, you probably shouldn't try to contribute.
> How do you intend to get new code contributors if you cut them off from the beginning?
By encouraging them to write patches that won't get "cut off". If they misunderstand patch review comments as personal rejections, we are better off without them. We try to maintain high quality standards, and reviewing each others patches is necessary for that. (Though we do some of that as commit-then-review, but for anonymous contributors that's impossible.)
> What's "the compiler"? There exists a lot of different compilers with a lot of different optimization techniques that can be switched on and off.
If you're using a non-optimizing compiler, you shouldn't change the code to make it faster. By the way, gcc -O0 generates the same code for "for (int i = 0; i < 42; i++) bar();" and "for (int i = 0; i < 42; ++i) bar();", and "int k; for (int i = 0; i < 42; ++i) k = bar();" only adds a single MOV, which is lost in the noise. Big projects like Clonk always have far, far bigger optimization opportunities, and getting sidetracked by believing microoptimizations were significant only results in slowdown. I know it's hard, I often have to consciously keep myself from getting thus distracted.
> as in "we don't want anything from you if you don't completly take over our opinions about the development process!
Uhm, no. Our policy is actually the other way round: The idea is that we don't subject coders to silly style rules like "never use post-increment". Now you have told me to stop doings things that I have been doing on purpose and with some thought behind it.
Style discussions are a mine field - with a lot of developers involved you are sure to get disagreement. Doing a swooping pass over the engine and wildly changing everything that you would have done slightly different... Well, that's just a recipe for stepping on people's toes. I certainly wouldn't recommend it if you don't have strong real-world arguments that go a bit above citing Stroustroup or the C++ FAQ.
> Sorry that I provided my help, I will refrain from doing so in the future.
Well, to make that clear - I am glad to see people getting interested in this. I just wanted to note that while the issues you raise are valid, the fixes are in most cases not so obvious.
> You should always use prefix in/decrement.
I am aware of the issue for non-primitive types. But why change it around for integers, where constructing a reference is equally complicated as saving the old value - and both should really be optimised away by the compiler?
> because maybe these calls were needed
Well yes, I understand that. I am just telling you that all the instances you noticed there *have* no side-effects and therefore removing them completely would be the better solution.
> wasting memory and cpu time to create them at runtime
Uhm, no? The compiler is at least as intelligent as your tool and will not allocate any runtime data. At least for primitive types. The overhead we're talking about is purely the source complexity. That's still a valid point, but a bit less so.
> the proper way of converting an int to bool is this:
Is it? For me that's breaking the abstraction by showing that the BOOL is an int. What if that changes in future? All I really know is that whatever BOOL is, it supports "!" which gives me a bool. I don't want to assume more.
> Bye.
Note I am doing computer language research semi-professionally. Please don't interpret my eagerness to discuss fine points of style as dismissal :)
> OK, I fixed the easy ones
What about the rest of Anonymous' contribution though? You looked through it, is there something we can make use of?
At the very least, if he detected memory leaks and possible null pointer exceptions with this tool, we should definitely go after them.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill