Modern C++ ile Metin2 Kodlarını Refaktör Ediyoruz

​

#ifndef FALSE
    #define FALSE    0
    #define TRUE    1
#endif

• Eski, problemli veya gereksiz kodları tespit etmek
• Daha temiz, okunabilir ve modern hallerini paylaşmak
• Birbirimizden öğrenerek ortak bir bilgi havuzu oluşturmak

• Kodun okunabilirliğini artırır
• Karmaşıklığı azaltır
• Kaynak kodun bakımını kolaylaştırır
• Sistemin genişletilebilirliğini artırır
• Performans iyileştirmeleri sağlar
• Daha stabil ve hızlı çalışan bir yazılım ortaya çıkarır

1. ItemDropPenalty içindeki GetRealAlignment çağrısı azaltma
2. etc_drop_item.txt dosyası ve okuma mantığı düzenlemesi
3. InitializeItemTable ve InitializeMobTable refaktör
   
   
   

void CHARACTER::ItemDropPenalty(LPCHARACTER pkKiller)

    int iAlignIndex;

    if (GetRealAlignment() >= 120000)
    {
        iAlignIndex = 0;
    }
    else if (GetRealAlignment() >= 80000)
    {
        iAlignIndex = 1;
    }
    else if (GetRealAlignment() >= 40000)
    {
        iAlignIndex = 2;
    }
    else if (GetRealAlignment() >= 10000)
    {
        iAlignIndex = 3;
    }
    else if (GetRealAlignment() >= 0)
    {
        iAlignIndex = 4;
    }
    else if (GetRealAlignment() > -40000)
    {
        iAlignIndex = 5;
    }
    else if (GetRealAlignment() > -80000)
    {
        iAlignIndex = 6;
    }
    else if (GetRealAlignment() > -120000)
    {
        iAlignIndex = 7;
    }
    else
    {
        iAlignIndex = 8;
    }

GetRealAlignment()

Arayın:

void CHARACTER::ItemDropPenalty(LPCHARACTER pkKiller)
  
Üzerine yardımcı fonksiyonu ekleyin:

static constexpr int GetAlignIndex(int align)
{
    if (align >= 120000) return 0;
    if (align >= 80000)  return 1;
    if (align >= 40000)  return 2;
    if (align >= 10000)  return 3;
    if (align >= 0)      return 4;
    if (align > -40000)  return 5;
    if (align > -80000)  return 6;
    if (align > -120000) return 7;
    return 8;
}

Şimdi ise o koca kod bloğu yerine sadece bunu yapıştırın:

    int iAlignIndex = GetAlignIndex(GetRealAlignment());

• Tekrarlı fonksiyon çağrıları ortadan kaldırıldı. GetRealAlignment() fonksiyonu artık yalnızca bir kez çağrılıyor.
• Kod okunabilirliği ciddi şekilde arttı. Uzun ve karmaşık if / else zinciri yerine, amacı net bir yardımcı fonksiyon kullanıldı.
• Bakımı ve değiştirilmesi kolaylaştı. Alignment aralıkları tek bir yerde tanımlı. Değerler değişirse yalnızca bu fonksiyon güncellenir.
• Hata yapma riski azaltıldı. Çok sayıda koşullu blok yerine, merkezi ve kontrollü bir mantık kullanıldı.
• Modern C++ yaklaşımına daha uygun. constexpr kullanımı sayesinde derleyici optimizasyonlarına açık, niyeti net bir kod elde edildi.
• Davranış değişmeden iyileştirme yapıldı. Mevcut oyun mantığı korunarak sadece kod kalitesi artırıldı.

Konu 'DB_NAME_COLUMN Sistemi Kaldırma Detaylı Rehber'

Pazartesi 19:18

Korece konuşmayan bize bir faydası olmadığı gibi hem kod kalabalığı yapıyor hem de encoding bozulması gibi sebeplerle sık sık geliştiricilere sorun çıkarıyor. Bence kaldırmak en doğrusu. Özetle proto'lardaki Korece isim / Lokal isim ikilemini kaldırıp tek sütun kullanacağız.

Nasıl Yapılır
​

Burayı görüntülemek için üye girişi yapmalı veya kayıt olmalısınız.

• Kaptan Yosun
• column kaldırma locale locale_name metin2 name rehber
• Yanıt: 0
• Forum: Rehberler

• 

