「C++」の記事 - Crieit

【随時更新】「ゼロからのOS自作入門」の実践

2023-04-09T21:54:23+09:00

ゼロからのOS自作入門
第3刷を読みながら、基本的には内容通りにやっていき、詰まったところをメモしていく。
記事を分けずに追記を重ねていきます。

環境

OS
Windows11
開発環境
WSL2+ubuntu18.04にみんな大好きVSCodeからSSH接続する形で作業
https://github.com/uchan-nos/mikanos-buildの「ビルド環境の構築」に従い環境構築

1章

1.1

WSL2でokteta使えるよ

バイナリエディタoktetaのインストール。書籍ではWSLならWindowsのバイナリエディタを使った方が良いとあったが、現在のWSLはGUIアプリに対応しているため、oktetaがそのまま使える。
リンク：Windows 10でもLinux GUIアプリが利用可能～Microsoft Store版が既定の「WSL」に

作成したEFIの実行環境は、書籍では以下の3通りが紹介されていた。
・USBメモリに入れて同じPCで起動(いちいち開発環境の中断になるため、非推奨)
・USBメモリに入れて別PCで起動
・エミュレータ(QEMU)での起動
自分はQEMUでの起動を選択したが、ubuntu版ではなくWindows版QEMUをインストールした。
この場合ビルド・デプロイした一式をWindowsから起動する1手間が必要になるが、VcXsrvのインストール・常駐は不要になる。Windows版は性能に制限がありそうなので、今後限界が来たら諦めてubuntu版QEMUを使用する事にする。

バイナリ直打ち結局動かない

書籍ではまずバイナリエディタで直接HalloeWorld実行ファイルを作成し、それを起動していたが、自分の環境ではどうやっても「Start PXE over IPv4」のエラーが出て正常に起動しなかった。まあ筆者と環境が違ったらその可能性もあるのでは？と、この項目をあきらめて、次に進んだ。

1.9

C++で1.4章と同じ内容のソースコードを作成・ビルドしたものを起動したら、こちらは正常起動した。なので1.4章がうまくいかなくても次に進んでしまって問題はないと思う。
そう考えるといろんな環境に対応してるWindowsってすごいなって思った。

2章

2.2

git不慣れマン

書籍に書いてあるcheckoutじゃなくてcloneした。

git clone -b osbook_day02a https://github.com/uchan-nos/mikanos.git

EDKⅡビルドでの生成ファイルの場所

自分は以下になっていました。
/home/common/edk2/Build/MikanLoaderX64/DEBUG_CLANG38/X64/MikanLoaderPkg/Loader/DEBUG/Loader.efi

2.5

すすめかた

checkoutして本読んでビルドするだけでは勉強にならなそう、でも写経は大変そうだったので、
1. 2.2章でcloneしたソースにgithubの該当タブのソース差分を直接コピペして育てていきながら
2. 本を読んでソース上にコメントで読解内容を書き込み
でやっていく事にする。

Win32APIでDrag＆Dropしたファイルをある場所にコピーする方法

2022-04-18T17:53:40+09:00

Win32APIでDrag＆Dropしたファイルをある場所にコピーする方法

1.宣言

#include "Shlwapi.h"
// Shlwapi.hの関数を使用するために下記の追加が必要
#pragma comment (lib, "Shlwapi.lib")

2.実処理

    UINT n;
    UINT i;
    UINT ret;
    TCHAR pszBuff[MAX_PATH * 10] = {};
    TCHAR pszNewFile[MAX_PATH * 10] = { _T("\\\\wsl$\\Arch\\mnt\\wsl\\share")};

    n = DragQueryFileA((HDROP)wParam, -1, NULL, 0);
    for (i = 0; i < n; i++) {
        ret = DragQueryFile((HDROP)wParam, i, pszBuff, MAX_PATH * 10);
        if (ret == -1) continue;

        LPWSTR fileName = PathFindFileNameW(pszBuff);
        wsprintf(pszNewFile, L"%s\\%s", pszNewFile, fileName);

        // 第３引数がFalseなので、コピー先に同名ファイルがあった場合は上書保存
        // TRUEにした場合は、失敗してエラーになる
        CopyFile(pszBuff, pszNewFile, FALSE);
    }

