template 型別的需求描述:C++20 concepts(part 1)

Template 是 C++ 一個泛型的重要功能。透過 template 可以讓開發者只要寫一次,就可以針對不同的型別的資料,來做處理。

他雖然用起來很方便,但是大部分情況下都缺少對於需求型別的描述,所以如果沒用好寫錯了,就很有可能因為使用了不符合需求的型別,而導致無法正確編譯;而這個時候,編譯器給個錯誤訊息往往也會過於雜亂、讓開發者難以理解、也難以找到真正的問題點。

比如說下面這個簡單的範例程式:

閱讀更多»

Qt 安裝腳本更新

之前有寫了一篇《在 Windows 命令提示字元安裝 Qt SDK》,大概紀錄了一下,在沒有圖形介面的環境下,使用腳本來安裝 Qt SDK 的方法。

腳本在當時是沒問題的,但是沒想到前幾天要用的時候,卻發現又無法使用了…

網路上找了一下資料,發現似乎是在過沒幾天、Qt 把安裝程式更新到 3.1.x 後,又改了一些東西造成的。(拜託顧一下相容性啊…)

找到的資料是 StackOverflow 上的《Bypassing “User Data Collection" screen》這個回應。根據他的說法,這次改版主要是加入了「User Data Collection」的畫面,另外在選擇元件的部分也多了分類的選擇。

也因此,腳本要針對這兩個變化,做出修改:

閱讀更多»

GitLab 的 feature flag 設定

最近 Heresy 還是繼續在玩 GitLab CI/CD 的應用。

之前 GitLab 推出了 DAG 的功能,透過 needs 這個標籤,可以多線同時進行工作,在某些場合算是相當方便的~

不過後來因為 Heresy 試著把工作拆分到很細,所以就採到他的一個問題,那就是 needs 的數量上限了。

在官方文件(連結)中也有提到,目前有針對 needs 中指定的工作數量做限制。下面是原文:

We are temporarily limiting the maximum number of jobs that a single job can need in the needs: array:

  • For GitLab.com, the limit is five. For more information, see our infrastructure issue.
  • For self-managed instances, the limit is:
  • Five by default (ci_dag_limit_needs feature flag is enabled).
  • 50 if the ci_dag_limit_needs feature flag is disabled.

 

閱讀更多»

在 Windows 命令提示字元安裝 Qt SDK

這篇算是《GitLab CI + Windows Docker 的一些紀錄》的延伸。由於 Heresy 這邊的開發專案有用到 Qt SDK(官網),所以在建置用的 Docker 容器裡面,也需要安裝 Qt 的 SDK。

但是由於 Qt 現在的線上安裝程式也都是以圖形介面為主,並在圖形介面中選擇要安裝那些套件;所以要怎麼在沒有圖形介面的 Docker 內安裝,就需要稍微研究一下了。

