C++相談室 part152

**デフォルトの名無しさん** · 2020/07/12(日) 13:42:20.13

https://mevius.5ch.net/test/read.cgi/tech/1589424805/

**デフォルトの名無しさん** · 2020/09/21(月) 20:04:55.13

>>425
現行のLLVMとかによる最適化なら知ってるけど、まだ実現されてないAIによる最適化ってなにかなぁと思って。

**デフォルトの名無しさん** · 2020/09/21(月) 20:11:19.83

typedefがわかりにくいのではなくてC言語以来のポインタ定義構文がおかしいんである
これは聖典『プログラミング言語C』でも「批判を浴びることがある」みたいに書かれている

これはどうせCベースの言語なら乗り越えねばならない関門なのでノーカンとして、
単に型のエイリアスが欲しいときはtypedefで十分やし、
定義型をテンプレートにしたいとか別の型にしたいときはクラスにしたら宜しい
かと

**デフォルトの名無しさん** · 2020/09/21(月) 20:12:23.44

普通に考えて
機械語を入力としてそれと等価で高速に動作する機械語を出力する
作業をAIに任せるってことなんじゃないの（たぶん）

**デフォルトの名無しさん** · 2020/09/21(月) 20:13:49.74

同じことをするのにいくつも書き方があるようだと
C++はますますプログラミング言語界のPerlになってしまうま、

**デフォルトの名無しさん** · 2020/09/21(月) 20:19:15.08

AIによる最適化はそもそも最適な最適化が何なのかは計算不能（コルモゴロフ複雑性
というのはどうすんじゃ………

**デフォルトの名無しさん** · 2020/09/21(月) 20:20:24.50

>>428
ごめんね、喧嘩売ってるつもりじゃないんだ。
コンパイル最適化技術は興味あるんだけど俺の知識が数年前で止まってるので新しい知識として取り入れたかっただけ。

>機械語を入力としてそれと等価で高速に動作する機械語を出力する
それってAIと関係なく何十年も前からあるなんの変哲もない最適化だと思うの。

**デフォルトの名無しさん** · 2020/09/21(月) 20:27:18.34

>>423
最適化の為だけにC/C++使ってるわけじゃない
ハードを直接触る必要があるから使うというのもあるし
まあAdaとかでもいいんだけどさすがに使える人が少なすぎる

**デフォルトの名無しさん** · 2020/09/21(月) 20:29:32.74

>>428
AIなら何でも解決するとか思ってそうw

**デフォルトの名無しさん** · 2020/09/21(月) 20:32:17.31

>AIによる最適化はそもそも最適な最適化が何なのかは計算不能
AIって解析的に解くわけじゃないから計算不能でもいい感じに動いてくれるんじゃないの

>それってAIと関係なく何十年も前からあるなんの変哲もない最適化だと思うの。
最適化技術は素人だから知らないけど現状が割と決まった最適化ルールに当てはめてる
だけだとしたら改善の余地はあるんじゃないのかな
想像だけど

**デフォルトの名無しさん** · 2020/09/21(月) 20:33:13.25

>>433
わりとまじでそう思ってるけど

**デフォルトの名無しさん** · 2020/09/21(月) 20:39:34.82

もちろん、LLVMのようにJITの結果をAOTしてくれるような俺の脳味噌で考えられる最大限の最適化より、もっと進んだ技術が将来的に出てくるとは思うんだよ。
最近そういう技術から離れてたので、俺の知らないうちに新しいブレークスルーがあったのかと思って純粋な興味で質問しました。

**デフォルトの名無しさん** · 2020/09/21(月) 21:20:09.92

>>419
それを言うならこっちでしょ
template <typename T>
auto func(T&&) -> enable_if_t<is_integral_v<T>, void> {}

これとどっちが合理的だと思う？
template <typename T>
enable_if_t<is_integral_v<T>, void> func(T&&) {}

typedefとusingの話ではないけど
合理性という論点では同じことだよ

**デフォルトの名無しさん** · 2020/09/21(月) 21:21:22.91

>>418
そう、だからtypedefはもういじるのやめてtemplate化はできないまま放置されてるんだよな

**デフォルトの名無しさん** · 2020/09/21(月) 21:22:17.03

>>435
ああなるほど、納得したわ
君の思うように進めばイイねw

**デフォルトの名無しさん** · 2020/09/21(月) 21:25:30.85

深層学習、機械学習のことをざっくりAIと呼ぶ人は
まぁおおよそ技術わかってない人だろうね

**デフォルトの名無しさん** · 2020/09/21(月) 21:36:38.22

プログラミングを知らない人が「こんぴゅーたって何でも出来るんでしょ」って言ってるのと似てる

**デフォルトの名無しさん** · 2020/09/21(月) 21:39:42.46

>>441
そう聞こえちまう発言を見かける頻度が高すぎてやだよな

**デフォルトの名無しさん** · 2020/09/21(月) 21:40:29.70

>>437
「それを言うならこっちでしょ」の意味も
「合理性という論点では同じ」の意味も
「文法的に非合理的」の意味も全て分かりませんでした

**デフォルトの名無しさん** · 2020/09/21(月) 21:55:50.30

>>443
では言い方を変えようか
関数識別子でも型識別子でもそれを一覧しやすいところに集めやすいことを合理性と言っている
概要と詳細はどっちを先に書くべきかってことだよ

typedefは右端に宣言対象の識別子
usingは左端から７文字目という決まった位置に宣言対象の識別子
trailing-return-typeも５文字目という決まった位置に宣言対象の識別子がある
可読性という観点からどう思う？

**デフォルトの名無しさん** · 2020/09/21(月) 22:03:23.74

typedefは変数宣言を流用した手抜きだからこんな糞みたいなのも書けてしまう

typedef int are, kore, sore, dore, *hare, **yore, (*more)(float, long), (*ore)[42];

**デフォルトの名無しさん** · 2020/09/21(月) 22:18:42.28

typedef int (*more)(float, long); //この書き方に抵抗は全くないが
using more = int (*)(float, long); //それでも俺はこっちが好き

**デフォルトの名無しさん** · 2020/09/21(月) 22:19:03.41

>>445
その点については統一感あってむしろ美しいと思うけどｗ
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;
}

**デフォルトの名無しさん** · 2020/09/21(月) 22:21:35.15

int are, kore;
変数のareとkoreが本質的に同じ型であることが重要なときに統一できるのはいいけどね
intの同義語をそんなに量産してどうするんだと

**デフォルトの名無しさん** · 2020/09/21(月) 22:22:41.71

usingとtypedefでいうと関数ポインタ、配列の扱い違うよね
あのあたりよくわかってない
誰か解説して

**デフォルトの名無しさん** · 2020/09/21(月) 22:34:38.79

>>440
まるでさも自分がわかってるみたいな言い方

**はちみつ餃子** ◆8X2XSCHEME · 2020/09/21(月) 22:58:02.34

別のスレでちょっと書いたことがあるが……。
人工知能 (AI) ってのは人間の知能を代行するものという意味合いで私は考えてる。

昔はコンパイラそのものが人工知能の枠内で扱われていたこともある。
それ以前にルールベース、つまり if 文の羅列のようなものまで人工知能の一種だった。

でもそれらが分野として確立されたら人工知能とは呼ばれなくなっていた。
機械でやるのが当たり前のものになったから。
普通の道具になったから「知能」ではなくなったんだ。

人工知能を実用化するってのは人工知能を人工知能でなくすること。
逆に言えば人工知能と呼ばれている間は曖昧模糊としてよくわからんのが当たり前なんだと思う。

これはいろんな使い方をされる「人工知能」という言葉について私なりの解釈であって
正しさを主張するつもりはないが、それなりに実態に合った解釈ではあると思う。

**デフォルトの名無しさん** · 2020/09/21(月) 23:08:20.77

かなり酔ってるな
ビール？　今日何本目？

**デフォルトの名無しさん** · 2020/09/21(月) 23:08:24.99

そんなこねくり回した理解いる？
たんなる学術分野を指すだけの言葉じゃん
意味が広いだけ

**はちみつ餃子** ◆8X2XSCHEME · 2020/09/21(月) 23:13:49.84

>>452
ワイン。一杯目の終わりの方。

でもまあ前に別スレでも書いた内容だから酔って考えてるというわけでもない。
と思ったけど前に考えてたときも酔ってたかもしれん。

**デフォルトの名無しさん** · 2020/09/21(月) 23:33:11.93

最適化方面へのAIの適用というと、
高度なルールベース（80年代のAI）までいったん後退したものに
収束が必ずしも保障されない最適化処理（有限ステップで終わる保証がないからもはやアルゴリズムと呼ぶのは抵抗があるがGAとか
を組み合わせたものになりそうなﾖｶﾝ

FPGAの論理合成エンジンみたいなやつを考えたら宜しいかと、
もはや冪等性は気体できない
ビルドをやるたびに結果が変わるorz

**デフォルトの名無しさん** · 2020/09/21(月) 23:38:03.83

この場合LPはAIに含めて良いものかどうか、

**デフォルトの名無しさん** · 2020/09/22(火) 01:59:39.72

>>418 >>438
それを知らずに議論するやつが居ると思ってるのか・・・

**デフォルトの名無しさん** · 2020/09/22(火) 02:02:23.48

>>447
やめてくり～

**デフォルトの名無しさん** · 2020/09/22(火) 03:43:14.70

文字列の内容を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++;
}

**デフォルトの名無しさん** · 2020/09/22(火) 03:58:17.38

datalistに行ごとに抽出するならiとj逆のような気もするけど
とりあえずdatalistの方にも、各行の終わりに\0(文字列の終端)が必要じゃね？
ゼロ終端文字列として扱わないとか、最初にmemsetしてるなら別だけど

**デフォルトの名無しさん** · 2020/09/22(火) 04:01:42.12

>>459
こんなプログラム書いてるようじゃ無理

**デフォルトの名無しさん** · 2020/09/22(火) 04:05:50.78

>>449
違わない

**デフォルトの名無しさん** · 2020/09/22(火) 04:30:48.29

>>457
逆にいなかったと思ってるなら日本語の
勉強からやり直してくださいｗ

**デフォルトの名無しさん** · 2020/09/22(火) 07:14:47.66

>>443
で、意味通じたのかな？
君の見解が聞きたいんだが

**デフォルトの名無しさん** · 2020/09/22(火) 08:00:49.11

>>459
このレベルで人に聞いてるようでは使い物にならんな

**デフォルトの名無しさん** · 2020/09/22(火) 09:27:17.92

>>459
https://ideone.com/CwLwnB

**デフォルトの名無しさん** · 2020/09/22(火) 10:13:21.77

>>417
それのどこが非合理なのか全く分からない。
ちなみに、俺は数学が好きで、学生時代、ほぼ満点だった。

**デフォルトの名無しさん** · 2020/09/22(火) 10:52:41.92

>>467
>444 を読むと、言いたかったことはわかる。
> 関数識別子でも型識別子でもそれを一覧しやすいところに集めやすいことを合理性と言っている

言葉のチョイスはおかしいと思うけどね。単に「読みやすさ」「読みにくさ」とか言えばよかったところ。

**デフォルトの名無しさん** · 2020/09/22(火) 10:52:56.79

>>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);

**デフォルトの名無しさん** · 2020/09/22(火) 15:44:58.47

>>468
個人的に数学記号のようなもの解読する値から強い方だからかも知れないが、
usingがtypedfよりも特に読みやすいとさえ思わない。
ただし、
#define 名前定義内容
と
using 名前 = 定義内容;
で順序に対応関係が有ることはある。
しかしながら、C/C++では、
型名変数名;　// (100)
の順序な分けで、LL言語に多い、
var 変数名 : 型名;
の順序ではないので、統一と言う点では、typdefは(100)と美しく統一されている。

**デフォルトの名無しさん** · 2020/09/22(火) 15:58:07.27

ほぼ満点だったってネタじゃなかったのかよwww

**デフォルトの名無しさん** · 2020/09/22(火) 16:00:22.94

typedef int (*funcA)(float, long), (*funcB)(float, long), (*funcC)(float, long);
↑
の代わりに
typedef int (*(funcA, funcB, funcC))(float, long);
とか描けないよな

**デフォルトの名無しさん** · 2020/09/22(火) 16:17:29.92

>>464
通じませんでした
しかしこれ以上興味も維持できませんので
この話はここで閉じさせてください
レスしてもらったのに申し訳ないです

見解は元の>>416さんにでも尋ねてみてください

**443** · 2020/09/22(火) 16:18:39.11

メール欄と名前欄間違えた

**はちみつ餃子** ◆8X2XSCHEME · 2020/09/22(火) 16:34:37.47

>>470
> しかしながら、C/C++では、
> 型名変数名;　// (100)
> の順序な分けで

「型名変数名;」ではなく「型指定子宣言子;」な。
(実際には宣言子は複数書けるがそれはわきに置く。)
順序はある程度は好みだろうとは思うが、
変数を宣言するにあたって「型名を与えているわけではない」んだ。

