Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Better framework

オープン
#18 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
18/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
停滞
技術スタック
cpp

調査の方向性

まず、提案されている main.cpp のフローと MessageQueue.h の proc() のスケッチを確認し、次に issue で言及されている現在のイテレータ実装と比較してください。未解決の問いは、メッセージブロックのフラッシュ、ブロックの所有権、callback の抽象化、メッセージ型のレイアウトです。framework の設計と実装について合意し、これらの問いが解決されれば作業は完了です。

索引モデルが issue の本文から書いたものです。

説明

Maybe something like

main.cpp:
void HandleMessage(MessageBlock &out, Message in);
int main()
{
while(1) { messagequeue.proc(); }
}

MessageQueue.h:
void proc()
{
MessageBlock mb;
for(auto m : EachMessage(cursor) ) {
if(mb.len>10000) send(mb);
HandleMessage (mb, m);
}
if(mb.len) send(mb);
}

Not too different from what I have now, but this could let me delete the complicated iterator stuff

Should I limit MAX_MESSAGE_SIZE to be half of MAX_MESSAGEBLOCK_SIZE so I know when to flush? Or maybe keep a vector of blocks, and just pass a new block to the function when one gets full?

Maybe this would be the corelib, and then there would be a more abstract library where you give it callback functions for different message types. Maybe the type member of a message could have 1 byte for generic type and the other byte for the application specific type?

主要言語
C++
スター
0
フォーク
0
PR マージ指標
30日以内にマージされた PR はありません

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Die4Ever/AsyncGameEngine のほかの issue

Die4Ever/AsyncGameEngine の issue をすべて見る

似ている issue

C++ の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。