在找了一些資料後,可以知道 Qt 的安裝程式框架(Qt Installer Framework、QTIFW、官方文件)是有支援使用腳本(script)來做控制的!(官方文件

而在網路上,也可以找到使用這樣的機制,來自動安裝  Qt 的腳本範例。Heresy 這邊是參考《How can I install Qt 5.2.1 from the command line in Cygwin?》的例子。

閱讀更多»

Visual C++ 2017 的 Docker 建置環境

前一篇《GitLab CI + Windows Docker 的一些紀錄》的時候,Heresy 已經大概有說明最近在玩 GitLab CI/CD,並試著拿 Docker 來做 Runner 時、在 Windows 平台上碰到的一些狀況了。

當時本來是想放棄的,不過後來還是繼續玩下去了;而玩了一個多禮拜,也總算是把整個環境初步完成了。

而這篇,就來分享一下,Heresy 這邊建置出 Visual C++ 2017 建置環境的 Docker 映像檔的紀錄。

首先,微軟官方其實針對怎麼建立包含 Visual Studio 的 Docker 映像檔有好幾個地方都有範例(範例一範例二範例三),內容基本上都相當地類似。

Heresy 這邊最後能用的範例,是基於 dotnet-framework:3.5-sdk-windowsservercore-1709 的版本(連結),其內容如下:

閱讀更多»

GitLab CI + Windows Docker 的一些紀錄

Docker(官網)這種比虛擬機器更輕量化的「容器」虛擬化技術,基本上算是這幾年來一個滿重要的技術。透過 Docker,他可以將需要的環境打包、建構出類似虛擬機器,但是更小、更彈性的可移植環境,在需要自動佈署的環境上,應該算是很實用的一種技術。(參考介紹參考介紹

不過由於工作的領域不同,所以 Heresy 其實之前都沒有去碰這一個技術;真的開始接觸到,是之前試著使用 Docker 來架設 GitLab Server 的時候開始的。

後來,Heresy 也很認真地開始搞整個 GitLab CI/CD 的架構,試著透過 GitLab 的系統來做一些程式開發的自動化建置、測試。最初,考慮到環境的熟系程度,Heresy 都是直接使用作業系統的 shell 來作為 gitlab-runner 的 executor。

閱讀更多»

C++11/14 literals:part 2

針對 C++11C++14 的 literals,前面已經寫了 part 1 來針對標準提供的 literals 做了一些說明;而接下來這篇,則是來紀錄一下如何自訂屬於自己的 literals、也就是所謂「User-defined literals」(CppReference)。

在定義 User-defined literals 的時候,能支援的格式是有限制的,包括了:

  • 整數:(unsigned long long int)
  • 浮點數:(long double)
  • 字元:(char)(wchar_t)(char16_t)(char32_t)
  • 字串:(char,size_t)(wchar_t,size_t)(char16_t,size_t)(char32_t,size_t)

如果不是這些型別的話,是不能編譯的。

閱讀更多»

Boost ASIO WebSocket Server 網站憑證設定

Heresy 這邊很早之前,就有開始使用 WebSocket++ 來開發自己的 WebSocket Server;而後來其實也有改用 Boost.Beast 來做同樣的工作。而這兩套函式庫的底層,其實都是 Boost::asio(官網),所以其實在某些地方還滿接近的。

而之前用起來都還算很正常,不管是老老的 IE 還是 Chrome 都可以使用,在有申請 SSL 憑證的情況下,就算建立加密的 WSS 也是可以正確使用的。

但是,前陣子當想使用 node.js(官網)來進行 WebSocket 的連線的時候,卻發現會出現「unable to verify the first certificate」的錯誤。

閱讀更多»

GitLab CI/CD 支援 DAG、工作可以多線同時進行了~

Heresy 今年把新的 GitLab Server 架好後,就開始玩 CI/CD(Continuous Integration and Deployment)的功能、試著透過這個架構,來做一定程度的自動化了。

除了目前 C++ 專案的自動建置腳本已經算是完成了,其他一些特別的工作,也開始試著用 GitLab CI/CD 來玩,所以這段期間對這東西還算玩得滿認真的。

而從開始些 C++ 專案的跨平台建置開始,其實 Heresy 就覺得 GitLab CI/CD 的架構,有一點很討厭,就是他是基於「stage」來控制流程的,前面的 stage 沒有全部結束的話,後面的 stage 就不會進行。

所以如果整個 pipeline 有 build 和 test 兩個 stage 的情況下,就會變成要所有的 build 都完成,才能進行測試。

閱讀更多»

[濫用] GitLab CI/CD 的 cache 機制

感謝網友提醒,根據官方《Cache vs artifacts》的說法,看來 Heresy 這邊把 build 階段產生的檔案透過 cache 傳遞到 test 階段,應該是嚴重的誤解/誤用了。 XD


之前在《GitLab 簡單的 C++ 專案腳本範例》和《GitLab 的 C++ CI/CD 腳本:使用 PowerShell》這兩篇文章,有分享了 Heresy 這邊目前 GitLab CI/CD 的腳本寫法了。

而當時也有提到,在 build 階段到 test 階段,Heresy 沒有玩出比較正規的檔案傳遞方法。

最近 Heresy 又開始測試這部分的東西。理論上,要在不同的 job 間傳遞檔案,是要透過在 .gitlab-ci.yml 裡面加上 cache官網)來做。

在有加入 cache 的狀況下,GitLab Runner 會在 job 開始、透過 git 取得檔案後,就試著把 cahce 的檔案抓下來;而當腳本執行完後,則會再把 cache 指定的檔案打包,放到 Gitlab-runner 上。

Heresy 目前加上 cache 後的 .gitlab-ci.yml 大致上會像下面這樣:

閱讀更多»