たとえばポインタ型の変数だと

int* a;

みたいに宣言できるが、
このとき int という型指定子と *a という宣言子から成る。
a の型名は int* であるが、
宣言のときには int は型指定子の側について * は宣言子の側についてるわけ。

typedef は変数宣言の文法と一致させているという意味では一貫していることに合意するが、
そもそも型名を途中で分断するかのような変数宣言の文法がイケてないので、
そっちで統一するのが本当にうれしいのかね？という点で疑問を提示する。

いや、それでうれしいというのならそれでもいいんだが、
前提がそれほど一貫してないのに一貫性をもちだしても仕方なくね？

**デフォルトの名無しさん** · 2020/09/22(火) 16:38:32.20

>>475
すまんが、個人的には、
int *ptr;
を
int* ptr;
と書く人は頭が悪いのかな、と思っていつも見ている。

**デフォルトの名無しさん** · 2020/09/22(火) 16:43:05.81

int* a;
int* b;
int c;
//int[42] d;
↑こう書きたいという勢力と…

int *a, *b, c, d[42];
↑こう書きたいという勢力があるんやろね

好みというかその人のバックグラウンドというか

**はちみつ餃子** ◆8X2XSCHEME · 2020/09/22(火) 16:48:28.25

>>476
* は (文法的には) 宣言子の側についてるからそちらにくっつくもんなんだろうが、
型名としては int* だから int* と書く方が好ましいと考えている。
文法的な解釈はともかく「型名変数名;」に近い書き方の方がわかりやすいという考え方だ。

あと、 C++ の設計者自身が * を左に寄せる書き方をしてるから私はそれに巻かれている。
C として書くときは * は変数名の側にくっつけて書くようにしてる。 (K&R ではそういう書き方になってるので。)
* の両側に空白を入れる流儀も存在するようだ。

**デフォルトの名無しさん** · 2020/09/22(火) 17:23:35.93

>>478
>あと、 C++ の設計者自身が * を左に寄せる書き方をしてるから私はそれに巻かれている。
>C として書くときは * は変数名の側にくっつけて書くようにしてる。 (K&R ではそういう書き方になってるので。)

Cの設計者は数学的、C++の設計者は凡才的。

**デフォルトの名無しさん** · 2020/09/22(火) 18:25:41.01

>>476
+1
ほんそれ
stroustrupは頭が●照る

**デフォルトの名無しさん** · 2020/09/22(火) 18:27:35.58

>>478
int* a, *b, *c;
あほやろ

**デフォルトの名無しさん** · 2020/09/22(火) 18:44:14.87

わしは自身がハゲてきてビヨヨーン先生を師と仰ぐようになったから左寄せ派

**デフォルトの名無しさん** · 2020/09/22(火) 19:04:01.34

俺も左寄せ派だわ。
*は明らかに型の一部なのに変数宣言のときだけ型でないふりしてるのがいただけない

**デフォルトの名無しさん** · 2020/09/22(火) 19:05:41.48

int *aを
int* aと書きたい人は
int (*f)()を
int(* f)()と書けば満足するのだろうかという不思議はある
そういうときこそtypedefですよ、ってことなんだろうか

**デフォルトの名無しさん** · 2020/09/22(火) 19:07:53.44

古典ネタはもうええっちゅうねん

**デフォルトの名無しさん** · 2020/09/22(火) 19:09:48.55

>>484
int*を返す関数じゃないんだから不思議はないと思うが

**デフォルトの名無しさん** · 2020/09/22(火) 19:13:34.90

時代はauto

**デフォルトの名無しさん** · 2020/09/22(火) 19:14:45.07

どうでもいいわ

**デフォルトの名無しさん** · 2020/09/22(火) 19:32:53.07

>>486
なるほど
int*p // 左に*寄せる
int (*f)() // 寄せない
int (*a)[42] // 寄せない
int* (*f)() // 戻り値側だけ左に寄せる
こういう感じでやっていくのかな

**デフォルトの名無しさん** · 2020/09/22(火) 20:39:49.00

いつも老害呼ばわりされてる俺が
今日ほどこいつら老害と思ったことはない

**デフォルトの名無しさん** · 2020/09/22(火) 22:46:59.09

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.

◆QZaw55cn4c · 2020/09/22(火) 23:08:52.68

