C++17 的 structured binding declaration

這篇來講一下，在 C++17 的時候，加入的一個還算滿好用的功能、structured binding declaration（文件）。

Structured binding declaration 在 Heresy 來看，主要的目的是讓開發者可以快速地將擁有多項資料的物件中拿出來使用。

像是以 std::tuple<> 來說，如果要把每一筆資料都拿出來的話，標準的作法是透過 std::get<>() 來一個一個拿，或是透過 std::tie() 來做一定程度的簡化。

而如果透過 structured binding declaration 的話，則可以進一步簡化成：

Copilot 八月 22 試用期結束後年薪 100 美元

之前有介紹過 GitHub Copilot 這個透過 AI 來輔助程式開發的工具了。他的定位是協同開發者，在極端的狀況下，甚至可以只靠註解就完成簡單的程式，算是相當厲害了。

不過，現在在預覽了兩個多月後，現在 GitHub 跳出來、公布 8/22 之後就要結束預覽、開始收費了（頁面）～

C++11 使用 emplace 取代 push_back 和 insert

以 vector 來說，以往要插入新的資料，大多會使用 push_back() 這個函式。

但是實際上，使用 push_back() 的時候，大部分的時候、我們會需要先建立一個臨時性的物件，然後在把他丟到 vector 裡面；實際上，在這邊也會產生額外的成本的～

像是下面這段程式碼：

C++20 std::format part 3 – 自定義型別的處理

這系列應該是最後一篇了。在講完了基本的使用、還有一些其他的函式，最後這邊來講一下要怎麼針對自己定義的型別、或是官方沒支援的型別做處理、讓他可以用在 std::format 上。

不過 Heresy 這邊也必須講一下，Heresy 自己沒有找到針對這部分比較完整的說明、範例，所以其實這裡的東西大多是網路上找了很多範例、自己拼湊出來的，其實也不太能保證都正確，只能說在 MSVC 上可以正常運作。

如果哪裡有寫錯的話，也希望可以告知一下。

C++20 std::format part 2：其他的函式

延續前面的 part 1，這邊繼續來講一些 C++20 std::format 的其他東西吧～
這邊，主要是來講一下他提供的一些其他函式。

---

輸出到既有物件／記憶體

std::format 所提供的函式，最基本的應該就是前面已經介紹過的 std::format()；他的用法基本上就是會產生一個 std::string、然後回傳出來。

而在某些狀況下，可能會需要他把資料寫到既有的變數／記憶體中，而不是建立一個新的物件，這時候，就可以使用 std::format_to()（文件）或 std::format_to_n()（文件）來做到。

Visual Studio 2022 17.2 正式推出

微軟在去年底正式推出了第一款原生 64 位元的 Visual Studio 2022（17.0）後，其實已經有一次比較大的更新、17.1 了～

不過比較可惜的是，Heresy 這邊的程式因為踩到 Lambda + OpenMP 的問題，所以一直沒能把主要的建置環境切換到 Visual Studio 2022…

而現在，微軟終於推出解決該問題的 Visual Studio 2022 17.2 了！
官方的介紹是《Visual Studio 2022 17.2 is now available!》，比較完整個變化則可以參考官方的 Release Note。

C++20 的標準資料格式化函式庫 part 1

由於 C++ 本身的 stream 要拿來做文字的格式化，使用上很麻煩，所以 Heresy 這邊之前都是用 Boost C++ Libraries 的 boost format 來做。

本來是期望 boost format 可以整到 std 裡面變成標準，不過很遺憾的是，C++ 20 雖然加入了 format 函式庫，但是卻不是基於 Boost format、而是基於 {fmt} 這個函式庫（官網、GitHub）的版本。

考慮到個人是希望盡量使用標準函式庫，這邊就來稍微整理一下 C++20 的 format 吧～

首先，這部分的文件可以參考：https://en.cppreference.com/w/cpp/utility/format

Visual C++ 終於正式支援 OpenMP 3 的 task 了

微軟的 Visual C++ 這幾年雖然對於 C++ 新的標準支援的算是相當積極，但是對於 OpenMP 的支援一直以來都很糟糕，儘管官方標準已經更新到 OpenMP 5.2 了，但是直到推出 Visual Studio 2019 的時候，卻還停留在 OpenMP 2.0 的超古老版本…

直到之前在 Visual Studio 2019 16.9 的時候，才終於試著開始幫 Visual C++ 的 OpenMP 加上新功能；當時主要的改進，是加入了 OpenMP 對於 SIMD 的支援，另外也開始試著要將 OpenMP 的實作切換到 LLVM 的版本。

而這次微軟又發布了《OpenMP Task Support for C++ in Visual Studio》，在最新的 Visual Studio 2022 17.2（還在預覽階段）中，在使用 LLVM OpenMP（加上 -openmp:llvm）的情況下，終於支援 OpenMP 3 的 task 這個 directive 了！

用 AI 來輔助寫程式：直接給你整個函式的 GitHub Copilot

GitHub Copilot（官網）是 GitHub 在 2021 年六月發布，一個透過 OpenAI（官網）的 Codex 系統（官網、應該是基於 GPT-3）來完成的 AI 程式輔助開發系統。

以往的程式輔助系統，大部分都是很局部的自動完成，例如自動完成要呼叫函式名稱、或是變數名稱；雖然算是很有幫助，但是其實相對侷限。

而 GitHub Copilot 則是透過深度學習技術，大幅強化了自動完成的能力，甚至變成可以只打註解、就給你整個函式的內容！在應用上的空間，算是提供了相當的程度。

Visual Studio 的 Solution Filter

在開發一個大型專案裡面，通常會有一堆小專案，彼此之間可能還會有很複雜的相依性；在 Visual Studio 裡，微軟是透過一個「方案」（solution、附檔名是 sln）來管理多個「專案」（project）的形式來做的，在開啟方案後，就會把所有的專案都載入。

但是實際上，大部分要開發的時候，其實都是針對特定專案來進行，其實只需要和他有關的專案就可以了，並不需要真的把所有的專案都載入。

為了這種需求，微軟其實有提供「方案篩選」的功能（官方文件），讓開發者可以在不修改方案的情況下，自行設定要載入那些專案、並儲存成一個 Solution Filter（副檔名是 slnf）的檔案，方便日後使用。