C# vs C++: pamięć, wydajność, tworzenie gier i próg wejścia

C# i C++ łączy litera i składnia z nawiasami klamrowymi, ale działają na różnych poziomach. C++ (1985) kompiluje się bezpośrednio do kodu maszynowego i pozwala dokładnie kontrolować, gdzie żyje każdy obiekt i kiedy umiera. C# (2002) kompiluje się do języka pośredniego, który środowisko .NET zamienia na kod maszynowy w czasie działania, a pamięć odzyskuje za ciebie odśmiecacz (garbage collector). Niemal każda różnica opisana poniżej wynika z tego jednego wyboru.

W skrócie

Pamięć: odśmiecacz a RAII

W C++ obiekt o automatycznym czasie życia jest niszczony, gdy wychodzi poza zasięg, a jego destruktor uruchamia się dokładnie w tym momencie. Obiekty na stercie należą do inteligentnych wskaźników (std::unique_ptr, std::shared_ptr) albo są zarządzane ręcznie przez new i delete. Ten wzorzec, Resource Acquisition Is Initialization (RAII), daje deterministyczne sprzątanie pamięci i każdego innego zasobu.

// C++
#include <memory>
#include <fstream>

void save() {
    std::ofstream file("log.txt");          // opened here
    auto buffer = std::make_unique<char[]>(4096);
    file << "saved\n";
}   // file closed and buffer freed here, in reverse order

W C# każda instancja klasy żyje na zarządzanej stercie, a odśmiecacz zwalnia ją w jakimś późniejszym momencie, gdy nic już się do niej nie odwołuje. Nigdy nie piszesz delete i nigdy nie zwolnisz czegoś, co jest wciąż w użyciu. Pamięć jest obsłużona; tym, czego odśmiecacz nie obsługuje od razu, są inne zasoby: pliki, gniazda, połączenia z bazą danych. Do nich C# ma IDisposable i instrukcję using, która wywołuje Dispose na końcu bloku, czyli najbliższy odpowiednik destruktora:

using System;

class Connection : IDisposable
{
    private readonly string name;
    public Connection(string name) { this.name = name; Console.WriteLine($"open {name}"); }
    public void Send(string msg) { Console.WriteLine($"{name} <- {msg}"); }
    public void Dispose() { Console.WriteLine($"close {name}"); }
}

class Program
{
    static void Main()
    {
        using (var db = new Connection("db"))
        using (var cache = new Connection("cache"))
        {
            db.Send("SELECT 1");
            cache.Send("PING");
        }   // Dispose runs here, in reverse order, even if an exception is thrown
        Console.WriteLine("done");
    }
}

Wynik:

open db
open cache
db <- SELECT 1
cache <- PING
close cache
close db
done

Różnica polega na tym, że w C++ sprzątanie jest związane z zasięgiem dla każdego obiektu lokalnego i każdego obiektu należącego do inteligentnego wskaźnika, a w C# jest automatyczne dla pamięci i opcjonalne (przez using) dla całej reszty. Więcej na ten temat na stronie o instrukcji using.

Bezpieczeństwo: wyjątki zamiast niezdefiniowanego zachowania

Odczyt za końcem tablicy w C++ to niezdefiniowane zachowanie: program może wypisać śmieci, się wysypać albo działać dalej z uszkodzoną pamięcią, a wynik może się zmieniać między kompilacjami. Ten sam błąd w C# rzuca wyjątek dokładnie w tej linii.

// C++: compiles, and the behavior is undefined
int scores[3] = {90, 85, 77};
int x = scores[5];   // reads whatever is in memory there

using System;

class Program
{
    static void Main()
    {
        int[] scores = { 90, 85, 77 };
        try
        {
            int x = scores[5];
            Console.WriteLine(x);
        }
        catch (IndexOutOfRangeException)
        {
            Console.WriteLine("Index 5 is outside an array of length " + scores.Length);
        }

        string name = null;
        try
        {
            Console.WriteLine(name.Length);
        }
        catch (NullReferenceException)
        {
            Console.WriteLine("name was null");
        }
    }
}

Wynik:

Index 5 is outside an array of length 3
name was null

Cała klasa błędów uszkodzenia pamięci (przepełnienia bufora, użycie po zwolnieniu, podwójne zwolnienie, wiszące wskaźniki) nie istnieje w bezpiecznym C#. To w dużej mierze dlatego kod w C# pisze się i przegląda szybciej.

Wskaźniki i kod unsafe

C# ma wskaźniki, ale tylko wewnątrz bloków unsafe, a projekt musi to jawnie włączyć przez <AllowUnsafeBlocks>true</AllowUnsafeBlocks>. Obiekty na zarządzanej stercie mogą się przesuwać podczas odśmiecania, więc przed pobraniem ich adresu przypinasz je przez fixed:

// C#, requires AllowUnsafeBlocks
unsafe
{
    int[] data = { 1, 2, 3 };
    fixed (int* p = data)
    {
        *(p + 1) = 20;   // data is now { 1, 20, 3 }
    }
}

Kodu unsafe używa się do współpracy z bibliotekami natywnymi i w kilku gorących pętlach. Większość niskopoziomowego kodu C# korzysta dziś zamiast tego z Span<T>, lokalnych zmiennych ref i stackalloc, które dają wydajność zbliżoną do wskaźników, zachowując sprawdzanie zakresu.

Wydajność

C++ daje kompilatorowi cały program z wyprzedzeniem i niczego nie dodaje w czasie działania: nie ma odśmiecacza, JIT ani sprawdzania zakresu, chyba że o nie poprosisz. Dlatego wybiera się go tam, gdzie liczy się każda mikrosekunda lub każdy bajt i gdzie pauzy są niedopuszczalne.

C# płaci za bezpieczeństwo środowiskiem uruchomieniowym, rozgrzewaniem JIT przy starcie i okazjonalnymi pauzami odśmiecacza. Pod względem przepustowości zwykle ustępuje C++ niewiele, a różnica zmniejsza się z każdym wydaniem .NET: wielopoziomowy JIT z optymalizacją sterowaną profilem, struktury i Span<T> do unikania alokacji, instrukcje sprzętowe dla SIMD oraz Native AOT do kompilacji z wyprzedzeniem do jednego natywnego pliku wykonywalnego. W API webowych, narzędziach i logice biznesowej dominują baza danych i sieć, a różnica między językami rzadko jest widoczna.

Tworzenie gier: Unity a Unreal

Tu większość osób po raz pierwszy styka się z tym pytaniem. Unity skryptuje się w C#: kod rozgrywki, UI i narzędzia to klasy C# przypięte do obiektów gry, a rdzeń silnika jest w C++. Unreal Engine jest napisany w C++, a rozgrywkę tworzy się w C++ plus wizualnym systemie skryptowym Blueprints. Godot obsługuje zarówno GDScript, jak i C#.

C# z Unity łatwiej opanować i szybciej się w nim iteruje, dlatego jest tak popularny w grach niezależnych i mobilnych. Unreal i C++ to standard w studiach AAA, a programiści silników wszędzie pracują w C++. Częsta ścieżka to start w Unity, a potem nauka C++ przy przejściu na Unreal lub do pracy nad silnikiem.

Model budowania

Program w C++ dzieli się na nagłówki (.h, deklaracje) i pliki źródłowe (.cpp, definicje). Preprocesor wkleja nagłówki do każdego pliku źródłowego, każdy plik kompiluje się osobno, a linker łączy wyniki. Szablony są instancjonowane w każdym pliku, który ich używa, co jest jednym z powodów, dla których duże projekty C++ budują się wolno.

C# nie ma nic z tych rzeczy. Projekt to zbiór plików .cs kompilowanych razem do assembly (.dll); kolejność deklaracji i plików nie ma znaczenia, a typ z jednego pliku może używać typu z innego bez żadnego include. Biblioteki dostarcza się jako pakiety NuGet. Dyrektywa using importuje przestrzeń nazw, a nie plik.

Różnice w składni, które zauważysz

• Obiekty. auto p = std::make_unique<Player>(); i p->Jump(); w C++; var p = new Player(); i p.Jump(); w C#. C# używa . do wszystkiego.
• Napisy. std::string to modyfikowalna wartość; string w C# to niemodyfikowalny typ referencyjny.
• Wielodziedziczenie. C++ pozwala klasie dziedziczyć po kilku klasach; C# pozwala na jedną klasę bazową plus dowolną liczbę interfejsów.
• Szablony a generyki. Szablony C++ to generowanie kodu w czasie kompilacji i pozwalają na metaprogramowanie; generyki C# są sprawdzane raz, z jawnymi ograniczeniami (where T : IComparable<T>).
• Biblioteka standardowa. Biblioteka C# zawiera HTTP, JSON, wyrażenia regularne, operacje na plikach, kompresję i kryptografię; w C++ wiele z tego pochodzi z bibliotek zewnętrznych.

Czego się uczyć

Ucz się C#, jeśli chcesz budować aplikacje, backendy webowe, narzędzia albo gry w Unity i szybko widzieć efekty. Ucz się C++, jeśli celujesz w silniki gier, grafikę, systemy wbudowane, systemy operacyjne, przeglądarki albo cokolwiek, gdzie chodzi właśnie o kontrolę na poziomie sprzętu i przewidywalne opóźnienia. C# to łagodniejszy pierwszy język; C++ warto poznać jako drugi, bo uczy, co środowisko uruchomieniowe C# robi za ciebie.