Wybrałeś fragment kodu, który faktycznie odwzorowuje logikę schematu blokowego: najpierw sprawdzamy warunek suma <= liczba, a dopiero gdy jest spełniony, wchodzimy do pętli, dodajemy i do zmiennej suma, inkrementujemy licznik i i wracamy do ponownego sprawdzenia warunku. To jest klasyczne zastosowanie pętli while, czyli sytuacji, kiedy nie znamy liczby iteracji z góry, ale wiemy, kiedy mamy skończyć – w tym wypadku, gdy suma przekroczy wartość graniczną liczba. Z mojego doświadczenia właśnie tak wygląda typowy fragment kodu sumujący kolejne liczby naturalne, dopóki nie zostanie osiągnięty limit. Ważne jest też to, że instrukcja wypisania wyniku znajduje się dopiero za pętlą, więc zostanie wykonana dokładnie raz, po zakończeniu obliczeń, co idealnie zgadza się z blokiem pisz suma na schemacie. W dobrych praktykach programistycznych zawsze pilnujemy, żeby warunek pętli dokładnie odpowiadał opisowi w algorytmie, a modyfikacja zmiennych sterujących, takich jak suma i i, była wykonywana wewnątrz pętli w spójny sposób. Taka konstrukcja jest potem łatwa w utrzymaniu, przeniesieniu do innych języków czy modyfikacji, na przykład można bez problemu zmienić warunek na suma < liczba albo dodać dodatkowe sprawdzenie, czy i nie rośnie za szybko. W praktycznych projektach, np. przy obliczaniu sum kontrolnych, limitów budżetowych, punktów gracza w grze, dokładnie taki wzorzec while warunek, obliczenia, inkrementacja, wypisz wynik pojawia się naprawdę często.
W niepoprawnych fragmentach kodu problemem nie jest sam język C plus plus, tylko sposób odwzorowania algorytmu z rysunku. Schemat blokowy jasno mówi, że dopóki suma jest mniejsza lub równa liczba, mamy wielokrotnie dodawać kolejne wartości i oraz zwiększać licznik, a dopiero po wyjściu z tego cyklu jednorazowo wypisać wartość suma. Konstrukcja z pętlą do while wykonuje ciało przynajmniej raz bez wcześniejszego sprawdzenia warunku, czyli najpierw dodaje i do sumy, a dopiero później porównuje suma <= liczba. To subtelne przesunięcie powoduje, że kod może wykonać jedną iterację za dużo w stosunku do schematu. W praktyce bywa to bardzo groźne, na przykład przy obsłudze buforów w systemach wbudowanych czy przy obliczeniach finansowych. Fragment oparty wyłącznie na instrukcji if z else nie tworzy żadnej pętli, więc kod wykona maksymalnie jedno dodanie i, a to jest całkowicie sprzeczne z ideą powtarzania z diagramu. To typowy błąd uczniów, którzy mylą pojedyncze rozgałęzienie z cyklicznym przetwarzaniem danych. Z kolei użycie pętli for z else wygląda na pierwszy rzut oka efektownie, ale również nie odpowiada schematowi. Po pierwsze, zakres iteracji jest na sztywno powiązany z warunkiem i <= liczba, a algorytm operuje na warunku suma <= liczba. Po drugie, else po pętli for nie jest standardową konstrukcją w C plus plus i w praktyce taki kod nawet się nie skompiluje. Z mojego doświadczenia wynika, że źródłem większości takich pomyłek jest próba zbyt kreatywnego kombinowania zamiast trzymania się prostego tłumaczenia: warunek na rombie przekładamy na warunek w pętli, strzałka oznacza powrót na początek, a blok pisz suma to pojedyncza instrukcja po zakończeniu pętli. Dopiero jak to rozumiemy, można zaczynać optymalizacje czy inne fajerwerki składniowe.