C++相談室 part152
■ このスレッドは過去ログ倉庫に格納されています
プログラミングを知らない人が「こんぴゅーたって何でも出来るんでしょ」って言ってるのと似てる >>441 そう聞こえちまう発言を見かける頻度が高すぎてやだよな >>437 「それを言うならこっちでしょ」の意味も 「合理性という論点では同じ」の意味も 「文法的に非合理的」の意味も全て分かりませんでした >>443 では言い方を変えようか 関数識別子でも型識別子でもそれを一覧しやすいところに集めやすいことを合理性と言っている 概要と詳細はどっちを先に書くべきかってことだよ typedefは右端に宣言対象の識別子 usingは左端から7文字目という決まった位置に宣言対象の識別子 trailing-return-typeも5文字目という決まった位置に宣言対象の識別子がある 可読性という観点からどう思う? typedefは変数宣言を流用した手抜きだからこんな糞みたいなのも書けてしまう typedef int are, kore, sore, dore, *hare, **yore, (*more)(float, long), (*ore)[42]; typedef int (*more)(float, long); //この書き方に抵抗は全くないが using more = int (*)(float, long); //それでも俺はこっちが好き >>445 その点については統一感あってむしろ美しいと思うけどw typedef int are, kore, sore, dore, *hare, **yore, (*more)(float, long), (*ore)[42]; sore g(float, long) {} int main() { are a = (int)0; kore b = a; hare c = &b; yore d = &c; dore e[42]; more f = g; ore h = &e; return 0; } int are, kore; 変数のareとkoreが本質的に同じ型であることが重要なときに統一できるのはいいけどね intの同義語をそんなに量産してどうするんだと usingとtypedefでいうと関数ポインタ、配列の扱い違うよね あのあたりよくわかってない 誰か解説して >>440 まるでさも自分がわかってるみたいな言い方 別のスレでちょっと書いたことがあるが……。 人工知能 (AI) ってのは人間の知能を代行するものという意味合いで私は考えてる。 昔はコンパイラそのものが人工知能の枠内で扱われていたこともある。 それ以前にルールベース、つまり if 文の羅列のようなものまで人工知能の一種だった。 でもそれらが分野として確立されたら人工知能とは呼ばれなくなっていた。 機械でやるのが当たり前のものになったから。 普通の道具になったから「知能」ではなくなったんだ。 人工知能を実用化するってのは人工知能を人工知能でなくすること。 逆に言えば人工知能と呼ばれている間は曖昧模糊としてよくわからんのが当たり前なんだと思う。 これはいろんな使い方をされる「人工知能」という言葉について私なりの解釈であって 正しさを主張するつもりはないが、それなりに実態に合った解釈ではあると思う。 そんなこねくり回した理解いる? たんなる学術分野を指すだけの言葉じゃん 意味が広いだけ >>452 ワイン。 一杯目の終わりの方。 でもまあ前に別スレでも書いた内容だから酔って考えてるというわけでもない。 と思ったけど前に考えてたときも酔ってたかもしれん。 最適化方面へのAIの適用というと、 高度なルールベース(80年代のAI)までいったん後退したものに 収束が必ずしも保障されない最適化処理(有限ステップで終わる保証がないからもはやアルゴリズムと呼ぶのは抵抗があるがGAとか を組み合わせたものになりそうなヨカン FPGAの論理合成エンジンみたいなやつを考えたら宜しいかと、 もはや冪等性は気体できない ビルドをやるたびに結果が変わるorz >>418 >>438 それを知らずに議論するやつが居ると思ってるのか・・・ 文字列の内容を1行毎に配列に入れたいのですが 以下のプログラムだと一部の文字しか抽出できていませんでした 完全が必要な点を教えてください for (unsigned int i = 0; ; i++) { for (unsigned int j = 0; ; j++) { if (*str == '\0') return; if (*str == '\n') break; datalist[j][i] = *str; str++; } str++; } datalistに行ごとに抽出するならiとj逆のような気もするけど とりあえずdatalistの方にも、各行の終わりに\0(文字列の終端)が必要じゃね? ゼロ終端文字列として扱わないとか、最初にmemsetしてるなら別だけど >>457 逆にいなかったと思ってるなら日本語の 勉強からやり直してくださいw >>443 で、意味通じたのかな? 君の見解が聞きたいんだが >>459 このレベルで人に聞いてるようでは使い物にならんな >>417 それのどこが非合理なのか全く分からない。 ちなみに、俺は数学が好きで、学生時代、ほぼ満点だった。 >>467 >444 を読むと、言いたかったことはわかる。 > 関数識別子でも型識別子でもそれを一覧しやすいところに集めやすいことを合理性と言っている 言葉のチョイスはおかしいと思うけどね。単に「読みやすさ」「読みにくさ」とか言えばよかったところ。 >>459 vector<string_view> dim; string_view sv = str; string_view::size_type f; while ((f = sv.find('\n')) != string_view::npos) { dim.emplace_back(sv.begin(), f); sv = sv.substr(f + 1); } dim.push_back(sv); >>468 個人的に数学記号のようなもの解読する値から強い方だからかも知れないが、 usingがtypedfよりも特に読みやすいとさえ思わない。 ただし、 #define 名前 定義内容 と using 名前 = 定義内容; で順序に対応関係が有ることはある。 しかしながら、C/C++では、 型名 変数名; // (100) の順序な分けで、LL言語に多い、 var 変数名 : 型名; の順序ではないので、統一と言う点では、typdefは(100)と美しく統一されている。 typedef int (*funcA)(float, long), (*funcB)(float, long), (*funcC)(float, long); ↑ の代わりに typedef int (*(funcA, funcB, funcC))(float, long); とか描けないよな >>464 通じませんでした しかしこれ以上興味も維持できませんので この話はここで閉じさせてください レスしてもらったのに申し訳ないです 見解は元の>>416 さんにでも尋ねてみてください >>470 > しかしながら、C/C++では、 > 型名 変数名; // (100) > の順序な分けで 「型名 変数名;」ではなく「型指定子 宣言子;」な。 (実際には宣言子は複数書けるがそれはわきに置く。) 順序はある程度は好みだろうとは思うが、 変数を宣言するにあたって「型名を与えているわけではない」んだ。 たとえばポインタ型の変数だと int* a; みたいに宣言できるが、 このとき int という型指定子と *a という宣言子から成る。 a の型名は int* であるが、 宣言のときには int は型指定子の側について * は宣言子の側についてるわけ。 typedef は変数宣言の文法と一致させているという意味では一貫していることに合意するが、 そもそも型名を途中で分断するかのような変数宣言の文法がイケてないので、 そっちで統一するのが本当にうれしいのかね? という点で疑問を提示する。 いや、それでうれしいというのならそれでもいいんだが、 前提がそれほど一貫してないのに一貫性をもちだしても仕方なくね? >>475 すまんが、個人的には、 int *ptr; を int* ptr; と書く人は頭が悪いのかな、と思っていつも見ている。 int* a; int* b; int c; //int[42] d; ↑こう書きたいという勢力と… int *a, *b, c, d[42]; ↑こう書きたいという勢力があるんやろね 好みというかその人のバックグラウンドというか >>476 * は (文法的には) 宣言子の側についてるからそちらにくっつくもんなんだろうが、 型名としては int* だから int* と書く方が好ましいと考えている。 文法的な解釈はともかく「型名 変数名;」に近い書き方の方がわかりやすいという考え方だ。 あと、 C++ の設計者自身が * を左に寄せる書き方をしてるから私はそれに巻かれている。 C として書くときは * は変数名の側にくっつけて書くようにしてる。 (K&R ではそういう書き方になってるので。) * の両側に空白を入れる流儀も存在するようだ。 >>478 >あと、 C++ の設計者自身が * を左に寄せる書き方をしてるから私はそれに巻かれている。 >C として書くときは * は変数名の側にくっつけて書くようにしてる。 (K&R ではそういう書き方になってるので。) Cの設計者は数学的、C++の設計者は凡才的。 >>476 +1 ほんそれ stroustrupは頭が●照る >>478 int* a, *b, *c; あほやろ わしは自身がハゲてきてビヨヨーン先生を師と仰ぐようになったから左寄せ派 俺も左寄せ派だわ。 *は明らかに型の一部なのに変数宣言のときだけ型でないふりしてるのがいただけない int *aを int* aと書きたい人は int (*f)()を int(* f)()と書けば満足するのだろうかという不思議はある そういうときこそtypedefですよ、ってことなんだろうか >>484 int*を返す関数じゃないんだから不思議はないと思うが >>486 なるほど int*p // 左に*寄せる int (*f)() // 寄せない int (*a)[42] // 寄せない int* (*f)() // 戻り値側だけ左に寄せる こういう感じでやっていくのかな いつも老害呼ばわりされてる俺が 今日ほどこいつら老害と思ったことはない Is int* p; right or is int *p; right? https://isocpp.org/wiki/faq/style-and-techniques#whitespace > The choice between int* p; and int *p; is not about right and wrong, > but about style and emphasis. C emphasized expressions; declarations > were often considered little more than a necessary evil. > C++, on the other hand, has a heavy emphasis on types. boost::format() が標準にとりこまれるのって、c++20 からでしたっけ? >>484 元からイケてない変数宣言の文法を部分的にどうにかすっきり見せる って程度の話なんで、複雑な事例を更に複雑にするような変なルール にしたいわけではない。 C++ 的な方向に振るなら int (*f)(); は std::add_pointer_t<int()> f; か std::decay_t<int()> f; かなぁ……。 冗長だけど変に入り組んだ感じがなくなるので type_traits はそれなりに取り入れてもいいと思うよ。 >>492 std::format は boost::format とはだいぶん違うように見えるが。 でもまあ std::format が出来たのは C++20 からではあるよ。 >>495 ありがとうございます 今回は sprintf() で妥協します… sprintf_s()と_countof()をセットで標準にしてホスイ >>497 C だと _countof に相当するものは欲しいなと思うが、 C++ 的には std::size か std::extent を使いたまえ。 >>493 >元からイケてない変数宣言の文法を部分的にどうにかすっきり見せる 一般的なポインタを表現するためには、どうしても、宣言子の中にも型の一部を 書くべきだったので、文法がそのように選択され、 int* a; ではなく、 int *a; と書く方がその記法と統一感がある。 数学者や物理学者は一般性や統一性がある方が美しいと感じる人が多いと 言われており、通常、数物の世界で「美しい」というのは、統一性のある 書き方。 なので、C/C++の型でも、後者の方が美しく感じるのが数物系の才能がある 人の感覚。 >>496 どんな判断だよ libfmt使えばいいじゃん >>499 ポインタだけでなく、配列も、 int a[3]; の様に書く。これも、人気言語であったBASIC言語の DIM a(3) と似た感覚となっている。 配列はもちろん型の一部ではあるが、これを int[3] a; と書いて分かり易いとは限らない。というのは、 配列を使う場合には、BASICの場合ではa(i)、Cの場合では、a[i]のように書くので、 これも、宣言に置いても、BASICやCの書き方の方が分かり易いと思うのも自然。 それに int *ptr_s[3]; // (100) のような場合に、分かり易く型を全て左に書くのは難しい。 書くとすれば、 int*[3] ptr_s; となるが、これが果たして分かり易いかと言えばNoだろう。 使う場合には、ptr_s[i] が int へのポインタになるのだから、 (100)の記法は至って分かり易い。 >>499 > どうしても、宣言子の中にも型の一部を書くべき それを前提とするならそれと一貫させることを俺は否定してない。 でも前提とできないよねという話をしてるんだから なんで「べき」なのかを説明しないとなんの主張にもなってないよ。 >>501 さらにいえば二次元配列の場合、宣言は、 int a[3][2]; //C。使う場合は a[i][j] DIM a(3,2); //BASIC。使う場合は、a(i,j) となるが、もしCで型を全て左に書くとすれば、 int[3][2] a; となると思うかもしれないが、これは、数学的な統一性からすれば 間違いで、正しくは、 int[2][3] a; となり、前後を逆に書くのが「正しい」。 これが即座に理解できる人が数学的才能が有る人で、 教えてもらわないと分からない人才能が無い。 >>502 Cの記法は、物理学で言うところの「組立単位」に相当する「組み立て型」を 一般的に表現するためには、かなり美しく正しい選択をしている。 int *a[10]; // (1) int (*a)[10]; // (2) と は、物理学のように言えば、int-ptr-array-aとint-array-ptr-aの違いを 表しているが、Cの表現はとても理にかなっており非常に分かり易い。 これらの型を全てまとめて左に書こうとすれば、書くことは出来て、 int*[10] a; // int-ptr-array-a, (10) int[10]* a; // int-array-ptr-a, (11) となるが、果たしてこれが分かり易いかどうかと言う問題となる。 それぞれを使う際の a[i] や、*a の表記と(1), (2)に上手く対応しているので、 (10),(11)よりも統一が取れており、数学的には「美しい」状態となっている。 >>502 それは、>>503 や >>504 のようなことがあるから。 >>502 C言語のように「書くべき」ことが分かる一番分かり易い例は、Cで int a[1][2][3][4]; と書くものが、全部左に型を書く記法だと int[4][3][2][1] a; と書かないと、組み立て型(物理学における「組立単位」に相当)における 一般性を失うが、それだと、使う際の a[i1][i2][i3][i4]と要素数の指定とが 直感的に逆さまになってしまう問題が起きる。 もし、 int[1][2][3][4] a; のように書くと、一般性を失い、組み立て型としては破綻しまい、その場しのぎの 記法となってしまう。 もしこれが理解できないのなら、悪いけど、数学的才能や、コンパイラを設計する才能が無い。 じじいはこういう語りつくされた古い話題しか話せないからな 大工が金槌はこうでなくてはならない(家を作ったことない) クソみたいなマウント合戦を繰り広げる老害であることを自覚しろ >>504 数学的・物理的な美しさを (仮に (あくまでも仮に) その主張が妥当だとしても) C++ スレで根拠にするのが不思議。 そんな美しさなんてどうでもいいもの。 こちらの主張は 宣言の文法が型名とは別にある → その時点で一貫性なんてないよ → どちらを軸にすることもありうる → でもまあ C++ の発展の様子からすると型名を軸にしたさが見えるね って話で、現時点で無い文法を導入したいとか思っているわけでもないし、 存在する文法を絶対に駄目だというわけでもない。 とはいえ (話の大元に戻るが) 現在の C++ が typedef を冷遇しているので、 なるべく using を使ったほうがいいよねってだけ。 わしのFormatterは int* a; int *a, *b, c; のように整形しよる。これが落とし所として妥当であろう >>500 https://github.com/fmtlib/fmt でしょうか?github になれてなくて、これを使う方法もよくわからないし… 20年使っている sprintf() でもういいや…って妥協してしまいました 手元のコンパイラは g++17, 職場のは g++11 だけれども、セキュリティが堅くて「無断で」cygwin をアップデートさせてもらえない… 必要に迫られて徹夜して間に合わせたけれども、プログラミングへの集中力はずいぶんと落ちてしまいました… コメントありがとうございました >>506 auto signal(int, void(*fp)(int)) -> decltype(fp); //こう書かれたら「破綻」で読めなくなるのか? おまえさんは それこそC++11のグラマーが読めない、つまり数学的才能に乏しいことになるぞ >>512 あいつ結局Cの文法と設計思想を説明してるだけだよな それをC++11の文法と設計思想を否定する根拠にしようとしているようだが 筋違いというか脈絡がない ぼくはusing使いたくないんだーtypedef使うのを邪魔すんなー 僕はものすごく数学と物理に詳しいんだーセンスないやつうるせー 数学や物理学は、2000年以上も続く巨大なエコシステムを持っており、 それ以上簡潔にならないくらいな表現方法を発明済み。 それとは別の表現をしてもそれらを超えることはまず不可能で、文系の人達の 自己満足に過ぎない。 思っクソ関係ない 話せば面白そうな気がしたがそっちへ行くのね あーあ残念 最近の「モダン」言語は、既存のものを知らずに新しいものを作ろうとする傾向が目立つ。 彼らは、今までの理論などそのメリットが理解出来ておらず、効率の悪い、 分かりにくい、整合性の無い、その場しのぎで、一般性が無い記法を導入する。 >>503 えっ? そもそも int a[2][3]; //C。使う場合は a[j][i] DIM a(3,2); //BASIC。使う場合は、a(i,j) じゃないのかな >>499 は支持する >>506 ここもおかしい 元々 int a[4][3][2][1]; と書くべき 分かりにくい文法で自爆ってダサすぎるなw そもそもC++なのに素の多重配列使うって センスなさすぎだし >俺は数学が好きで、学生時代、ほぼ満点だった。 数物系が得意な人が、こんな馬鹿っぽくて曖昧な書き方するのかね? この情報でどうやってお前の能力を推し量れと >>493 なんでもテンプレートに書き直せばいいってもんでもない CでもそうだけどC++を使うからにはC++らしく使いたいね C訛りのたどたどしいC++からは早く脱したい Cで憶えたことがとりあえず使えるのがC++に用意された入りやすい門ではあるけどね そこは振り出しでしかないんだよ >>493 みたいなのをC++らしい、と思ってるならだいぶアレだけどな 仕事で使うならBetter Cで留めるのが正しいC++の使い方。 >>493 > std::add_pointer_t<int()> f; > std::decay_t<int()> f; (´・∀・`)ヘー そんなんあるんですね 勉強になりました >>529 凄くC++らしいと思うけどw 意地でもテンプレートで何とかしようというのは >>524 確かに、数物系に「特異」な人のコメントにしては貧弱だなあと、私も思いました たとえばガロア理論、とか、相対性理論、超弦理論、とか、を熱っぽく語って欲しいです 個人的にはエルゴート理論について薀蓄を知りたいですね >>527 でも iostream は失敗作という気がふつふつと…(略) c++らしいって言っても時代によってかなり変わるし無意味な言い回しだわ。 時代によってかなり変わるの? C++98以降しか知らないけど C++らしさ=テンプレート と断言していいほどの一点張りだと思うけど(個人の感想です) ここまで喧喧諤諤の多くの意見が飛びかっておるが iostream は要らん子、というのは一致しておるな とくに operator << >> 系のやつ coutで出力するよりstd::stringに一旦文字列化してからprintf()で出した方が速いという時点で以下略 個人的には iostream をそこそこ好きなんだが、 今だったらこんな設計はしないだろうなというのはとてもよくわかる。 >>535 互換性を捨てられない以上は汚い部分も捨てられないんだよね。 だからどうやって抽象化層をかぶせるか、もっと直接に言えば 汚い部分をどう隠すかというのが C++ らしさじゃないかな。 そして型 (または型の表記) に関して汚い部分を隠す道具としては テンプレートは特に有用なもののひとつだとは思う。 ただ、一点張りは言い過ぎで、取れる手段、手数の多さも C++ らしさだというのが私の感想。 組み合わせよう。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる