快速存取 tuple 的所有元素:std::apply

之前在《讓函式回傳多個值:std::tuple》這篇文章中,曾經介紹過 C++11 引進的 std::tuple 這個可以用來儲存多種不同型別的類別了。

而由於 tuple 內部可以存放不同型別的資料,所以雖然可以用 std::tie() 或是 C++17 的 structured binding 來存取資料,但是都是需要針對特定的 tuple 來寫;實際上如果想針對所有類型的 tuple 寫個通用的函式,其實還滿麻煩的。

在 C++11 比較好的方法,應該就是 Parameter Pack、以類似遞迴的方式來寫了吧?而由於要透過 std::get<>() 這個函式去存取 tuple 的值的時候,索引值會需要是編譯階段的參數,所以會變得更為難寫…

閱讀更多»

廣告

C++17 Fold Expression

之前 Heresy 曾經寫過一篇《C++11 的「…」:Parameter Pack》,算是簡單介紹了 C++11 新增的 「parameter pack」;這項功能,基本上就是用「...」來處理數量不固定的函式引數、以及 template parameter。

而在當時來說,真的要去處理這些數量不固定的 parameter pack,大概都是得用類似遞迴的方法來寫了。

到了 C++17,為了簡化這邊的開發難度,則是又引進了「fold expressions」的語法、來讓開發者可以更簡單地處理  parameter pack。(參考

閱讀更多»

C++ 固定大小的整數型別

這篇簡單來記錄一下 C++11 加入、代表特定大小的整數型別(Fixed width integer types)。

一般來說,在 C++ 裡面我們要使用整數型別的變數的時候,大致上會根據數值上的需求,宣告成 charshortintlonglong long;而如果不考慮負數的話,則可以在前面加上 unsigned、變成無號整數。而其他也還有像是 short intsigned short 這類的用法。

但是這邊有一個問題,那就是上面這些型別到底用了多少記憶體

char 由於代表的是字元,一般都是 8bit 沒有太大的問題;而 short 以此類推應該是 16bit,但是 intlonglong long 呢?理論上應該是二進位的形式越來越大,所以是 32、64、128 嗎?但是現在 C++ 真的有 128bit 的整數嗎?當然沒有。

閱讀更多»

Visual Studio 2022 17.6

Visual Studio 2022 的更新又來囉~這次的版本是 17.6,官方的公告是《Visual Studio 2022 – 17.6 Now Available》,這邊就來簡單紀錄一下個人有興趣的更新了。

首先,Visual Studio 執行後列出的新增功能列表如下:

  • C# 的 IntelliCode API 使用範例
  • .NET 遠端偵錯的視覺化檢視支援
  • Unreal Engine 記錄檢視器
  • Tim Jones 提供的 HLSL 工具擴充功能
  • 適用于 ARM64 裝罝的 .NET MAUI 工具
  • 適用于 Unix 的遠端檔案總管
  • CMake 偵錯工具
  • 匯入 C 或 C++ 內嵌 STM32CubelDE
  • GitHub 問題整合
  • 中斷點群組
  • WSL 上 .NET 的分析工具即時圖表
  • 建立 C + + 成員函式
  • C++ 的檢測分析工具
  • Android 資訊清單編輯器

閱讀更多»

C++23 std::optional 的新函式

之前 Heresy 就已經有在《更多元的函式回傳型別:optional 與 outcome》和《C++ 23 可以回傳值或錯誤的 std::expected》這兩篇文章介紹過 C++17 的 std::optional 和 C++23 的 std::expected 了。

不過,Heresy 是在看到《Functional exception-less error handling with C++23’s optional and expected》後,才發現原來 C++23 還有為 std::optional 增加新功能、讓他在使用上更方便!

這邊新增的有三個 monadic operation:and_then()transform()or_else(),這三者都是接受一個可呼叫的物件作為引數,來處理 std::optional 的不同狀況。(參考

閱讀更多»

Windows 的 GitLab Runner 可以在 Windows 11 使用 process 隔離的 Docker 了

之前 Heresy 就在《GitLab CI + Windows Docker 的一些紀錄 Part 2》抱怨過,GitLab Runner 如果要使用 Docker 作為 executor 的話,由於 Windows Runner 的作業系統版本會受限於 GitLab Runner 使用的 helper image 的支援度,這也導致如果要建立使用 Docker executor 模式的 Windows 版 GitLab runner 變得很麻煩。

像是之前 GitLab Runner 15.10 的時候,想在 Windows 11 的電腦上用 Docker executor 模式來跑 runner 的話,基本上就只會得到下面的錯誤:

ERROR: Preparation failed: detecting base image: unsupported Windows Version: 
Microsoft Windows Version 22H2 (OS Build 22621.1485)

而前一陣子,GitLab 更新到了 15.11 了(官方介紹),GitLab Runner 也同時更新到 15.11.0(changelog),這才終於更新了 Windows 版的 helper image,讓 Windows 11 的電腦可以使用 Docker executor 模式!

閱讀更多»

幫 C++ 的 output stream 加上 callback

這篇某種意義上算是之前《攔截 std::cout 的輸出結果》的延伸。

在把 std::cout 等內容攔截下來後,自然就是要想辦法拿來用了。但是要怎麼知道裡面有新東西、該去讀資料呢?

由於 std::streambuf參考)的設計應該是沒有辦法掛 callback 之類的東西,所以如果想要有類似的功能,應該就是得自己去擴展一個有 callback 功能的 stream buffer 了。

下面就是一個簡單的例子,會每行執行一次 callback:

閱讀更多»

在 Windows Docker 內建置 Qt 6.5 的問題

Heresy 這邊在 Docker 裡面使用 Visual Studio 來建立 Windows 版的 Qt 已經好一陣子了,有興趣的可以參考之前的《使用 Visual Studio 建置 Qt 6》。

而之前 Qt 6.x 的幾個版本改變都沒有太大的問題、可以直接建置出來;不過最近在要建置 Qt 6.5.0(官方介紹下載)的時候,卻碰到問題而沒辦法完成建置…這邊就稍微來記錄一下。

閱讀更多»

攔截 std::cout 的輸出結果

一般在寫 C++ 的程式的時候,大多會用標準輸出(standard output)來輸出文字、或是偵錯用的資訊。在標準函式庫裡面,針對輸出的部分就有提供 std::coutstd::cerrstd::clog,以及各自對應的寬字元版本。

但是在開發圖形介面的時候,往往不會顯示 console 視窗,所以這些訊息也就都看不到了。

而如果想要去攔截這些輸出的資訊,並將它們顯示在圖形介面裡面,該怎麼做呢?實際上,C++ 是允許是透過 rdbuf() 這個函式(參考),來取得或設定一個 stream 內部要使用的 stream buffer(參考)的。

也因此,透過這樣的機制,實際上是可以讓 std::cout 把資料寫到另外準備好的 stream buffer 中,然後再讀出來的!

閱讀更多»

Visual Studio 2022 17.5

微軟 Visual Studio 2022 第五次大更新來了~官方的公告是《Visual Studio 2022 – 17.5 Released》、直接和 C++ 相關的,則是《Visual Studio 2022 version 17.5 for C++ Developers》這篇;release note 的更新細節(頁面)也已經更新了。

這次官方的更新重點包括了(執行後列出來的):

  • 多合一式搜尋
  • 效能增強功能
  • 輕鬆將容器發佈至 Azure Container Apps !
  • ASP.NET Core – 開發人員通道
  • InteIIiCode – C# 建議的內嵌差異檢視
  • Unreal Engine Blueprints 支援
  • 編輯Markdown 檔案
  • 快速新增檔案
  • 文字視覺化檢視增強功能
  • 序列監視器
  • 複製及展開巨集展開
  • 程式碼涵蓋範圍篩選
  • 協助工具檢查程式

閱讀更多»