[1] bool CClientManager::InitializeItemTable()
[2] bool CClientManager::InitializeMobTable()

• (mob/item)_proto_test.txt için ayrı bir “override” mantığı vardı: ekstra dosya okuma, ekstra tablo üretme, ekstra map ve set yönetimi.
• (mob/item)_names.txt için map<int, const char*> gibi sahipliği belirsiz pointer map’i kullanılıyordu.
• Aynı proto dosyaları birden fazla kez okunup addNumber gibi ek hesaplarla gereksiz karmaşa yaratıyordu.
• new[], memset, iterator/itertype gibi yapılarla hem okunması zor, hem bozması kolay, hem de riskli bir akış vardı.

Bu refaktörde yapılanlar (özet):​

• item_proto_test.txt ve mob_proto_test.txt mantıkları tamamen kaldırıldı.
• item_names.txt / mob_names.txt tarafı modernize edildi:
  
  • atoi yerine str_to_number ile daha güvenli parse,
  • std::unordered_map<int, std::string_view> ile daha net lookup.
• Proto dosyaları tek bir akışla okunur hâle getirildi:
  
  • Dosya aç → header atla → reserve → emplace_back ile parse → logla → vnum’a göre sırala.
• memset ve gereksiz default initialization’lar kaldırıldı.
• resize + index yerine reserve + emplace_back modeli kullanıldı.

Bu refaktörün sağladığı faydalar:​

• Dosya okuma/parsing akışı tek hâle geldi → denetlemesi kolay
• Gereksiz ctor / assignment / reallocation yok → daha temiz ve ölçeklenebilir
• test_map / vnumSet / addNumber gibi yan yapılar yok → karmaşa azaldı
• Re-load senaryosu daha temiz → tablolar kontrollü şekilde yeniden kuruluyor
• Modern C++ yaklaşımına daha uygun → unordered_map, reserve + emplace_back, net object lifetime

Larry Watterson demiş ki:

amacım konunuzu baltalamak değil lütfen yanlış anlamayın, hatta zaman ayırabilirsem katkı sağlamak isterim, mantıklı bir başlık. söylediklerim sadece genel bilgilendirme. kullandığınız C++26 değil ki,

C++:

    std::vector<TClientItemTable> items(rowCount);
    std::ranges::fill(items, TClientItemTable{});

burda mesela vector'un default ctorunu çağırmışsınız, bu işlem zaten "rowCount" değeri kadar "TClientItemTable" structını default ctor ile ramde oluşturur.
"fill" algoritması ise default ctor ile bir adet nesneyi hayata getirir ve her elemana bu nesneyi kopyalar (yani örneğin rowCount değeri 1k olsun bu 1k kez kopya oluşturmak demek, gereksiz bir maliyet) yani;

1-> "std::vector" default ctor ile x tane "TClientItemTable" oluşturdu
2-> std::ranges::fill, bir kez default ctor "rowCount" kez copy assign operator çağrıldı

niyete göre "reserve" edilip eleman pushlanabilir, assign benzeri member funclar kullanılabilir vesaire, ama sizin kullanımız pek doğru değil.

yani bu iki işlemde aslında siz rowCount +1 kez default ctor ve rowCount kadar kopya oluşturdunuz

C++:

        const std::string_view name = it->second;
        strlcpy(itemTable->szName, name.data(), sizeof(itemTable->szName));

burda bir UB kokusu var ama csvparser ne yapıyor bir fikrim yok bu yüzden net bir şey söyleyemiyorum, null string'den kaynaklı bir sorun meydana gelebilir(ihtimal, kodu bilmiyorum. string_view bir nesnenin başlangıç adresini ve sizeını tutar, genelde karşılaşılacak sorun lifetime ve null stringdir).

diğer kodlarınızda patch olarak nitelendirilebilir, örneğin "GetAlignIndex"

gerçek bir modernizasyonda sanırsam şöyle bir tablo olabilirdi(işte branchless yapılabilirdi, o olabilirdi bu olabilirdi, mikro optimizasyon konuşmuyorum(derleyiciden akıllı değiliz, erken optimizasyon optimizasyon değildir), ilk aklıma gelen yöntem bu "modernize" etmek açısından, derleyici optimizasyonuyla assembly düzeyde büyük ihtimalle aynıya yakın kod üretilir, kontrol etmek gerek);