Drag＆Dropしたファイルを、WSL2のマウントフォルダに格納するようにした。
Shlwapi.hの関数は「PathFindFileNameW」。
ヘッダをincludeしただけだと、「未定義の関数」としてビルド時にエラーになる。
「#pragma comment (lib, "Shlwapi.lib")」を追記すると、Shlwapi.libをプロジェクトに参照追加しなくても動作するようになる。
理由がわかっていないので調査したい。

「PathFindFileNameW(pszBuff)」を実行して取得できるのは「xxxx.txt」のようなファイル名部分となる。
「PathFindFileNameW」を使用しているのは、TCHARを使用しているから。
CHARを使用する場合はたぶん「PathFindFileNameA」を使用するんだと思う。

「wsprintf(pszNewFile, L"%s\%s", pszNewFile, fileName);」で、変数pszNewFileにコピー先のpathと取得したファイル名を連結している。

[C++] Vector配列でクラスを扱う時にクラスメンバーにリファレンスが含まれていると面倒

2021-02-07T20:36:55+09:00

オブジェクトをVector配列に積んだり消したりするソースでも書くか・・・

#include 
#include 
using namespace std;

class A
{
public:
    A() = delete;
    A(int item) : m_item(item) {}
private:
    int &m_item;
};

class MainProc
{
public:
    void AddVector(A obj)
    {
        m_vecA.emplace_back(obj);
    }
    void DelVector(A srcobj)
    {
        if (m_vecA.size())
        {
            auto it = remove_if(m_vecA.begin(), m_vecA.end(),
                [&](A &dstobj) { return (dstobj.m_item == srcobj.m_item); });
            m_vecA.erase(it, m_vecA.end());
        }
    }
private:
    vector m_vecA;
};

int main()
{
    MainProc MP;
    int i1 = 1, i2 = 2;
    A obj1(i1), obj2(i2);
    MP.AddVector(obj1);
    MP.AddVector(obj2);
    MP.DelVector(obj1);
}

ビルドしたら難しそうなエラーが出ました。

main.cpp:24:122:   required from here
/usr/include/c++/7/bits/stl_algo.h:871:16: error: use of deleted function ‘A& A::operator=(A&&)’
      *__result = _GLIBCXX_MOVE(*__first);
                ^
main.cpp:5:7: note: ‘A& A::operator=(A&&)’ is implicitly deleted because the default definition would be ill-formed:
 class A
 ：

想像なのであまりあてにしないで欲しいんですが、多分↓のような感じ？

・remove_ifとかeraseのところでclassAの代入(operator=)をしたいよ
　→でもoperator=はこちらでdeleteしときましたよ
　　→なんでかというと代入できるならしたいけどclassAのメンバーにリファレンスがいて無理だからだよ

面倒なのでclassAのm_itemをポインタ型にして解決しました。

Unreal Engineで実行中にテクスチャを更新するサンプル

2020-06-10T08:58:14+09:00

Unreal Engineで実行時にテクスチャの色を変更できたら便利かなと思って試したもの。できたはできたが思ったようにうまくはいかなかった。ためしに白色を他の色に変えようと思ったのだが、ムラができてしまった。元の画像がそうなのか、UEに取り込まれてミップマップ化された時にそうなったのかはわからない。検証するかもしれないししないかもしれないのでとりあえずメモだけ。

    UPrimitiveComponent* Primitive = Cast(GetComponentByClass(UPrimitiveComponent::StaticClass()));
    UMaterialInstanceDynamic* Material = Primitive->CreateAndSetMaterialInstanceDynamicFromMaterial(
        0,
        Cast(StaticLoadObject(UMaterial::StaticClass(), nullptr, TEXT("/Game/Materials/MyMaterial")))
    );

    UTexture2D* Texture = Cast(StaticLoadObject(
        UTexture2D::StaticClass(), nullptr, TEXT("/Game/Model/train/Textures/MyTexture")
    ));
    Texture->CompressionSettings = TextureCompressionSettings::TC_VectorDisplacementmap;
    Texture->MipGenSettings = TextureMipGenSettings::TMGS_NoMipmaps;
    Texture->SRGB = false;
    Texture->UpdateResource();

    struct RGBA { uint8 R, G, B, A; };

    RGBA* Data = (RGBA*)Texture->PlatformData->Mips[0].BulkData.Lock(LOCK_READ_WRITE);
    int DataSize = Texture->PlatformData->Mips[0].SizeX
        * Texture->PlatformData->Mips[0].SizeY;

    for (int Index = 0; Index < DataSize; Index++)
    {
        RGBA* Color = Data + Index * sizeof(RGBA);
        // UE_LOG(LogTemp, Log, TEXT("RGBA %d %d %d"), Color->R, Color->G, Color->B);
        if (Color->R > 200 && Color->G > 200 && Color->B > 200)
        {
            Color->G = 0;
        }
    }
    Texture->PlatformData->Mips[0].BulkData.Unlock();
    Texture->UpdateResource();

    Material->SetTextureParameterValue(TEXT("BaseColor Map"), Texture);

このActorを画面上に配置してモデルのコンポーネントを追加して動かす。しかしそれにしても失敗するとすぐエディタが落ちる……。

詳しく調べてないけどそのマテリアル自体が変わってしまって同時に複数の色にはできない場合、そうしたい人は別のやり方が必要なのかもしれない。

下記を参考にした。

UE4/C++: メッシュのマテリアルやテクスチャーをC++コードで制御する方法 - C++ ときどきごはん、わりとてぃーぶれいく☆

Unreal Engineで画面のサイズとタップ座標を取得する

2020-06-05T22:12:19+09:00

Unreal EngineでC++を使って画面のサイズを取得する方法。

#include "Kismet/GameplayStatics.h"

void AMyPawn::GetTest()
{
    AMyPlayerController* PlayerController = Cast(
        UGameplayStatics::GetPlayerController(GetWorld(), 0)
    );

    float x, y;
    PlayerController->GetMousePosition(x, y);

    int width, height;
    PlayerController->GetViewportSize(width, height);
}

他にも解像度取得もあったりしてそっちの機能はサイズが異なる（やり方はメモってなかったので忘れてしまった）。今回はちゃんとゲーム画面のサイズが欲しかったのでGetViewportSizeを使った。

正しいのかどうかよく分かってない＆まだちょっと実機では試してないのでとりあえずメモ。

C++でint型同士の演算結果をlong longで受け取っても、オーバーフローで正しい値にならない場合がある - ABC 162 D - RGB Triplets

2020-04-27T12:09:32+09:00

緊急事態宣言に伴う自粛期間中なので、昨日は家にこもってAtCoder(競技プログラミング)の過去問を練習していました。

昨日は「ABC 162 D - RGB Triplets」を解いていたのですが、なぜかtestcase_17とtestcase_18だけACにならず、長時間悩みました。

結論から言ってしまうとint型同士の演算によるオーバーフローが原因だったのですが、実際のプログラム例を掲載します。

オーバーフローで結果が異なる例

次のC++プログラムにある「R1,R2」「G1,G2」「B1,B2」の各変数は、それぞれ1333を代入しています。
1333は小さな数で、int型の範囲内です。

ただし計算結果は大きな値となるため、long longで受け取ることにしました。

#include 
using namespace std;

