C言語なら俺に聞け 149
■ このスレッドは過去ログ倉庫に格納されています
>>141
おまえの指摘が間違っているかどうか以前に
おまえは何を指摘したんだ？
たとえば「10分」という物理量はどういう計算で出てきた値だ？
テキトーすぎて相手するに値しないんだが >>143
> ﾜｯﾁｮｲ ff12
回答無し
だからゆとりは駄目なんだよ
>>149
> ﾜｯﾁｮｲ 3308
同上 >>144
> ハードウェア言語で使われる変数(フリップ・フロップ)の動作遷移を意識した変数名にした方が私には分かり易いのです。
他文書と同期したいのならコメントに残せ。
ソフトウェアはソフトウェアだけで評価出来ないと管理上問題だ。(大体において同期が取れずに意味不明になる）
そもそもその部分、ハード叩いている感じでもないし。
それ以前にFFの状態遷移でSHIFTも無いと思うが。
> 命令文 = 小文字、引数,変数 = 大文字 と決めています。
これはマジで今すぐ直せ。
大文字にするのは目立たせる為であって、RAMが64バイトしかないような環境ならさておき、
今時ただの変数なんて目立ったら余計に邪魔になるだけ。今時白黒端末もないから、普通は、
命令文（キーワード）＝青（色付き）、引数/変数＝黒（色無し）、マクロ＝全大文字、と大体相場が決まっている。
(そもそもverilogにも大文字文化はない。VHDLには多少有った気もするが…)
> Ｃの参考書
Cに限らず、プログラミング全般で、入門書/参考書はゴミだ。理由は筆者自身がゴミだから。
海外の参考書は一部達人が書いている物があって、それは参考になるらしいが、俺はよくは知らん。
（ただこれも、昔からプログラミングをやっているのなら常識のはずだが）
> この事象が起こりうるという説明
int/int は端数切り捨てで商のみが返る、というのはCの仕様だ。
> 変数を全て大文字にしているのは単純に昔からの癖です。
言っちゃ悪いが、君は「昔から」というほどプログラミングをやってないはずだ。
昔からやってるなら、マイコンで割り算やfloatを使うこと自体が無いし、
Cの割り算の仕様を知らないこともない。
そしてそのソフトウェアの完成度で良しと出来ること自体が(普通のプログラマからすると)キチガイじみてる。
確実に事故るぞ。 >>144(続き）
ただしあまり反発もないところを見ると、ただのゆとり（若者）でもないらしい。
仮に全てを満足出来るプロフィールを定義すると以下となるが、合ってるのか？
・全て大文字とはCOBOL/FORTRAN/BASIC/アセンブラの世界。つまりC以前からであり、プログラミング歴自体は長い。
・Cの基本的仕様を知らない＝Cは普段使いではない。
・変数が大文字の方が都合がいい＝RAMがほぼ無い4bitマイコン等だとあり得る。この場合、ほぼアセンブラ。
・基本ハードウェア+ちょいソフト（アセンブラ）程度で、今時ならIoTの末端の各センサ等、
定期的に計測値を報告するようなプログラムはずっとやってきている。
WatchDogTimerやPowerOnResetを使いまくりなのでプログラム自体はポンコツでもいい。
だとすると、下からCを攻めてきているわけだが、これはほぼ無いパターンだから最初にそれを言うべきだ。
この場合、参考書はK&Rのみで、それ以外は全部ゴミだから捨てていい。
割り算の仕様なら、P13にもろに書いてある。
> Cでは他の多くの言語と同様、整数の割り算では切り捨てが行われて、
> 小数部が切り捨てられてしまうからである。(K&R第2版P13)
K&Rは「既にプログラミング出来る人がCを入門する用」に書いてあるから、
プログラミング自体の入門者には不向きだが、君の場合は最適だ。
一応言っておくが、ハロワがP7、コメントがP11、のP13な。本当にど頭に書いてある。
アセンブラの範囲を超えてCに踏み込んできたのなら、C流の管理方法に合わせた方がいい。
アセンブラの管理方法は、結局はアセンブラの規模用でしかなく、Cの規模には対応しづらい。
アセンブラ修得済みの人がCを修得するのは容易い。
ただし既に言ったように、世の中の「入門書」はそういう人向けではないから、K&R以外は読まなくていい。
とりあえずK&Rを頭から全部一通り読め。それでだいぶ状況が変わるはずだ。 >>147
× キャストに頼らないコードを書く
○ 『暗黙の』キャストに頼らないコードを書く
だろ。ただ、intをfloatに突っ込むと『精度が落ちる』と警告が出るはずだが。
(少なくともVC++ではそう。gccはこの辺甘々だから駄目かもしれんが)
キャスト自体が悪、というのはC++（というより型安全)の思想だが、
現実的にはCでは『明示的な』キャスト無しではまともに書けない。
ただし、『暗黙的な』キャストは当然無しには出来る。 >>150
10分という物理量と3308はどういう関係だ？
テキトーすぎて相手するに値しないんだが >>154
暗黙のキャスト？
意味わからん造語で語られても困るわ >>154
> 現実的にはCでは『明示的な』キャスト無しではまともに書けない。
ほうほう
暗黙変換を明示的なキャストにすることで
どんな「現実的」なコードが書けるんだ？ おいバカ >>154, >>156
＞暗黙のキャスト
integral promotion？
それとも bcc用語では暗黙の型変換のことですか？ 確かにintをflotに突っ込むのは型だけ変わるじゃなくてデータも変わるからなぁ <stdint.h>とかのint8_tとかって
「プログラマが気が付かない整数型に関するミスをコンパイルする段階で（エラーとして）発見できる」
以外に使い道ってか利点ってないよね？
int8_tで定義することでプログラムの速度が上がったりはしないと思ってるんだけど 間違ってる？ >>161
速度も上がらないし、そもそもコンパイル時にエラーとしても発見できない。
ただ単にコーディング時や人のソースを読む時にビット数が明確に認識できるだけ。 （通信プロトコル等の）外的要因でビット数が規定されているものを操作するコードを書くとき >>162
例えばすごく初歩的なんだけど
uint8_t型で宣言したループカウンタが500回回ったらコンパイルの時に警告でるよね。
……と思って今試したら警告レベルを最大にしてやっと出たわ。
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
int
main(void)
{
for (uint_fast8_t cnt = 0; cnt < 500; cnt++) {
printf("%d\n", cnt);
}
exit(EXIT_SUCCESS);
}
これを
$ gcc -std=c99 -Wall -Wextra -Wpedantic -o inttest ./inttest.c
でやっと注意してくれる。
あれ？ なんかもっと良い感じに撥ねられて（不注意な自分には）便利だなと思ったんだが，勘違いだったようだw >>161
利点というか、1byteが8bitでない環境もあるので、ポータブルなコードを書く場合は他に選択肢がないと思う それはどちらかというと静的解析の仕事じゃないかなあ。 >>164
> ……と思って今試したら警告レベルを最大にしてやっと出たわ。
最大にすれば出るのだから『便利』と言っていい。
警告レベルは自分に合わせて使うものだ。
判断する能力がないのなら、とりあえず最大にしとけ。
>>161
演算速度自体は上がらない。むしろ符号拡張等が必要になり落ちる。（事が多い）
これは通常はintがCPU内部のALU幅と同じ（つまり最速）に設定される為だ。
ただしフットプリントは減る為、キャッシュヒット率が上がり、結果的に速くなることはある。
よく分からなければ、基本的に全部 int で、明確に必要なところだけその他を使えばいい。
(同一ソースでint幅が異なる複数の処理系で動かすというような場合を除く） int8_tとか使おうとしているやつ相手に、とりあえずint使っとけとか
どんだけドヤアホなんだよ >>169
いやint8_tの利点を聞いてる時点で>>167に分があると思うぞ 現時的にはちょっとデータを保存するとかネットワーク越しに外に送るとかした時点でサイズは意識することになるから、intが無難とも言い難い。
意識できてればなんでもいいんだが… 構造体とかにint_8が入ってたらintに入れて計算してint_8に入れて
戻すのがいいのか？ 計算の途中でint8_tの範囲外になる可能性があるかどうかと範囲外になった場合にどうしたいか次第だろ。 int32_tが最速だけれどsize_tと一緒に使うと型変換がいることで遅くなるんだよな >>175
何が最速化は環境によるのでは？
少なくともfast型のほうが早そうだが ごめんバカみたいな質問なんだけど
その「遅い」っていうのは実行時の速度だよね。コンパイルが遅いってことじゃないよね。
だとすると8の倍数のbit数のCPUでint<8×N>型を使ってもタイムロスって起きない気がするんだけど……。 >>177
そういうのはSSE命令とか使うXMMレジスタ使う話。
Intelコンパイラでも無いとアセンブラの話。
単純に上位ビットを0で埋める。(分遅くなる)
ただ、CPUアーキテクチャにも依存する。
95年当時はpentiumは32ビットCPUだが16ビットの方が速く、pentiumⅡ以降で32ビットの方が速くなった。
Core2は32ビットが速く、64ビットは遅く、Core iから64ビットの方が速くなった。
(ハードレベルでも、ただ実装しただけと、最適化したのとある) encode.exe
PGM 形式の画像ファイルを入力に与え，Run Length 法によって圧縮したデータを出力す る
decode.exe
encode.exe で圧縮したデータを入力に与え，PGM 形式の画像ファイルを出力する。
これをc言語で書くにはどうすればいいですか？
osはUnix開発環境はMSYS2です。 ランレングスと画像フォーマットは何ら関係ないよ。
てかもしかしてランレングスのコードそのものを教えてもらうつもり？
学校の課題は自分でやりな。 コードはかけたのですがエラーが出ないのに圧縮するとデータサイズが大きくなるはずなのに小さくなります。それがわからないです。 >>182
私はあなたの言ってることが分からないです。 元のファイルと出来上がったファイルの中身を16進ダンプしたりして調べれば良いのでは？
それとプログラムもよーく読み直してみな。 >>182
圧縮したらデータサイズが小さくなったって悩んでるんだよね？
自分で何言ってるか分かってる？？
布団も圧縮したら小さくなるぜ。 Run Length は連続データが少ないと大きくなる事があるからその辺は特に不思議はない。 でかくなる様なデータで確かめる課題かね？
ちょっとそのまんま見てみたいね PGMのランレングスは何かしら工夫してんのかな
（行単位で生列とRLを切り替えできるとか？ 連続性の強い色空間を選択してるとか？） 0ﾊﾞｲﾄのﾃﾞｰﾀを圧縮すると間違いなく大きくなる 虚数空間にデータを書き移すから、さらに小さくなる、かも ホログラフィーみたいに3次元情報?が2次元に畳み込まれてなんて話ではないんだろう 任意のデータをその半分に出来る圧縮技法、誰か考えて SERNをハックしてLHCでマイクロブラックホールを作ってどうたらこうたらするとかなり圧縮できるよ 綴りを間違えるとホワイトホールができちゃうかもしれんぞ マジレスすると情報っていうのは消失しないと考えられているので
BH表面にエネルギー運動量テンソルの波動として，飲み込まれた物質郡の属性
（電荷など）が記録される……筈w
少なくとも現状の場の量子論と重力宇宙論ではそういう結論が出てる。
C言語とは関係ないけど，BHを記憶装置として用いるっていう考えは
突拍子もないけど理論的には可能だよねぇ，上記の理屈が正しいとすると。 >>195
例えば100bitの長さのデータは全部で2^100種類作ることができる
50bitの長さのデータは全部で2^50種類作ることができる
任意のデータを半分に圧縮できる方法があるとして
100bitで作れる2^100種類のデータをすべて圧縮したなら
50bitの長さで2^100種類の異なるデータができなくてはいけないがそれは不可能 いやいや、ちょっと待て。ここは発想の転換が必要だ。例えば8インチのフロッピーディスクから3.5インチの
いや、なんでもない。みんなには内緒にしておいてくれ。 「任意の」データを半分に圧縮できるとすると
圧縮した後のデータもさらに半分に圧縮できるはず
そうやって圧縮を繰り返せば最後には全てのデータは1ビットになる
よってそのような圧縮法がないことは明らか
可逆でないならそれでもいいかｗ しかしソースコードとかって圧縮率高いよね。
やっぱり同じような文字が続いたりインデントに空白文字が続いたりするからだろうか。 今から趣味でプログラミング始めます！激励してください！！ 趣味で初プログラミングなら、俺からもpythonを勧める。
GUIが手軽だとモチベーション違うよ。 分かった！いやよくわかんないけどそっちから始める！
XCodeでできるかな、ありがとう！ $ brew install python
とやって
$ python
これで起動する。もうスレチだし「macOS Python3」とかでググれ。 ttps://bituse.info/c/kadai/44
上記のサイトなどを参考に
簡単な九九の表を作ると
1 2 3 4 5 6 7 8 9
2 4 6 8 10 12 14 16 18
3 6 9 12 15...
...
...
（略）
このようになると思いますが、
隣の数字を参照にして足して
3 5 7 9 11 13 15 17
6 10 14 18 22 26 30 34
9 15 21 27 33...
...
...
（略）
と、表示するには上記のサイトの様なプログラムをどのようにすれば良いのでしょうか？
宜しくお願いします。 puts("3 5 7 9 11 13 15 17\n");
puts("6 10 14 18 22 26 30 34\n");
puts("9 15 21 27 33...\n"); >>218
puts は改行するので、文字列の末尾に \n を付けると2回改行することになる >>216
#include <stdio.h>
int main(void){
int i, j, k, n, m;
n = 0;
m = 0;
for (i = 1; i <= 9; i++){
n += 3;
m += 2;
k = n;
printf("%3d", k);
for (j = 1; j <= 9; j++){
k = k + m;
printf(" %3d", k);
}
printf("\n");
}
return 0;
} int main() {
char *ary[] = { "AAAA" , "BBBB" , "CCCC" };
printf("%s\n%s\n%s\n" , ary[0], ary[1], ary[2]);
printf("%x\n%x\n%x\n" , ary[0] , ary[1] , ary[2]);
printf("%x\n%x\n%x\n" , &ary[0] , &ary[1] , &ary[2]);
return 0;
}
実行結果
AAAA
BBBB
CCCC
405064
405069
40506e
61ff24
61ff28
61ff2c
っていうのでよくわからなくなったんですが
0061FF24==00405064で00405064==41414141
なのに、同じary[n]で参照？してるアドレスが違うのは%sが特別だからですか？
それと、AAAA,BBBB,CCCCはどの変数にも格納されていなくて、ただポインタがその文字列たちを指しているっていう理解であってます？
*がよくわからない・・・・・ ああ直接ポインタを作っててそれで変数がある必要もないのかな？
AAAA,BBBB,CCCCを普通に配列で作って、それを1つのポインタでオフセットを指定して選ぶ。みたいなのってCでできるんですか？ any[]には各文字列のアドレスが格納される。文字列へのポインターの配列。
%sはポインターが指すアドレスの文字列を、%xはポインターに格納されたアドレスを表示する。
&any[]とすると、ポインターそのもののアドレスを取得して表示する。
61ff24 -> 405064 -> "AAAA"
みたいになってる。 一つのポインターでオフセットを指定することはできるけど、
"AAAA"はAAAAの4byteではなくて、文字列の終端である0を含めた5byteになる。
char *any = "AAAABBBBCCCC";
こういうイメージで+4や+8でアクセスしようとしたら
%sで表示したとき意図する結果にならないかもしれない。
文字列として扱わなければ問題ないです。
char *any = "AAAA\0BBBB\0CCCC";
こんな書き方もできますが、*を理解したほうがよいと思います。
アドレスやオフセットの概念は理解しているようですので。 >>222 の実行結果を解釈すると...
文字列 "AAAA" "BBBB" "CCCC" の実体は 0x405064 から格納されていて、
16進ダンプだと
0x405064: 41 41 41 41 00 ; {'A', 'A', 'A', 'A', '\0'}
0x405069: 42 42 42 42 00 ; {'B', 'B', 'B', 'B', '\0'}
0x40506e: 43 43 43 43 00 ; {'C', 'C', 'C', 'C', '\0'}
という具合に(アラインメントのためのパディングなしに)詰め込まれている。
行分けせずに
0x405064: 41 41 41 41 00 42 42 42 42 00 43 43 43 43 00
と書けば「詰め込む」のイメージが分かりやすいかも。
charへのポインタの配列 ary[] は 0x61ff24 から配置されていて
番地: 0x61ff24 == &ary[0], 値: 0x00405064 == ary[0] (== "AAAA"の先頭番地)
番地: 0x61ff28 == &ary[1], 値: 0x00405069 == ary[1] (== "BBBB"の先頭番地)
番地: 0x61ff2c == &ary[2], 値: 0x0040506e == ary[2] (== "CCCC"の先頭番地)
これで分からんかな。
ポインタが指す実体(文字列)の番地、その(文字列の)番地が格納された配列の値、
(値としてポインタが格納された)配列要素の番地。 どうでもいいけど略すならaryじゃなくて，arrでは。 ありがとうございます。
読んでみてなんとなくは理解できるようになりました
>>225
NULLのことはすっかり忘れてました
*を理解できるように頑張ります、ご丁寧にありがとうございました。 >>216-221
Ruby で作った
NUMBERS = ( 1..5 ).to_a
Count = NUMBERS.length
# 九九の表、Times Table ( Multiplication table ) を作る。
# map は1次元配列を作るので、each_slice で、2次元配列にする
Multiplication_table = NUMBERS.product( NUMBERS ).map { | x, y | x * y }
.each_slice( Count ).to_a
result = [ ]
Multiplication_table.each do | ary | # 1行ずつ処理する
result.push ary.each_cons( 2 ).map { | x, y | x + y } # 隣同士を足す
end
p result
結果
[[3, 5, 7, 9], [6, 10, 14, 18], [9, 15, 21, 27], [12, 20, 28, 36], [15, 25, 35, 45]] >>231
やめてさしあげろw
まあ擁護するなら人気のありなしで言語の優劣は測れないと思うけどね。
IOなんてドマイナーだけど俺は好きだし，素晴しい言語だと思っている。
なおRuby いいやaryもまれによく見る。
俺は省略せずarray派だが。 まあarrayくらい省略するなって話よな
creatじゃないんだからw 総体としての頻度は稀だが、とある人の書いたソースには悉く ary として書かれており、
その書いた人というスコープ内においては良く見る >>238
weblio辞書より
まれによくある
別表記：稀によくある、稀に良くある
起こり得る事柄を形容して用いられることのある言い回し。
滑稽な表現であるが、あからさまな形容矛盾であり、日本語としては意味をなさない。
「ブロント語」として広まったインターネットスラング。
「まれによくある」の語のニュアンスは、使用者や使用場面によって異なるといえるが、
「頻繁に起こるとも言えるし、めったに起きないとも言える」といった意味合いだったり、「特定の人においてはよくあるが、その他の人には起こらない」といった意味合いだったり、あるいは、いわゆる「あるあるネタ」を指していたりする。 ちなみに>>222のやつは入門サイトにあったやつを少しいじったやつです スッキリわかるC言語と苦しんで覚えるC言語
どちらで勉強するか迷ってるんですがどっちがいいと思いますか？ >>242
＞スッキリわかるC言語
胡散臭いです…
＞苦しんで覚えるC言語
正直で好感を持てる題名ですね >>242
立ち読みして自分にとって説明が理解しやすいと思った方を選んだら？ 苦CのほうはWebにサイトがあるのでそっちを見ては？ まだ新しいスッキリわかるC言語をベースにウェブで分からない時に苦しーも見る方針に決めました
皆さんありがとうございます >>241
IDEを使ってメモリウインドウから>>226の内容を納得いくまで確認しろ。
> AAAA,BBBB,CCCCを普通に配列で作って、それを1つのポインタでオフセットを指定して選ぶ。みたいなのってCでできるんですか？
それを222で君がやっているように見えるが。
書き方が気に入らないのなら、以下でも多分行ける。
for (int i=0;i<3;i++) printf("%s", *(ary+i));
他言語とは文字列の扱いが異なる。Cの方がより原始的で、はっきり言って使いにくい。
他言語：文字は長さ１の文字列
C言語：文字はcharで、文字列はcharの配列
ただ、char周りなんてどうせ大して使わないから飛ばしていい。さらに言うと、
> AAAA,BBBB,CCCCを普通に配列で作って、それを1つのポインタでオフセットを指定して選ぶ。
なんてのはbotとかでも作るわけでなければ使わない。
printfべた書きで大体事足りる。 ■ このスレッドは過去ログ倉庫に格納されています
