Yardım Classda tanımlanan her değeri initialize ediyor musunuz?

Selamlar,

Cpp bilgim iyi düzeyde değil, bugün karşılaştığım bir bugta classda tanımladığım member variablelardan birini default value ile Initialize metodu içerisinde kullanmadığım için çokça kez içerisinden çıkamadığım core dumplar ile uğraştım, tanımladıktan sonra düzeldi.

Bu bir standart mıdır? Chatgpt'nin yorumu aşağıdaki gibi, eğer init metodunda kullanılmaz ise potansiyel aşağıdaki zararlarından bahsediyor, source'u kontrol ettiğimde yaklaşık 10-15 adet örneğide mevcut bende sadece, tam olarak 4'te bahsettiği debugging nightmares'i yaşadım bugün "Crash later in an unrelated part of the code, making debugging very difficult.", cpp üstadlarımızın bilgisine başvurmak istiyorum, teşekkürler. @Denizeri24

1. Indeterminate Values ("Garbage"):

• For fundamental types (like int, float, DWORD, BYTE, bool, pointers, etc.), if you don't explicitly initialize them, they will hold whatever random bits happened to be in that memory location previously. This is often called a "garbage value."
• They don't automatically default to zero, nullptr, or false (unless they are static or global variables, which these are not).

1. Undefined Behavior on Read:

• The most critical issue is that reading from an uninitialized variable before it has been assigned a value results in undefined behavior.
• "Undefined behavior" means the C++ standard doesn't dictate what must happen. The program could:
• Crash immediately (e.g., segmentation fault if dereferencing a garbage pointer).
• Crash later in an unrelated part of the code, making debugging very difficult.
• Produce incorrect results silently (e.g., calculations using garbage values).
• Seem to work correctly sometimes (if the garbage value happens to be benign by chance) but fail unpredictably under different conditions, compiler settings, or system architectures.

1. Specific Examples of Potential Problems:

• Pointers (LPEVENT, LPCHARACTER, etc.): An uninitialized pointer won't be nullptr. Checking if (m_pkSomeEvent) might evaluate to true even if no event was created. Attempting to access members (->) or dereference (*) will likely crash. Trying to event_cancel a garbage pointer value is undefined.
• Numeric Types (int, DWORD, BYTE, long): Using these in calculations (e.g., get_dword_time() - m_dwWalkStartTime), comparisons (if (m_dwMountVnum > 0)), or as loop counters/indices will yield unpredictable results based on the garbage value. Cooldowns might be wrong, stats incorrect, loops might run too many or too few times.
• Booleans (bool): An uninitialized bool isn't guaranteed to be true or false. if (m_bPolyMaintainStat) could execute the wrong branch of code. Flags could be misinterpreted.
• Counters/Indices: Variables like m_iRefineAdditionalCell or m_BiologCollectedItems holding garbage values lead to incorrect game logic and state.
• Object State: The character object starts in an inconsistent, unpredictable state, which can violate assumptions made by other functions that interact with it. For instance, GetEmpire() could return a random byte value if m_bEmpire isn't initialized.

1. Debugging Nightmares:

• Bugs caused by uninitialized variables are notoriously hard to find because they might only appear intermittently or under specific circumstances. The crash or incorrect behavior might happen long after the uninitialized variable was read.