boost::format() が標準にとりこまれるのって、c++20 からでしたっけ？

**はちみつ餃子** ◆8X2XSCHEME · 2020/09/22(火) 23:30:22.08

>>484
元からイケてない変数宣言の文法を部分的にどうにかすっきり見せる
って程度の話なんで、複雑な事例を更に複雑にするような変なルール
にしたいわけではない。

C++ 的な方向に振るなら int (*f)(); は
std::add_pointer_t<int()> f;
か
std::decay_t<int()> f;
かなぁ……。

冗長だけど変に入り組んだ感じがなくなるので type_traits はそれなりに取り入れてもいいと思うよ。

**デフォルトの名無しさん** · 2020/09/22(火) 23:33:23.38

boost？libfmtじゃねーの？

**はちみつ餃子** ◆8X2XSCHEME · 2020/09/22(火) 23:37:01.31

>>492
std::format は boost::format とはだいぶん違うように見えるが。
でもまあ std::format が出来たのは C++20 からではあるよ。

◆QZaw55cn4c · 2020/09/23(水) 00:15:55.98

>>495
ありがとうございます
今回は sprintf() で妥協します…

**デフォルトの名無しさん** · 2020/09/23(水) 01:33:58.69

sprintf_s()と_countof()をセットで標準にしてﾎｽｲ

**はちみつ餃子** ◆8X2XSCHEME · 2020/09/23(水) 01:40:34.94

>>497
C だと _countof に相当するものは欲しいなと思うが、
C++ 的には std::size か std::extent を使いたまえ。

**デフォルトの名無しさん** · 2020/09/23(水) 01:44:08.47

>>493
>元からイケてない変数宣言の文法を部分的にどうにかすっきり見せる
一般的なポインタを表現するためには、どうしても、宣言子の中にも型の一部を
書くべきだったので、文法がそのように選択され、
int* a;
ではなく、
int *a;
と書く方がその記法と統一感がある。
数学者や物理学者は一般性や統一性がある方が美しいと感じる人が多いと
言われており、通常、数物の世界で「美しい」というのは、統一性のある
書き方。
なので、C/C++の型でも、後者の方が美しく感じるのが数物系の才能がある
人の感覚。

**デフォルトの名無しさん** · 2020/09/23(水) 01:47:03.11

>>496
どんな判断だよ
libfmt使えばいいじゃん

**デフォルトの名無しさん** · 2020/09/23(水) 01:50:27.78

>>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)の記法は至って分かり易い。

**はちみつ餃子** ◆8X2XSCHEME · 2020/09/23(水) 01:55:10.68

>>499
> どうしても、宣言子の中にも型の一部を書くべき

それを前提とするならそれと一貫させることを俺は否定してない。
でも前提とできないよねという話をしてるんだから
なんで「べき」なのかを説明しないとなんの主張にもなってないよ。

**デフォルトの名無しさん** · 2020/09/23(水) 01:55:45.37

>>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;
となり、前後を逆に書くのが「正しい」。
これが即座に理解できる人が数学的才能が有る人で、
教えてもらわないと分からない人才能が無い。

**デフォルトの名無しさん** · 2020/09/23(水) 02:05:33.12

>>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)よりも統一が取れており、数学的には「美しい」状態となっている。

**デフォルトの名無しさん** · 2020/09/23(水) 02:18:13.45

>>502
それは、>>503 や >>504 のようなことがあるから。

**デフォルトの名無しさん** · 2020/09/23(水) 02:24:26.38

>>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;
のように書くと、一般性を失い、組み立て型としては破綻しまい、その場しのぎの
記法となってしまう。
もしこれが理解できないのなら、悪いけど、数学的才能や、コンパイラを設計する才能が無い。

**デフォルトの名無しさん** · 2020/09/23(水) 02:24:53.28

どうでもよい

**デフォルトの名無しさん** · 2020/09/23(水) 02:27:39.29

じじいはこういう語りつくされた古い話題しか話せないからな

**デフォルトの名無しさん** · 2020/09/23(水) 02:55:43.29

大工が金槌はこうでなくてはならない（家を作ったことない）

**デフォルトの名無しさん** · 2020/09/23(水) 02:56:47.86

この手の輩はいないほうがいい
邪魔

**デフォルトの名無しさん** · 2020/09/23(水) 02:58:20.51

クソみたいなマウント合戦を繰り広げる老害であることを自覚しろ

