C言語なら俺に聞け 144
■ このスレッドは過去ログ倉庫に格納されています
>>410
探してるんですけど、なかなか本やにないので ますますよく分からんが
少なくとも「その前に」ってレベルじゃねぇ >>412
自作ゲームを作るのが目的で、自分の性分として元祖からやっていきたいと思って、、、、
ファミコンの実機はパソコンx８６とDirectXで作ったとかなんとか、、、、
要領が小さい横スクロールアクション（ロックマンの亜種）を作ってみたいのです。 >>413
実機って何を指してるか知らんけど
ファミコン(1983)、スーファミ(1990)に対してDirectX1.0は1995年発表だぞ
x86は流石にもっと古かった >>413
>ファミコンの実機はパソコンx８６とDirectXで作ったとかなんとか、、、、
何処からそんなデマを聞いたんだ?
ファミコン実機の中身はx86どころか8bitCPU(6502ベースのカスタム品)だということ知ってる? >>413
ファミコンの発売は1983年でスーパーファミコンは1990年だ。
まだDirectXも何もない時代なんだけど、何のことを言っているのかな?
Windows上でのエミュレータの話? >>409
単純な数行のソース？
Hello worldでさえ6行もあるよな。。。 >>416
Vipでゲーム機の進化の話があ出たときに、スーファミの開発環境がDirectXだって書いてあった >>419
DirectXはその前身のGame SDKでさえWin95(1995年)と同時期にリリースされてる
スーパーファミコンの登場はそれより前のWin3.1(1992年)すら登場していない時期
まだMS-DOSの全盛期だよ、タイミング的に有り得ない >>152
遅くなったが、なかなか難しいがその難しさ含めアイデア次第でとても面白いな！
ツイやらインスタみたいのがもてはやされとるけどやっぱこういう反リアルタイムで半匿名性保持したものって必要なんだと思うし、2hは仰るとおりこのまま行くと5年後10年後にはホントの過疎化で存続危ういし、今からテコ入れして人の誘導図るのは大賛成！
よし、俺もC本気出してやるかw https://ideone.com/Jhbm7n
グラムシュミット計算して結果をそのまま出力するって課題が出て、一応出来はしたんだけど出力で変になったんだ
リンク先に書いてる奴が正しい出力で、最後のコメントみたいにすると違う結果が出てくる
具体的に言えばcmdで
「 f3 1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000」ってやると
「 1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000」が出力される（リンク先はコレ）はずなんだが
コメント通りにすると
「1.000 1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000」になっちゃう
環境はVSCodeでコンパイラはVS2017のcl >>427
Cは複数の値を返却値として返すことはできない。関数の引数リスト以外で、カンマを書くとカンマ演算子として解釈される。 >>428
なるほど、ありがとう
カンマ演算子ってのを初めて知ったよ
>>429
41行目 >>428
構造体を型宣言して戻り値にすれば、複数の値を実体返し出来るけどね。 結局、質問者は問題点が何処にあるか理解できたのかな?
カンマ演算子の評価結果は、最後の式の評価結果だからね
余計なお世話かも知れないけど、どうしても結果を戻り値で返したい場合は構造体に纏めれば出来るよ
というか、ベクトル自体を配列ではなくて構造体に纏めた方がプログラムの見通しがすっきりすると思う もう駄目だ
>>427のコードを構造体に纏めて書き換えてみたけど、ideoneのコマンドライン入力がどうやってもエラーを吐く
もう諦めたのでテストデータ埋め込みでコードを晒す(数学的には意味のないテストデータだけど)
誰か原因分かる人確認お願いします
手元のVC++2017ではコマンドライン入力でも正常動作することは確認してる
https://ideone.com/IEGKl0 もしかして勘違いしてた?
ideoneの標準入力stdinってプログラム実行開始前のコマンドライン入力としては使えないのか?
もうどうでもいいけど… fscanf(stdin,...) とかの 入力ｽﾄﾘｰﾑにこれを与えるってだけ
実行時引数を渡すしくみはなかったような >>436
ちなみに初心者だよな？
だとすると、一般的にはCでは構造体の値渡しは(特に理由がある場合以外は）しないので、
ポインタ渡しで書くことに慣れた方がいい。 . はほぼ使わず、 -> ばかりになる。
具体的に言うと、
void gram_schmidt(BASIC3* bas, VECT3* v_1, VECT3* v_2, VECT3* v_3);
として、
BASIS3 bas;
gram_schmidt(&bas, &v_1, &v_2, &v_3);
とする。
値渡しする場合の理由だが、通常は、以下のどちらか。
・中で一時期的に書き換えるため、どうせコピーが必要。
・中で何度も使う場合、値渡しの方が速い場合がある。
値渡しはスタック上に置かれるためイミディエートオフセット命令が出る。（Read1回でデータを読み込める）
ポインタ渡しは間接参照になるため、アクセス速度が少し遅い。(2回Readが必要）
ただし値渡しは呼ぶ際と戻る際に構造体の中身を全コピーするので、それとの兼ね合いになる。
単純には、値渡しはコピーが2回発生するのだから、確実に速くなるとしたら3回以上使う場合で、
逆に言えば、2回以下のときはポインタ渡しにしておけ、となる。だから大体ポインタ渡しになる。
個人的には、このくらい自動で最適化してくれとも思うが、
Cは「書いたように動かせ、余分なことはするな」の文化だから、手動で切り替える方が好まれているのだろう。
(C++の場合はコピーコンストラクタが動くことになっているので、自動で切り替えたら違反になり、出来ないはず。) >>440
うーん、まあそうなんだけどね
今回はそんなに大きなデータでも無いので手抜きしてる
元々のコードは次元もパラメータとして持っていたので、基底空間の構造体そのものをベクトル構造体のリスト構造で構成するのが正解なんだろうね
ポインタでベクトル構造体を引き渡すことになるとは思う
ただそこまでやるのが面倒くさかったので、3次元ベクトル空間に限定して無理やりデータを小さくまとめてしまってる
この程度なら値渡しでもいいかと手抜きしてるのが裏事情、ぶっちゃっけて言うとまともに実装するのが面倒臭かった
まあ、あんまり細かいこと突っつかないで＞＜ >>441
やれば分かるが、そんなに記述量は変わらないぞ。
. が -> に変わるのが大半で、それ以外はほぼそのままで済むはず。
主に計算用途で、Python -> Cを目指しているのか？
だとしたら速い書き方が出来ないと意味無いだろ。
そして、ベクトルの値渡しとかスタックを余計に食う＝再帰したら悲惨なことになるから止めとけ。
->の表記が気に入らないのなら、C++の「参照」を使えば . のままでも書ける。
この場合は、ソース自体の書き換えは呼び出し部分だけで済む。
(ただし、非const参照は推奨されていない場合もある。例：googleのコーディングルール） >>442
このスレには珍しく数学的な背景に詳しそうだな
ちょっと聞きたいけど、基底空間の拡張そのものはベクトル構造体をリスト化すれば簡単なんだけど、ベクトルの要素の拡張で簡単な方法ないかな?
実は最初にそれを考えたんだけど要素もリスト化するとポインタの連鎖が大変なことになりそうで、躊躇した結果がVECT3やBASIS3などの次元決め打ちになってしまってる
あとは演算部も際限なく項が増えていくので再起でも使わなければとても実装できそうもない
これもポインタの実装が大変なことになるのが容易に想像できる
参考までに先のコードを拡張するにあたって何か良さそうなアイディアないかな >>443
いや俺は多分君よりは詳しくないが。
ただ、君はだいぶ勘違いしてると思うぞ。
1. まず、値渡しをポインタ渡しにしたところで、記述量は大して変わらない。
これはやってみれば分かるし、どのみち通る道だろうからやっとけ。
大変なことになんてならない。
2. 次に、Cのポインタは配列のサイズは気にしてない。
だからベクトル要素の拡張とか、最初から気にする必要が無い。
強いてコツを言うなら、ド頭を「長さ」にして、データは末尾にしとけ、という程度。
(大体これで上手くいく)
typedef struct {
int num;
// int elemSize;
double* elems;
} VECTX;
typedef struct {
int num;
// int elemSize;
VECTX* vectors;
} BASISX;
多分これで全て事足りる。
混乱するようなら num を dim(ension) なり rank 等に変えてもいいが、
ダックタイプ的に手抜きする気なら num に統一してついでに int elemSize も構造体に入れとけ。
そしたらコピー等は同じ関数が使えるようになる。
(void*にキャストしてmemcpyするにしてもサイズが無いと無理。
Cには実行時型情報(RTTI)が無いから、必要なら自前で用意するしかない）
或いは、VECTXとBASISXを分けずに、どちらもvoid*にキャストして1種類の構造体で扱ってもいい。 構造体返しなんか、知らないうちに使ってるんだから気にするな。
君が返り値に指定したその型が実は構造体だったなんて誰も気にしてないから。 ファイル操作しているなら、
FILE構造体のお世話になっているはず
この構造体の中身を一度見てみると良いよ でも FILE 構造体を構造体返しや構造体渡しにはしないからなあ… 構造体返しやら構造体渡しやらを使ってる標準ライブラリ関数なんかあらへんやろ K&Rでも初期のほう
構造体の値渡し/構造体の値戻しは出来なかったわけで
標準関数に盛り込まれることはなかったんじゃなかろうかと いや、コンパイラの吐くコードがアホだったから解放したスタックから値をコピーする事になっちまってただけだ。
割り込み専用スタックが無いアーキテクトマシンはそこで死んだ。 >>453
socket関連に構造体渡しってあったっけ？
あったっけっつっちゃった >>456
由緒正しきバークレーソケットに構造体渡し・構造体返しがあるわけがない、常識的に 構造体の値渡しについては440に書いたとおりだが、
構造体の値返しは通常はあり得ないだろ。
理由は何らメリットがないから。 ないな。呼ぶ側で何らかの方法で領域確保してそのポインタを渡せばいいし。
まあ物凄く良い感じで最適化されて無駄がなくなるならあってもいいが。 >>443
よほど高次元を扱わない限り決め打ちコピペ、マクロ、キャストを駆使する方法とかある
変態仕様だから俺はおすすめしない
typedef struct {
int element_sz;
int elements[2];
} VEC2;
typedef struct {
int element_sz;
int elements[3];
} VEC3;
#define INIT_VEC(name, size) \
VEC##dim name = {.elements_sz = size} >>462
それ、ちょっと考えたんだけどさ、無理矢理１行に書けばいいだけなんだよね。
BASIS3 bas;
gram_schmidt(&bas, &v_1, &v_2, &v_3); // (A)
BASIS3 bas = gram_schmidt(&v_1, &v_2, &v_3); // (B)
BASIS3 bas; gram_schmidt(&bas, &v_1, &v_2, &v_3); // (C)
(A)が一般方式だ。
(B)が宣言的な記述で、関数型（）な奴らが「美しい」と主張する書き方だ。
とはいえ俺も(A)よりは(B)の方がいいと思ってはいるんだが、
それなら(C)って書けばいいだけなんだよな。
あまり一般的ではないけど、確保&初期化に関してはありかなと思えてきてる。
実はマクロで(B)を(A)に変更することを考えていたのだけど、
そんなことやるなら(C)でいいじゃんってね。
コンパイラが(B)を(A)相当にするのも簡単だとは思うんだけど、（C++のクラスがこれだし）
(C)が出来るんだからこれでいいじゃん、で終わりだよなと。
basを2回書かないといけないのは何とかならんのか、というのはあるが。 >>463
ちなみにそれはちょっと違う。決め打ちにするのであれば、以下の方がいい。
typedef struct {
double x;
double y;
} Vec2;
typedef struct {
double x;
double y;
double z;
} Vec3;
決め打ちのメリットは、
・分かりやすい名前を使える
・型チェックが有効になる
ことだから。
上はそのままだから分かるだろ。下は、例えば内積計算関数が、
3次元*2次元とかの違法の場合に書きようがなく、コンパイル以前にIntellisenseで落とせる事。
elementsが配列になっていると、当然ループになり、3次元*2次元でも書けてしまう。
ただし決め打ちの場合はその後のコンパイラの型チェックで落とされるが。
VecXとして一般化した場合は、この辺が全部通ってしまうわけでね。
ただまあ、C言語は、コンパイラにバグ取りを手伝ってもらう言語ではなく、
そもそもおめーがバグなく書きゃいいだけだろ、というノリなんだが。 >>465
それ演算式どうするんや？個別で書くんか？
アドレス渡しもできそうにないし、それ書くなら
typedef double[3] VEC3;
でよくね？ >>466
個別で書くに決まってるだろ。
実際それが最速だし、この場合は適切だ。
> アドレス渡しもできそうにないし
オイオイ。
つかお前、マジで言ってるのなら豆腐の角で頭打って死ぬレベルだぞ。 >>467
アドレス渡しじゃねえ、キャストだ
アドレス渡ししてキャストできれば汎用にできそうやなあとか考えててアホなこと書いてたわ
個別で書くと割り切るならありやな >>468
誤解ないように追記しとくわ
void*でって意味 >>469
typedef double[3] VEC3;
で VEC3をvoid*にキャストするのは止めた方がいい。使い物にならないから。
void*で一般化するには何にしてもサイズが必要だから。
サイズ無しで型を一般化したいのなら素直にテンプレート使っとけ。 >>470
いや、だからキャストを考えてないなら
typedef double[3] VEC3;
でよくね？と書いてた >>471
それは使い勝手の問題だが、
VEC3 v0 = {1,2,3};
VEC3 v2;
v2[0] = 1; // 添字で指定
と
Vec3 v0 = {1,2,3};
Vec3 v1 = {.x=1,.y=2,.z=3}; // 名前が付いているからこれも出来る
Vec3 v2;
v2.x = 1; // 名前で指定
とどっちが見やすいかと聞かれたら、普通は後者と答えるだろ。
個別にした場合はループが回せないが、
2次元と3次元の決め打ちだけで済むならいらんだろ、ってことだよ。
(どうしてもループ回したければ double* p = &v1.x; で行けるし)
ただまあここら辺は外野の俺らが言い合っても意味がない。
使用者が決めればいいだけ。好みの範疇だからね。 >>472
>>468にも書いたけど、個別で式書くと割り切るなら同じ意見やで
ただ、次元増えたときは面倒やろと思っただけ >>474
アプリケーションハンガリアン記法。
参考までに、システムハンガリアン記法はNG。 戻り値が構造体ってのは、型宣言に構造体が使えるから言語仕様的に出来なきゃならないんだよ。本当はな。
でも関数内オート変数に一旦格納した型後でreturn オート変数ってやると、コンパイラがアホだからポインターだけ渡してスタック破棄した後に領域コピーしちまうんだ。
運が良ければ残ってるかもね。的な綱渡りさ。割り込みが掛かった時点で死ねる。 >>476
そんなアホコンパイラは捨てろよ w
そもそもC言語ではスタックの解放は呼び出し側でやるからお前みたいなトンチキが作らない限りそんなことにはならんよ >>476
それはどう実装されるかの問題。
まあしかし後付け感はあるな。配列はポインタにされちゃうのに構造体の中に配列入れると丸々渡せたりして。
まあ昔々に考えられて互換性を考慮して拡張されてきた言語なので仕方がないようにも思うが。 >配列はポインタにされちゃうのに構造体の中に配列入れると丸々渡せたり
あほか >>427
構造体が話を難しくしているのではないか？
単純に最初から二次元配列を使うだけでいいのでは
Ideone.com - i9PcuN - Online C Compiler & Debugging Tool
ttps://ideone.com/i9PcuN
gram schmidt {{2, 3, 4, 5},{ 7, 8, 9, 10},{ 20, 90, 78, 3},{6, 6, 7, 7}} - Wolfram|Alpha Results
ttp://m.wolframalpha.com/input/?i=gram+schmidt+%7B%7B2%2C+3%2C+4%2C+5%7D%2C%7B+7%2C+8%2C+9%2C+10%7D%2C%7B+20%2C+90%2C+78%2C+3%7D%2C%7B6%2C+6%2C+7%2C+7%7D%7D
>gschmidt 2 3 4 5 7 8 9 10 20 90 78 3 6 6 7 7
これで試すとwolframのと同じになる スタックがどうたら言ってるやつ
ジジイの昔話をそのまま受け売りしてるだけだな 基本型とユーザー定義型の概念が理解出来てないところかな 小手先のテクニックだけでなく概念そのものしっかり理解した方が良い >>476
構造体を返せないコンパイラはいくらでもあるけど
>>476みたいな返し方のコンパイラは見たことがない
例えばどのコンパイラがそういう返し方をする？
doubleをレジスタで保持出来ないCPUも基本的には処理方法は構造体と同じと思う 主にDOS時代の話だなぁ
Sparcのアセンブラで説明する勇者は居らぬか 配列で要素間をまたいで先頭からnビットの位置から6bit取り出してintに入れるにはどうしますか？ 課題を丸投げするな。
自分なりの解を出して、もっと効率化できるかと聞くならあり。 組み込み系のヒープってなーに？の環境だと、まだまだ自動変数はスタックに置かれてたりするぞ。 >>489
ビットフィールドを使う組み合わせ分だけunionしろ。 C言語の登場当時に画期的だったのは構造体として自由に新しいデータ型を作り出すことが出来たことだった
C++では更にデータだけでは無くて関数まで含めたデータ型がクラスに発展してオブジェクトの概念にまで到達した
要は構造体は新しい概念をプログラムの世界に持ち込むための手段
ベクトルや多次元空間といった概念も構造体によってプログラム内で直接取り扱うことが出来る様になる 配列の任意のところからの 6bit の抜出しってーと
Base64エンコードの実装か？ >>489
それはリトルエンディアンで考えるのかそれともビッグエンディアンなのか？
まあいずれにしてもまずはその配列の型のビット数で割る必要がある。
配列のその要素の中に先頭のビットがある。 >>496
BASE64は３バイトを４つの文字に置き換えるんだから、３バイトづつ処理するコードを書けばいいんだよ。
４文字を３バイトに変える方も同じく４文字づつ処理するコードを書く。
そーすれば、必ず同じ位置からビットフィールド取り出す処理だけになる。 あれ？もしや俺の書いたお題を解くために質問してたのか？
ま、頑張れ。調べていけば何れわかる。 >>495
> C言語の登場当時に画期的だったのは構造体として自由に新しいデータ型を作り出すことが出来たことだった
PL/1, Pascalにもあったし、範囲型とかをサポートしないサブセットだよ？
むしろポインタを陽に使える方が画期的だったな ポインタはPascalにもあるし、アドレスと紐ついているというのが
受けたんだと思うけどね >>506
ああすまん、陽にって言うより自由に使えるって書いた方がよかったかな >>502
EBSDICとBase64にどういう関係が？
バイナリならなんでも変換できるんだから特定のコードは関係ないだろう。 >>507
ここでのポインタが自由に使えるの意図は>>495 の構造体に対する考え方と本質的に意味することは同じだろ 要は言語としての設計思想というか考え方の問題であって、画期的の意味は最初という意味では無いということ ■ このスレッドは過去ログ倉庫に格納されています
