<p>There are several issues with the code:</p>

<ol>
<li>If there are no debufs, no damage would be taken.</li>
<li><code>DestroyMe()</code> function name sounds dangerous. Depending on how its implemented, it might or might not be an issue. If it's just a call to the destructor of the current object wrapped in a function, then there is an issue, as the object would be destroyed in the middle of it executing code. If it's a call to a function which queues the deletion event of the current object, then there is no issue, as the object would be destroyed after it completes its execution and the event loop kicks in.</li>
<li>The actual issue that seems to be mentioned in the anime, the "It was calling the same operation over and over again" -- it will call <code>DestroyMe()</code> as long as <code>m_currentHealth &lt;= 0.f</code> and there are more debuffs left to iterate, which might result in <code>DestroyMe()</code> being called multiple times, over and over again. The loop should stop after the first <code>DestroyMe()</code> call, because deleting an object more than once results in memory corruption, which will likely result in a crash in the long run.</li>
</ol>

<p>I'm not really sure why every debuf takes away the health, instead of the health being taken away only once, with the effects of all debuffs being applied on the initial damage taken, but I will assume that's the correct game logic.</p>

<p>The correct code would be</p>

<pre><code>// the calculation of damage when attacked
void DestructibleActor::ReceiveDamage(float sourceDamage) 
{
    // apply debuffs
    auto resolvedDamage = sourceDamage;
    for (const auto&amp; debuf:m_debufs)
    {
        resolvedDamage = debuf.ApplyToDamage(resolvedDamage);
        m_currentHealth -= resolvedDamage
        if (m_currentHealth &lt;= 0.f)
        {
            m_currentHealth = 0.f;
            DestroyMe();
            break;
        }
    }
}
</code></pre>

CC BY-SA 3.0
2017-07-15T00:17:07.190Z
I should point out that as I have written memory allocators in the past, deleting the same memory doesn't have to be an issue. It could also be redundant. It all depends on the allocator's behavior. Mine just acted like a low level linked list so the "node" for the deleted data either gets set as free several times or redeleted several times (which would just correspond to redundant pointer redirections). Good catch though.
user64742
CC BY-SA 3.0
2017-07-16T07:26:03.147Z
Double-free is a bug, and generally leads to undefined behavior and crashes. Even if you have a custom allocator that somehow disallows reuse of the same memory address, double-free is a smelly code as it makes no sense and you will get yelled at by static code analyzers.
BananaBlender
CC BY-SA 3.0
2017-07-17T00:41:21.287Z
Of course! I didn't design it for that purpose. Some languages just require an allocator due to lacks of features. No no no. I was merely stating that a crash isn't guaranteed. Certain design classifications don't always crash.
user64742
CC BY-SA 3.0
2017-07-14T18:07:42.637Z
2017-07-14T18:07:42.637Z
BananaBlender
<p>The code is not an infinite loop but it is a bug.</p>

<p>There's two (possibly three) issues:</p>

<ul>
<li>If no debufs are present no damage will be applied at all</li>
<li>Excessive damage will be applied if there is more than 1 debuf</li>
<li>If DestroyMe() immediately deletes the object and there are still m_debufs to be processed the loop will be executing over a deleted object and trashing memory. Most game engines have a destroy queue to work around this and more so that may not be an issue.</li>
</ul>

<p>The application of damage should be outside the loop.</p>

<p>Here's the corrected function:</p>

<pre><code>// the calculation of damage when attacked
void DestructibleActor::ReceiveDamage(float sourceDamage) 
{
    // apply debuffs
    auto resolvedDamage = sourceDamage;
    for (const auto&amp; debuf:m_debufs)
    {
        resolvedDamage = debuf.ApplyToDamage(resolvedDamage);
    }
    m_currentHealth -= resolvedDamage
    if (m_currentHealth &lt;= 0.f)
    {
        m_currentHealth = 0.f;
        DestroyMe();
    }
}
</code></pre>