(yanlış hatırlamıyorsam C++20'de constexpr fonksiyonların içinde static tanımlayamıyorduk, bu kod C++ sürümünüze göre derlenmeyebilir ama 23'de legal)

C++:

[[nodiscard("please use the align index ret value")]] static constexpr std::uint8_t GetAlignIndex(int align) noexcept
{
    static constexpr std::array align_arr_idx_table{
        120'000, //0
        80'000, // 1
        40'000, //2
        10'000, //3
        0, // 4
        -40'000, //5
        -80'000, //6
        -120'000, // 7
    };

    const auto iter{std::ranges::lower_bound(align_arr_idx_table, align, std::ranges::greater{})};

    if (iter == align_arr_idx_table.cend())
    {
        return align_arr_idx_table.size();
    }

    return static_cast<std::uint8_t>(std::ranges::distance(align_arr_idx_table.begin(), iter));
}

çok uzatmadan; C++26'dan önce C++20 ve 23'e odaklanmanızı tavsiye edebilirim, en basitinden bu txt'leri run time maliyetinden kurtararak tamamen compile timeda okumanız bile mümkün, yaptığınız o zaman refactor olabilir naçizane, emeğinize sağlık.

Hepsini görmek için tıklayın...

m_vec_itemTable.clear();
m_vec_itemTable.resize(rowCount);

Kaptan Yosun demiş ki:

Konuyu tam olarak bunun için yoruma açık tutuyorum, katkınız için teşekkür ederim.

Başlığa C++26 yazmamın sebebi en azından C++26 ile derlenebilir kod almak ve daha modern yaklaşımları teşvik etmek. Yoksa evet bu özellikler C++20 ile geldi.

UB kokusu var dediğiniz yerde hakkınız var, ancak pratikte CSV parser \0’lu buffer veriyor.

Bug yok ancak kod sadece suboptimal. Yine de eski koda göre hala çok daha temiz bu hali.

Bu rowcount kere yapılan copy assignment'i de evet gereksiz iş yükü olmuş, işaret ettiğiniz için teşekkür ederim. Bunu da direkt fill fonksiyonunu tamamen kaldırarak elimine edebiliriz. Çünkü resize(rowCount) zaten rowCount adet TItemTable default-construct eder.

C++:

m_vec_itemTable.clear();
m_vec_itemTable.resize(rowCount);

Herhalde en optimal kod bu şekilde olur.

Eski kod memset ile byte-level sıfırlamaya güveniyordu. Bu C kodu için normal ama C++ için güvenli değil. Artık default initialization üzerinden ilerlemek daha doğru. C++'ın kendisine bıraktım yani işi.

Ana yorumdaki std::ranges::fill kısımlarını siliyorum, daha iyi bir öneriniz varsa lütfen yorum yapınız.

Tekrardan, katkınız ve yapıcı elestiriniznicin teşekkür ederim. Lütfen ileride de yaptığım patch/refaktörleri eleştirmeye devam edin.

Hepsini görmek için tıklayın...

m_vec_itemTable.clear();
m_vec_itemTable.resize(rowCount);

• İlk öğe pushlandı -> Sorun yok. Duruma göre ya default ctor + copy veyahut move ctor (veya direkt emplace edilirse placement-new ile alakalı ctor) çalıştı.
• İkinci öğe pushlandı -> Üsttekiyle aynı + re-allocation oluştu. Neden? Kapasite doldu. RAM'de yeterli alan reserved olmadığından dolayı, C++ runtime RAM'de yeni boyuta uygun yeni bir alan tahsis etti ve nesneler henüz Object Lifetime'ı devam ederken yen bellek bölgesine taşındı. (Şayet move ctor sağlandıysa [noexcept garantisi olması gerekir] move ctor veyahut default edildiyse, burada vector'deki nesneler teker teker move edilir ama move ctor not declared ve copy operator declared veyahut provided ise copy ctor çağırılır maliyetlidir)

m_vec_itemTable[0] = ItemTable{}; // default varsayalım

m_vec_itemTable.clear();
m_vec_itemTable.reserve(rowCount);

for(std::size_t row_idx{}; row_idx < rowCount; ++row_idx)
{
    m_vec_itemTable.emplace_back(arg1, arg2...); // placement-new uygulanır, yani nesne direkt burda oluşut ve uygun ctor'a iletilir
    // Veyahut
    m_vec_itemTable.emplace_back(std::move(item_table)); // push_back de olabilir, ikisi de move ctor'u çağıracaktır.
}

