2026/01/14(水)cpprefjpを読もう。【変数の型推論のためのauto】

C++11 変数の型推論のためのauto [N1984] cpprefjp

C++11からの機能で、変数宣言時に具体的な型名を省略して宣言できる。
個人的にはユーザー定義クラスを使用する時に使用する印象。
ある程度短い型名ではわざわざ使わないかも。uint16_tとか...

auto container = std::vector<std::pair<uint8_t, uint16_t>>();
auto user_class = UserDefineClass<uint32_t>();

仕様

auto による型推論は、以下の場所で初期化子がある場合のみ使用可能である。
  • ブロックスコープでの変数宣言
  • 名前空間スコープでの変数宣言
  • for 文の初期化文部での変数宣言
  • if 文、 switch 文、 for 文、 while 文の条件部での変数宣言
  • new 式の型名指定部
  • クラス定義内での静的メンバ宣言

なんとなく変数の初期化で使用できるイメージだが、使用できないケースについてGeminiで確認した。
が、思考モードにしても結構適当言われたので無課金だとあんまり当てにならないな...
cpprefjpを適当でもだらだら見ていなかったら気づかんかったな
以下内容は一応整合性は確認した。

autoが使用できないケース
  • 関数引数
    確かに、あまり見たことない気がする。
    C++14でジェネリックラムダ、C++20で関数テンプレートの簡易定義というものが追加され使用できるようになっているらしい。
    詳細はまたいずれ...

  • 非静的メンバ変数
    言われてみると関数内、式の中でしか見てないな。
    static constまたはstatic constexprの場合は使用可能らしい。
    wnadbox

  • 関数の戻り値
    C++11の機能戻り値の型を後置する関数宣言構文 [N2541]で表現可能。

    auto func() -> int {
        return 0;
    }
    

    以前、標準ライブラリのtype_traitsを見ていた時に結構見かけた。
    ただ、自分で実装する時に使用するかといわれると...
    現状あんまり有効活用できるイメージがない

  • 配列宣言
    初期化子リストとしては使用可能らしい。一応コード例 wandbox
  • テンプレート引数
    c++17からは使用可能らしい 非型テンプレートパラメータのauto宣言 [P0127R2]

2025/12/04(木)プログラマーのための圏論 課題1

プログラマーのための圏論

1. 恒等関数を、好きな言語で(それがたまたまHaskellなら2番目に好きな言語で)できるだけうまく実装せよ。

C++の場合、すでに例が出ているのが後で使うので

template<typename T>
T identity(T arg)
{
    return arg;
}

C#のジェネリクスで書くと以下のようになるか。

public T func<T>(T arg) 
{
    return arg;
}

あと、次の課題のために<functional>のヘッダーを調べたらドンピシャなものがあった。
std::identity


2. 合成関数を好きな言語で実装せよ。このメソッドは2つの関数を引数として受け取り、その合成である関数を返す。

C++の場合

#include <functional>

template <typename T>
T composite(std::function<T(T)> f, std::function<T(T)> g, T a)
{
    return g(f(a));
}

Cの場合
関数ポインタのtypedefってぱっと見でわかりづらいな

typedef int (*fptr)(int);
int composite(fptr f, fptr g, int a)
{
    return g(f(a));
}


3. 合成関数が恒等関数と整合しているかテストするプログラムを作成せよ。

1と2で作った関数を組み合わせて動かせって意味であってるよな?

C++の場合(wandboxで確認)

int main()
{
    int val = composite(identity<int>, identity<int>, 10);
    std::cout << val << std::endl;
}

結果

10


4. ワールドワイドウェブは、何らかの意味で圏だろうか? リンクは射だろうか?

射は対象と対象をつなぐものなので、ページとページをつなぐ場合
リンクは射と言えるはず。
wwwは複数の対象(ページ)とそれらをつなぐ射(リンク)で構成されているので、
wwwは圏と言えるはず。


5. Facebookは人を対象とし友達関係を射とする圏だろうか?

4と同様に複数の対象を人、それらを繋ぐ射を関係性とするならば
Facebookは圏と言えるはず。


6. 有向グラフが圏になるのはどのような場合だろうか?