CC BY-SA 3.0
2017-07-15T00:39:08.097Z
The corrected code also does show up towards the end of that segment, too.
Makoto
CC BY-SA 4.0
2021-08-16T05:50:44.300Z
Comments are not for extended discussion; this conversation has been [moved to chat](https://chat.stackexchange.com/rooms/128609/discussion-on-answer-by-stephane-hockenhull-is-code-in-episode-1-of-new-game-2-a).
Aki Tanaka
CC BY-SA 3.0
2017-07-14T12:07:56.093Z
2017-07-14T12:37:18.997Z
2017-07-14T12:37:18.997Z
Stephane Hockenhull
<p>In episode 1 of New Game 2, around 9:40, there is a shot of the code that Nene has written:</p>

<p><a href="https://i.sstatic.net/JRFI2.png" rel="noreferrer"><img src="https://i.sstatic.net/JRFI2.png" alt="enter image description here"></a></p>

<p>Here is it in text form with the comments translated:</p>



<pre><code>// the calculation of damage when attacked
void DestructibleActor::ReceiveDamage(float sourceDamage) 
{
    // apply debuffs
    auto resolvedDamage = sourceDamage;
    for (const auto&amp; debuf:m_debufs)
    {
        resolvedDamage = debuf.ApplyToDamage(resolvedDamage);
        m_currentHealth -= resolvedDamage
        if (m_currentHealth &lt;= 0.f)
        {
            m_currentHealth = 0.f;
            DestroyMe();
        }
    }
}
</code></pre>

<p>After the shot, Umiko, pointing at the for loop, said that the reason why the code crashed is that there is an infinite loop.</p>

<p>I don't really know C++ so I'm not sure whether what she is saying is true.</p>

<p>From what I can see, the for loop is just iterating through the debufs that the Actor currently has. Unless the Actor has an infinite amount of debufs, I don't think it can possibly become an infinite loop.</p>

<p>But I'm not sure because the only reason that there is a shot of the code is that they wanted to put an easter egg here, right? We would have just gotten a shot of the back of the laptop and heard Umiko saying "Oh you've got an infinite loop there". The fact that they actually showed some code makes me think that somehow the code is an easter egg of some sort.</p>

<p>Will the code actually create an infinite loop?</p>

CC BY-SA 3.0
2017-07-14T12:17:43.710Z
Probably helpful: [additional screenshot](https://i.imgur.com/0XQKR4G.png) of Umiko saying that "It was *calling the same operation* over and over again", which might not be shown in the code.
Aki Tanaka
CC BY-SA 3.0
2017-07-14T12:19:59.517Z
Oh! I didn't know that! @AkiTanaka the sub that I watched says "infinite loop"
Sweeper
CC BY-SA 3.0
2017-07-14T12:21:50.627Z
it could be a stackoverflow then coz we don't know if DestroyMe isn't calling ReceiveDamage
Hakase
CC BY-SA 3.0
2017-07-14T21:33:40.793Z
I'm voting to close this question as off-topic because it's a question purely about programming which does not require any context or knowledge of the source anime/manga to answer, as per https://anime.meta.stackexchange.com/a/669.
Logan M
CC BY-SA 3.0
2017-07-16T05:00:15.227Z
@LoganM I don't really agree. It's not just that OP has a question about some source code that happened to come from an anime; OP's question is about a particular statement made _about_ the source code by a character in the anime, and there is an anime-related answer, namely "Crunchyroll done goofed and mistranslated the line".
senshin
CC BY-SA 3.0
2017-07-16T20:12:02.717Z
@senshin I think you're reading what you want the question to be about, rather than what is actually asked. The question provides some source code and asks whether it generates an infinite loop as real-life C++ code. *New Game!* is a fictional work; there is no need for code presented in it to conform to real-life standards. What Umiko says about the code is more authoritative than any C++ standards or compilers. The top (accepted) answer has no mention of any in-universe information. I think an on-topic question could be asked about this with a good answer, but as phrased this isn't it.
Logan M
CC BY-SA 3.0
2017-10-26T00:20:27.860Z
@LoganM I agree about [not requiring context/knowledge of the source anime/manga to answer]. I haven't even watched the show yet. Not sure it'd be fully on-topic in gamedev.SE either as it's entirely **fictional**. It's arguably off-topic unless  "Historical or societal context of an anime or manga", or "Plot, character, or **setting explanations**", gets expanded/stretched a bit.
Stephane Hockenhull
<new-game>
Is code in episode 1 of New Game 2 actually an infinite loop?
# Is code in episode 1 of New Game 2 actually an infinite loop?
Posted by: username_0 on 2017-07-14
In episode 1 of New Game 2, around 9:40, there is a shot of the code that Nene has written:

Here is it in text form with the comments translated:
// the calculation of damage when attacked
void DestructibleActor::ReceiveDamage(float sourceDamage) 
{
    // apply debuffs
    auto resolvedDamage = sourceDamage;
    for (const auto& debuf:m_debufs)
    {
        resolvedDamage = debuf.ApplyToDamage(resolvedDamage);
        m_currentHealth -= resolvedDamage
        if (m_currentHealth <= 0.f)
        {
            m_currentHealth = 0.f;
            DestroyMe();
        }
    }
}

After the shot, Umiko, pointing at the for loop, said that the reason why the code crashed is that there is an infinite loop.
I don't really know C++ so I'm not sure whether what she is saying is true.
From what I can see, the for loop is just iterating through the debufs that the Actor currently has. Unless the Actor has an infinite amount of debufs, I don't think it can possibly become an infinite loop.
But I'm not sure because the only reason that there is a shot of the code is that they wanted to put an easter egg here, right? We would have just gotten a shot of the back of the laptop and heard Umiko saying "Oh you've got an infinite loop there". The fact that they actually showed some code makes me think that somehow the code is an easter egg of some sort.
Will the code actually create an infinite loop?
**Tags:** new-game
> **Comments:**
> **username_1**: Probably helpful: [additional screenshot](https://i.imgur.com/0XQKR4G.png) of Umiko saying that "It was *calling the same operation* over and over again", which might not be shown in the code.  
> **username_0**: Oh! I didn't know that! @AkiTanaka the sub that I watched says "infinite loop"  
> **username_2**: it could be a stackoverflow then coz we don't know if DestroyMe isn't calling ReceiveDamage  
> **username_3**: I'm voting to close this question as off-topic because it's a question purely about programming which does not require any context or knowledge of the source anime/manga to answer, as per https://anime.meta.stackexchange.com/a/669.  
> **username_4**: @LoganM I don't really agree. It's not just that OP has a question about some source code that happened to come from an anime; OP's question is about a particular statement made _about_ the source code by a character in the anime, and there is an anime-related answer, namely "Crunchyroll done goofed and mistranslated the line".  
> **username_3**: @senshin I think you're reading what you want the question to be about, rather than what is actually asked. The question provides some source code and asks whether it generates an infinite loop as real-life C++ code. *New Game!* is a fictional work; there is no need for code presented in it to conform to real-life standards. What Umiko says about the code is more authoritative than any C++ standards or compilers. The top (accepted) answer has no mention of any in-universe information. I think an on-topic question could be asked about this with a good answer, but as phrased this isn't it.  
> **username_5**: @LoganM I agree about [not requiring context/knowledge of the source anime/manga to answer]. I haven't even watched the show yet. Not sure it'd be fully on-topic in gamedev.SE either as it's entirely **fictional**. It's arguably off-topic unless  "Historical or societal context of an anime or manga", or "Plot, character, or **setting explanations**", gets expanded/stretched a bit.  
---
## 2 answers
### Answer by username_5 on 2017-07-14. Score: 23 | Accepted answer
The code is not an infinite loop but it is a bug.
There's two (possibly three) issues:

If no debufs are present no damage will be applied at all
Excessive damage will be applied if there is more than 1 debuf
If DestroyMe() immediately deletes the object and there are still m_debufs to be processed the loop will be executing over a deleted object and trashing memory. Most game engines have a destroy queue to work around this and more so that may not be an issue.

The application of damage should be outside the loop.
Here's the corrected function:
// the calculation of damage when attacked
void DestructibleActor::ReceiveDamage(float sourceDamage) 
{
    // apply debuffs
    auto resolvedDamage = sourceDamage;
    for (const auto& debuf:m_debufs)
    {
        resolvedDamage = debuf.ApplyToDamage(resolvedDamage);
    }
    m_currentHealth -= resolvedDamage
    if (m_currentHealth <= 0.f)
    {
        m_currentHealth = 0.f;
        DestroyMe();
    }
}
> **Comments:**
> **username_8** (2017-07-15): The corrected code also does show up towards the end of that segment, too.  
> **username_1** (2021-08-16): Comments are not for extended discussion; this conversation has been [moved to chat](https://chat.stackexchange.com/rooms/128609/discussion-on-answer-by-stephane-hockenhull-is-code-in-episode-1-of-new-game-2-a).  
---
### Answer by username_6 on 2017-07-14. Score: 2
There are several issues with the code:

If there are no debufs, no damage would be taken.
DestroyMe() function name sounds dangerous. Depending on how its implemented, it might or might not be an issue. If it's just a call to the destructor of the current object wrapped in a function, then there is an issue, as the object would be destroyed in the middle of it executing code. If it's a call to a function which queues the deletion event of the current object, then there is no issue, as the object would be destroyed after it completes its execution and the event loop kicks in.
The actual issue that seems to be mentioned in the anime, the "It was calling the same operation over and over again" -- it will call DestroyMe() as long as m_currentHealth <= 0.f and there are more debuffs left to iterate, which might result in DestroyMe() being called multiple times, over and over again. The loop should stop after the first DestroyMe() call, because deleting an object more than once results in memory corruption, which will likely result in a crash in the long run.

I'm not really sure why every debuf takes away the health, instead of the health being taken away only once, with the effects of all debuffs being applied on the initial damage taken, but I will assume that's the correct game logic.
The correct code would be
// the calculation of damage when attacked
void DestructibleActor::ReceiveDamage(float sourceDamage) 
{
    // apply debuffs
    auto resolvedDamage = sourceDamage;
    for (const auto& debuf:m_debufs)
    {
        resolvedDamage = debuf.ApplyToDamage(resolvedDamage);
        m_currentHealth -= resolvedDamage
        if (m_currentHealth <= 0.f)
        {
            m_currentHealth = 0.f;
            DestroyMe();
            break;
        }
    }
}
> **Comments:**
> **username_7** (2017-07-15): I should point out that as I have written memory allocators in the past, deleting the same memory doesn't have to be an issue. It could also be redundant. It all depends on the allocator's behavior. Mine just acted like a low level linked list so the "node" for the deleted data either gets set as free several times or redeleted several times (which would just correspond to redundant pointer redirections). Good catch though.  
> **username_6** (2017-07-16): Double-free is a bug, and generally leads to undefined behavior and crashes. Even if you have a custom allocator that somehow disallows reuse of the same memory address, double-free is a smelly code as it makes no sense and you will get yelled at by static code analyzers.  
> **username_7** (2017-07-17): Of course! I didn't design it for that purpose. Some languages just require an allocator due to lacks of features. No no no. I was merely stating that a crash isn't guaranteed. Certain design classifications don't always crash.  
---