• "reserve" member func, size argüman geçtiğiniz sayı kadar RAM'de bir alan tahsis(raw memory) eder, Object Lifetime burda başlamaz yani hiçbir nesne henüz hayata gelmemiştir ve bu alan dolana kadar re-allocation yaşanmaz.
• Tabloyu okursunuz ve container içine push/emplace işlemini yaparsınız.

Larry Watterson demiş ki:

Estağfurullah bir şey yapmadım, sadece bakınırken gözüme çarptı, o yüzden yazmak istedim.

C++:

m_vec_itemTable.clear();
m_vec_itemTable.resize(rowCount);

Bu tam optimal olmayabilir. Neden?

m_vec_itemTable, isminden gördüğüm kadarıyla bir member variable.​

Örneğin; siz boot sekansında database'den okuyup bu vector'e nesneyi pushluyorsunuz veya emplace ediyorsunuz.

Yine örneğin; bu tabloda 3 tane kayıt var. (Bu tablo item_proto'yu tutuyorsa binlerce kayıt vardır demek; anlaşılması açısından sayıları minimal tutuyorum.)

• İlk öğe pushlandı -> Sorun yok. Duruma göre ya default ctor + copy veyahut move ctor (veya direkt emplace edilirse placement-new ile alakalı ctor) çalıştı.
• İkinci öğe pushlandı -> Üsttekiyle aynı + re-allocation oluştu. Neden? Kapasite doldu. RAM'de yeterli alan reserved olmadığından dolayı, C++ runtime RAM'de yeni boyuta uygun yeni bir alan tahsis etti ve nesneler henüz Object Lifetime'ı devam ederken yen bellek bölgesine taşındı. (Şayet move ctor sağlandıysa [noexcept garantisi olması gerekir] move ctor veyahut default edildiyse, burada vector'deki nesneler teker teker move edilir ama move ctor not declared ve copy operator declared veyahut provided ise copy ctor çağırılır maliyetlidir)

Bu re-allocation, kapasite doldukça tekrar edilir ve maliyetli bir işlemdir; hele ki copy ctor çalışıyor ve struct'ınız trivially copyable değilse.

Örneğin; birkaç record eklediniz ve bu fonksiyonu yeniden tetiklediniz (reload vs. yoluyla);

Önce clear çağrıldı -> Bu yöntemle kapasite aynı kalır ve tüm elemanlar silinir. Yani örneğin; sizin kapasiteniz şu an 10. (Her derleyici bu kapasite artırım katsayısını kendisi implemente ediyor, ISO tarafında bir standart yok ama genelde 2 katı olarak artırım sağlanır.)

Sonra "resize" member func tetiklendi;

-> Yeni tabloda kaç tane record varsa o kadar adet default ctor çağrıldı.
-> Buradan sonrasında indeksteki elemana atama yapmanız gerekir mantıken. Örneğin:

C++:

m_vec_itemTable[0] = ItemTable{}; // default varsayalım

