>>4
ちょっとはググって言え。
使い道のないはずのイテレータをC++ではどう活用してるのか、
何故そんなことになるのか、考えてみろ。 というかこのスレワッチョイ外されているんだな。
最近この手の荒らし多いな。
俺はワッチョイ無しのスレは気に入らないから、
>>4の疑問について、ワッチョイ無しのスレ（＝このスレ）では答えないことにする。
まあもうヒントは十分に与えたし、馬鹿でなければ辿り着けるはずだが。 イテレータへのこだわりは確かに謎。結局ローレベルな話なんだよね。
foreachという切り口だとイキるのが難しいということか。
ナマポとプログラム言語の関係性はさっぱりわからない
アホ？ list<T>::iteratorがナマポ撲滅のためとか本気で言ってるのか？
改めて明解C読んだけどどう考えても入門者向けじゃねえなこれ
これ最初に読んだせいで挫折した人多そう
その教科書は教師を再生産するための商品
独学でどうにかするアイテムじゃあない
教科書の肝心のところに教師から教えてもらうフェイズがひっそりとしのばせてある
だから教師の関与が深い
補助の人間が必要な物品だよ
教科書を誰が買うかっていうと、先生がより先生っぽい演技・活躍を出来るアイテムを買うだろ
だから教師の再生産をするためのアイテムを教師が生徒に買わせるんだよ
教科書は生徒が買うんじゃなくて先生が買う、
そのフェイズでは教師の介在があってはじめて理解できるようなひっかけがなくちゃあならない、
だから「入門者向けじゃねえ」になる
C言語の入門書を読み終えて文法をある程度理解したところなんですけどこの次はどうしたらいいんでしょうか・・・
何かを作って見る
何を作るかは自分で決める
決められないときは、みんなに相談してみる
>>14
アルゴリズムとデータ構造の本を一冊買って勉強しとけ
もちろんコードを書くんだ
コードを書かないならそんな本は買わなくてよろしい >>14
標準ライブラリの関数の仕様を調べつつ、自分で実装してみる printf と scanf のフォーマット処理は勘弁してください
ありがとうございますとりあえずアルゴリズムとやらの本を買います
だめでしょ。
アルゴリズムイントロダクションがいいよ
事典は事典。最小限の解説読んであぁなるほどねって思える人用。
詳説 Cポインタ、2013、オライリー・ジャパン
ポインターだけで1冊、本が書けるw
引数に配列をとるとき
f(int* data)とf(int data[])の両方が有りだということは分かったのですが、基本的に後者の書き方をしてるコードはほとんど無くて大体前者な気がします。
これはなんででしょうか。後者の方がはっきり配列だとわかります。前者は配列を求められているのかただのint型のポインターを求められてるのか判断つかないと思うんです
ポインタ本ならこっちの方がいい
新・標準プログラマーズライブラリ
C言語 ポインタ完全制覇 大型本
前橋 和弥 (著) 2017/12/7
>>24
[ ] は、サイズが変わらない
* は、単なる先頭アドレスで、サイズが変わるかも知れない >>24
配列表記はアドレス表記のエイリアスだから区別するという発想がそもそもない
配列アクセスするコードならアドレスと配列のサイズを引数で渡す 関数の引数としては配列であろうがポインタであろうが、ただのアドレスとしての意味しかない
>>29
配列でもポインタでも同じってことは分かってるでしょ
それでも元が配列なら配列で受けたほうが分かりやすいのでは？
という疑問だと思う
>>24
ぶっちゃけ、Cに慣れてくるとどっちでもたいして変わらない
配列で受けたいのならそうすればいい。
実際のところ、両方それなりに使われてる。
例えば、main() は int *argv[] にすることが多いんじゃないかな
多分だけど >>24
配列っぽい表記に惑わされて、sizeofして長さを求めようとしたというバグを何度か見ました。
f(int data[100]) なんて渡し方だと、どう？
そんな文法はない。
宣言としては有効かな。でも意味はないだろうね。ただのポインタ。
>>33
じゃあ、これをポインタ表記に置き換えて見てください、お願い >>24
なるほど、じゃあ君は
void swap_int(int lhs[], int rhs[]);
と書いてもらえれば判断つきやすいんだな なんというか、Cならではの問題かな。
Javaもちょっと似てるか。
下のようなコードを書くとコンパイルエラーになるでしょ。
int ary[100];
int val;
val = ary++;
このaryは配列だから、ary自体の値を変化させる操作は出来ない。
それの類推で関数の仮引数はポインタで受けるんじゃないかな。
関数の中でポインタ風に使う変数はポインタの形で宣言。
関数内で値を変化させず [] によるインデクスだけでアクセスするなら
仮引数を配列の形で宣言するのも分かりやすい書き方かも。
後は歴史的な事情。
配列風に書くとインデクス計算に掛け算を使われて遅かった名残り。
>>30 俺はmainの引数は main(int argc, char *argv[]) だな。
保守的だけど、こんな場面で独自色出すことないしね。 >>24
あんたの感覚は正しいと思う
同じだと言ってる奴もいるけど
foo(int a[]){
a = … /* エラー */
とか微妙に違う
ただそこまで気にする人があまりいないだけ 関数の引数では配列の要素数は無視されるだけ
変数としての配列とポインタは別物だけど、関数の引数では全く同じもの
理由は既出だけど、C言語では配列とポインタは明確に違うよ。
相互変換可能なだけ。
ぶっちゃけ、相互変換可能ならその二つは同じじゃねえか？
数学的に
同じ点もあるし違う点もある
同じ点を強調したいときに「同じ」
違う点を強調したいときに「違う」
と言うだけ
具体的に語らないと何の意味もない
>>38
そのコード片、エラーになるかな?
仮引数のa(intへのポインタ)に
関数内で値を代入することは許されるはずだけど。 代入ではエラーにならんと思うよ。
lvalueとして使えると思う。配列っぽく書けるがあくまでポインタ。
>>43-44
すまん、お前らの言う通りだ
なんか勘違いしていたみたい 引数の配列がホンモノだとすると、非NULLが保証されてないとあかん。
というか構造体渡しと同様の配列渡しが必要だな。まあ使わんか。
>>37
その例は
void func(int ary[100])
{
int val;
val = ary++;
}
との違いを示そうとしているのだとしたら
int *val; じゃないとおかしいだろ
>>37
[]で書くべきと主張するんなら
char argv[][]にしなきゃねえ
もちエラーだけどｗ 配列をパラメータにするのは
サイズが決まってる時にそれを明示したい場合くらいだな
ポインタの方が汎用性が高いから
構造体みたいに
値渡しやコピーもあると(たまには)便利
>>50
void func(int ary[100]); これと
void func(int *ary); これが
意味が違うと思っているのか？ 設計意図を示すコメント的な意味ならあると思う
中身は同じだけど
初心者に対して誤解を与えるだけじゃね？
必ずそのサイズで呼ばれると保証されるわけでもないし。
>>52
意味は違うね
要素が100個以外の時に前者を使ってるコードを見たら気持ち悪いだろ？
そういうこと
コンパイラによってはary[1000]にアクセスすれば警告が出る ほんとに警告出るのか？
サイズ指定に意味がないというのが規格だし、コメント程度の役割しか持たせたらあかんという気が
お高い静的解析ツールだと警告出るかもね。
やってないから知らんけど。
そういう環境で開発できるならコメント以上の意味はあるかも。
仮定で申し訳ない。
>>55
おまえの主観は聞いてない
プログラムの実行結果が違ってくる例を示せ >>48
多次元配列なら
void func(int ary{}[100])
{
}
とか
void func(int (*ary){}[100])
{
} >>61
間違えた
void func(int ary[][100])
{
}
とか
void func(int (*ary)[100])
{
} >>60
もう一度言う、おまえの主観は聞いてない
正論か屁理屈かはおまえの主観だ
客観的事実を示せ、理屈はそれからだ >>63
だれも機械の解釈の違いには言及してない定期 >>62
void func(int ary[][100]); これはできるのに
int func(void)[][100] これはできない
{
int ary[][100]; これもできない
ary = 0;
return ary;
}
extern int ary[][100]; と
extern int (*ary)[100]; は意味が違う
結局、[]で書くべきなんて主張は
通用しないところが多すぎる戯れ言だ >>64
プログラム言語は機械に解釈させるためのものだ
自明なことを誰も言ってないなんてことこそ屁理屈そのものだろうが >>68
機械の解釈が同じでも人間には違う意味に見えるのはあるよな？ >>69
void func(int ary[100]); これのどこが
void func(int *ary); これの構文糖衣なんだ？
書いた奴の頭を疑わせる以外にどんな意味があるんだよ サイズが100でなければならない関数なら
void func(int (*ary)[100]); こう書いて
int ary[100];
func(&ary); こう渡せよボンクラ
>>71
どうした？
コードレビューで上司にボコボコにされた腹いせか？
こんなとこでイキっても虚しいだけやで。 >>71
どうした？
コードレビューで上司にボコボコにされた腹いせか？
こんなとこでイキっても虚しいだけやで。 >>73
ここがム板ってことを忘れたか？
技術的な話で来い 多次元配列の型は typedef で型名作っておけば楽なのでは？
>>68
>>76
この書き込みのどこが技術的な話なんだw
単にイキってるだけじゃん。 >>78
構文糖衣の話をしたんだが
構文糖衣と書いてないと読めないオツムなのか？
アホｗ バカｗｗｗ >>75
そりゃわかりにくいからだよ。
引数にするとCの多次元配列の嘘くささがよく表れるわ。
せめて構造体で包むとかして名前を付けた方がいいね。 >>70
それを糖衣構文というかどうかどうでもいいけど
だれも機械の解釈の違いには言及してない定期
>>50➡>>52
明示とは機械に対してではなく人間に対してのことを言ってるからこの返信は意味がずれてる 超初心者です。
シミュレーターで動かしながら独学で学んでいるのですが、
scanfが動かない（スルーされる）ので困っています。scanfが動くシミュレーターってあります？
for文でこんなのを発見したのです。
for(;;)
ご覧のとおりセミコロンがカッコ内に2つあるだけ。
これはどういうfor文でしょうか。
ググり方も分からないです。
昔からその書き方の無限ループを好む人は多い
俺が知ってる範囲だとカーニハンもその書き方を好んでいた
無限ループって言っても
大概は何かの条件で脱出するわけだから
while (条件) が一番わかりやすいと思う
あ、好みだろうから、反論は不要です
>>92
俺も無限ループはwhile(TRUE)派だな。
静的解析で怒られるから使うなって人もいるけど。
これも個人の好みなので反論不要です。 無限ループには
for(;;)
while(1)
while(true)
などがあるようですが、驚いたことにfor(;;)がC言語の伝統的スタイルなんだそうで。
for(;;)は無条件であることを的確に表現してる
条件が書いてないのはこれだけ
そういややったことないけど while () はできないのかな？
できたらできたでなんか怖いがw
>>100
冷静に考えると、何でfor(;;)の真ん中の条件式のとこ空欄でも正しい構文になるんだろうね。
for以外に条件式省略できる構文ってないよね？ 左右の式が省略できるから、ついでに真ん中の式も省略可能にしたんだろう。
ループの話でふと思い出したんだけど、この書き方キモいと思う？
LOCK();
while (条件) {
UNLOCK();
LOCK();
}
UNLOCK();
きもいけどきもいだけだから必要ならそうする
Cだしね
condwaitみたいなの、たまに書くと混乱するわ
LOCKして、何かして、UNLOCKして解放する
わけではないんだ？
>>108
while (条件) で統一したいと思いつつ、この手の場合LOCK, UNLOCKのインデントがズレててキモいなといつも気になってしまう
まあどーでも良すぎていつも放置するが
>>110
アトミックな条件チェックの話 >>112
手動でインライン展開する必要がなければ、普通は、
while (check_func()) {
}
bool check_func(){
LOCK();
bool retval = XXX; // check something here
UNLOCK();
return retval;
}
とする。
C++なら inline を付ければインライン展開時（元のコード）と似たようなオブジェクトコードが出ることになっている。 >>107
do {
LOCK();
UNLOCK();
} while (条件); >>107
条件を判断するためだけにLOCK/UNLOCKを行うコードだとしたら最悪のコードだ
do {
LOCK
判断
UNLOCK
if (!判断結果)break;
} while (1);
素直にこうしなさい どこが素直なんだ
締め切りが迫ってバグが取れず
なりふり構ってらんなくなったやつが書く
イカレたコードでしかない
ん？
一番素直だろうが
条件判断の為だけにLOCKしてるという前提で
判断を関数に分ける？
分けるかどうかはこんなちっぽけな理由で判断するべきじゃないよ
判断の度に関数にしてたら意味不明な関数で溢れるぞ
もちろん意味が明瞭で他にも同じ判断を使う可能性があるのであれば
関数やマクロでパッキングすべきだが
LOCK
判断
UNLOCK
というアトミックなシーケンスを関数にする理由はちっぽけじゃない
LOCK/UNLOCKが必要な具体的な場面を想定しての発言には見えない
どういう場面かなんて>>107では判断不能だし
分けるべきか分けないべきかも>>107では判断不能
判断出来ないのに
「わざわざ関数構成を変えるべき」
なんて主張をすべきじゃない >>123
いやー、わからんのはあなたに実務もしくは勉強の経験がないからよ 昨日のvoid func(int ary[100]);にしても
ary[1000]を警告する処理系の具体的な例が挙がってないしな
>>124
わからんねえ
エスパーじゃないんだから
経験が少なくて
分けないべき場面が思い浮かばないんだろうねえ >>127
そういうあなたは昨日のイキってた方の人？ パッと見て何をしているか分からないソースって
後の人が取っても苦労するし、気の毒
多分書いた人の意図は
while文内の判定時に
LOCKしたいのかとは思うが
check_func()というアドホックっぽい関数名が誤解のもとかな
get条件atomically()にすれば意図が明白
atomicallyって文言いるかねえ
いちいち全部につけて回るより
LOCK/UNLOCKしてることは
忘れたフリができるほうがいいと思うが
英語圏の人には for (;;) をまとめて熟語的に "forever" と読めて
座りがいいのかも知れん。
カーニハンとパイクの『プログラミング作法』に
それに近いようなことが書いてあった。
>>133
条件取得の関数がすでにあってそれがアトミックでないケースも想定 >>134
なるほどforeverか
そういう風にも読めるな >>134
そう言われると確かに座りが良いかもしれんが、(;;)をeverと読むのか。。。
今の時代では顔文字の失敗作にしか見えんなw >>134
#define ever (;;)
とかやんの？
だったら
#define forever for (;;)
のほうがマシだと思う
>>135
空想論なら付き合ってらんねえぜ 「その部分のループ、終了条件が色々なんでとりあえず for (;;) で回して」
みたいな口答でのやりとりで for (;;) を forever と読めば手っ取り早いでしょ。
while (1) で…よりも言いやすいんじゃないかと。
これは空想論だけどね。
無限ループで済むことを
forの第2式を空欄で
なんて回りくどい言い方しねえよ
>>140
別に回りくどくないし
良く見るコードだよ
いろんな人のコードを見たりしないの？
みんないろんなポリシーでいろんなコードを書くから
いろんな書き方を知っていた方が良いよ while (条件)
でしかループが組めないのはちょっとさみしい
無理やりこの形にするために
>>107みたいな意味不明なコードになる >>141
口頭でのやり取りつってんだろ
流れを読めよ 口頭で
forの第2式を空欄で
なんて発想は出て来なかった
> while (条件)でしかループが組めないのはちょっとさみしい
ここは同意
while(1) であろうが for(;;) であろうが同じこと
どっちかが好みで他方で書かれたからって可読性が落ちたとか騒ぐ
救いようのないドアホには付き合ってらんね
それだけだ
whileで無限ループする場合、0じゃなければ1以外を
使ってもいいわけだがどうする？
電話番号とか使えばオシャレかもしれないよ
とりあえず、おかしなのに絡まれた >>134 に同情を禁じ得ない。 別にiocccのコードが読めろとか言ってない
int *aryがint ary[100]じゃなきゃ読めないとかぬかしたり
while(1)がfor(;;)じゃなきゃ読めないとかぬかす
想像を絶するアホには付き合ってらんねつってるだけ
lock/doit/unlockを関数化する必要性がわからないアホも含まれる
>>151
「じゃなきゃ読めない」ってどこかに書いてたっけ？
そんな気はしてたが、やっぱり日本語不自由な人だったらしい。 何がじゃあなのかわからない
思考がbool値しかないのか
アトミックな操作の意味がわかってたらああはならんのですよ
世の糞コードのほとんどはコミュニケーションの失敗により発生する
C言語以前に日本語もちゃんと理解できない人と議論が噛み合うわけない。
相手しただけ損したわ、アホらしい。
勝手に損してろ
誰にも賠償請求できない
泣き寝入りだな
アホｗ バカｗｗｗ
はいはい、ちゃんとにほんごをべんきょうしてりかいできるようになってから、かきこんでくださいね。
まあ概ね ID:yJL450CM が言っていることは正しい。
>>107のコードは、かなり特殊で、普通はあり得ない。
キモイかと問われれば、キモイと答えるのが正しい。
(必要ならやればいいが)
>>116
それはdo-whileの標準的使い方とは異なるので、混乱を招く。
>>132
check_func()は、107を書き直した場所がすぐに分かる名前にしただけ。
実際、問題なく伝わってるだろ。
本番コードでこの名前はあり得ない。名前が被るから。
ただ、正直、こんなどうでもいいところで拘るのは止めた方がいい。上達しなくなる。
どれでもいいから自分が好きなのを選び、グダグダ言わずにどんどん書いた方がいい。
なお、Goにはwhileが無い。廃止されて、forだけになっている。
ちなみに、俺は
固定長ループ（単純ループ）： for … for (int i=0;i<num;i++) 程度の簡単な場合は常にこれ
可変長ループ(複雑なループ）： while
無限ループ： while (1)
do-while： 使わない
にしているが、正直、ここら辺は好みだし、自分がどう決めるかだけ。（上記は標準的だとも思っているが）
それよりは、自分の中で統一するほうが重要だ。
(少なくとも自分が書いたコードを読むときに混乱しなくなる)
業務なら、グダグダ言わずコーディングルールに従えばいい。
場所によってはwhileとforのどちらかが禁止とかもある。（どっちかは忘れた）
理由はバグって無限ループにしてしまったときにコード上から判定しづらいとかだったはず。 非常にくだらない質問にレス付けてくれてサンクス
なんか荒れる原因つくってスマンかった
やっぱりあの書き方きめえよなあ・・・
>>112
> LOCK, UNLOCKのインデントがズレててキモい
これは諦めろ。
酷い話、インデントがぴったり合ってないと駄目な奴はプログラマに向いてない。
どうやってもずれるからだ。
googleのコーディングルールにも昔は
・インデントを揃える努力は、キリがないしやるだけ無駄だから諦めろ
と書いてあったはず。（今見る限りないが）
ちなみにキモイ理由は、インデントではなくて、完全に入れ子になっていないからだ。
最近はこの「入れ子」の厳密さも増していて、XML(HTML等）では入れ子しか文法的に認めないだろ。
例えば、
<while>
</while>
ならありだが、
<lock>
<while>
</lock>
</while>
は駄目で、
<while>
<lock>
</lock>
</while>
にしなければならない。 >>161
do while の標準的な使い方？
無限ループも標準的な使い方ですよ
do whileはforやwhileに比べてパフォーマンスが良いことがあるので
使える時には積極的に使う人もいます
do whileを一切使わない人もいますが >>107
対称性保たれてるし、よくあるコードだぞ。
俺はキモイと思わん。 ロックしたい対象がわかりづらい
同じ用途のロック/アンロックが2箇所ずつある
C++の場合だと
無駄にロック期間が長くなる可能性がある
頭が良い人ならすぐに意図がくみ取れるけど
メンテする人が必ずしも頭が良いとは限らない
コメント書いてもバグではまって始めて読まれたりするからね
ワザと作られた落とし穴なんて受けとられる危険もありそう
バカでも分かるような書き方をする方が安全かなと思う
>>164
>>116のコードは、while (1) で開始しても同じだし、（=do-whileを使う意味がない）
そもそも>>113に比べてメリットもないだろ。
そこで do-while 使う奴なんて皆無だと思うぞ。
まあそれでもやりたければやればいい。
個人開発ではメチャやって、その失敗を業務に生かした方がいい。
ただ、上達したければ、ある程度普通のコーディングルールで組んだ方がいい。（世間に合わせる）
自分と相手のルールが一致してたら、相手のコードも読みやすく、
結果、同じ時間、同じ努力でも読める量に違いが出てくるから。
あと、初心者はよく
・色々文法を知ってて、様々な書き方が出来る奴が偉い
と勘違いしがちのようだが、これは明確な間違いだ。（これは他言語では本当に酷い）
こんな糞どうでもいいところを様々な書き方をしているような奴は雑魚だ。
上手い奴は、そいつが決めたやり方に従って、一定の書き方で書く。
だから、後で読み直すときも楽だってこと。
自分の手書き文字なら相当汚くても読めるだろ。それに近い。
基本的には意味のない手動インライン展開は止めた方がいい。
それは無駄に関数を大きくする。
関数呼び出しのコストが気になるなら、C++なら inline が用意されてる。
そもそもロックなんて糞遅いから、そこでCPU命令数個ケチる意味もないはずだが。
可読性を上げる為に最初にやるべきなのは、関数を分割して小さくすることだ。
呼び出しコストは考えず、分割しまくった方がいい。
結果、抽象度が上がり、読みやすくなる。（全体を読まなくても済むようになる） あくまで、プログラマが初心者の場合の話だけど。
いろいろなソースを見てきたけど。
仕事としてやるなら、初心者は、なるべく関数化してほしくないかな。
練習としてなら、いいけどね。
関数化する等して、抽象化した方が見やすいソースになるかというと、
間違いじゃないけど、正しくもない。
有能なプログラマーが書いたソースは素晴らしいし、可読性も申し分ない、うん。
でも、クソなコードは、関数化しちゃいけないものが、関数化されているなどが原因で、
追跡が難くなるんだな。
オブジェクト指向を謳う言語のソースなんか、C以上にプログラマーの手腕によって、
可読性の差が生じてしまう。関数だけでなく、クラスの設計が腐ってて、どうしもないとかね。
そうゆうソースの追跡は辛いわ。
Cの場合、ぐちょくちょなソースの場合、関数化されていない方が、
コードのメンテ等で、強引に追跡する際は苦労が少ない、そんな感じ。
そんなこたねえよ
関数を作った方がいいしファイルを分けた方がいい
ネストは浅い方がいい
>>116
なぜわざわざbreakなんて使うんだ？
素直にこれでいいでしょ
do {
LOCK
判断結果 = 判断
UNLOCK
} while(判断結果) >>173
breakしないと条件が偽の時にも処理が動いてしまうからでは
きっとループの中になんらかの処理があるはず >>174
> きっとループの中になんらかの処理があるはず
書いてもないものが見える謎の病気w >>172
分割しすぎも考えものだけどな。
>>113も視点移動が増える書き方で、可読性やメンテナンス性が悪いという人もいる。 >>170
do while のが軽い場合がある
って常識だと思ったが
>>175
私も当然他の処理があると思った
無いとするとビジーループか？
これだと気持ち悪いとかいう以前の問題になる >>172
行数やファイルの数で値段が決まる業界の人？ 全てのLOCK/UNLOCKのペアはそれだけで関数にする
2重ループやループ内のswitch caseは使わないで関数に分ける
いろんな人がいるね
自分では本当に例外なく実践してるんだろうか
宗教の例
gotoは使ってはいけない
2重ループは使ってはいけない
3項演算子は使ってはいけない
インデントは全て揃える
全てのリテラルは別途定義する
変数名に型情報を埋め込む
関数の途中でreturnしてはいけない
関数は小さいほど良い
条件分の中に関数コールや副作用のある文を書いてはいけない
インクルードファイルをネストしてはいけない
コメントは全て /* */ で (// や #if 0 を使ってはいけない)
全ての演算子のネストに対して ( ) をつける
全てのロック、アンロックのペアは関数に分けなければいけない
>>180
宗教の集大成がMISRAだな。
ほとんどがルールにあるわ。 switch caseはは無駄にカラムを消費する。から嫌い。
>>176
視点移動になるのは下手な関数化だ
サブルーチン呼び出しを1命令と読めるようにするのが
構造化プログラミングの本質 >>183
ある程度の規模の関数になると結局その1命令に見えるはずの処理が正確に何してるかを理解するためには関数内を覗くはめになっちゃう。
覗かないですむほど関数仕様を単純化すると今度は関数が増えて管理の手間が増える矛盾。
後者のほうが正解なんだろうけど、なかなか理想通りには行かないよね。 >>184
ある程度の規模ってLOCK/UNLOCKの話だぜ？ >>178
ファイル数とか初めて聞いたよ。
疎結合高凝集は大抵の場面で正義だよ。トータル1000行のソースだったら好きにすればいいが。
あと関数にもファイルにも「意味のある名前をつける」
ある意味大変難しいんだがこれができれば保守性が全然違う。 規模は覗かないとわからんよ
1個の関数からしか呼ばれないたった3行の、
ただ単に特定のループの終了条件を示す為の関数
結局両方見ないと意味不明
こんな関数が山ほどあるプロジェクトは悪夢だ
たった3行の為に
関数名を考え
関数ヘッダを作成し
プロファイリングや静的解析ツールやMAPの項目も増える
大きく依存した関数なのに
グローバル関数とローカル関数を分けて書くという宗教を理由に
全然別の場所に書く
最悪ですねえ
こういう人は
ifなども含め、複数文からなる全ての条件判断を関数にするんでしょうか
あり得ないですね
もちろん単なる1個のループの終了条件ではなくて
その条件に意味があって
他でも使う可能性があるなら関数に分けるべきですが
プロファイリングのときってstaticな関数も同列に扱うもんなの？
ある程度の規模、って
サイトによって違うんだし
一般化はできないんじゃ
>>177
> 私も当然他の処理があると思った
> 無いとするとビジーループか？
> これだと気持ち悪いとかいう以前の問題になる
君のレベルが低いだけ
最近のプロセッサはロック/アンロックをハードウェアレベルで行うようになってるけどビジーループ自体は使われてる
スピンロック でググれ 「長いから分割する」という発想で関数作ってる人は割といるんだよ。
そうするとまあコンテクストが広い範囲に分散してつらい。
そういえば昔客とソースレビューしてて、
引数チェックのための早期returnしてたら、
客「途中returnはやめてください」
俺「そうするとネストが深くなりすぎますよ？」
客「それなら関数に分けて下さい」
俺「分けた関数の先でも引数チェックするので同じですよ？」
客「それならその先の関数も別の関数に分けて下さい」
俺「…(反論するのめんどくせえ、言うとおりに作ってしまえ)」
結果、思い出すのも恐ろしい意味不明な関数ばかりのコードが出来上がったわ。
途中リターン禁止ってほんとアホだよね。要はreturnの否定だからな。
最近はMISRAからも外れてるらしいが
>>191
単なる1個のループの条件に意味がないことなんてあるのか？
たった3行というがlock/unlockという2行で
他のタスクが干渉しないようにガードする必要がある条件だぞ
干渉されるとしたら何でだ？ それでも意味がないのか？ >>196
CASもLL/SCもアトミックなR-M-Wも使うけど
どう考えてもそんなコードじゃないだろ
知らない癖に書くなよ そこまでローレベルの話じゃないと思うよ
無関係ではないけど
>>203
> 最近のプロセッサはロック/アンロックをハードウェアレベルで行うようになってるけど
って書いてあるのにCASとか出してくるアホ乙 じゃあハードセマフォか？
それスピンロックじゃないよな
恥の上塗りwww
>>206 が必死にググって見つけて来た関係ありそうな（でも全く頓珍漢な）言葉 → ハードセマフォ
自爆志願者かよ w な、ここのスレは読解力が乏しいのにお互いにマウント取り合って傍から見たらアホちゃうのって奴が多いだろ？
よくもまあLOCK/UNLOCK如きで生産性のカケラもない議論できるわ。
よほど暇なんかな？
初心者でもベテランでも新しい気付きがあるような内容に早く戻るといいね。
400メートルなら連続で泳げるけど、800メートルはよほどペース落とさないと無理だわ。
>>200
客「(コイツらには二度と仕事頼まんとこ、無能すぎ)」 >>220
多分両方ともそれなりに正しい方法を知ってるのに
会話の祖語からとんでもないところに着地するケースだな >>176
> 視点移動が増える書き方で、可読性やメンテナンス性が悪いという人もいる。
それは正しく分割出来てないから。(同じ抽象度で分割する）
読まなくても分かる名前を付けて、結果的に読まないから、視点移動はしない。例えば、以下。
while (1) {
int idx = get_data_idx();
if (idx<0) break;
int* data = prepare_data(idx);
calculate_data(data);
write_back_data(data, idx);
}
この部分はマルチスレッドでのデータ処理だとしよう。
get_data_idxは未演算のデータのインデックスを返し、ない場合は、-1を返すとしよう。
単純に、「インデックスを受け取り、チェックし、データを用意して演算して書き戻す」と読めるだろ。
そこでget_data_idxの中身を見ると、マルチスレッド用だからロックされてる、というだけ。
（余談だが>>107にはこういう具体性が見えないので、
> LOCK/UNLOCKが必要な具体的な場面を想定しての発言には見えない (>>122)
と言われている。これも当たっている）
「視点移動ガー」は読み方を間違っている。
プログラムが階層構造のツリーとして、
縦に掘るのではなく、横に読んで、必要であればその部分だけ縦に読むんだよ。
まず最初は同階層で全体の流れを把握して、必要であればその実装を読む。
実装を読む場合、名前と実装が一致しているかだけのチェックしかしない。
家を建てるとして、
全ての柱が設計図通りに組み上げられているか（全体のチェック）と、
それぞれの柱が設計図通りの仕上がりになってるか（ほぞ穴が正しく加工されてるか）は別にチェックするだろ。
プログラミングも同じで、上位と下位は別にチェックするんだよ。
同時に読まないからいちいち子関数に視点移動なんてしないし、視点移動しなくて済むように同抽象度で分割するんだよ。 >>177
> do while のが軽い場合がある
> って常識だと思ったが
それはお前が何も知らない初心者だから。
do while は初回のチェックが入らない分速い。(逆に言えば、その分だけしか速くない)
君は「なんだか知らないが do-while は速いんだ！」位の理解しかしてないだろ。
そんな馬鹿はC界隈にはいない。
問題は、この「初回チェックしない分速い」のをいちいち取り上げる必要があるか、という点で、
殆どの場合はどうでもいいから do-while は使われない。
ただし、どうしてもケチりたい場合は使われる。
（ルール等で駄目なら手動で初回部分だけインライン展開しても同じだが、それよりは do-while 使った方がいい）
禁止する必要はないけど、使う局面もない、といったところだと思うよ。
初回のチェックが必要ない＝その前か上位で初回チェックが必要ないことを保証している、であって、
全くチェックしていないわけではないんだよ。
結果、処理を整理して集約していくと、while文に吸収されることもある。
或いはそうならないとして、ど頭でチェックだけして不要ならショートカットしたい等の場合、
別にチェック＋ do-while になるが、それはメトリックスを増やしてしまう。（静的コールグラフ）
どのパスを通るかがデータ依存になり、それがかなり大きな区画になってしまうだろ。
それよりはショートカット出来ないけどどんなデータでも同じパス、
whileで弾かれて空振りするだけ、のほうがメンテナンスが遙かに楽なんだよ。
ここら辺はさんざんメンテナンスしてれば分かるようになるし、してないうちには分からない。
お前は相当それ以前だが。
「僕はdo-whileの方が速いケースもあるのを知ってるんだ！」ってのは痛いだけだから止めとけ。
自分でアホだと言っているようなものだ。
そんなことはみんな知ってて、その上で議論している。
コード分岐を増やすのが、1回のチェックを端折るのと釣り合うか？なんだよ。 成功するまでリトライみたいなのってdo-while使わない？
do {
} while (0);
こんなのもごくたまに
do-whileはマクロで文をまとめるのによく使うよ。
ただマジで、初心者はこの手の話に首を突っ込まない方がいい。
時間の無駄で、上達を阻害するだけ。
コードの美しさ/抽象レベル/分割/隠蔽/疎結合が必要なのは少なくとも200-1000行程度であって、
50行程度ならグダグダ言わずにベタで密結合で書き下した方が分かりやすい。
10行のプログラムを動かすにも苦労する初心者にも、
理解に少なくとも200行程度書ける腕前が必要な内容を教えるから空回りする。
(とはいえ、初段階の洗脳は必要悪だ、というのがJava教団であるが。
そしてFizzBuzzはイテレートするクラス、判定クラス、表示クラスに分割され、
イテレータがインタフェースとして活用される、というのが件の悪ノリだった）
1000行程度も書けない初心者は、まず1000行書けることを目指せ。(1000行程度なら勢いで書ける)
コードの美しさその他はその辺になればだんだん分かってくる。
その後に、自分で「コードを減らす」練習をした方がいい。
(コードを「書く」よりも「減らす」方が上達する、と言う奴は居て、俺もそう思う）
それまでは自分でコーディングルールの優劣を判定する頭もないのだから、（これはちゃんと認めた方がいい）
オレオレルールではなくて、コードを書いている連中のルールをそのまま使った方がいい。
俺はgoogleがいいと思うが。
(なお意識高い系C++erはgoogleのルールはもう古い！と言いだした模様。
俺は布教用のルールなんてゴミだと思っているが、まだチェックはしてない）
>>180-181
MISRAは「自分でどのルールが無駄か判断出来る人向け」であって、
お前らみたいな「自分では判断出来ない初心者向け」ではないんだよ。
素直にとりあえずgoogle使っとけ。 >>184
> 覗かないですむほど関数仕様を単純化すると今度は関数が増えて管理の手間が増える矛盾。
管理の手間は増えないと思うが。
もし増えていると感じるのなら、それはCには階層がないことの弊害だ。
関数内関数が普通に使える状況であれば、
関数切り出しは「処理を纏めて名前を付けただけ」でしかなく、
外部からその関数が呼ばれることが文法的にないことを保証出来るから、手間は増えない。
そしてこの点に、妥協的だが現実的なのは「名前に階層も付けてしまう」だ。
つまり、AAA階層内の関数はAAA_get_data_idx()等にし、
もし仮にAAA_get_data_idx内でさらにローカル関数が必要な場合は、AAA_get_data_idx_BBBにしてしまう、というものだ。
関数名が長くなる点を除いて問題はないし、「grep出来るから便利」 by Linus。
OOPも実質同じで、フルパスで呼ぶなら AAA->get_data_idx->BBB()等、_ が -> に代わるだけだが、
実際はオブジェクトポインタ＝途中のポインタだから、obj->BBB()となり、長くならずに済む。
（ただし、grep出来なくなる）
俺もCに階層記述能力がないのは問題だと思っているが、
現実的に分割/疎結合化が必要なのは200-1000行単位であり、
ここは「ファイル」（=モジュール）で分割しろ、というのがCだ。
だから不満ではあるが結果的に何とかなってしまうのも事実で、だからこそCがまだ生きながらえている、というのはある。
それにしても「関数内関数」は欲しいんだけどね。あと、ラムダも。
(gccでは前者は標準、後者はマクロで対応出来るが） >>230
1000業かけるお題を教えてください(｡・´_｀・｡) >>224
> do while は初回のチェックが入らない分速い。(逆に言えば、その分だけしか速くない)
違う、>>177はコンパイラがあまり賢くない時代の知識で止まってるロートルってだけ 現在通過中
風はそれほどでも無いが雨量がヤバい、尋常じゃない
デメリットは数文字ソースコードが増えるだけ
生成されるバイナリが悪くなることは無い
良くなる可能性はある
>>223
> それは正しく分割出来てないから。
そう。だから、>>113は正しく分割できていない、という人がいると書いたんだが。 do while を使わない(使えない)人っているよね
常に正しく分割されてるコードしかいじらないわけでも無いだろうし
常に正しく分割出来るとも限らないし
正しいか正しくないかは視点によっても違う
理想だけ語るだけで実際にコードを組んだ事が無さそうな人がいるようだけど
>>226
具体例あるか？
それ以前に「成功するまでリトライ」自体がよろしくないが。
>>236
do-whileに対して何か特殊な最適化がかかるという話なら、
俺は知らんから突っ込めない。
が、そうだとしても、それでコードを汚すこと自体が間違いだが。
>>241
そう思うんならそれでいい。
平行線だし、議論しても結果は出ない。
君のコードを見て他の人がどう思うかはそれぞれの自由だ。
俺はこの場合関数に括り出す方を選択する。
同様の連中もここにいるだろ。それだけの話さ。
ただそれ以前に、アトミックなんて最初から関数に括り出されていると思うが。
インラインアセンブラを使う気でなければそもそも無理だし。例えば、以下。
https://msdn.microsoft.com/ja-jp/library/dd78zt0c(v=vs.110).aspx
>>245
あー、8は俺だ。
ワッチョイありで立て直してくれればそっち行くわ。
（俺が立て直してもいいが) >>246
俺の記憶では、「FizzBuzz Implementation in Java」みたいなタイトルでGitHubに在ったはず。(だが出てこない)
★も2000位ついていたと思った。
クレームついて取り下げるとも思えないから、検索順位下げられたんじゃね？
そんなに見たければ自分で探せよ。多分まだそのまま公開してると思うぜ。 >>251
それだ。
(俺のキーワードが役に立ったようには見えないが…まあ辿り着けたようだしよしとしよう） >>247
> ただそれ以前に、アトミックなんて最初から関数に括り出されていると思うが。
そうだな。すでに atomic 実装されていたら俺も使うわ。
関わっているプロジェクトや文化にも依存するから、絶対はない。
例えば Kernel とかだと大半は関数化していない。俺は見た記憶がない。
まあそれだけの話。 >>255
俺は見たことがないだけ。気になったら探してくれ。 >>256
grepすれば出てきそうだが探す気はない。
linux kernel内でひたすらインラインされているとしたら、
おそらくスタック容量(1スレ当たり256バイトだったか？）の為だろう。
「関数化」はされていなくても「マクロ化」されていて、
ソースコード的には意味が同じという落ちじゃないか？
それなら君の噛みつき方は悪質だと思うがね。（意図的に議論を空回りさせててる） >>257
わざわざ自前で関数化していない、という話だぞ。 >>258
それが論点のすり替えなんだよ。
分かってないようだからそれでいいが。
というわけでこの件は終わりだ。 >>259
>>113 が自前で関数化する意図でしか読み取れないからな。
あれが自前実装でないというのであれば、それまでだ。 C言語なら俺に聞け（答えるとは言っていない）ですか？
>>253
「github にある」が重要なヒントとなりました >>242
> do while を使わない(使えない)人っているよね
このスレでも>>161とかな
while(){}に比べたら使用頻度は低いけど使用する機会があるから多くの言語で使えるようになってるのになぜかdo～while使わない俺かっけーとか思ってそうw
ただ今どきパフォーマンスがいいからdo～whileにすると言うのはナンセンス >>247
> 俺は知らんから突っ込めない。
知らないなら突っ込むなよ…
> do while は初回のチェックが入らない分速い。(逆に言えば、その分だけしか速くない)
とか馬鹿丸出しだぞ >>255
あんたの言ってるアトミック操作が>>107のLOCK/UNLOCKに相当する
わざとなのか理解してないのかは知らんけどレイヤーの違うものを混ぜて語られてもそりゃ噛み合わんよw >>247
コードを汚す？
do whileに慣れてないと
無限ループでdo whileを使うのがコードを汚す
になるのか？ >>266
> ただ今どきパフォーマンスがいいからdo～whileにすると言うのはナンセンス
forやwhileを選ぶ理由がある所でも
パフォーマンスを気にしてdo whileを選ぶべき
なんて話はしていない
どれを選んでも良いときに
forを選ぶ人、whileを選ぶ人、do whileを選ぶ人がいると言うだけ わざわざCを使うってことは
8bitのチープなマイコン、チープなコンパイラだったり
OSやドライバの開発だったり
アセンブラも混ぜて使うこともありそうな
一番低級な高級言語
他の言語よりも記述方法によるパフォーマンスの差
が語られても良いと思う
自己防衛のためだけのレスになってきたな
そろそろこの話題も終わりかな
ソース見て do {...} while (1); で無限ループになってたら
さすがに「なんで for (;;) や while (1) にせんの?」と尋ねるわ。
…でも「ループ先頭の(決して成立しない)終了判定が入らないから速いんだ」
と言われたら受け入れるかも。分かってやってるんだな、という意味で。
実際のところ for (;;) は無論のこと while (1) でも判定しないと思うけど。
>>273
3個とも超基本構文だと思うけど
そのレベルだと
「なんでfor(;;)なの？」って聞く人もいそうだな そういやループの話でgoto使うってレスないな
ネストが浅くなるし好んで使う人は・・・さすがに居ないか
>>274
K&R以来の伝統のCのイディオムだから？ goto label2
label1:
処理
label2:
条件判断
if (偽) goto label 1;
----
コンパイル結果的にはforやwhileはこんな感じ
条件が無かったとしても goto label2が入る
最適化しない場合やチープなコンパイラだと
このまま最適化されないかもしれない
goto label2
が不要な時にこれを除いたのがdo while
これのほうがバイナリはシンプル
>>175
多重ループから抜ける時
関数の終了処理
ガシガシに最適化をする時
使いどころはこんな感じ gotoを使わない(使えない)人だと
多重ループから抜ける為だけにフラグを使ったり
多重ループから抜ける目的の為だけの理由で
関連する複数のループを分けたりする
double data[4][4];
例えばこんな構造のデータのある統計情報を返す関数
ただし、データに非有限値が入っていたらNaNを返す
デバッグ用に計算結果を出力するコードが入っている
どういうコードにする？
>>270
> どれを選んでも良いときに
無限ループ以外にそんなケースあるか？
かつそれでdo～whileの方が効率的になるケース示してみ do…whileの方が初回の判定がないから速いとしてもループ回数が多いと誤差レベルだし無限ループならコンパイラで最適化されて差がなくなると思う
4.3BSDのccを-Oなしで使った場合の話をまだしてるやついるのか
いろいろ誤解が多いので口出ししておく。
アセンブリ言語に手で変換してみるとすぐわかるんだが、
whileは先頭付近に条件分岐が必要な他に、末尾に必ず無条件のジャンプが必要。
対してdo-whileは末尾の条件分岐だけでいい。
このおかげでループ1回あたり命令実行が一つ減る。
しかしコンパイラはwhile文をif文とdo-while文相当に置き換えて最適化するから、差は出ない。
ヘボコンパイラなら最適化しないかもしれないが、
その場合は他の部分も最適化されるはずもないので、速度云々いうだけ無駄。
do whileは最後に条件を書くのが気に入らないので使わないです
使いどころを知らない自慢
forはwhileの上位互換だからwhileを使わない
ていうならまだわかる
>>282
1回目が必ず条件TRUEになることがわかっているwhileループ全て
話題は無限ループだけど >>286
> しかしコンパイラはwhile文をif文とdo-while文相当に置き換えて最適化するから、差は出ない。
if文？
do ～whileに置き換えて単に最後の条件文に飛ぶジャンプ命令入れるだけだぞ アセンブラのジャンプ命令や条件分岐の使い方が分かってない様子だね
ループ全体で命令が1回増えるだけなのにループ1回当たりの命令実行回数が増えるとか言ってるし
----gotoの使用例----
for (y = 0; y < 9; y++){
. . for (x = 0; x < 9; x++){
. . . . if (判定) goto break_loop;
. . . . 処理
. . }
}
break_loop:
----do whileの使用例----
if (FindFirst()){
. . do {
. . . . 処理
. . } while (FindNext());
}
>>291
> 1回目が必ず条件TRUEになることがわかっているwhileループ全て
それ1回目は必ず実行してその結果で2回目以降を実行するかどうかを決めるってことだよね？
典型的なdo～whileパターン w
むしろそのパターンでwhile(){}使ってるなら単なるアホとしか思えない >>293
昔の話をしてるなら>>286の前半読め
今の話をしてるならそんなことみんなわかってるからいちいちドヤるな >>296
それは実行結果でループ制御してるわけじゃないだろ
x, y の値はループに入る時には条件満たしているべきだからdo～whileなんて使っちゃダメ do whileってそんな語ることあるの？良くも悪くも単なる構文だと思うけど
ダラダラと長いループだと継続条件が下方に隠れるので嫌ってのはある
それ以外は正直どうでも良い
>>297
今とか昔とかじゃなくて...
PCのプログラムしかしたことが無い人は分からないだろうけど
組み込みのチープなマイコンのコンパイラは
いまだに糞なのはたくさんあるよ
あと、
様々な事情により最適化をOFFにして出荷する事もある >>299
単なる構文を無条件で悪とする人がいるって話 >>299
gotoも単なる構文だしね
あるものは便利に使っていこう 構造体はメモリのスタックとヒープのどちらに格納されるのでしょうか？
>>306
書き方次第でどちらにもなりうる。
ポインタ変数作って自分で malloc() 等で初期化すればヒープになる。
関数の中で stastc 付けたり関数外で宣言すると data や bss 領域になると思う。
関数内で static 付けずに自動変数として宣言すれば多分スタックになる。
しかし、必ずそのようなコードを作るコンパイラにしなければならないという決まりはない。 「C言語」の名前の由来はＢ言語の後継だからというのは有名だけど、Ｂ言語って何でＢ言語？Ａ言語はないのに。
>>309
BCPLってどんなん？
PL/Iなら知ってるけど。 へー、BLCLってぱっと見Fortranぽいね。
時代を感じるわ。
Ｃ言語みたいにnotationが基本lowercaseになったのって画期的だったのかもね
>>300
だからそういう話なら
> 昔の話をしてるなら>>286の前半読め
って書いてあるだろ
応用力ないのかよ w うちの会社って、まだHungarian notationを強制しようとする人がいるんだけど、make excessiveせずに説得するにはどうしたら良いでしょうか？
>>301
あんたにはないのかもね
別に全てに人に同意してもらおうとは思ってない
色々おかしい人はいくらでもいるし >>317
なんだよその不自然な英語混じり文は
なんか変わり者っぽいな >>320
これだろ
>whileは先頭付近に条件分岐が必要な他に、末尾に必ず無条件のジャンプが必要。
whileの処理構造ならループ開始直後に条件判定の個所に(1度だけ)無条件ジャンプしてしまえば、あとは条件分岐を繰り返すだけで無条件ジャンプを再び使うことはない
ぶっちゃけ条件判定が先頭付近にあろうが末尾にあろうが何処でもいい
(do-whileの構造だと必ず一度は処理を実行する必要があるのでそんなことは出来ないけど) >>321
日本人なんだけど日本育ちじゃないのでニュアンスをどう伝えたら良いのか分からないのですみません >>322
それがdo-while構造に最適化してるってことでは？ >>323
C言語のソースと直接対応させるならそのほうがその方が素直といえば素直だけどね
条件分岐命令はジャンプ範囲に制限があることがある(-128～+127byte程度)ので下手すれば多段ジャンプを強いられることがある
アセンブラレベルでギリギリの調整をするときはループ構造が制約されることもあるよ 条件分岐で飛び先を相対で1バイトで指定しなければならないがそれ以上飛ばしたいなら逆の条件で無条件ジャンプによるループを抜けるようにすれば良いだけでは？
>>327
その方が適切な場合であればそうする
結局のところコンパイラの吐き出したバイナリをアセンブラでチューニングするような状況だと少しでも所要クロックが少なく命令バイト長が短くなるようにロジックを弄るんだよ これはダメだ。もう何を言っても無駄だろう。
と思わせれば100点である、と。
関数分け
いまいち
STATE *state
const でいいところもconstが無い
COL/ROW
名前がサイズじゃなくて位置っぽい
board[x][y]
board[y][x]の方が良いことあるかも
key
ifの羅列よりもswitch case
ways
static constをつけよう
directions
return で8個orしてるのがいやだ
名前
規模のわりに名前が長い
srand
なんで何回もよぶ？
ROW *2 + 7
同じ式を何度も書かない
state
色の持ち方が変
黒 : user or com
白 : user or com
じゃないの？
directions
意味的にBOOLだよね？
>>345
なるほど
何故でしょうか
C言語にもBOOLがあるのですね UIとデータ処理を切り離せるといいね
内容的に、
C++のクラス設計のいい練習になりそう
>>347
切り離したつもりだったのですが不十分のようですね com/user が1人ずつ限定なら片方の情報は冗長
データ的にはどっちも黒とかどっちも白とか設定できちゃうので無駄な判別が発生したり
com vs com とか user vs user とか
comアルゴリズム1 とか
将来を考えても
白と黒に対してプレーヤーデータを持つのが良い
結局俺があらかじめ言ったとおりだろ。再掲するが
> あと、初心者はよく
> ・色々文法を知ってて、様々な書き方が出来る奴が偉い
> と勘違いしがちのようだが、これは明確な間違いだ。（これは他言語では本当に酷い）
> こんな糞どうでもいいところを様々な書き方をしているような奴は雑魚だ。
> 上手い奴は、そいつが決めたやり方に従って、一定の書き方で書く。 (>>170)
do-while 知ってる俺ツエーなんてやってるうちは初心者だし上達しない。
そういう勘違いしている奴も（特に他言語では）多いのも事実だし、Cですらそういう馬鹿が押し寄せてきた、というだけだが。
これも既に言ったが、
> なお、Goにはwhileが無い。廃止されて、forだけになっている。 (>>161)
お前らの定義ではGo言語を使う限り上級者ではないことになるだろ。
それはお前らの頭でもおかしいと気づけるだろ。
昨今の問題は、お前らみたいな馬鹿が嘘デタラメを書いて、全くの初心者がそれに惑わされてしまうことだ。
コードの美しさについて語るのなら、10,000行書けるようになってからにしろ。
というか、お前らは「オレオレ流美しいコード」のようだが、それも間違いで、結局の所、
美しいコード＝保守が楽なコード、でしかない。ある意味、これが定義だ。
だから大規模(>10,000行）のコードを数年保守すればいやでも分かるし、それをやらないと『自分の頭では』分からない。
だから1000行すら書けない初心者がコードについて語るのがそもそも間違ってる。
既に言ったが、1000行書けるようになれば、「コードの美しさ」について何を議論しているのか分かるようになる。
逆に言えば、それまでは一体何を議論しているのかすら分からないはずなんだよ。
「疎結合化しろと言われたから分割してみたけど、これって必要なの？」ってのが本音のはず。
そこを意識高い系馬鹿が「疎結合は正義」みたいなことを言うから、必要以上に細切れにして余計に分かりにくくなる。
それを揶揄したのが"FizzBuzzEnterpriseEdition"というわけだ。
実際、お前らも少なからずこれに近い状態だと思うよ。 あと、ゆとり馬鹿は goto 文に何故か惹かれるようだが、それも止めとけ。
それは goto 文ではなくラベルブレークが必要なだけであり、
Cではそれが goto 文でも書ける、という話でしかない。
なお、ラベルブレークはJavaScriptでは標準だ。（ただしあまり使われていない）
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Statements/break
ポイントは「break文自身がそのラベルブロック中になければならない」(α）という点だ。
今のリンターが「ある/ないでしか判定しないから一律禁止」の可能性はあって、
リンターの精度が上がって上記（α）の判定が出来るようになれば、その用法では許可されてもおかしくはない。
ただそれ以前に、何度も言っているが、こういうのに拘るのは止めとけ。上達を阻害する。
こんな小手先の「数行の見た目」を改善するテクニックより、既に言ったが
> それはメトリックスを増やしてしまう。（静的コールグラフ） (>>224)
とかの方が遙かに重要なんだよ。
こっちは大規模コードをメンテナンスでこねくり回さないと分からない。
さっさとどんどん規模を上げていくべきだ。
（俳句に拘っていてもラノベが書けるようにはならない）
10行しか書けない初心者だからこそ、10行内で改善が見える部分に拘る。
これ自体は自然なのだけど、
低レベルの実装コードを減らす努力はプログラミングに於いてあまり意味がないんだ。
俺の例で言うと、例えば check_func() 内が、goto文無しで15行、ありで10行で書けたとしよう。
だから何？でしかない。
既に言ったとおり、下位の実装コードなんてどうせ読まないし、読むときは名前と一致してるかだけ。
それが10行であっても15行であっても一瞬で読めるのだから、誤差の範囲。
flagが使ってあっても、「ああ、はいはい」だから問題なし。お約束的展開ならいいんだよ。
そんなことより、見慣れない意図不明のコードで？？？となって詰まる方が問題。
というか、初心者は『見た目でしか判断出来ないから』行数や文字数に拘ったりするけど、それが間違いで、
まずは「読むのにかかる時間」を最小にするように組むんだよ。 実はいま初めてプレイした
置ける場所「＊」が非常に見にくい
これいらない
現在の個数もいらない
最後に表示すればいい
強くするには、
マスに点数をつける
駒の点数と石の数と置ける場所の数をスコアとする
スコアの重みは序盤と終盤とで変える
数手先まで読む
終盤は最後まで読む
これだけで結構強くなる
ラベルブレークしたらラベルがFor文の頭にくるもんで読みづらい
ブレークしなかったときだけ値を変えるとかもやりづらい
おれはケツにGotoする
>>358
おける場所マークがにくくくて点数も要らないと感じるのですね
自分の感覚ではわからなくてその感覚を理解できなくて残念です
どうすれば人のてを借りずにそういうことがわかるようにできるのでしょうか >>359
それはラベルブレーク自体ではなく文法の問題だろ。
後置ラベルであれば問題なし。
TypeScriptもGoも型は後置だし、じきにそういう言語が出てくるかもしれんよ。
label: {} // 前置
{} : label // 後置
goto は自由度が高すぎるんだよ。だからリンターには嫌われる。
ただ、お前らが goto に拘るのはさっぱり分からん。
「禁止されたらからこそ使いたくなる」という若気の至りだとしても、ちょっと行きすぎてる。 dgt:
if(mmr!=00) free(mmr);
return mdr;
err:
mdr=1;
goto dgt;
printf("メンテナンス楽しくさせたる0x%o'",>>365); for (y = 0; y < 9; y++){
. . for (x = 0; x < 9; x++){
. . . . if (判定) goto break_loop;
. . . . int nico[x+1]=(8^0^8);
. . }
}
break_loop:
8進数使わないよね
0も厳密には8進数だけど
2進数の方が欲しい
コンパイラによっては使えたりする
あと16進数の小数
>>369
顔に見えない
可変長配列？
初期化変じゃね？ >>322
だから「前半」って書いてあるだろ
今でもしょぼい環境あるぞとか言われてもそんな特殊な環境出されても困るし >>286
>しかしコンパイラはwhile文をif文とdo-while文相当に置き換えて最適化するから、差は出ない。
while文をgoto文とdo-while文相当に置き換えて最適化する
の方が正しいような気がする なぜコンパイル後のアセンブリコードで話をしないのか
この辺LLVMとかだとどうなってるんだろうね
>>375
> whileは先頭付近に条件分岐が必要な他に、末尾に必ず無条件のジャンプが必要。
> 対してdo-whileは末尾の条件分岐だけでいい。
> このおかげでループ1回あたり命令実行が一つ減る。
>>376
もうそれ何度も指摘されてる >>373
わざわざ検索したの？
であなたならどうやるの？ . . for (y = 0; y < 9; y++){
. . . . for (x = 0; x < 9; x++){
. . . . . . if (判定){
. . . . . . . . [breakする場合だけ行う処理]
. . . . . . . . goto break_loop;
. . . . . . }
. . . . . . 処理
. . . . }
. . }
. . [ループ完了した時だけ行う処理]
break_loop:
. . [共通の処理]
例外処理にgotoが必要なんて話は
大昔から語り尽くされているのに
今さらドヤられても・・・・
>>379
お前は本当に無知なようだが、
この議論は昔からある有名な物で、結論も『既に』決まっているんだよ。
> No, don't spoil the fun with a break. This is the last remaining valid use of goto :)
> If not this then you could use flags to break out of deep nested loops.
> Another approach to breaking out of a nested loop is to factor out both loops into a separate function, and return from that function when you want to exit.
>
> Summarized - to break out of nested loops:
>
> 1. use goto
> 2. use flags
> 3. factor out loops into separate function calls
> Couldn't resist not including xkcd here :)
>
> enter image description here
>
> source
>
> Goto's are considered harmful but as many people in the comments suggest it need not be. If used judiciously it can be a great tool. Anything used in moderation is fun.
まさにこの通り。
その中でお前がどれを選択するかは自由だし、それは俺含めた他人の選択とは無関係だ。
○○を選択した俺ツエーとイキれる話でもない。
俺はお前がこの『既に結論が決まっている』話をどう持って行きたいのか分からない。
レス乞食なら死ね。 CにはJavaのArrayList、HashMap、TreeMapみたいなライブラリはないみたいですが、普通はどうやってデータを管理するのでしょうか？
そう言ったデータ構造を標準機能で使いたいならC++を部分的に利用するのが手っ取り早いのでは？
gccもclangもC言語処理系ではあるけどC++の処理系でもある
>>386
C++でできるのは調べました
純粋なCではどうしているのかが分からないので >>387
標準ライブラリにそんな機能はないよ
純粋なC言語でやるなら、すべて自前で作るか適当な外部ライブラリを探すしかない 世の中には便利で高性能なライブラリがあるからね。言語自体が機能を内包してた方が迷いはないかも知れんが。
標準ライブラリのhsearchとか誰も使わんな。俺も使わない。
>>383
C言語の話題はもうされ尽くしてるから
お前はこのスレに来なくていいよ
人間の結論も既に決まってる
死ぬ事だ >>389
標準ライブラリってISO/IEC9899:2011か？
hsearchなんてないぞ
bsearchか、もしかして
あれは確かにイケてない関数の1つだな >>390
C言語は50年近い歴史が既にあって、無知な新参がイキる余地はない。
イキりたいだけならJavaScriptかGoに行け。
あっちは馬鹿同士で楽しくやってる。 Cのコードを自動生成するようなフレームワークもあると思うけど
そういうのが出てきたらCプログラマって必要なくないか？
最近Cのプログラマが需要がないから減ってる気がする
>>388>>389
hsearchはHashMapみたいですが、確かに使いづらそう・・・
自作するってやっぱりCは初心者には厳しいですね
ちなみにこのスレの方々は自作しますか？それとも外部ライブラリ使う派ですか？
外部ライブラリ使うのであればオススメありますか？ >>393
https://www.tiobe.com/tiobe-index/
PC等、富豪プログラミングが許される状況では書く必要はなくなっていくだろう。
Cは必要なところのみDLLに切り出してピンポイント高速化でいい。
ただ、IoTの場合、速度＝バッテリの持ち＝小型化に直結するので、
今後ともCで書くのが主流ではないかな。
C++は結局の所、C程の速度は出ないし、DLLもイマイチなので主流になりきれなかった。
Rustが完全に立ち上がれば、Cが駆逐される可能性はある。
Javaがなんだかんだで主流なのは、いろんな意味でバランスが取れているからだ。 ピンポイント高速化とDLLも関係ないし
Cが使われるのはほとんどが小規模組み込み
逆に小規模組み込みはCしか選択肢が無い場合が多い
他の言語と競ってもあまり意味が無い
>>396
俺はstringとかarrayとか自作しちゃうかな
Cやるなら他言語の標準ライブラリぐらいは自前で実装できないと話にならないよ
何にもないからね 必要なもの（だけ）を作る
使いたいけどないなら作る
これがC言語
>>397
そういうことじゃなくて
C言語のコードを別の言語で書いて変換すれば
Cでかく必要ないじゃんってこと >>396
あえて言えばGlibとかですかね。機能は揃ってると思う。
オブジェクト指向っぽいCになれてないとつらいけど… 言語なんか関係ない
知恵遅れなｸｿがｺｰﾄﾞ書けば
ｸｿなｺｰﾄﾞになる
それ以外ない
すべて知恵遅れが原因
Cで例えばメモリを操作するコードが100行あるとするよな？
そのコードを作成するフレームワークがあるなら
それ使えばいいし、Cいらなくねｗｗってことな
いちいちな
試験もされてないような知恵遅れが作ったﾌﾚｰﾑﾜｰｸ（）
なんかつかわないからな
障害の原因
知恵遅れはまとな思考してれば
まともな人間なら書けないようなｺｰﾄﾞを平気で書くからな
やばいぐらい頭悪いｺｰﾄﾞを
それも息するように書くからな
しかもその自覚がない
ｵﾂﾑに致命的な問題がある
ｱﾙｺﾞﾘｽﾞﾑを実現するための言語の問題じゃない
ｱﾙｺﾞﾘｽﾞﾑなんかどんな言語でも実現できる
言語なんかただの方言だからな
Cが畿内の方言なら
C++はｴﾐｼの方言
Javaはｸﾏｿの方言
>>408
コーディングもアルゴリズムも数学も出来ない学歴コンプなアホは黙ってろ if文の中を抜けたい場合ってどうすればいいですか？
breakはforとwileを抜けるんですよね？
ifを抜けるには？gotoは使いたくないです
意味不明
if文の中ってどういうこと？
ただ条件式があるだけだろ
goto使え
宗教的に無理ならdo while (0);で囲んでbreak
switchならbreakで抜けれる
breakで抜けなければ、続きが実行される
>>402
意味不明。
わざわざCのソースコードを中間出力する意味ないだろ。
>>406
もしかしてCソースなら何でも速くなると思ってるゆとり？
>>413
意味不明。
> if文の中を抜けたい場合
これを他言語でいいから書いてみて。
多分お前は相当な馬鹿で、全てピント外れだと思うぜ。
自分では賢いつもりなんだろうけど。 むかしのc++はcのｺｰﾄﾞｼﾞｪﾈﾚｰﾀｰだったからな
昔あったinfomixのesqlもｲﾝﾁｷなcのｺｰﾄﾞ書くと、それをcのｺｰﾄﾞにおきかえて出力する
昔、大量のfortranのｺｰﾄﾞをcに変換しないといけなかったことがあるが
最初は自動変換したがとても読めるｼﾛﾓﾉじゃなかったから
ﾄﾞｶﾀに人力作業をお願いした
ﾄﾞｶﾀはこういうのは得意
cで書いとけば間違いない
なんにでも使える
luaからでも超簡単に使えてしまう
if や単なる {} をbreakで抜けられたら便利だと思ったことがある
この場合、多段 break もほぼセットで必要
break n
break if
break for
break switch
break while
break do
こんなのでもいいかも
名前付きループ
だとbreakやcontinueにも使えるけど
わざわざ名前を付けるくらいならgotoでいい
あいかわらず
低学歴知恵遅れは頭悪いこといってるわ
ﾙｰﾌﾟのbreakなのか条件のbreakなのか
ｺﾝﾊﾟｲﾗが解釈できない
ｺﾚがｻﾞ知恵遅れ
for (;;) {
if (!aho) {
break;
}
}
自覚がないｱﾎが治らないからｱﾎの仕様では無限ﾙｰﾌﾟから抜けれない
ｱﾎのまま無限ﾙｰﾌﾟ
ループならいざ知らず、ただの複文ブロックでブロック外に制御が行きつ戻りつする様ならもはや構造化プログラミングとは呼べない
立派なスパゲティプログラムだろう
コーディングもアルゴリズムも数学も出来ない学歴コンプなアホは黙ってろ
まず低学歴知恵遅れは低学歴知恵遅れの自覚がないからな
cの言語構造がどうなってるかすらわかってない
まずどう字句解析されて
どう構文解析されてるかすら分かってない
まあ致命的
低学歴知恵遅れがﾊﾞｶなこと書いて
どやがおしてるﾜｹだからな
相変わらず
>>426
戻るなんて誰か書いてたか？
ただのbreakだ
関数途中のreturnと本質的には変わらん break_if
とかにするならまだ少しは分かる
低学歴知恵遅れは単純になにもﾓﾉをしらなすぎる
ﾀｲﾑｿﾞｰﾝｽﾚでも同じように
>>397
> C++は結局の所、C程の速度は出ないし、DLLもイマイチ
どこ情報よ 顔真っ赤にしなくてもな
低学歴かどうかなんか
ﾚｽからすぐにわかっちゃう
残念なことに
>>396
あればなるべく外部ライブラリを使う
十分に使われてるなら自作よりそっちのほうがいい >>439
大差でおれに3連敗したアホ
4連敗確定にされたいか？ 15GBのテキストデータの解析速度
4倍の差
複数の数値データから上位3個を選ぶアルゴリズム
高速、非破壊、安定 / 低速、破壊、不安定
フィボナッチ数列の計算
計算式、計算アルゴリズム、コードいずれも大差
>>439の恥ずかしい書き込み
795 ：デフォルトの名無しさん (ﾜｯﾁｮｲ cf80-gYkF) [] ：2018/08/06(月) 23:39:21.68 ID:9v3Lf9b90
全然ずれてない
ｺｰﾙｽﾀｯｸの深さとぴったり一致してる
ｵﾂﾑが足りない知恵遅れのために
さらにﾑﾀﾞな補助出力をつけてやったぞ（AとB）
https://ideone.com/2vP2kN
ここまでくると
ﾒｸﾗやﾂﾝﾎﾞを誘導するのに近い。。。
↓この課題は、最終的には、ｺﾚにおちつくことになる
（なんでかは、nを増やせばきっと知恵遅れでも分かるとは思ってたからな）
https://ideone.com/eaJEjX
補助出力がないとなにやってるのかすら分からないﾒｸﾗやﾂﾝﾎﾞでは
ｺﾚがなにやってるかもきっと理解できないわ
u_l、u_r、u_yしかないからな
知恵遅れは再帰が理解できてないのが、よおく分かったわ 882 ：デフォルトの名無しさん (ﾜｯﾁｮｲ de80-oNxq) [] ：2018/08/11(土) 19:44:24.09 ID:17qcRus/0
で、>>881の結果に基づいて
一般項で処理するｺｰﾄﾞを書いた
https://ideone.com/QKTrLi
一般項で処理
やってみたが
一般項で処理なんかするとともかく遅い
6,942,482 bitsの一般項の計算で
お話にならないぐらいものすごい時間がかかる
calculation 6942482bits
f,10000000,35.082393,34.855636
g,10000000,0.722054,0.720584
つまり、結論としてﾌｨﾎﾞﾅｯﾁ数を求めるなら
GMPに用意されてる関数を使うのが一番
再帰階乗演算使う方がはるかにﾏｼ
一般項で求めるのはｳﾝｺ なんかしらんけど
よほど悔しいらしい
低学歴知恵遅れは
自己評価だけは高いからな
最後に本当に共通ライブラリより高速なロジックがはられてたが
それに対する彼のコメント
// ｱﾎが書いたｺｰﾄﾞ
// なにをやってるかは不明
ｵﾚはちゃんと
ｱﾎがｽﾚで書いたｺｰﾄﾞをwebｺﾝﾊﾟｲﾗで動かしたからな
ビット数がWebだと３２なのでそこで矛盾があっただけだった
ちゃんと作って張りなおされたやつは数千桁あっという間に求めるやつだったぞ
みただろ？
ｵﾚはしっかり低学歴知恵遅れが相当に頭悪いことを
しっかり 実 証 してるからな
半角君が劣化コピーして
if (32bit変数 & 0x8000000000000000)
がTRUEにならんとか騒いでたね
1~64まで足して
まず0x8000000000000000
になるとかないからな
ぱっと見で分かるﾚﾍﾞﾙだからな
相当な知恵遅れでなければな
>>455
低学歴知恵遅れに大差で3連敗するって
どんな気持ち？ かわいそうに
精神的勝利か
低学歴知恵遅れのｺﾞﾐｸｽﾞ人間が
まともな人間に勝てるﾜｹがないからな
>>458
n += n;
まだこんな簡単なコードを理解してないとは思わなかった
説明もしたのに
これが1から64まで足すコードに見えるってヤバくないか？ n = 0 (z)0 (f)0 (m)0 (aho)1
n = 1 (z)1 (f)1 (m)1 (aho)1
n = 2 (z)1 (f)1 (m)1 (aho)1
n = 3 (z)2 (f)2 (m)2 (aho)1
n = 4 (z)3 (f)3 (m)3 (aho)1
n = 5 (z)5 (f)5 (m)5 (aho)1
n = 6 (z)8 (f)8 (m)8 (aho)1
n = 7 (z)13 (f)13 (m)13 (aho)1
n = 8 (z)21 (f)21 (m)21 (aho)1
n = 9 (z)34 (f)34 (m)34 (aho)1
n = 10 (z)55 (f)55 (m)55 (aho)1
n = 11 (z)89 (f)89 (m)89 (aho)1
n = 12 (z)144 (f)144 (m)144 (aho)1
n = 13 (z)233 (f)233 (m)233 (aho)1
n = 14 (z)377 (f)377 (m)377 (aho)1
n = 15 (z)610 (f)610 (m)610 (aho)1
n = 16 (z)987 (f)987 (m)987 (aho)1
64bitとか以前の問題だからな
知恵遅れの脳内では987がunsigned intでｵｰﾊﾞｰﾌﾛｰする
当然
https://ideone.com/vhpLPV
851 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 0b50-2km2)[sage] 投稿日：2018年08月11日(土) 00時06分54秒68 [深夜] ID:N9ICkOCi0 [1/10] (PC)
10000進数多倍長
超単純なFFT
演算は乗算と加算のみ
誤差の感じから100000進数でも大丈夫そうですね
計算式は基本以下を多倍長にしただけ
多少の無駄は除いてますが
----
uint64_t f(uint64_t n){
n++;
uint64_t a = 1;
uint64_t b = 0;
uint64_t t;
for (int i = 0 ; i < 64 ; i++){
t = b * b;
b = 2 * a * b + t;
a = a * a + t;
if (n & 0x8000000000000000){
t = b;
b = a + b;
a = t;
}
n += n;
}
return a;
} 知恵遅れがどっかからｺﾋﾟってきたｺｰﾄﾞはってるわ
ｺﾚが低学歴知恵遅れが低学歴知恵遅れであることの 実 証 も含めた
ｴﾚｶﾞﾝﾄなﾚｽ
866 自分：デフォルトの名無しさん (ﾜｯﾁｮｲ de80-oNxq)[] 投稿日：2018年08月11日(土) 11時39分50秒69 [朝] ID:17qcRus/0 [1/7] (PC)
とりあえずかわいそうなぐらい頭悪いﾔﾂしかいないのは分かった
一旦、多倍長演算向けに3つの方法を評価する
ちなみにgmpの関数にﾌｨﾎﾞﾅｯﾁの関数がついてる
きっとこの速度にすら届かないと考えられる（まだ動かしてない）
↓多倍長演算使ってない3つの方法の簡単なｺｰﾄﾞがｺﾚ
https://ideone.com/vhpLPV
※ ｵﾏｹでｱﾎが書いたｺｰﾄﾞ(>>851)も入ってる
※ ｵﾚの適切なありがたい注釈がついてる
1.ひたすら足し算
2.一般項
多倍長演算をするまえに適切な精度を設定しないといけない
どれぐらいの精度にすればいいかがまだ未解決 ※ とりあえず2回計算することでいけるような気がしないでもない
3.再帰階乗演算
https://www.ics.uci.edu/~eppstein/161/960109.html
探した中でｺｲﾂが一番いい感じがする
> This is a recursive algorithm, so as usual we get a recurrence relation defining time,
> just by writing down the time spent in a call to matpow (O(1)) plus the time in each recursive call
> (only one recursive call, with argument n/2). So the recurrence is
> time(n) = O(1) + time(n / 2) webｺﾝﾊﾟｲﾗで動かしてみ
まちがいなく動かない
>>470のリンク先は勝手に半角君が変数を32bitに変えちゃったんで動かないだけ
>>470に直接書いてあるコードはそのままで正しく動く 劣化コピーっていうか
わざわざ書き換えてるじゃねーか！
釣りだった
…ほかがunsigned intだから関数名変えるついでに一緒に変えちゃったのか
これは訴訟レベル
>>474
サマータイムのスレとかでも一人空回りしている。
いや、時々変なのも絡まって巻き込んで空回りしてるか。 >>396
俺の場合はCを使ってMapみたいなものまで使わねばならないほど膨大なデータを扱うことが
滅多にないのでだいたいは不要。数百から数千のデータのキーでの検索なんか何も考えずに
ループさせて全検索してしまう。億単位のデータの処理が必要な場合は(だいたいはCではない
言語を使って)RDBにデータを入れてやるかな。その方が楽だから。
ああ、でも、昔 dbm ライブラリとか使ったことあるなあ。半端に多い場合はそういうので良いかも。
今だと Linux ディストリビューションとかは最初から gdbm ライブラリ入ってるの多いと思う。これね。
https://linuxjm.osdn.jp/html/GNU_gdbm/man3/gdbm.3.html >>413
> if文の中を抜けたい場合ってどうすればいいですか？
抜けようとしなくても抜けるので何もする必要はない。 半角さんは、巷にあふれるただのマウント野郎とは違って、きちんとソースを出している
唯の者ではないと思います
コード保守でのバグはこうやって生まれる
うっかりミスの見事な事例がまさかこのスレで見られるとは思ってなかった
>>484
コードを出しゃ良いってもんじゃない
自分の劣化コピーのせいで動かないコードに対して
今回だけでもこれだけ書いてるから
>>451,458,465,468,470,472,476 2ちゃんねるでしか自己主張できない低学歴知恵遅れが
なんか必死になってるわ
わかりやすいわ
ﾎﾝﾄ
>>442の1個目3個目は相手が悪かっただけ
としても
2個目は初心者用の課題に対して
初心者が普通に考えるよりはるかに悪いアルゴリズムを選んでおいて
「これを選ばないヤツは知恵遅れ」発言の連投だから
1個目も3個目も言ってることはコロコロ変わるし
「こうしないヤツはアホ」発言をして
自分で変えてるし
>>432も頭おかしいだろ 働いてはいないがニートと呼べるほど若くもない
早期退職で悠々自適生活の元組込みソフト開発者だよ
是非別スレでやって欲しい
スレ数はいくら使っても良いから
ｵﾏｴなかなか分かってるわ
ｵﾚのﾚｽも文字列的には長い
しかし、中身が濃いから、情報価値も高い
つまり価値が高い情報を継続して提供している
ｸｿﾆｰﾄの長文は情報価値ｾﾞﾛ
中身ｽｶｽｶ
ただの落書き
>>493
フリがなかなか分かりにくいんだけど、そこ笑うとこ？ ｵﾚに敗北はない
このｽﾚのｸｿﾆｰﾄにも敗北はない
ただｺﾚには違いがある
ｵﾚは正面から戦う
ｸｿﾆｰﾄは戦わない
ｺｲﾂﾗは身をひそめながら遠くからとりあえず石投げる
この違い
>>496
ああ、ごめん。
一生懸命ネタ振ってたのね。でもネタフリにしてはあんまり面白くはないかな。
ただ俺はそんな一生懸命なお前嫌いじゃない（笑） 一日でこの板に少なくとも 23 回「低学歴知恵遅れ」って書いてるね。
どれだけ拗らせてるの?
いやぁ、今どき職場で「低学歴知恵遅れ」なんて言ってくる上司がいたら
ネット掲示板で同じセリフを繰り返すより、録音して訴えるだろ。
それにしても、まるで署名のように必ず投稿文に盛り込むから、
何か隠された意図があるのでは、と深読みしてしまうのも事実。
単にクセになってて本人には意味の薄い間投詞になってるのかも知れんけど。
…読み取れないとガッカリなので一応書いておくけど、
「いくら匿名の電子掲示板でもそういう言葉遣いは良くないよ」と
たしなめている(忠告している、の方が受け入れやすいかな)つもり。
低学歴底辺のｸｿﾆｰﾄ、そして底辺ﾄﾞｶﾀなのは
図星なんでしょ
人間をﾎﾝﾄのこといわれると
必死になる
残念なことに
低学歴かどうかとか
知恵遅れかどうかとか
ｸｿﾆｰﾄかどうか
底辺ﾄﾞｶﾀかどうか
ﾚｽからすぐに分かってしまう
まともに人間がみればすぐに分かる
ｷﾐﾗはなまとなに人間未満のｺﾞﾐｸｽﾞなﾜｹ
その自覚すらない
だからまともな人間にすらなれないわけ
わかった？
半コテって一番タチ悪いな
コテハンつけろよNGにするから
本当は夏休み中の中高生じゃないのか？
何だか妙に精神年齢が幼く思える
図星でしっかり反応してるしな
やっぱりなこのｽﾚは
駆除が必要な典型的な低学歴知恵遅れの
ｸｿﾆｰﾄとか底辺ﾄﾞｶﾀしかいないわ
>>508
確かに夏休み始まった辺りから見かけるようになった気がする >>499
このスレだけなら 35 だが、この板全体の数なんだ。
必死チェッカーもどきを見たら堂々の 2 位で笑った。
いや、彼の御高説をもっと見たかったんだ。
ちなみに「知恵遅れ」はその 23 とは別に単独で 16 回出てきたよ。 >>413
if (条件) {
…
…
ここで(ブロックから)抜けたい -(1)
… -(2)
} else { … }
こういうこと？ (1) はさらに if で条件付で分岐しないと意味がないけど…
※ (1)で分岐しないかぎり (2) 以降が無意味のコードになる
if の外側を do { } while(0) で外を囲って break; したら？ >>516
それだったら2を実行するための何らかの条件がある筈なのでそのためのifブロックの中に2を入れればよい。
そつではなく無条件に2を実行したくないならばソースから削除するかコメントにでもすればよい。 すまん。スマホでフリック入力しててタイプミスした。
>>519 意図は伝わったぜー
確かにｗ
if (条件1) {
…
if (条件2) { … -(1) } else { … -(2) } >>519
そりゃ方法なんていくらでもあるよ
そういう方法をとりたくないってことだろ
理由はしらんが
たとえば(-2)が大きくてインデントを変えたくないとか だから何でdo while(0)なんて変態コードに固執するんだよ
元質問者に聞くしかない 「goto は使いたくない」の条件で
ブロックというものを中に入ったら出られないものと勘違いしているとか。
最初にforやwhileを覚えちゃって勘違いに繋がったとか。
何人たりともforより先に関数のブロックを憶えるのにね
関数のブロックだけが何か特別なものと思い込んでるケースが多い
goto 便利だけどなぁ。
break するがためのフラグ作って何ブロックも break するとか goto を避けるがためのいびつな if を連続させるとかよりよほど可読性が高い。
もちろん意味を的確に表したフラグやifの構造にできるに越したことはないけどさ。
>>523
あえて固執して解決方法を編み出しておくと
ひょんなときに役立つことがあるしな
準備なんてのは9割無駄で当たり前だよね ジャクソン法やワーニエ法みたいに
データ構造とプログラム構造を一致させる構造化プログラミング()では
データが損傷していた場合にはプログラム構造を一致させることができない
よって構造化定理を諦めたアプローチをせざるを得ない
こういうのがgotoやlongjmpの出番
>>529
その説明じゃ変態行為に固執する理由が説明できてないだろ
ええ加減にせんか、この変態！ ま、Cの場合は適切にgoto使った方が良いだろうな。後から作られた言語では break でラベル指定できるだの例外処理できるだのしてるから使わなくて済むようになってるわけで、それのないCはそれの代わりにgoto利用しちゃった方が分かりやすく書ける。
いやCのgotoは制限がキツすぎて
いざという時には役立たず
だからlongjmpがある
そんな制限キツかったっけ？
longjump の方がキツいでしょ
setjump/longjumpは簡易タスクディスパッチャーをC言語だけで実現するためだけにあるのかと思ってたよ。
それ以外の用途はあんまり思い浮かばないなぁ。
自分で対処不能なエラーが起きたときに、初期化してやり直す時に使ったな
だもんで通常の処理の流れで使うものだとは思わなかった
ディスパッチャとしてはダメダメじゃん
jmp_buf jb;
void sig(int n)
{
longjmp(jb, 1);
}
int main(void)
{
signal(SIGINT, sig);
if (setjmp(jb) == 0) for (;;) ;
else puts("ok");
return 0;
}
俺んとこではokが出ない
おまいらんとこではどんな結果になる？
確かsignalとlongjmpは相性悪かったような？
よく覚えてないけど。
>>538
こちらは Linux (CentOS7)だが、出たよ。 >>539
sigsetjmp(), siglongjmp() ってのがあるので、そっち使った方が良さそうではあるな。 Linuxとかならpthreadがあるのでわざわざ自分でディスパッチャ作ることはないと思うけど、組み込み用に簡易的に作ることはあるかもね。
俺は組み込みならprotothreadsのほうがシンプルで好き。
#include <signal.h>
void (*signal(int signum， void (*sighandler)(int signum)))(int signum);
この宣言が読めない
signal 関数名
signum 第1仮引数名
sighandler 第2仮引数名
sighandler ポインタ
*sighandler 関数
signum 第1仮引数名
signalの返却値はsighandlerと同じ型
>>524
思い浮かばないってのがなかなか考えられない
ていうか、
for/while/do while 以外もbreakで抜けられたら良いと思ったことが私もある
>>525
なぜgotoは使いたく無い？
という質問の答えも聞いておかないと
コーディング規約なのか宗教なのか
gotoの使い方を知らないだけなのか >>536
OSのタスク切り替え処理
ブートローダーからアプリケーションへのジャンプ
リセット
例外処理 >>546
全て別の方法で実現しちゃうので、俺的にはlongjmpの必要性を感じないかな？ まあデータの損傷をいきなりデータ構造そのものの破綻に結びつけるのは些か強引な論理展開ではあるな
>>547
関数ポインタ
アセンブラ
スタック書き換え
このどれか？ >>550
こんな感じ。
OSのタスク切り替え処理
→普通にOSの機能を使う、カーネルなしで簡易ディスパッチャ実装はpthread
ブートローダーからアプリケーションへのジャンプ
→アドレス固定ならアドレスを関数ポインタにキャストしてジャンプ、またはインラインアセンブラ
リセット
→周辺機能やbssやdataセクションも初期化したいのでWDT等のCPUリセット機能を使う
例外処理
→密結合を避けるためオーソドックスに返り値で判定、最後にgoto使うかも？
そういや例外処理longjmpで思い出したけど、一昔以上前のCマガジンにマクロでC++と同じようなtry～catch構文実装方法の記事があったけど、確かにそのマクロ内ではsetjmp/longjmp使ってたわ。
マクロでカプセル化してれば例外処理で使うかも。 >>552
あ、まちがえた。
pthreadじゃなくてprotothreadsね。 あ、レスして気づいたけどcoutがあるってことはc++なのかな？
まあこれはprintfってことにしといてくださいｗ 重複質問になりそうなのでこちらで処理したい。
newもC++のキーワードなんだけど。。
関数に実引数のポインタを渡すとその値が、対応する仮引数に代入(コピー)され、以後、仮引数は変数のように使える。
仮引数の値を変えてもコピーが書き換えられるだけで元の実引数の値には影響しない。
書き換えられるようにするには、書き換えたい場所のアドレスを渡して、*演算子か、[]演算子を使わないといけない。
駄目な例のa = new char [8];はmainのaの複製への代入なのでmainのaはNULLのまま
良い例の*a = new char [8];はmainのaそのものへの代入なので期待した結果が得られる
関数呼び出しのとき、実引数がどこにコピーされるかというと、「スタック」という積み上げ式のメモリーブロックか、一時的なCPUレジスタが使われる。
インラインではない関数呼び出しにおいては、関数の戻り先のアドレスと、仮引数のデータがスタックに積み上げられる。
積み上げ式だから、自分自身の関数を呼び出しても動作する。これを「再帰呼び出し」という。
スタックの積み上げには限度がある。限度を超えると、スタックサイズが拡張されたり、異常終了する。
スタックの積み上げが限度を超えて異常な状態になることを「スタックオーバーフロー」という。
すません。私の質問が曖昧だったので追加で
void setStr(int *a) {
a[0] = 10;
}
int main() {
int a[10];
setStr(&a[0]);
cout << a[0] << endl;
return 0;
}
例えば、この場合は、setStr(&a[0])として、その後、関数内でa[0]=10;と値を代入すればちゃんと 10 が出力されます。
前のHPの失敗例も同じくsetStr(a)としてアドレスを渡し、受け取りはポインタ変数なのに値は変わらない。
単に数値か文字列かの違いなんでしょうか？
とりあえず一度、配列とポインタに対する余計な先入観を捨てて素直に元サイトを読み込めば理解できると思うよ
一つの考え方に囚われ過ぎてると思う
void setStr(char **a) これを
void setStr(int *a) こう読み替え
char *a = NULL; setStr(&a); これを
int a = 0; setStr(&a); こう読み替えてみそ
つまり char* → int と読み替えるんだ
ポインタ変数とアドレスは違うという話は
整数変数と整数は違うという話と同じだ
ああ分かった！
俺は自分で勝手に「char型のポインタ=文字列だ」と思い込んでて、そのせいで混乱してただけでした。
思い込み怖い・・・
void setStr(char *a) {
a[0]='a';
}
int main() {
char a[] = "test";
setStr(a);
cout << a << endl;
return 0;
}
これで「aest」と表示されたからピンときた。確かに失敗例はポインタ変数を渡しているだけだｗ
ありがとうございました。
>>563
そりゃそうだよ、世の中にはスタックを持たないマシンもあるからな ハードウェアスタックを持たなくて再帰呼び出し出来ないうんこ環境があるね
そういうのは自分で値を積み上げるように作るしかないな
そういえばずいぶん昔に昔ながらのBASIC言語でクイックソートを実装したときに当然サブルーチンの再起呼び出しなど使えないので
自分で似たようなことをやったなあ
というか確か何かのプログラム認定試験の定番の出題テーマだった気がする
当時必死に勉強してたことを思い出した
>>571
そんなアホな…
うわ、ホントだ。汎用レジスタは全て外部RAMにマッピングされてたのね。 制御記憶を主記憶とシェアするアーキテクチャはそんなに珍しくない
普通にR0とかのレジスタ名ついてるんだけど実体は内蔵RAMにマッピングされてるアーキテクチャならよく見るけど、外部RAMってのは初めて見たわ。
今もこういうアーキテクチャのCPUあるのかな？
>>576
wikipediaによると
ROM 内蔵20Kバイト RAM CPU内蔵256バイト/TMS9918用16Kバイト
だそうだ。 >>573
制御記憶ってマイクロコードを入れるところなんだが…
主記憶と共用してる奴なんてあったか？ >>578
必ずしもマイクロ【コード】を入れるところじゃないんだけどね
たとえばメインフレームではDIAGNOSE命令で制御記憶を目的外使用なんてのをやってたよ
それやってるときはTestインジケーターが点灯することになってて >>579
> たとえばメインフレームではDIAGNOSE命令で制御記憶を目的外使用なんてのをやってたよ
そんな特殊な例出されてもなぁ w
そりゃ記憶装置だから他の物を入れることはできるよ
だから何？ って話だけどな
> それやってるときはTestインジケーターが点灯することになってて
で、主記憶と共用ってどこのアーキテクチャなんだ？ メルトダウン事件移行もアップデートの度にどんどんコンパイルとか画像縮小なんかの処理が遅くなってる気がする
もう怖くて淫照は買えない
>>582
そりゃなるよ
命令の動作を書き換えるんだから何でもできちゃう
なのでDiag関連の命令はCE（カスタマーエンジニア）モードでしか使えないとかなってたはず
今時のCPUでもエラッタ対策としてマイクロコードの書換えするけどコード自体は暗号化されてる
この暗号化キーが漏れたらえらいことになると思う マシンによって違うのか？
M-180HはCEモードでないと動作しなかったが
そういうことだね
俺んとこではPWOFFするオウンコードとかできたし
すみません思い切り初心者の質問です。
printf("%s: abc", str);
↑こういう文が abcのみが変わる形で（str変数は変更されません）
沢山登場するプログラムを作っており コピペが面倒だしバグの温床になりそうなので
#defineマクロなどを使って引数にabcを指定すると上記の文がまるごと出力されるようにしたいと思いました。
そこで
#define PR_POS(_pos) printf("%s: _pos", str)
という定義を作ったのですが恐らく引用符の中身は変更されることはないので
#include <stdio.h>
#include <stdlib.h>
#define PR_POS(_pos) printf("%s: _pos\n", str)
int main(void) {
char str[256] = "text";
//printf("%s: abc\n", str);
PR_POS(abc);
exit(EXIT_SUCCESS);
}
というプログラムを作っても実際コンパイルしたものを実行すると
text: _pos
という望んでいない出力が返ってくるだけです
これを
text: abc
という出力にするにはどうすればいいでしょうか……。
>>591
#define PR_POS(_pos) printf("%s: " #_pos "\n", str)
でいけるはず
詳しくは
プリプロセッサ 文字列化演算子
とかでぐぐれ #define PR_POS(_pos) printf("%s: " #_pos, str)
>>592
うわあああ！ ありがとうございます。
正直 検索しても検索しても一向にそれらしき答えが見付からなかったんで
もう方法がないのかなとか思ってました……。
文字列化演算子なるものがあるのですね。用語まで教えていただいてほんとうに感謝しています。
しかもC99でも定められてるっぽい？
（gcc -std=c99 -Wall -Werror -pedanticで警告がなかった）
嬉しいです。これで随分すっきりしたソースコードになりそうです！
>>593さまもありがとうございます。 #include <stdio.h>
#define DEBUG(fmt, ...) \
fprintf(stdout, "%s:%d #%s " fmt "\n", \
__FILE__, __LINE__, __func__, ##__VA_ARGS__);
初心者ならこのマクロを覚えておくと良いぞ。誰もが一度は使うはず。
>>595
> しかもC99でも定められてるっぽい？
X 3010：2003 (ISO/IEC 9899：1999)
6.10.3.2 #演算子
制約
関数形式マクロの置換要素並びの中にある各#前処理字句の次の前処理字句は，仮引数でなければならない。
意味規則
置換要素並びの中で，仮引数の直前に#前処理字句がある場合，対応する実引数の前処理字句列のつづりを含んだ一つの単純文字列リテラル前処理字句によって，#前処理字句と仮引数を置き換える。（後略）
http://kikakurui.com/x3/X3010-2003-01.html >>596
すいません。初心者なのにめちゃめちゃ上から目線みたいになってしまうんですが
assert()を使わないのはなぜですかね。
POSIX C99でも定義されているので ほとんどどのコンパイラでも処理できると思うんです。 >>598
マクロの紹介だけだから。
デバッグ方法としてならassertを多用したほうが良いぞ。 フィールドのエラーログ用に>>596みたいなコードをリリースバイナリにも埋めることがあるけど
その場合はassertじゃ役に立たないんだよな。 斜め読みだけど、abcが変わってstrが変更されないならabcの方を文字列変数にしてprintfすれば良いんじゃね？
>>596
可変長引数マクロはgccだけって記憶があったけどC99規格で使えるんだね。
「可変部の実引数が0個の場合に……」のgcc拡張とゴッチャになってた模様。
>>598
警告を表示しても動作を止めたくない場合には重宝するよ。
デバッグ中に「ここまでは処理が通過した」と確認する時とか。 >>602
なるほど。
assert()関数だと引数の結果が0の場合問答無用で停止してしまいますもんね。 本番のコードと差が出て邪魔なのでassertはあまり使いませんね。
どうせデバッガ使うというのもあるし。
>>604
本業の方の意見はほんとありがたいです。
コンパイルエラーと違ってassert(3)は実行時にエラーを吐くので同じ「実行するときに診断する」プログラムでassert(3)より高機能なデバッガ（GDBとか）を使うということですか？
---
>>591の処理ですが以下のように書き直したところ望み通りに動きました。
みなさまありがとうございます。感謝します。
#include <stdio.h>
#include <stdlib.h>
#define PR_POS(_pos) printf("%s:" #_pos "\n", str)
int main(void) {
char str[256] = "text";
//printf("%s: abc\n", str);
PR_POS(abc);
exit(EXIT_SUCCESS);
} assertの使い道って「ここでは必ずhogeになる！」という意志をコードに残すという意味はあるかな。
言ってるとおりで動かすときはgdb使うし、開発中は単体テストで同等以上の確認するしで、実用性は今はあまり無いと思いますね。
本番コードでもassert使うかな
ハードエラーみたいなのはカバーしきれない
>>606
> assertの使い道って「ここでは必ずhogeになる！」という意志をコードに残すという意味はあるかな。
assertion の意味は主張だからむしろそれが正しいとも言えるな
> 実用性は今はあまり無いと思いますね。
最初作るときはそうでも改修時に全然触ってない所のassert()に引っかかることもあるから俺は基本入れてる int a = 42;
a = a++;
↑これがコンパイルエラーになる理由って
「左辺aに対する代入と右辺aに対するインクリメントのどちらの演算を優先して処理するか不定である為」
で合ってますか？ 不定じゃなくて未定義かも……。
>>611
あれ。すいません。よく分からなくなりました。
$ gcc -pedantic -std=c99 -Wall -Werror -O2
でコンパイルするとエラーになり停止しますが
$ icc -std=c99 -Wall -Werror -O2
でコンパイルするとあっさり通りますね……。 >>610
未定義っす (>>1 C FAQ の 3 章を参照してください)
蛇足ながらシーケンスポイントの間でオブジェクトを変更できるのは高々１回だけとか、そんな感じのルール
>>613
gcc の -Werror オプションは警告をエラー扱いにするっす >>614
ありがとうございます。
ちなみにicc (Intel(R) C/C++ Compiler)で-Wallおよび-Werrorオプションを設定したときは
警告もなにも出力されることなくコンパイルに成功してしまったんですが
理由とか分かりますかね。すいません。変な質問で……。 >>614
あと，おっしゃる通り（すくなくともC99では）未定義でした。ありがとうございます。
> 直前の副作用完了点から次の副作用完了点までの間に，
> 式の評価によって一つのオブジェクトに格納された値を変更する回数は，高々1回でなければならない。
> さらに，変更後の値の読取りは，格納される値を決定するためだけに行われなければならない。
（JIS X 3010:2003 p.48; 参考 
） >>610
そういう文法的になことには今は拘らない方がいい。(これは他言語学習者の方が酷いが)
上達の妨げにしかならない。
プログラミング言語は、「正しく書いたときに正しく動作する」ようにしか設計されていない。
特にCはそうだ。
意味不明なことを書いたらだいたい全て「未定義」であり、
意味不明なことを書く奴が悪い、ということになっている。
そしてそれが「未定義」と覚えることも、実質的な意味はない。
そんなコードはすぐに修正され、存在しないからだ。
実際、 a = a++; なんてコードは、どのOSSにもないはずだ。
この意味で、Cは全くの素人の入門者用ではない。
例えばC#はそこら辺厳しい言語で、そういった意味不明な書き方は全てコンパイルエラーにされるはず。
（さすがにその例では知らんが、例えば「未初期化の変数を使用」とかがエラーになる）
というか、マジでそのレベルならC#やった方がいい。
文法エラーなんてサジェストが出てOK押したら自動的に修正してくれる。
お前がどんな環境でやってるのかは知らんが。
ただ、こういった無駄な遠回りをしなくて済むだけでも、君にとってC#は有効だと思うよ。
つか、初心者は全ての文法を押さえないといけないと勘違いするようだが、それは間違いだ。
自分が使うだけの文法を押さえ、さっさと使うべきだ。
お前だって日本語の全ての漢字が読めるわけでもないのに日本語を使ってるだろ。
プログラミング言語も同様で、手段でしかないのだから、文法を一通り確認したら、
さっさとゲーム等何でもいいから作れ。
ネタがないのならそれはそもそも今プログラミングを学ぶ必要がないとも言えるし、
それでもやりたいのならラズパイでも買ってきてLEDチカチカでも目指せ。
文法を学ぶことが目的になってはいけない。それは完全に空回りだ。 やりたいことはシンプルに書けよってことだな。
最終的に a にどうなってほしいのか、それってもっと端的に書けないの？ってこと。
Cオタクになるのが目的じゃなければな。
(ちなみに補足)>>610
初心者には理解不能だと思うが、
「文法で許されていることが全て許される」環境なんて実質的に存在しない。
だから文法のコーナーケースについてはそもそも覚える必要がない。
(とはいえ、肝心のK&Rがフリーダムすぎて…ってのはあるが)
これは小説→ラノベの流れと同じで、
美辞麗句の技巧に走る必要はなく、簡単な文を書き連ねて面白い筋を書け、ということ。
プログラミングにおいてはこれが徹底していて、
同じ物なら、簡単な方が『常に』いい、ということになっている。
ただ、どこからが複雑なのか？というのは議論になる。
例えば自然言語で韓国が漢字を廃止した際、
「停留所」を「ばすが とまる ところ」と書き換え、老人が「舐めとんのか！」と切れた。
実際、全員が読める漢字を「もっと簡単に」という理由で平仮名に書き換えられても困るだろ。
丁度これと同じ（だが方向は逆）で、
新しいプログラミング言語は比較的すんなり書ける文法が用意されており、
それを使うべきかどうかでは揉めたりしている。
ただ、Cは古いのでまどろっこしい文法しかなく、ベタな書き方しか出来ない。
だから比較的この論争に巻き込まれることはないはず。
（それ以前に文法セット自体が小さくて、え？これだけ？のはずだが）
>>619
天然と養殖では学びのベクトルが逆なんだよな。
天然： 1を足したい → a++ と書くのか
養殖： a++と書くと → 1が足されるのか
結果、要因側をenumすると文法一覧になるのが養殖で、これが間違いの元だ。
そしてそれを馬鹿正直に一つずつ潰すから文法エリートになっていく。
そうではなく、要因側のenum結果はやりたいこと一覧になって、全部揃えばゲームが作れる！が正しい。 >>620
ちょっと反論があります。正直Cどころかプログラミング初学者なのですが……。
要するに私は〝養殖〟であり，そのような学び方では成長しないと仰りたいわけですよね。
まあ確かに自分でも「規格厨」というか，衒学的な性格をなのは自覚してます
しかしプログラミング言語というのは自然言語とは違う面が多々あると思います。
そして「文法を網羅すべきか」という点においては特に違うと思います。
プログラミング言語は少なくとも概念においては文法に正確に従えば定められた動作を確実に行ないます。
日本語の文法を遵守して話しても考えが伝わらないのとは全く異るところです。
だから私はプログラミング言語においては先に（かなり厳密に）文法を学ぶべきであり，
「文法を学ぶ」ことのなかには未定義動作に関する諸々の知識を習得することも含まれていると考えます。
偉そうにすいませんでした。まあ上手くいかなければまた考えを改めるつもりではいます。 やりたいことを素直に書いたつもりで未定義な文法になってしまうなら、もっと論理を考えた方がいいかも。
やりたいことを行う手順を整理できてないってことだと思うよ。
a = a++; ということが結局どういう動作するのかを知ることより、何をしたくてそういう（矛盾をはらむ）書き方になったのかを自己分析した方がいい。
もちろん基本的な文法は勉強しておく前提はあるよ。
おれは養殖とか天然とかは分からんけど。
Cは文法的にはコードのデザインをほとんど規定しないからね。
そういう意味では頑張って覚えるほどでもない。まあ量も少ないので覚えてもいい。
でも古いコードとの互換性にこだわる様なおっさんにはならんでくれやという感じ。
>>621
あなたの言うことにも一理ある。
でもこの板にいる人は1つの言語しか使えない人って少数派で、たいていは3、4つまたはそれ以上の言語を操るマルチリンガルな人が多いと思う。
んで、その人たちはどうやって新しい言語を使えるようになるかって言うと、1つの言語をマスターすると(Prologとか特殊な言語は除いて)他の言語も方言みたいなもので、書き方の問題だけなことが多いのね。
その際には特定言語の重箱の隅をつつくような知識が必要なわけではなく、むしろ最大公約数的な知識、もっと言うと言語に依存しない設計力のほうが大事になってくる。
なので、特定言語のあまり細かいルールにこだわり過ぎないほうが良い、という経験論での意見は間違ってはないと思うよ。 そうそう、しいて文法を覚えるなら適切に const を指定するクセを付けてほしいな（const に限った話ではないんだが）。
文字列を引数で受ける箇所全部が char* になってるコードを見るとクラクラするw
>>621
反論自体は自由にやればいいんだよ。それが匿名掲示板のメリットなのだから。
ただ、書かれている内容については吟味しないといけない。
その中には君にも峻別出来る内容もあるはずだから。
(というか、こっちが君にも分かる範囲で《客観的な範囲で》話せばいいのだが)
事実から言うと、C言語は『当初から』バリバリの実用言語であり、今も現役だ。
これは同世代の他言語とは全然違う。
だから、普通に書いてれば「未定義」なんてのに命中するはずがないんだよ。
そんな言語、使い物にならないだろ？
次に、歴史も長いのだから、何をどうやったら嵌るかのノウハウも溜まっている。
それの集大成がコーディングルールであり、例えば goto 禁止論だ。
これについても是非はあるが、これまでの経験をタダで享受する気なら、乗った方が得だ。
そしてそれに従っておけば大体全て「未定義」は回避出来る。
具体的に言えば、警告レベルを一番か二番目に厳しい状態で使って、警告についてはほぼ全部直し、
google等「コードを実際に書いている連中」のルールに従って書けば、そもそも未定義なんて踏まない。
それらはそのように整備されているから。
業務で「コーディングルール無し、警告も全部無視してよし」なんてのはあり得ないし、
仮に個人レベルでそうでもバグが取れなくて無駄に苦労するだけ。
だから結果的に「未定義」なんて気にする必要ないんだよ。
一般的な環境で普通に書いてれば命中しないし、知る必要もない。
一通りも書けない初心者なら特にそう。他にやることはいくらでもある。
君は休日にプログラミングをやろうとしているのだから、本来は「天然」なんだよ。
それを自分で「養殖」型のカリキュラムにして、無駄に上達しにくくなってる。
そこが勿体ない。
君が何の為にCを学ぶのかは知らないが、もっと直接的にその結果を目指すべきだ。
とりあえず学ぼう、では全く上達しないんだよ。
それは日本人の英語でもそうだろ。使わないと上達しないんだよ。 >>624
確かにそうですね。先に述べた通りプログラム全般に暗いのですが
JavaやPythonなども大まかな構造（サブルーチンとか演算体系とか）は
似ているかなと感じました（見当違いなこと言ってるかも）。
もっと抽象的な立場になったほうがいいですかね。
>>625
アドバイスありがとうございます。
ggってみたところconstはその重要性の割に実務で使われていない傾向にあるみたいですね。
しかし役割を考えると，特に保守の面で，積極的に使うべきだなと確信しました。
「ここは固定された値代入を想定している」という意図を明確にできるってことですよね？ >>626
そうですね。
動くプログラムを作っていたらa=a++;なんていう文は登場することはないですね。
お察しの通りプログラマーでもなんでもない独学状態なので，
そういう人間が犯しがちなミスを防ぎたい一心で規格や文法などを厳密に勉強すべきと思っておりました。
C#についてですが，こういう事を素人が言うのはまさに傲慢ですけど，
どうせ勉強するなら万人が使ってる/種々のソフトウェアを作っている標準言語を勉強したいな
と思ったのがきっかけなので，正直C#はあまり乗り気になれません。 >>627
const の役割はその通り、その値を書き換えないことを意思表示するためのもの。
strcpy の引数なんかを見ても分かると思うけど、このように使い分けするだけで関数の入出力もよくわかる。
ケアレスミスで入出力を逆に書いてもコンパイラが指摘してくれる確率が上がるし、コンパイラにとっても最適化のヒントになってる。
でも実際、const皆無のコードも珍しくない。
そんな所に自分だけ const 付けると、余所の関数を呼ぶために意味不明なキャストをするハメになってストレスMAXになる。
ただ厳密に考え出すと、値受けの引数 int x なんかは const int x であるべきでは？なんて思うけど、個人的にはそこまで強要はしなくてもいいかな… なんて思う。
でもポインタ受けの引数 char* p なんかは const char* p にすることを強要したい。
前者について緩いのは、その const はその関数の中の実装を縛るものであり、そんなことは関数の外の世界の人にとってあまり重要ではないから、というのが理由。 >>628
C#にマイクロソフト性を強く見出しているのか知らんがJDKがゴタついていて.NET Coreが出てマルチプラットフォームで優位性があり、Unityでゲームも作れる
コンピュータを勉強したいならCでいいけどプログラミングを勉強したいならCと比較してもC#は十分万人が使っている標準言語としての地を持つよ 組み込みなどの特殊な分野を除けばC言語の方こそ万人向けとは言い難いな
C言語はそれほど広範な分野で利用されるような言語ではないよ
C言語が使えない環境は少ないけど、かと言ってC言語を積極的に使う必要のある環境も少ない、かな？
でも全ての基本として、低レベルなCを理解しておくのは有意だと思う。
C の前にアセンブラやってみるのも悪くないと思うよ。
今はお手軽なワンチップマイコンも多いし。
欲を言えば昔の 8bitパソコンくらいがメモリもそこそこあってちょうどいいし、16bit くらいになるとスタックフレームも使いやすくていいんだけど、今そういうので丁度いいのはあまり無いのが残念なところだけど。
>>628
君が思っているほど言語間の差異はないよ。
とはいえ、本気でコンピューターについて学ぶのならCは外せない。
最初からやる必要があるとは思わないが、それも含めて自由にすればいい。
最初はスクリプト言語(Ruby/Python/JavaScript)の方が上達は速いとは思うが。
>>627
> ggってみたところconstはその重要性の割に実務で使われていない傾向にあるみたいですね。
constもある意味宗教だからね。
使われてない理由は、単に、苦労に見合う結果を得られないからだよ。
Cに関してはconstを積極的に付ける理由もないからね。
C++は参照を導入したからconstを付けないと変更されるかどうかが分かりにくくなった。
Cだとポインタなら変更される（可能性がある）、そうでないなら変更されないと文法的に確定している。
だからgoogleは参照はconst以外禁止、というルールでC相当にしている。
C#では明示的にoutと書いて分かりやすくしている。
constを付けたことによるメリットは、constに対して代入したときにコンパイルエラーになることだが、
そもそもこれがないんだよ。constなんて間違う場所に使うものではない。
(ただし俺はCでストリング操作を積極的にやったことはないので、char*に関しては分からん。
>>629が引っかかっているのもそこだろうし。
とはいえ、世の中はstringはimmutableということでほぼ確定してしまったし、
今更mutableなstringの作法について学ぶ必要もないはずだが） >>626
＞君が何の為にCを学ぶのかは知らないが、もっと直接的にその結果を目指すべきだ。
＞とりあえず学ぼう、では全く上達しないんだよ。
うーん、これは非常にいい指摘ですね
私は、これに気が付くのにずいぶんと遅くなってしまいました 素人は技術もないのに、登山で直線的に、絶壁を登ろうとするから失敗する。
勉強のプロは、斜めに進んでいくから、登れる
素人がすぐに思いつくような、直線的な方法をやってもダメ。
全員が失敗してる。
C の授業を受けた、ほとんどの大学生が、こんな授業は無駄・役に立たないと言ってるw
彼らはなぜ、そう言うのか、理由を考えたらよい
C のようなポインタのある言語を、1年勉強しても、
ポインタを追っかけるだけで時間がつぶれるから、何も作れない
その時間で、Ruby/Python/JavaScript の3つの動的言語をやれば、ツールを作れる
まず素人は、動的言語・静的言語・ポインタのある言語の、
位置付けや難易度をわかっていない
>>638
難しいと思います
C++ に移ってからも、T ** を T *& に書き直すとかする段階で、自分のポインタ概念の認識が浅かったことを実感させられたりしたものです Cのポインタはシンプルだからわかりやすいと思います
ビット演算のほうが難しいと思います
m = (m & 052525) + ((m & 0125252) >> 1);
m = (m & 031463) + ((m & 0146314) >> 2);
m = (m & 007417) + ((m & 0170360) >> 4);
m = (m & 000377) + ((m & 0177400) >> 8);
>>640
8進数表記って滅多に使わないから、たまに良かれと思って桁合わせでゼロパディングすると意図せず8進数になって悩むよな。 >>641
あ、それ、30年ぐらい前にハマった。
幸い8や9を使っている所でコンパイルエラーになったからよかったが(それでも当初はなんでエラーになるのかと悩んだがw)、もし使ってなかったらROMに焼いてからターゲットマシンで変な動きになって悩み続けた事だろう。 Cが全盛だった時代、否が応でもプログラミングの勉強はCから始めた。
昔の人は理解できて今の人には難しいと考えるのは傲慢ではなかろうか。
ところでアンサイクロペディアのC言語の項が18禁になってるのは全部椋田のせいだな。
>>643
> 昔の人は理解できて今の人には難しいと考えるのは傲慢ではなかろうか。
いや事実だ。理由は単純で、つまりは裾野が広がっているだけなのだが、以下。
1. C言語の難易度自体は昔と同じだが、C言語の問題点を修正したより簡単な言語が開発された。
2. 昔プログラミングをしてたのは理系の大学生/大卒だけだった。
今は文系も含め、しかも中高生から始めようとしている。
数学で培われる論理/抽象思考能力はプログラミングに不可欠なのだが、
これらがまだ整っていない状態の中高生や文系にプログラミングを教えるってのがそもそもの間違い。
どのみち今の状況で計算機科学専攻ならCは必修だろうし、そういう連中には問題ない。
ただ、そうじゃない連中がCをやる必要はないってこと。
Pythonだけで済む世界ならそれもありだ。 昔も中高生の頃からプログラミングは始めていたけどな
いわゆるベーマガ世代の年齢層がBASIC やアセンブラからC言語に流入してたので平均的レベルは比較的高かったように思う
処理目的の抽象度が上がっているという現実もあるからなぁ
プログラミングの学習は、最初電卓でやってた
ニーモニックが16進表示みたいなやつだったな
それで、ループや分岐、サブルーチンを覚えた
その後は、Z80のアセンブラに移ったっけ
高級言語やりたかったけど、
8ビットのプアなPCしか持ってなかったし
漢字モア使えないPCで漢字ROM買って取付け
漢字非対応のドットインパクトプリンタに
機械語プログラム使って漢字出力してた
>>645
ベーマガやってた連中はごく一部なのだから一般化するのは無理がある。
そしてそれに対応する連中は、今はもっと増えている。
家にPCがあるのが当たり前の時代だし、IDEも無料、
インターネットでOSSのソース見放題、質問も出来る。
昔の大学生も、大学で初めてプログラミングした連中はCで撃沈してた。
今は昔と比べてIDE等の環境が断然良くなっているが、
大学生の割合が増えた分、大学生の平均的頭は悪くなっている。
（昔は上位1/4が大学生だったが、今は上位1/2で、東京に至っては2/3じゃなかったっけ？
昔だと当然高卒だった連中が大学に行ってるのだから、Fランでは授業が成立しないのも当然）
だから今の「平均的大学生」が大学でプログラミングを始めても、当然Cでは撃沈する。
今の「上位半分の大学＝国公立＋有名どころ」（＝昔の上位1/4の頃の大学生相当）の理系で、
昔の大学生と同様にCで撃沈するはず。
それを文系含めて全員プログラミングをやらせようってのだからかなり無理がある。
とはいえ、個人差の方が大きいし、やるのは自由だ。
ただ、もっといい言語（改良された言語）は沢山あるのだから、無理してCに拘る必要はない。
情報/計算機系はどうしても速度勝負になるから、どのみちCは外せないが。 今の平均的な大学生のレベル低下はゆとり教育の弊害だと思うが
みなさんほんとうに色々な助言ありがとうございます。
目的はなにかといいますと，ゲームを作りたいのではなく，むしろ計算機の仕組みなどを学びたいと思っています。
やっぱり始めはPythonのほうがいいんですかね……。
（ちなみにガッツりゆとり世代です。中学あたりで土曜日通学が復活したかな？）
調べただけですがRustもよさげですね。私が学びたいと思っている計算機の基礎的な部分に触れられると同時に
C99では非常に複雑で非本質的な努力を要求される，安全なメモリ管理やUnicodeに対応した文字列操作が
簡単に実現できるというのは魅力的です。また，Mozilla社が主導しているというのも好印象です。
難点は，かなり新規の言語なので，Cほど開発手法が洗練されておらず，
またコンパイラの実装が一つしかないことですかね。
しかし開発版ながらRust製のOSもあるようですし，私がCを通じて得たいなと思っていた知見や概念を
Cほど紆余曲折を経ずに取得できそうです。（学問に王道なしとは言いますがね……）
これ以上は（というか既に大分）スレチになってしまうので書き込むのはやめます
青二才に貴重な時間を割いて様々な助言を頂いたこと，ほんとうに感謝しています。
別にCでいいと思うよ。
ただ何使うにしても、画面表示とかができないとモチベーション上がらないかもね。
GUIとまではいかなくてもコンソール上にテキストで簡易グラフィックくらいやらないと、動いてる様を眺める楽しみが半減だ。
エスケープシーケンスとかを一緒に勉強するといいかもな。
とりあえずライフゲームでも作って眺めてみたら。
まあ手っ取り早くプログラミング全般を眺めるならマルチパラダイムの言語を最初に学ぶのも悪くはないと思うよ
手続き型、オブジェクト指向、関数型のマルチパラダイムなら、他にはC#やJavaScriptなどが環境が充実してるので手軽ではあるけどね
計算機の仕組み、つまりコンピュータの動作原理を学ぶならアセンブラだろうけど、普通のOSのAPIはCなので、やっぱりC言語を勉強するのはベストプラクティスだろうね。
PythonだったりC#だったりはプログラミングは習得できても動作原理は深く学べない。
果たしてC#等の高級言語しか使えない人の何割が割り込みやCPU動作モードやSFRについて正確に理解してるのやら。
>>653
Rustの方が細かなノウハウでコケずにコンパイラが指摘してくれるというのはあるが今の目的ならCの方が素直でいいと思う
実機の動きを追える上に色々な機能が付いていて嬉しいという言語なので覚える事が滅茶苦茶多いよ >>652
中高生なら学校の勉強しとけ。結果的にそっちの方が近道だから。
プログラミングは抽象思考が出来て自分でサイクルを回せる奴しか上達しない。
具体的に言うと、「○○→△△って事は●●→▲▲ってことだろ。
ならここをこう改造すればこうなるはず…ビンゴだぜ！俺って頭イー」
を『自分だけ』で勝手に繰り返せる奴だ。(β）
学校の教科でこれに最も近いのは物理で、次点で数学だ。
だからこのタイプの奴は物理と数学は『本人は特に努力した覚えが無くとも』無双出来る。
逆に言えば、そうなっていない奴は本質的にプログラミングに向いてない。
その場合は、そもそもプログラミングをやるべきではないと俺は思っているが、
それでもやるのなら、まず物理と数学の『勉強の仕方』を変えて『抽象思考』を身につけるべきだ。
（単に勉強するだけなら『暗記』でも一定まではカバー出来てしまうが、それでは意味がない）
プログラミングを始める前に、プログラミングが上達する基礎能力としての抽象思考を身につけないといけない。
次に、既にこれが出来ていたとすると、
教科自体の内容はプログラミングには直接は関係ないから、中高生でも出来るのは事実だ。
（ここら辺のことをわきまえず、『中高生でも出来る』とだけ見て全員に教えようとしてるから問題がある。
とはいえ、主導している馬鹿共はプログラミングが出来ない連中だから、話が通じないのも当然だが）
仮に君がここまでは到達しているとして、話を進めると、以下になる。
> むしろ計算機の仕組みなどを学びたい
現状、C以外に選択肢はない。
> Rust
止めとけ。今のRustはプログラミング初心者用には出来てない。C以上に確実に撃沈する。
> Python
海外では「関数呼び出し、ループ、条件分岐」等の基礎の基礎を学ぶのなら一番早いと言われている。
現実的にはAWK/Perl/Ruby/JavaScript等いわゆるスクリプト言語全般は全てこれに当てはまるが。
ただ、上記の「プログラミングが上達出来る奴」ならこの部分は数日～数週間で通過してしまう為、
言うほど関係ない。「初心者ならどの言語でも同じ」とよく言われているのはこれ。 例えば体育、運動神経のいい奴は何をやってもそこそこ上手いし、一瞬で上達するだろ。
あれと同じで、「プログラミング神経」のいい奴はどの言語でも上手く行くし、すぐ上達するんだよ。
だから言語自体よりは「プログラミング神経」としての『抽象思考』能力の方が重要なんだよ。
そしてそれがない奴が頑張ってみたところで、
ちょっと運動神経のいいやつが遊びでやってるのを見たらスゲー上手くて萎える、みたいなことになる。
だから本当は基礎能力としての抽象思考を鍛えることが重要で、プログラミングの上達はその結果にすぎない。
そこを「プログラミングを『教えれば』上達する」と勘違いしている馬鹿が色々やろうとしてるからおかしなことになってる。
『教えれば』上達するのは暗記科目であって、
上達する状況を整えた上で『勝手にやらせる』と自然と上達するのが非暗記科目だ。
で、言っちゃ悪いが君は多分「抽象思考」型ではなく、「暗記」型だ。enumして全潰しというのがそれ。
君は本質的にプログラミングに向いてないタイプだと思うぞ。
教科の延長でプログラミングを学びたいと思ってるのなら止めとけ。
上記(β)タイプは主に一点突破で、むしろ勝手に突っ込んでいって自爆するのが多い。
最近出てきたのはGateboxだが、いい感じに突き抜けてるだろ。
https://gatebox.ai/home/
http://www.itmedia.co.jp/news/articles/1612/14/news092.html
こういうことを平気で出来る奴じゃないと上達しない。
君にはその臭いを感じない。 やっぱりプログラミングより数学の勉強の方が全然大事だと思うわ
無駄な時間を過ごしたおっさんの後悔からの発言だけど
若者は線形代数と物理いっぱいやった方がいいよ
BIOSの割り込みサービスで画面に文字表示するやつよんだらどうなりますか？
>>653
これでも買っとけ
70年代のTRPGの生の感触がばりばり伝わってくるAD&Dの本
コンパイラ―原理・技法・ツール (Information & Computing) | A.V. エイホ, R. セシィ, J.D. ウルマン, M.S. ラム, Alfred V. Aho, Jeffery D. Ullman, Ravi Sethi, Monica S. Lam, 原田 賢一 |本 | 通販 | Amazon
https://www.amazon.co.jp/dp/478191229X >>618
> そういう文法的になことには今は拘らない方がいい。
臭い物に蓋してんじゃねえ
無理に気になる必要はなくても
気になったのに誤魔化せって最低なアドバイスだ
学問そのものを全否定する暴論だ そんなに気になるならコンパイラを読めば良い
コンパイラを読まずにああだこうだと言ってそれを学問と言い張るのは今更ニーチェを読んで学問と言い張っているのと似ている
組込み開発者におくるMISRA‐C:2004―C言語利用の高信頼化ガイド、MISRA‐C研究会、2006
この本は、日本の大企業から、C の専門家が数十人集まって作った。
この100ルールまで行かないと、教えられない
汎整数拡張・副作用完了点・短絡評価・bool とか、各概念が難しい。
とても初心者に教えられない
特に学生なんて、現実を知らないから、文法があっていれば正しいと思う、
固定概念があるから成長できない
現実には、MISRA-C、100ルールに従わないと話にならない。
学生にはそういう事はわからないから、アホみたいなコードを書く
コードは、正しい文法で書いても、ダメだから。
可読性・保守性・バグを起こさない、Ruby みたいなコーディングが大切
だから、Rubyでプログラミング学ぶのが大切。
学ぶのは文法規則じゃない！
システムを作る・保守するためのプログラミング！
Ruby の女神・女優の池澤あやかも、同じことを言ってる。
慶応大学卒だけど、大学で、C の授業は無意味だって
山陰地方のRuby合宿へ行って、webアプリが作れるようになった
Cの開発時間の大半が、ポインタ・バグでつぶれるから、プログラミングを学べない。
文法がわかるだけで、ものを作れないから楽しくない
だから、Cの授業の評判が悪い。
無意味な授業だよなって
だから初心者は、Rubyから初めて、まず動くものを作る
最初の質問者は計算機の仕組みを知りたいのであってWebアプリを作りたいわけでもMISRA Cルールを知りたいわけでもない件
典型的な超頭悪そうなﾔﾂﾗが
ひたすら長文連投してる
>>670
またrubyガイジかよ。Cスレにまで出張ってくるななよ Cのスレに不毛な喧嘩売ってくるのは大体Cで挫折して、
劣等感を何とか慰めようとするカーミング行動だから気にするな
>>669的にはコンピュータのしくみはどうでもいいってこと？ >>663 にある本の紹介文なのか宣伝コピーなのか、
「70年代のTRPGの生の感触がばりばり伝わってくるAD&Dの本」て部分を
どう解釈したら良いのか分からないのだ。
Cや「ドラゴン・ブック」、TRPG, AD&D って言葉くらいは知ってる者に
解題してくれないか。
ひどく野暮な質問かも知れないけど、聞くは一時の恥とか言うし、敢えて頼む。 >むしろ計算機の仕組みなどを学びたいと思っています。
それなら情報処理の基礎なんかをやった方が良い様な気がする
今は基本情報処理とか言うんだっけか?
資格とかのやつよ
向いてないっすか……。正直物理や数学は得意なほうなんですがね……。
>>683
高齢者はマウンティングする病にかかりがちなので気にすんなよ >>653
武内覚さんのLinuxの仕組み片手にCやるのがおすすめ
ファイルIOとかなら、システムコール、VFS、FS、Raid、デバドラ、スケジューラー、SCSiまでユーザーランドからデバイスまで一貫して、かつお手軽に触れる cの文法で書けるだけの
無能を自覚できてない低学歴知恵遅れの高齢底辺ITどかたに多い
お。半角文字の入ってない書き込みを久しぶりに見たような気がする。
底辺ITﾄﾞｶﾀさんたちは
今日みたいな台風の日も自宅待機ではなく
出勤でしたか
大変でしたね
台風で東海道線や環状線が止まるのはまあ想定内だったが阪急や京阪まで止まるのは想定外だったわ
やっぱワンチップマイコンでアセンブラがいいよ。
クリスマスに向けてLEDチカチカさせてジングルベルでも鳴らしてみるとかどうよ。
ロジアナがあればベストだが無ければせめてオシロは欲しいな
>>683
向いていないね。それは臭いから分かる。お前は本当の「天然」ではない。
以下参考だが、結局中身は同じだ。
> 一撃必殺！急にマンガ家だの声優だの絵師だのになりたいと言い出した子どもや大人を止める、オススメの方法
> https://togetter.com/li/1130025
今はプログラミングなんて本当に簡単に始められる。そのレベルでグダグダ質問している時点で向いてない。
本当の「天然」なら、もう既にとりあえず何かしらのコードを書いてる。
お前は勉強しないと何も出来ないと考えている「いい子ちゃん」タイプだ。
そういう奴は自分でサイクルを回せず（＝暴走出来ない）、上手くなれない。
無理してプログラマになっても、後輩に簡単に抜かれ、馬鹿にされる、悲惨な人生になるぞ。止めとけ。
(ここ見るだけでも老害を馬鹿にしたがっている奴はいくらでもいるのが分かるだろ）
ベーマガ世代だって理解してやっていたわけではない。やりたくてやってただけだ。
先に数学をやった方が効率が良かったはずだが、そんな事は考えてもいない。
お前は、サッカーをやる前に、筋トレして体幹も作り上げ、万全の状態にしようとしている。
勿論そういうのもありだが、それはやはり「養殖」なんだよ。
「天然」はそうじゃない。サッカーをしながら、もっと上手くなりたいから筋トレして体幹も作っていく。
好きだから続けられるし、環境が多少酷くても我慢出来る。（これがIT産業がブラック化しやすい遠因にもなってる）
そういう「天然」向け仕様の環境で、「養殖」では悲惨なことになる。
(勿論、プログラミングをやってみてから好きになる、というのもありだが、それはかなり少数派だと思う)
向いてる/向いてないで言えば、
ちょっとコードを書けるようになって調子に乗ってここで俺ツエーしている馬鹿共の方が向いてると言える。 今はプログラミングの裾野が広がって、絶対的な人数が全く足りてない。
だから文系をSEとして大量投入してみたものの、いい結果がでたとは言いがたい状況だ。
それで次は「小学生からプログラミングを教える」「国民全員がプログラミング出来るように」
みたいなアホなことをやろうとしているのだが、これは完全に愚策だ。
プログラミング出来ない/したこと無い奴らが仕切ってるからおかしなことになってる。
それにお前がつき合う必要はない。
教育改革ってのは取り返しが付かない人体実験になるから、性急にやっては駄目なんだ。
この認識すらなくゆとり教育を導入した文化省の連中は、
今からでも全員死刑に処すべきだと俺は思っている。
（それくらい罪深いし、社会に対して悪影響を及ぼしている。日本はミスリードに甘すぎだ）
今の「小学生からプログラミング」についてはどうやらお遊び程度だからまあいい。
やるにしても当初はこの程度で様子見しながら拡大するか取りやめるか試すべきなのさ。
（俺は意味無いから止めろと思っているが）
今時PCもスマホもない家なんて珍しいだろ。
なら初心者用のプログラミング環境はすぐに整えられるし、勝手に始められる。
だからそのレベルでこんな所に質問してる時点で間違ってる。
天然：何故プログラミングをするのか？そこにPCがあるからだ (単にいじくり回したいだけ)
幼稚園児：ケーキ屋さんになりたい！（だってケーキ大好きだしもっと食べたいから）
お前には幼稚園児が「ケーキ屋さんになりたい！だってお金儲かるし！」
みたいな事を言っている違和感がある。
初心者の癖に計画しすぎだ。必要があって否応なしに始めるわけでも無し、意味不明すぎる。
そういう奴も中にはいるのかもしれないけどさ。
ただ、確実に言えるのは、プログラミング界隈は良くも悪くも全般的にギーク向けに出来上がってる。
お前がギークになりきれないのなら、ずっとアウェイのままだ。
それは幸せなことではないと思うよ。
>>696
周りに迷惑かけない分、頭の悪い長文書く奴より立派だから安心しよう ｵﾚみたいに的確に要点をまとめてる長文なら読める
低学歴知恵遅れの長文は読めるｼﾛﾓﾉじゃないからな
文章だけで低学歴知恵遅れかどうかは
簡単に判別できる
このｽﾚに連投されてる長文の駄文は
低学歴知恵遅れが記述したと推認することに疑いの余地がない
必要なら数学の知識などなくても感覚で覚えるからな
座標計算の必要があれば三角関数など知らない小中学生でもsinやcosくらいは使う
>>700
小中学生に三角関数は無理でしょう…まず相似の概念を習うのが中学2～3年くらいなのでは？ 数学は教科書で勉強しないとあかんよ
経験で得た知識なんてただの思いこみ
思い込みでも何でも使っているうちに覚える
自分の場合は30年以上前中学生の頃に画像処理のプログラミングしている間に三角関数(といってもX座標はcos、Y座標はsinといった程度)や
論理演算(RGBの合成はOR、反転はXORなど)を覚えた
その後になって高校の頃に教科書でまともに学んだ覚えがある
>>701
三角関数が何なのかは分からなくても、sin と cos を使うだけなら小学生でも定型文的に覚えちゃうんじゃね（おれは中学の頃だったが）。
円を描くところから始まり、直径を変化させると渦巻きにできたり位相や周期を変えて橢円やらリサージュになることに気付いたりで、
パラメータをやみくもに変えて手探りで欲しい結果にたどり着くようになる。
もちろん円的な動きの元ネタは必要で、ベーマガみたいなののコードをパクって出発だな。
小学生の頃はファミリーベーシックだったので三角関数には行き着かず、中学生でMSXになって三角関数に出会ったが、小学生の頃にMSXがあれば手を出してたと思う。 そういや小学生のころはスーパーマリオが出たころで、ファイアバーをどうしても再現したくてファミリーベーシックで頑張ってたわ。
三角関数に行きついてないから、角度の範囲毎の動きを個別に書いたな。
でも長さが伸び縮みしたり軌跡がカクカクで、結局将来の夢に据えてお仕舞いにしたw
ニュー速で話題にしていた、CLA Fortran プログラムですが、
C言語への移植が終わりました。
公開方法について、検討しています。
↓ここを使おう蚊と考えています。
https://ideone.com/
C言語へ書き換えたソースと、入力用データとパラメータの３つですが
入力用データとパラメータについては、サンプルに掲載したものと同一
なので公開は必要ないかも知れません。
ただし実行するには必要になります。どうしましょうか？
テキストファイル形式で単独でアップロードするか、
ソースの一番下にコメントとして載せるかどの方法が良いでしょうか？
あと、オリジナルFortranソースもアップロードした方が良いですか？
これは以前PDFを見つけてくれた方がソースに起こして頂いたものです。 >>694
>>695
よくわからんのだが、お前が相手をしてるそいつはなぜプログラミングを初めたいと思ってると思ってる？
よくわからんのだが、ギークとかなんやらの最初とそいつの最初の具体的な差がよく分からん C言語ポインタ完全制覇っていう書籍が気になってるんだけどこれはどの程度の知識がある人を対象にしてるの？
どの程度っても難しいなｗ
簡単なポインタは分かるけど、二重ポインタとか配列が絡むと混乱しちゃう程度の知識の人向け？
初心者なら悪い本じゃないから買っちゃえ。
>>701
円を書く時に使えると聞いて確かに書けるので使っていて、後で高校生向けのやたらやさしく書いてある図と絵が満載の参考書を見てどういうことか詳細がわかった。俺が中2の時の話。
で、今思うに、これぐらいならちゃんと教えれば小学生でもわかるんじゃないか？俺としては単に教えてないからできないだけのような気がしてならないぞ。
しかし後々高校に入ってから数学の授業で「これ割るこれがsin」などと教師が言ってるのを見て、こんな説明だけでわかるやつはいないだろうとも思った。
ちゃんと教えられる人があまり居ない事もわからないやつを続出させる原因なのかもなと。 あの説明はひどいよな
だから何？がずーっと消えない
sin,cos,tanそのものはアホな小学生でない限り余裕で理解できる。
ただ、それに付随した加法定理やらいろんな公式をセットにして教えたいし、それより先に教えることがたくさんあるので>>711の言っている通り教えてないだけだと思う。 せんせい
「同じ授業を受けていい点数を取る生徒ももいるんだから、悪いのはIQの低い君達」
「分かる奴は塾に行ってる？じゃあ悪いのは君達の努力不足だ」
>>709-710
初心者には、この本もよい
詳説 Cポインタ、2013、オライリー・ジャパン >>711
普通は円を書くのに三角関数を使わない
普通は え、
>>711ってarcとか使わないで円を書くって言ってるの？ 三角関数の説明に三角形だけの図を描いてこれ割るこれとか言って済まそうってのは手抜きな感じがする。やはり円も描かねば。
ま、しかし、sin. cos 使って円が書けるのがわかったのは良いが、当時のマイコンは貧弱で浮動小数点演算なんかやらせてたら遅くて仕方がなかった。
しかしBASICでグラフィックに円を描かせると妙に速い。正数計算して描いてるからだが、どうするとそんなことができるのかを延々と探り続けてようやっとわかったのが高校生になってからだったかな。
今はもうほとんど覚えてないが二乗して足してってオーバーしたら引いてみたいな計算したと思った。
>>717>>720
まあ40年ぐらい昔の話だからね。 >>722
それってブレゼンハムやミッチェナーのDDAアルゴリズムを利用した直線や円周の高速描画だろ
懐かしいな >>726
何て言うのかは知らなかった。何かのプログラム解析してわかったんだったかな。その辺は忘れた。
直線も足してってオーバーしたら引くみたいなやり方だよね。今ではハードウェアで組み込まれてるんだろうな。 >>725
ポインタが指す先が const の場合とかポインタそのものが const の場合とかさらに volatile が組合わさったりさらにそういうののポインタだったり配列だったり関数ポインタまで入り込んだりした場合に、
正確に型宣言したり読んだりするには結構修行が必要だからいろいろややこしいことが書いてあるんじゃないか >>722
＞当時のマイコンは貧弱で浮動小数点演算なんかやらせてたら遅くて仕方がなかった。
この辺は工夫次第
8bitPCが全盛だった頃、動く３Dオブジェクトを表示するのに機械語で演算処理組んでいた
全部整数化し、SIN関数値は全部テーブルで持たせていたな
試して見れば分かるが実際に必要なテーブル範囲は90度もいらない 敵の弾が自分めがけて飛んでくる
ってたったそれだけでも中学の頃は大変だったな・・・
なつかしい
>>730
大変だった
どんな式を立てたかは忘れたが、角度によって弾の速さが変わっちゃったりして試行錯誤してたな １フレームごとに最短距離で追尾してくる最も厄介なミサイルが実は一番簡単
もうすでにC言語なんか関係なく回顧厨になっとるな。
俺も乗っかろう。
昔はBASIC標準のライン描画やらペイントルーチンが遅いので、いかに高速なアルゴリズムを作るかパソコン雑誌の特集になってたりしたな。
超高速中間色対応ペイントルーチン！みたいな。
ある意味、良い時代だった。
液晶上にある発光体の色は3種類
マゼマゼする原理は同じ
>>734
CoolType/CelarTypeがそれに近いけどな R成分100%にB成分100%をビット演算で重ねる、みたいな話か。
重ねるというよりも隣接するドットを違う色で決まったパターンで表示することで
擬似的に色調表現するテクニック
基本的に8色しか使えなかった頃に多色表現するために開発された手法
複数ドットでひとつの点を表現するためにいかに自然に見せるかといかに高速化するかが
プログラム的に腕の見せ所だった
cleartype はそういうのじゃなく、三原色の並びを利用して擬似的に横方向の解像度を上げる方法でしょ。
1画素内に三原色が RGB と並んでた場合、それを2画素並べると以下のように画素の分解能を超えた位置に白点を表示できる。
RGB___ 白黒 … 座標 0 に白点
_GBR__ シアン赤 … 座標 1/3 に白点
__BRG_ 青黄 … 座標 2/3 に白点
___RGB 黒白 … 座標 1 に白点
すまん、投稿が受け入れられたタイミングがマズくて
>>739 に対する反応みたいに並んでしもうた。
>>740 は >>739 の「マゼマゼする原理は同じ」に乗っかったネタ文だ。
R成分100%とB成分100%をマゼマゼして、HTMLの16進表記で#FF00FFの色を作ったら、
「そりゃ“マゼンタ”だよ、バカだねぇお前さんは」という想定(しかし破綻)。 もちろん「マゼマゼ」は >>738 だよ、引用アンカーを間違えるとは。
マゼマゼでダメダメ。再び「バカだねぇお前さんは」 >>745
ん？俺は別に煽られたとは捉えてないし問題ないぞ。
そもそも話が通じないのは「抽象思考」が出来てないからだ。
三角関数で → 円も描ける、であって、（演繹）
円を描く為には → 三角関数、ではない。（暗記）
とはいえ適用する場合は大体お約束的だし、
大学入試なんて解けるように作ってあるのだから、「暗記」タイプでも努力すれば数学の点も上げられる。
しかしそれでは駄目なんだよ。意味がない。
そして小学生に三角関数を教えても「暗記」にしかならないから、その時点で教えるのはやはり間違っている。
> これ割るこれがsin (>>711)
これも、結局の所これ以外にどう表現しろと？という話だからね。
これが嫌だったのなら教育関係に就職して改革すべきだが、
実際ゆとり教育を先導した戦犯役人はこのタイプだった（はずな）ので救えない。
理解出来なかった奴が「俺が理解出来なかったから」という理由で主導するからおかしな事になる。
今現在の「プログラミング教育導入」もこれに近く、
そもそもプログラミングできない/やったこと無い奴らが主導してるから暴走してる。
三角関数なんて、円以外で適用される場合の方が多い。
それを過度に円に結びつけるのは数学としては間違っている。
単振動なんて、本来は円運動とは関係ないだろ。あれはma=kxの解がsinxだって話であって。
内積が|a||b|cosθになるのだって、円なんて全く関係ないし。
三角関数は、「偶々そういう関数を定義したら、何か知らんけど色々使える」であって、その見方だと
> これ割るこれがsin
になってしまう。これ以外に表現しようがない。
逆に、「宇宙の全ては円で出来ている」（なぜなら三角関数が適用出来る場合が多いから）
という捉え方も出来なくはないが、こっちの方がカルトだろ。
おそらく、数学の発達過程で他にも色々関数が定義されて、でも使えない物は淘汰されて、
結果的に今の三角関数だけが残ったのだと思うぜ。 中間色/CoolType./AAも、俺にとっては「隣接するピクセルを用いて中間値を表現すること」で同じだ。
お前らはそれを
・フォントの場合
・色/ピクセルの場合
と別々に覚えてるから別物に見える。それはお前らの脳内が「暗記」ベースだからだよ。
暗記ベースでプログラミングの上達を目指すのは「デザインパターン」だ。
しかしこれも必要以上に細分化し、しかもJava文法が足りない点を必死で補っていたりで、
はっきり言ってポシャったろ。あれでは無理があるのさ。
勿論、「暗記」しかできない奴はいまだにそれにすがり続けているようだが。
ただ、実際の所、プログラミングは当然実装出来ると分かっている範囲で為されることが圧倒的に多いので、
「暗記」ベースの手法でもほぼ全ケースで何かしらの適用が出来、対応出来る。
だからそんなに問題にはならず、ある意味Javaプログラマが一定レベルまで順当に成長するのはこれがある。
ただ、「暗記」ベースだと、知らない事は発想出来ない。別物扱いだから。
中間色を「抽象思考」で捉えているのなら、
方向を変えて適用した結果がCoolTypeでありAAでしかなく、これらは自然に連結する。
この点がずいぶん違う。
この点に於いて、「暗記」ベースの奴は文法リッチな言語、JavaやC++の方がいい。
というかな、プログラミングが上達する奴と全く上達しない奴が居て、
別段人間的に問題がある（全く努力をしてない）訳ではないのが不思議だったのだが、
今のところの俺の結論はこれだ。
「暗記」ベースの奴はCやJavaScript等の文法がスカスカな言語では上達しにくい。（上達出来ない）
文法リッチな言語だと、「この文法はこのときに使う」というやり方で、
「プログラミングパターン」を「暗記」で積み上げることが出来る。
（これは本来「デザインパターン」と呼ばれるべき物だが、
この用語は継承をこねくり回したゴミの呼称となってしまっているので、敢えて別に命名する）
だから、文法を一通り押さえれば、知識としてのプログラミングパターンを一定量積み上げることが出来、
結果、一定までは確実に上達するというわけだ。
Javaはこの手法で平均レベルのプログラマを大量確保出来ている。
ただし逆に、文法等の暗記事項に計上されてないと、彼等は上達出来ないので、過度に暗記にすがる。
これが今の「デザインパターン」の状態だ。必要以上に細分化し、また、無駄に増やし続けている。
彼等にとっては新規パターンの登録と暗記がすなわち上達であり、それ以外に方法がないからだ。
したがって、今後ともこの暴走は続く。
C++erで言えば、彼等は shared_ptr/unique_ptr/weak_ptr の使い方にはご執心だが、そこまでしか見えていない。
次に導入されようとしている observer_ptr については必要性も使い方も分かっておらず、理解も出来ない。
なぜなら、「暗記」出来るのはそれらが定義されて以降であり、
「暗記」では現在未定義の物を演繹的に作り出すことが出来ないからだ。
良くも悪くも、C++が文法リッチになる過程で、CerとC++erが自然発生的に分かれてきたのはこの辺だと思う。
Linusから見ると、C++の文法もデザインパターンと同様のゴミの山に見えているはず。
(JavaScriptなんて、たったあれだけの文法で、C++で表現出来る範囲を越えるのだから笑える)
Cの場合には文法がスカスカだから、
ポインタで → 何でも出来る、とならないと上達しにくい。（演繹）
この場合は → shared_ptr、では無理だ。暴走出来ない。（暗記）
だから「暗記」ベースな奴は文法リッチな言語を選んだ方がいい。
(ただしポインタがあまりに汎用性がありすぎて最適化等に問題があり、
結果、他言語では色々制限を付けられてきたのはご存じの通り）
逆に「たったこれだけの文法で全て表現出来るなんてステキ」と思える奴は
CやJavaScript等の文法スカスカ言語の方が向いてる。
JavaScriptがゴミゴミ言われながらもここまで残っているのもこの点が大きい。
あれは使える奴が使ったら凄く使える言語だ。
ただ、今のJavaScriptプログラマの大半がゴミなのも事実だが。
Cの授業が全く無駄だ、という話も出所はここだ。
プログラミングなんて、結局、「代入、条件分岐、関数呼び出し、ループ」でしかなく、
ループですら代入と条件分岐で実装出来るのだから冗長だ。
一応チューリング完全であるbrainfuckは関数呼び出しすらないので、これも冗長とも言える。
そしてCの授業で行われるのはまさに「代入、条件分岐、関数呼び出し、ループ」だけであり、
これでどうやって初音ミクが歌って踊るのだ？と初心者には思えるだろう。
最終的にはGPUを介してVRAM上に代入(ラスタライズ）しているだけだとしても、
それが初心者に見えるはずもない。
(もっとも、今の3Dベースの2D《テクスチャとして貼ってるだけ》だと
ラスタライズ結果をVRAMに戻しているかも怪しいが)
ただ、MITがSICPを止めたのと同様、今時初心者がCをやる必要はない。
DrawLineで線が描ける、HTML出力したら絵が出る、で済む連中がCやるのが間違ってる。
逆に、デバイスドライバ等を書いたり、
計算機自体の専門家(HighPerformanceComputing)等を目指すならCは必修になる。
メモリーリークについて質問です
プログラム終了時に残ってしまったものに関してはOSが解放してくれるから対処しなくていいと聞きました
今までデバッグしてメモリーリークが出ると無くなるまで結構あれこれやってたんですが全部無駄だったんでしょうか
>>753
終了時には解放してもらえるけど、メモリリークしたままだと動き続けられないじゃん。
たまに再起動してもらうの？ あーいや想定してるのはちょっとした処理を行って出力して落ちるだけのプログラムなんです
ループの中で何回もmallocしてメモリを食いつぶすとかそんなことも無くて、ただ終了時まで動的確保した変数が解放されてないみたいな
そういう状況でお願いします
>>755
そういう限定的な条件では解放は省略するって方針もあるかもね。
終了パターンがいろいろあると解放するだけでも一苦労だったりするし。
ただせっかく作ったそのコードは制約が多く他には転用しづらかったりと資産としての価値は低いと思う。
そもそもデバッグでメモリリークを発見とか言ってるとなると、メモリの管理はしっかりしてて解放を省略していることも設計に入ってる、という状況ではないんじゃないの？
それはメモリを管理できてないってことじゃないのかな。
そんな場当たり的なことやってると大きなコード書けないよ。
メモリリークを潰させるのは、メモリを解放すること自体が目的というよりメモリを管理させる教育的な目的じゃないかね。 いや教育というか、上司が作ったAPIを利用して機能作れって指示が出ててですね
そのAPIが上で説明したように変数解放しないままプログラム終了してたって状況です
んでこれいいんですかこうすれば治りますがみたいなこと言ったらいいんだ勝手に解放されるかと
ともあれそういう方針が有りだということは分かりました。どうもです
そのAPIを流用するのは難しいな。
しないつもりなのかも知れないが。
まあしかしできればメモリリークしない方が良いな。
そのままだと常駐するプログラムのループの中で使えないし。
>>757
上司の指示ならそのままにしとけばいい
メモリーリークしてもプロセス終了で解放されるから問題なし
って言う奴は一定数いて説得しても改心しないから放置しとくしかない
後々何かで事故った時のためにドキュメントに書いとけ たいていドキュメントは失われるので俺ならソースコメントに書いておくな。
「2018/09/06 メモリ解放してないので注意(先輩の指示で改修見送り)」
そりゃ、そういう状況では解放処理は抽象的な書き方にすべきなんですよ。
freeがなければ安心できないのって病気に近いよ。