int main() {
    int R1 = 1333;
    int G1 = 1333;
    int B1 = 1333;
    long long res1 = R1 * G1 * B1;
    cout << res1 << endl; // -1926374259

    long long R2 = 1333;
    long long G2 = 1333;
    long long B2 = 1333;
    long long res2 = R2 * G2 * B2;
    cout << res2 << endl; // 2368593037
}

見てわかるように、計算結果をlong longで受け取ったとしても、1333をint型にしたパターンでは結果が正しくなりません。

ハードコードで書き直してみる

変数に代入するパターンではオーバーフローが起きていたため、次にハードコードで書き直してみました。

#include 
using namespace std;

int main() {
    // ハードコードのint
    long long res1 = 1333 * 1333 * 1333;
    cout << res1 << endl; // -1926374259

    // ハードコードのlong long
    long long res2 = 1333LL * 1333LL * 1333LL;
    cout << res2 << endl; // 2368593037
}

計算結果は相変わらずですが、私の環境(GCC 9.2.0)では次の警告が発生しました。
これにより、オーバーフローが発生していることがわかります。

$ g++-9 test.cpp
test.cpp: In function 'int main()':
test.cpp:9:34: warning: integer overflow in expression of type 'int' results in '-1926374259' [-Woverflow]
    9 |     long long res1 = 1333 * 1333 * 1333;
      |                      ~~~~~~~~~~^~~~

同じ型同士の演算と、異なる型による演算の違い

発生した警告の内容を見るに、int型同士の演算結果はintになるため、オーバーフローが発生したと推測できます。
左辺で計算結果をlong longで受け取ったとしても、右辺の演算の時点でダメだったようです。

そこで右辺にlong longを組み合わせてみたところ、想定した値が返却されるようになりました。

#include 
using namespace std;

int main() {
    // ハードコードのint
    long long res1 = 1333 * 1333 * 1333;
    cout << res1 << endl; // -1926374259

    // ハードコードのlong long
    long long res2 = 1333LL * 1333LL * 1333LL;
    cout << res2 << endl; // 2368593037

    // intとlong longを組み合わせた例
    long long res3 = 1333 * 1333 * 1333LL;
    cout << res3 << endl; // 2368593037
}

さいごに

1333のような小さな値であれば、単にint型へ保存すれば十分だと思っていました。

しかし演算に用いるケースでは、演算結果がとり得る値の範囲や、演算結果の型も考慮したプログラミングが必要であると言えそうです。

C++は競プロのために入門コンテンツを使って速習したくらいの実力なのですが、奥が深くまだまだ学べることがたくさんありそう。

POCO を static に link する

2019-05-25T13:19:11+09:00

結論

-Wl,--start-group -Wl,-Bstatic -lPocoFoundation -lPocoUtil -lPocoXML -lPocoJSON -lPocoNet -Wl,--end-group -Wl,-Bdynamic -lpthread

今世のリンカオプションには --start-group, --end-group なんて便利なものがあるんですね

はじめに

Cerflet ベースの WebApplication を deploy しようとして、POCO に依存してしまうのもアレだなと思い、だったら static に link してしまおうと思ったのが事の発端です

POCO の static library を make

POCO の configure の --static オプションを使って make します

./configure --static
make

はじめは shared library 作る時と同じで make -j4 ってやってたんですけどリンクエラーがでるので、多分、static に link してるから順番とかが影響してるんだろうなと深く考えずに make にしたらでなくなりました
こんな些細なところからすでにlink する時の嫌な事が始まってます ^^;;;

しっかりハマる

マジメな C++ プログラマだった頃の辛い思い出が蘇ってきます...

pthread がない

dynamic に link した時と同じ感覚で素朴に lPocoFoundation をリンクしようとしたのですが

g++ -o hellocerflet_s HelloCerflet.cpp ../lib/httpcerflet.cpp -I../lib/  -L/usr/local/lib -lPocoFoundation -static

Thread.cpp:(.text+0x1ec): undefined reference to `pthread_setspecific'
Thread.cpp:(.text+0x228): undefined reference to `pthread_sigmask'
Thread.cpp:(.text+0x30c): undefined reference to `pthread_mutex_lock'
Thread.cpp:(.text+0x328): undefined reference to `pthread_cond_broadcast'
Thread.cpp:(.text+0x338): undefined reference to `pthread_mutex_unlock'
...

-lpthread つけてやらないといけないんですね

Poco 自身の依存関係

で、-lpthread つけてあげたんですが

g++ -o hellocerflet_s HelloCerflet.cpp ../lib/httpcerflet.cpp -I../lib/  -L/usr/local/lib -lPocoFoundation -static -lpthread

httpcerflet.cpp:(.text+0x54): undefined reference to `Poco::Util::Application::loadConfiguration(int)'
httpcerflet.cpp:(.text+0x64): undefined reference to `Poco::Util::Application::initialize(Poco::Util::Application&)'
/tmp/ccZExLN3.o: In function `HttpCerflet::uninitialize()':
httpcerflet.cpp:(.text+0x8c): undefined reference to `Poco::Util::Application::uninitialize()'
...

あ、static link だから lPocoFoundation が依存する Poco のライブラリも先にリンクしておいてあげないと...

link の順番

で、undefined だって言われる Poco のライブラリをどんどん前に追加しているのに、まだ undefined が...

g++ -o hellocerflet_s HelloCerflet.cpp ../lib/httpcerflet.cpp -I../lib/  -L/usr/local/lib -lPocoXML -lPocoJSON -lPocoUtil -lPocoNet -lPocoFoundation -static -lpthread

...
JSONConfiguration.cpp:(.text+0x6a0): undefined reference to `Poco::JSON::Query::~Query()'
...
XMLConfiguration.cpp:(.text+0x1cc): undefined reference to `Poco::XML::Document::documentElement() const'

ちゃんと -lPocoXML も -lPocoJSON も link してるのになんで undefined なんて言われるんだろ?
このあたりでもう考えるのが嫌になって POCO static link とかでググるとそのものズバリなのが
定義されていないシンボルへのPoco C++ 静的リンクの問題

そうだ、リンクの順番！使われる前にリンクしておかないといけないんでした

glibc の静的リンク

POCO内部の依存関係に合わせて正しい順番でリンクすると

g++ -o hellocerflet_s HelloCerflet.cpp ../lib/httpcerflet.cpp -I../lib/  -L/usr/local/lib -lPocoUtil -lPocoXML -lPocoJSON -lPocoNet -lPocoFoundation -static -lpthread

/usr/local/lib/libPocoFoundation.a(Path.o): In function `Poco::PathImpl::homeImpl[abi:cxx11]()':
Path.cpp:(.text+0x220): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

glibc まで static にリンクしようとしてました ^^;;;

第一次正解

なので、pthread だけは dynamic に link するようにして

g++ -o hellocerflet_s HelloCerflet.cpp ../lib/httpcerflet.cpp -I../lib/  -L/usr/local/lib -Wl,-Bstatic -lPocoUtil -Wl,-Bstatic -lPocoXML -Wl,-Bstatic -lPocoJSON -Wl,-Bstatic -lPocoNet -Wl,-Bstatic -lPocoFoundation -Wl,-Bdynamic -lpthread

やっとできました

ちょっと考察

しかし今どきリンクの順番みたいな機械的に解決できることに人間が頭を使わないといけないのってちょっと残念ですよね、人って機械的な作業が苦手なクリエイティブなクリーチャーなのに

でも、さすがになにか進歩してるんじゃないかとおもって static link order とかでググりまくってると　Why does the order in which libraries are linked sometimes cause errors in GCC?
やっぱり人類は賢かった！--start-group, --end-group なんてリンカのオプションをつくってくれた人がいて、この中だと順番気にしなくてもリンカがよしなにやってくれるんですね！