Burada tekrardan bir nesne hayata getirmiş olacaksınız ve bunu move edeceksiniz (yukarıdaki kodda copy assign operator çalışır). Bu da yeniden gereksiz maliyet sayılabilir (zaten rowCount kadar nesneyi RAM'de hayata getirdiniz resize fonksiyonu ile). Sonradan bir nesne emplace/push ederseniz kapasite büyük ihtimalle yeniden arttırılmaya çalışacak ve yine re-allocation yaşayacaksınız.

Bu hangi durumda kullanılabilir?

Şayet <algorithm> başlık dosyasından bir algoritmayı koşturacaksanız bu zaten zaruriyettir. Alakalı container'da yeterli eleman(boş bir containersa) yoksa ve algoritma koşturursanız (örneğin std::transform) programınız crash yiyecektir(seg fault).

Ben olsam şunu yapardım:

C++:

m_vec_itemTable.clear();
m_vec_itemTable.reserve(rowCount);

for(std::size_t row_idx{}; row_idx < rowCount; ++row_idx)
{
    m_vec_itemTable.emplace_back(arg1, arg2...); // placement-new uygulanır, yani nesne direkt burda oluşut ve uygun ctor'a iletilir
    // Veyahut
    m_vec_itemTable.emplace_back(std::move(item_table)); // push_back de olabilir, ikisi de move ctor'u çağıracaktır.
}

Neden?

• "reserve" member func, size argüman geçtiğiniz sayı kadar RAM'de bir alan tahsis(raw memory) eder, Object Lifetime burda başlamaz yani hiçbir nesne henüz hayata gelmemiştir ve bu alan dolana kadar re-allocation yaşanmaz.
• Tabloyu okursunuz ve container içine push/emplace işlemini yaparsınız.

Run-time'da bu container'a bir şey eklemeyeceğinizi düşünürsek, kullanabileceğiniz en mantıklı yöntemlerden biri budur.
Umarım çok fazla teknikte boğmamış ve anlatabilmişimdir. C++; 2 satır kodun altında bile çok fazla teknik detay yatan bir dil, ben minimal tutmaya çalıştım. Haddime olmasa da Bjarne'nin bir konuşmasında "kullanacağınızı kadar öğrenin yeter, her detayı bilmenize gerek yok" benzeri söylemini kendimce yanlış buluyorum(lütfen "Bjarne'den iyi mi bileceksin kardeşim! kimsin sen ya?" diyecekler demesin, bu benim tamamen şahsi görüşümdür, herkesin bir görüşü ve hatası olabilir), şahsımca mükemmel ve çok güçlü bir dil(ki bundan para kazanıyorum, sevdam sorgulanamaz) ama kontrolsüz güç, güç değildir. Günümüz "rust" sevicileride burdan çıkyıor zaten, yine de Metin2'nin kaynak kodlarına göre(zaten berbat bir mühendislik) bu detaylar "over-engineering" gibi tanımlanabilir bazı arkadaşlar tarafından ama olması gereken, prod-levelde kullanılan ve doğrusu budur. Saygılarımla.

Hepsini görmek için tıklayın...

    /* - [4] Allocate target vector --------------------------------------------
       We re-load to get accurate row count after header.
       RowCount includes header, so we subtract 1.
    -------------------------------------------------------------------------- */
    data.Destroy();

    if (!data.Load("mob_proto.txt", '\t'))
    {
        fprintf(stderr, "Failed to reload mob_proto.txt\n");
        return false;
    }

    data.Next(); // skip header row

    m_vec_mobTable.resize(data.m_File.GetRowCount() - 1);

    /* - [5] Parse rows ---------------------------------------------------------
       Parse row-by-row into pre-allocated vector slots.
       index guard prevents overflow if file has unexpected row count issues.
    -------------------------------------------------------------------------- */
    std::size_t index = 0;

    while (data.Next() && index < m_vec_mobTable.size())
    {
        TMobTable& mob = m_vec_mobTable[index];

        if (!Set_Proto_Mob_Table(&mob, data, localMap))
        {
            // Non-fatal: we keep going to load as much as possible.
            fprintf(stderr, "Failed to parse mob_proto row.\n");
        }

        /* - [6] Debug log ----------------------------------------------------- */
        sys_log(1, "MOB #%-5d %-24s level: %-3u rank: %u empire: %d",
            mob.dwVnum,
            mob.szName,
            mob.bLevel,
            mob.bRank,
            mob.bEmpire);

        ++index;
    }

    /* - [4] Reserve target vector capacity -------------------------------------
       We re-load the file to get an accurate row count.
       reserve() allocates raw memory only; no TMobTable objects are constructed yet.
       This prevents re-allocation during parsing.
    -------------------------------------------------------------------------- */
    data.Destroy();

    if (!data.Load("mob_proto.txt", '\t'))
    {
        fprintf(stderr, "Failed to reload mob_proto.txt\n");
        return false;
    }

    data.Next(); // skip header row

    const std::size_t rowCount = data.m_File.GetRowCount() - 1;

    m_vec_mobTable.clear();
    m_vec_mobTable.reserve(rowCount);

    /* - [5] Emplace and parse rows ---------------------------------------------
       Each TMobTable is constructed directly inside the vector via emplace_back().
       Set_Proto_Mob_Table fills the object in-place.
       No temporary objects, no copy/move, no index-based assignment.
    -------------------------------------------------------------------------- */
    while (data.Next())
    {
        m_vec_mobTable.emplace_back();
        TMobTable& mob = m_vec_mobTable.back();

        if (!Set_Proto_Mob_Table(&mob, data, localMap))
        {
            fprintf(stderr, "Failed to parse mob_proto row.\n");
            m_vec_mobTable.pop_back();
            continue;
        }

        sys_log(1, "MOB #%-5d %-24s level: %-3u rank: %u empire: %d",
            mob.dwVnum,
            mob.szName,
            mob.bLevel,
            mob.bRank,
            mob.bEmpire);
    }

1. Reallocation riski ortadan kalkıyor
2. Gereksiz ctor / assignment maliyeti oluşmuyor
3. Nesneler doğrudan doğru ctor ile, tek seferde hayata geliyor

Denizeri24 demiş ki:

C++:

m_vec_mobTable.assign(data.m_File.GetRowCount() - 1, TMobTable());

28180 eklentisini görüntüle

Hepsini görmek için tıklayın...

Kaptan Yosun demiş ki:

Haklısın, resize + index üzerinden doldurma yaklaşımı çalışıyor ama gereksiz default ctor çağrılarına yol açıyor ve uzun vadede ölçeklenebilir değil. Bu yüzden düzgün bir refactor için clear + reserve + emplace_back modeline geçmek daha doğru.

Şöyle yaptım:

Eski:

    /* - [4] Allocate target vector --------------------------------------------
       We re-load to get accurate row count after header.
       RowCount includes header, so we subtract 1.
    -------------------------------------------------------------------------- */
    data.Destroy();

    if (!data.Load("mob_proto.txt", '\t'))
    {
        fprintf(stderr, "Failed to reload mob_proto.txt\n");
        return false;
    }

    data.Next(); // skip header row

    m_vec_mobTable.resize(data.m_File.GetRowCount() - 1);

    /* - [5] Parse rows ---------------------------------------------------------
       Parse row-by-row into pre-allocated vector slots.
       index guard prevents overflow if file has unexpected row count issues.
    -------------------------------------------------------------------------- */
    std::size_t index = 0;

    while (data.Next() && index < m_vec_mobTable.size())
    {
        TMobTable& mob = m_vec_mobTable[index];

        if (!Set_Proto_Mob_Table(&mob, data, localMap))
        {
            // Non-fatal: we keep going to load as much as possible.
            fprintf(stderr, "Failed to parse mob_proto row.\n");
        }

        /* - [6] Debug log ----------------------------------------------------- */
        sys_log(1, "MOB #%-5d %-24s level: %-3u rank: %u empire: %d",
            mob.dwVnum,
            mob.szName,
            mob.bLevel,
            mob.bRank,
            mob.bEmpire);

        ++index;
    }

Yeni:

    /* - [4] Reserve target vector capacity -------------------------------------
       We re-load the file to get an accurate row count.
       reserve() allocates raw memory only; no TMobTable objects are constructed yet.
       This prevents re-allocation during parsing.
    -------------------------------------------------------------------------- */
    data.Destroy();

    if (!data.Load("mob_proto.txt", '\t'))
    {
        fprintf(stderr, "Failed to reload mob_proto.txt\n");
        return false;
    }

    data.Next(); // skip header row

    const std::size_t rowCount = data.m_File.GetRowCount() - 1;

    m_vec_mobTable.clear();
    m_vec_mobTable.reserve(rowCount);

    /* - [5] Emplace and parse rows ---------------------------------------------
       Each TMobTable is constructed directly inside the vector via emplace_back().
       Set_Proto_Mob_Table fills the object in-place.
       No temporary objects, no copy/move, no index-based assignment.
    -------------------------------------------------------------------------- */
    while (data.Next())
    {
        m_vec_mobTable.emplace_back();
        TMobTable& mob = m_vec_mobTable.back();

        if (!Set_Proto_Mob_Table(&mob, data, localMap))
        {
            fprintf(stderr, "Failed to parse mob_proto row.\n");
            m_vec_mobTable.pop_back();
            continue;
        }

        sys_log(1, "MOB #%-5d %-24s level: %-3u rank: %u empire: %d",
            mob.dwVnum,
            mob.szName,
            mob.bLevel,
            mob.bRank,
            mob.bEmpire);
    }

Artık bu şekilde

1. Reallocation riski ortadan kalkıyor
2. Gereksiz ctor / assignment maliyeti oluşmuyor
3. Nesneler doğrudan doğru ctor ile, tek seferde hayata geliyor

Ana refaktör yorumumu da buna göre düzenleyeceğim. Bu sefer oldu gibi, ne dersin?
Detaylı ve yapıcı açıklama için ayrıca teşekkür ederim.

Hepsini görmek için tıklayın...

auto& elm{m_vec.emplace_back(args..)};

(void)elm.id;

    while (data.Next())
    {
        TMobTable mob_table{};

        if (!Set_Proto_Mob_Table(&mob_table, data, localMap))
        {
            fprintf(stderr, "Failed to parse mob_proto row.\n");
            continue;
        }

        sys_log(1, "MOB #%-5d %-24s level: %-3u rank: %u empire: %d",
            mob_table.dwVnum,
            mob_table.szName,
            mob_table.bLevel,
            mob_table.bRank,
            mob_table.bEmpire);
        
        (void)m_vec_mobTable.emplace_back(std::move(mob_table)); // struct trivially copyable ise move gereksiz
    }

Larry Watterson demiş ki:

Olabilir evet, bu arada emplace_back son eklenen nesnenin referansını return eden bir overload sahip. İleridek kullanımlarınız için söylüyorum, en son eklediğiniz nesnenin referansına ulaşabilirsiniz.

Kod:

auto& elm{m_vec.emplace_back(args..)};

(void)elm.id;

gibi.


Önce ekle sonra if kontrolüne göre pop_back yap gereksiz kalabilir.

C++:

    while (data.Next())
    {
        TMobTable mob_table{};

        if (!Set_Proto_Mob_Table(&mob_table, data, localMap))
        {
            fprintf(stderr, "Failed to parse mob_proto row.\n");
            continue;
        }

        sys_log(1, "MOB #%-5d %-24s level: %-3u rank: %u empire: %d",
            mob_table.dwVnum,
            mob_table.szName,
            mob_table.bLevel,
            mob_table.bRank,
            mob_table.bEmpire);
    
        (void)m_vec_mobTable.emplace_back(std::move(mob_table)); // struct trivially copyable ise move gereksiz
    }

İlk yapılanda şayet Set_Proto_Mob_Table fonksiyonu noexcept garantisi vermiyorsa, exception throw ettiği durumlarda başınız ağrıyabilir.

Direkt bir nesne emplace ettiniz ve şunlar oluştu:
-> vector'un sonunda default-construct edilmiş bir nesne var
-> Set_Proto_Mob_Table exception throw ettiği senaryoda catch ile eklediğini silmezseniz(pop_back ile yani) eklediğiniz nesne asla silinmez.
-> Potansiyel olarak yine re-allocation yaşanabilir

Size gönderdiğim kodda ise:
-> Set_Proto_Mob_Table bir exception throw etse bile bunu try catch ile yakalamanız yeterlidir, stack unwinding sayesinde "mob_table" nesnesi zaten otomatik yok olacaktır.

Hepsini görmek için tıklayın...

Kaptan Yosun demiş ki:

Metin2'nin neresi exception-safe ki? Bir de Set_Proto_Mob_Table zaten bool döndürüyor. Sizin verdiğiniz kod server ve Dump Proto parsing için over-engineering değil mi? Yanlış mı düşünüyorum?

Hepsini görmek için tıklayın...

Larry Watterson demiş ki:

Yani o Metin2'nin sorunu benim yazdıklarım başlıktakı "Modern C++ ile Refaktör" ile ilgili, Metin2 evet exception-safe değil ama sonuçta yaptığımız "Moder C++ Refaktörü", Metin2'de olmaması bu durumun "yok" olduğu anlamına gelmiyor ki sadece Metin2'de ele alınmamış veyahut yok sayılmış oluyor, halbuki çok önemli bir konudur.(gerçi C++11 öncesi direkt noexcept specifier yoktu ama farklı yöntemlerle sağlanabiliyordu[detaylarına aşırı hakim değilim Modern C++ öncesinde ne yaptıklarının.]).

Verdiğim kodda neden over-engineering olduğunu düşündüğünüzü söylerseniz onu da açıklayabilirim ama böyle bir durum yok ki, sizin yönteminizde mantık şu; "Önce çantaya bir tane kalem koyayım, gerekli şartları sağlanmazsa kalemi çantadan geri çıkarayım."
Benim verdiğim ise şu; "Önce şartları kontrol edeyim, şartlar tamam ise kalemi çantaya koyayım." (ek olarak Exception Safety konusuna değinmeyeceğim.)

Kod olarak bakacak olursanız kodda fazladan 2 satır silindi ve emplace kontrolden ve logdan sonraya eklendi, neden böyle düşündüğünüze anlam veremedim açıkçası.

Hepsini görmek için tıklayın...