**はちみつ餃子** ◆8X2XSCHEME · 2020/09/23(水) 02:59:44.49

>>504
数学的・物理的な美しさを (仮に (あくまでも仮に) その主張が妥当だとしても) C++ スレで根拠にするのが不思議。
そんな美しさなんてどうでもいいもの。

こちらの主張は

宣言の文法が型名とは別にある
→ その時点で一貫性なんてないよ
→ どちらを軸にすることもありうる
→ でもまあ C++ の発展の様子からすると型名を軸にしたさが見えるね

って話で、現時点で無い文法を導入したいとか思っているわけでもないし、
存在する文法を絶対に駄目だというわけでもない。

とはいえ (話の大元に戻るが) 現在の C++ が typedef を冷遇しているので、
なるべく using を使ったほうがいいよねってだけ。

**デフォルトの名無しさん** · 2020/09/23(水) 04:12:53.08

わしのFormatterは
int* a;
int *a, *b, c;
のように整形しよる。これが落とし所として妥当であろう

◆QZaw55cn4c · 2020/09/23(水) 05:07:59.09

>>500
https://github.com/fmtlib/fmt
でしょうか？github になれてなくて、これを使う方法もよくわからないし…
20年使っている sprintf() でもういいや…って妥協してしまいました
手元のコンパイラは g++17, 職場のは g++11 だけれども、セキュリティが堅くて「無断で」cygwin をアップデートさせてもらえない…
必要に迫られて徹夜して間に合わせたけれども、プログラミングへの集中力はずいぶんと落ちてしまいました…

コメントありがとうございました

**デフォルトの名無しさん** · 2020/09/23(水) 07:58:28.38

>>506
auto signal(int, void(*fp)(int)) -> decltype(fp); //こう書かれたら「破綻」で読めなくなるのか？　おまえさんは
それこそC++11のグラマーが読めない、つまり数学的才能に乏しいことになるぞ

**デフォルトの名無しさん** · 2020/09/23(水) 08:04:19.35

>>512
あいつ結局Cの文法と設計思想を説明してるだけだよな
それをC++11の文法と設計思想を否定する根拠にしようとしているようだが
筋違いというか脈絡がない

ぼくはusing使いたくないんだーtypedef使うのを邪魔すんなー
僕はものすごく数学と物理に詳しいんだーセンスないやつうるせー

**デフォルトの名無しさん** · 2020/09/23(水) 09:08:00.93

数学や物理学は、2000年以上も続く巨大なエコシステムを持っており、
それ以上簡潔にならないくらいな表現方法を発明済み。
それとは別の表現をしてもそれらを超えることはまず不可能で、文系の人達の
自己満足に過ぎない。

**デフォルトの名無しさん** · 2020/09/23(水) 09:23:45.36

思っクソ関係ない
話せば面白そうな気がしたがそっちへ行くのね
あーあ残念

**デフォルトの名無しさん** · 2020/09/23(水) 09:33:29.79

最近の「モダン」言語は、既存のものを知らずに新しいものを作ろうとする傾向が目立つ。
彼らは、今までの理論などそのメリットが理解出来ておらず、効率の悪い、
分かりにくい、整合性の無い、その場しのぎで、一般性が無い記法を導入する。

**デフォルトの名無しさん** · 2020/09/23(水) 09:58:47.10

つまんね

**デフォルトの名無しさん** · 2020/09/23(水) 10:19:32.59

>>503
えっ？
そもそも
int a[2][3];　//C。使う場合は a[j][i]
DIM a(3,2);　//BASIC。使う場合は、a(i,j)
じゃないのかな

>>499 は支持する

**デフォルトの名無しさん** · 2020/09/23(水) 10:22:59.31

>>506
ここもおかしい

元々
int a[4][3][2][1];
と書くべき

**デフォルトの名無しさん** · 2020/09/23(水) 11:04:51.52

分かりにくい文法で自爆ってダサすぎるなw
そもそもC++なのに素の多重配列使うって
センスなさすぎだし

**デフォルトの名無しさん** · 2020/09/23(水) 12:28:26.75

>俺は数学が好きで、学生時代、ほぼ満点だった。

数物系が得意な人が、こんな馬鹿っぽくて曖昧な書き方するのかね？
この情報でどうやってお前の能力を推し量れと

**デフォルトの名無しさん** · 2020/09/23(水) 12:31:30.53

正直マジレスするアホが居るとは思いもよらなんだ