で、本稿の結論にいたります

再度、結論

-Wl,--start-group -Wl,-Bstatic -lPocoFoundation -lPocoUtil -lPocoXML -lPocoJSON -lPocoNet -Wl,--end-group -Wl,-Bdynamic -lpthread

感想

まるで紅茶に浸した一匙のマドレーヌを口に含んだ時みたいに鮮明に記憶が戻ってきました
私は gcc のこういう所があんまり好きじゃなかったんでした

C++ ベースのウェブアプリケーションサーバ Cerflet のご紹介

2019-04-20T12:08:57+09:00

はじめに

Cerflet は Maya Posch さん作の C++ ベースのシンプルな Web Application server です
Raspberry Pi でもサクサクに動いています

python の tornado みたいにリクエストハンドラを書くだけで簡単に使える上に、オール C++ かつオンメモリなので超高速が期待できます

ちなみに Cerf はジビエ好きな方はピンと来るかと存じますが多分、フランス語の 鹿(セール) なんじゃないかなと想像してます、Maya さんの他のプロダクトも動物の名前のが多いし、彼女の会社の名前からして Nyanko だし

実装

本体の実装は物凄くシンプルでコメント込で 80行ぐらいしかないです、すごい
私だったら C++ の80行ってコマンドライン処理するだけでもゆうに超えちゃったりします

サーバの処理も実行時オプションの処理も POCO の機能が有効に使われてて、POCO の凄さと、POCOを使えば Web Application でさえこんなにシンプルにつくれるという Maya さんのソフトウェア・アーキテクチャのセンスの良さに敬服いたしますとともに、Poco.Net のプラグマティックなチュートリアルとして大変ありがたく読ませていただきました次第でございます

How to try it

POCO をインストール
git clone https://github.com/MayaPosch/Cerflet.git
cd Cerflet/sample
make
./hellocerflet

「libPocoNet.so.60 がないよ」とかエラーになるようでしたら ldconfigしてみてください

で、hellocerflet を起動したサーバの port 8080 番をブラウザで開くと

ビックリするほど簡単です

こちらの HTTPRequestHandler の中身を変えて、たとえば ContentType を "text/html" じゃなくて "application/json" にして、ostr に json 文字列を返したら超高速かつコンパクトな API サーバーとしてすぐにでも大活躍しそうです

作者の御紹介

作者の Maya Posch さんですが、御本人のブログによると生まれつきに抱えるいくつかの問題、特に両性具有に起因する問題（当時のニュース番組がこれとかこれとか残ってます）で祖国オランダを離れざるを得ず、安住の地を求めて世界を旅しながら自分の会社 Nyanko を運営しつつプログラミングと電子工作に関する数々のプロダクトと著作を世に出していらっしゃいます
まるで物語みたいに数奇な人生を歩みながら outcomes を出されていることに正直圧倒されてしまいました、すごい人がいるもんなんだなぁ
翻って自分を鑑みるにいったい何をやってるんだと情けなく忸怩たる思いに至る次第です

近著 Hands-On Embedded Programming with C++17 を魅力的なタイトルに惹かれて読んだのが彼女を知るきっかけだったんですが、この本も POCO の紹介をふくめて Raspberry Pi みたいなSBC でプロダクトをつくる上でのオリジナルな話題にあふれていてとても面白い本でした

感想

数日前に某所で「C++でウェブアプリ書く気にはならないし」なんて言っちゃったの、謹んで取り消させてください

読書は時として人の世界観をダイナミックに変えてしまうものなのです ^^;;;;;;;

POCO を使おうとして error while loading shared libraries: libPocoNet.so.60: cannot open shared object file: No such file or directory みたいに「ないよ」って言われる時

2019-04-20T09:56:19+09:00

こちらの皆様の雰囲気と合っていないようなのでこちらに移動致しました