すいません、有向グラフって何ですか (高卒並感
wikiを見る...
グラフ理論

つながり方だけではなく「どちらからどちらにつながっているか」をも問題にする場合、エッジに矢印をつける。このようなグラフを有向グラフ、または、ダイグラフという。

対象はグラフの各ノード、それらのつながりがエッジとなるので
有向グラフはそもそも圏なのではないか?

問い方から考えると有向グラフそのものは圏ではないと言ってそうだが...
有向グラフについてwikiをぱっと見じゃ判断できないね
もう少し調べてみよう。

2025/02/06(木)ゆるGIT学習

今まで仕事ではもっぱらSubversionを使っていた。
WindowsなのでクライアントはTortoiseSVN
新しい仕事でgitを使うことになったのでいろいろ再確認していく。
趣味で使う分には雰囲気で操作しても問題ないんだが、仕事だとさすがに?って思ったので
誤った記載があったら修正しますんでコメントください

基本

originってなんだよ

リモートリポジトリのエイリアス
以下は同じ意味になる

git fetch origin master
git fetch git@github.com:hoge/fuga.git master
HEADってなんだよ

作業中ブランチの最新コミット

コマンド

clone

ざっくりfetch+checkout
リモートの最新を取得し、デフォルトブランチをチェックアウトする。 gitのデフォルトブランチ名はmaster
そういえばgithubは数年前からmainになったね

pull

内部的にはfetch + merge
fetchorigin/master が最新に更新される
mergemaster ブランチに最新が取り込まれる

fetch

リモートの最新を取り込む
ローカルブランチには反映されない
origin/masterは最新になるがmasterはそのまま

merge

2つの異なるブランチの変更を統合する。
この際、マージコミットという特別なコミットが生成される。

A---B---C-----M(マージコミット)
        |    /
        D---E
rebase

ブランチの変更を別のブランチの先頭に付けなおす
いまいち動作を把握しきれていない...

  1. 元の状態
    master: A---B---C---D---E
    .               |
    dev:            D'---E'
    
  2. devブランチ内でgit rebase masterを処理

    master: A---B---C---D---E
    .               |
    dev:            D---E---D'---E'
    
  3. masterブランチ内でgit rebase devを処理
    master: A---B---C---D---E---D'---E'
    
checkout

作業ブランチの切り替え

branch

新しいブランチを作成する。
git branch -aですべてのブランチ、作業中のブランチを表示する。

push

ローカルの変更をリモートへ反映させる

2024/12/15(日)ssh設定覚え書き

SSHの設定

鯖:Ubuntu 24.04.1LTS (openssh)
倉:Windows11 Pro (teraterm)

公開鍵の設定

クライアント側(Windows)作業

  1. 公開鍵の作成

パスフレーズ無しで作成。
生成場所を聞かれるので任意の場所に保存

> ssh-key-gen

サーバー側(Ubuntu)作業

  1. 鯖(Ubuntu)側で公開鍵を設定する
    ~/.ssh/authorized_keysに作製した公開鍵を書き込む

  2. パスワードでのログインを禁止する
    /etc/ssh/sshd_config内の以下設定を変更

- PasswordAuthentication yes
+ PasswordAuthentication no

以上

2022/10/26(水)github actions + vercel でスプラ3のスケジュール画像を自動生成&配信する環境を作った

動作概要

  • github actionsのスケジューリング機能で2時間おきに画像生成スクリプトを走らせる
  • 生成画像をgithubにpushしてvercelで自動デプロイ、publicフォルダの静的コンテンツとして配信できるようにした。

https://github.com/yotsugi-vip/vip-splat3-schedule

画像生成

生成スクリプト

  • splat3 API(有志公開の非公式API)
  • node-canvas
  • node-fetch

上記APIから24時間分のスケジュールをjsonで取得、cli上での動作となるのでnode-canvasjsonの内容を画像として吐き出すようにした。
オフセット設定がめんどくさかったけどまぁまぁ見れる形で出力できるようにした。

自動実行

github actionsのスケジューリング機能を使って2時間おきに画像生成スクリプトを実行するように指定
画像生成後はnextjsのpublicフォルダに格納しcommit & pushまで実行。
vercel上でpushを検知して自動ビルドしてくれる。

失敗談

vercelの仕様をよく読んでなかった点

最初期の環境の構成として

定期POST → API実行 → 生成画像公開の手順で作成したのだが、
vercelのpublicフォルダは書き込み不可なのを把握してなかった。

github actionsのスケジューラのTZがJSTじゃない

スプラトゥーンのステージは奇数時毎に更新されるのでスケジューラを

1,3,5,7,9,11,13,15,17,19,21,23時に設定したが、実際動作させると1時間ずれて実行されていた。
原因はgithub actionがUTC基準で動いていたためJSTの+9時間差で実行されていたから。
スケジューラはUTC基準で偶数時毎に起動するように変更した。