C++相談室 part152

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

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

**デフォルトの名無しさん** · 2020/09/13(日) 23:14:53.91

./hello < hello.txt > hello.txt

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

Pythonで書いたGUIアプリをC++で書き直す日々が始まるお(*´ω｀*)

**デフォルトの名無しさん** · 2020/09/14(月) 03:28:48.08

イテレータを i 個分進める (戻す) のって i 回インクリメント (デクリメント) するしかないの？

一気に進める方法があったら教えて下さい

**デフォルトの名無しさん** · 2020/09/14(月) 03:32:02.02

ああvectorならできてsetなら無理ってことか
ググったらわかりました
すみませんでした

**デフォルトの名無しさん** · 2020/09/14(月) 08:44:25.84

>>340
わざとやってみたことあるけど
途中で飽きてきてCtrl+C
うすらでかいファイルができていた

ずーっと放置するとHDDの空き容量がなくなって
stdoutへの書き込みが失敗するようになるはず
それがOSのファイルにも使うドライブだとシステムダウンして
親ガメこけたら皆こけただね

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

>>346
つstd::next
自分で増分するのに比べて早くはならないと思う

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

>>334

**デフォルトの名無しさん** · 2020/09/14(月) 10:42:29.67

>>346
advance

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

typedef struct HOGE
{
　int x;
　int y;

　HOGE(int x, int y)
　{
　　this->x = x;
　　this->y = y;
　}
} hoge_t;

class TEST {
　hoge_t h(1, 2); // expected identifier before numeric constant
}

で、// のとおりエラーが出てしまいます。
typedef struct と class の違いが理解できていないのが悪いのですが
メンバ変数として利用するとき初期化は出来ないのでしょうか。

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

>>351
丸括弧じゃなくブレースだよ
それとTESTの最後にセミコロンがない

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

>>351
初歩の初歩でつまづいとるな
クラスの直下にプロセスを書けるとでも思っているところとか初心者スレ逝けばやさしいひとたちが教えてくれるぞこわっぱ

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

ブーメラン投げてんなよ
C++11からokになったの知らねえとか
勉強不足にも程があるだろうが

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

あっそっか
コレ、メンバの初期化してんのか
てっきり文かいてんのかとおもたわ
スマンスマン

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

そもそもプロセスなんてどこから出てきたんだ？

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

>>351
それは、恐らく昔のC++では動かなかったような非常にきわどい書き方をしている。
1. まず、クラス名をtypedef宣言しても、それをどの場所でもクラス名の変わりに
　使えるかどうかは、微妙。余り行われていないことで、よく調べてみないと分からない。
　特に、この例の様なコンストラクタによる初期化を伴う変数の宣言の場合には、
　当たり前のように出来るように見えて、コンパイラ作者目線では解析に負担がかかること。
2. static以外のメンバ変数(インスタンス変数)を、クラス宣言の中で直接初期化する
　書き方は、あるバージョン以降のC++でのみできるようになってきたはずで、
　その書き方に対応していないコンパイラだとエラーになる。

**デフォルトの名無しさん** · 2020/09/15(火) 17:03:32.49

>>357
1に関して。
まず、typedef宣言自体が、ポインタや配列や関数型などが複雑に絡んだ
「組み立て型」を簡単に表すためと、
C言語では、構造体型をそのまま型名として使うことができず、typedefを
使わなければ、「struct タグ名」とstructを省略できなかったので、
typedefが好んで使われた。

ところが、C++では、structやclassキーワードを書かなくても、いきなり
タグ名を書いても型名として扱われる。だから、class名/struct名を敢えて
typedef宣言する人は非常に少なくなった。なので、そのような書き方に
滅多に遭遇しないので、テスト不十分でコンパイラにバグが残っている可能性がある。

**はちみつ餃子** ◆8X2XSCHEME · 2020/09/15(火) 17:21:18.89

>>358
メンバ関数を含まない struct (つまりは POD) なら、
C のヘッダファイルとしても使えるように書く場合は珍しくもないと思うよ。

コンパイラのバグを心配し始めたらなんもできなくない？
主要なコンパイラでよほど長く改善できてないバグだったり、
(特殊な開発環境などで) 実際に使わざるを得ない特定のバージョンにバグがある
ことが分かっているときなら配慮もするけど、
普段の習慣として気にするほどのことじゃないでしょ。

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

hoge_t h = {1, 2};

で普通にコンパイル通るんだが
class TEST のインスタンスが造られる度に実行されるのか
それともあるインスタンスで変更されたら
次に造られるインスタンスは後者の値になるのか

**はちみつ餃子** ◆8X2XSCHEME · 2020/09/15(火) 17:33:54.20

>>360
TEST 型のオブジェクトが生成されるたびに h も生成されるよ。
TEST のコンストラクタで初期化するのと機能はなんも変わらん。

**デフォルトの名無しさん** · 2020/09/15(火) 17:49:15.00

実は、
z x(a,b);
の形式は、コンパイラが関数xのプロトタイプ宣言と、引数付きのコンストラクタ
呼び出しによる変数xの初期化の区別を付けるのが難しい例として知られている。
その区別は、基本的にはaの部分が型名なのか、型名でないのかで区別される。
それに加えて、zの部分にtypedef名を書くと、コンパイラはいろいろなことを配慮
しなくてはならなくなる。
関数のプロトタイプ宣言と、メンバ変数の定義では、コンパイルの流れが大きく変わるので、
なるべく早い段階でそれらを区別しなければならない。
余り深く解析しすぎてはコンパイル時間が増大してしまう。
だから、適度にヒューリスティックな方法で判別していることがある。
ヒューリスティックな方法なので、滅多に書かない特殊な書き方をした場合、間違えてしまう可能性があるかもしれない。

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

なんでここってそんな殺伐と喧嘩腰みたいなやつ多いの？
もっと柔らかくさ切磋琢磨してこうよ

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

class TEST {
hoge_t h;
TEST() : h{1, 2} {}
};
のほうがわかりやすくね

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

class TEST {
hoge_t h;
TEST() : h{1, 2} {}
};
のほうがわかりやすくね

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

うおダブルクリックしちゃった
てかJavaScriptで防止しとけよｗ

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

コンストラクタにpublicつけ忘れた

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

コードを書くとききは、最低限簡単なテストコードで
コンパイルが通るかどうか確認してから書きなさい
技術系ブログですらそのルール守ってない事があり
そういうブログはたいてい読むに値しない

**デフォルトの名無しさん** · 2020/09/15(火) 20:59:22.26

>>351

#include <iostream>
using namespace std;

struct Hoge{
int x;
int y;

Hoge(int x, int y){
this->x = x;
this->y = y;
}
};

int main() {
Hoge h(1, 2);
cout << h.x << endl;
return 0;
}

GVkKul - Online C++0x Compiler & Debugging Tool - Ideone.com
https://ideone.com/GVkKul

余り深く考えないならこんなんでいいんじゃなかろうか

**デフォルトの名無しさん** · 2020/09/15(火) 21:01:17.48

explicit Hoge(int x, int y)
にしろと言う派もいそう

**デフォルトの名無しさん** · 2020/09/15(火) 21:07:56.21

アホ人口が過密すぎ

**デフォルトの名無しさん** · 2020/09/15(火) 21:43:29.84

こうですか？
わかりません＞＜；

■ 小数を含む10進数の表記の再現に関する定理
有限桁の10進数で表記された非負の数x0をIEEE 754形式（2進数版）に変換して
xを得たとして、x0の最小の桁が10^mの位、xの仮数部のLSBが2^pの位ならば、
　　m > p * log10(2)
を満たす限り、xからx0の最小の桁まで正確に再現できる。

■ 証明
x0の最小の桁が10^mの位（10^mより小さい位が無い）ということは、
x0は周期10^mの格子点上にある。（kを適当な整数として、x0=k*10^mと表すことができる。）

一方、x0をxに変換する際、仮数部のLSBが丸めで繰り上がらなかったとすると、
　　x ≦ x0 ≦ x + 2^(p-1)
が成り立ち、仮数部のLSBが丸めで繰り上がった場合は
　　x - 2^(p-1) ≦ x0 ≦ x
が成り立つ。（全ての不等号が等号付きなのは、偶数丸めの可能性を考慮している。）
合わせると、どっちにせよ以下の式が成り立つ：
　　x - 2^(p-1) ≦ x0 ≦ x + 2^(p-1) -- (1)

x0が周期10^mの格子点上であることから、式(1)より
　　(2^(p-1) - (- 2^(p-1))) ＜ 10^m　　∴ m > 2 * log10(2)
であれば、xから式(1)を満たすx0が一意に定まり、
周期10^mの格子点上に位置する他の数と区別できる。
□

**はちみつ餃子** ◆8X2XSCHEME · 2020/09/15(火) 22:07:33.21

>>364
それはどうだろう。慣れという面は大きいと思うよ。

普通のローカル変数は変数の宣言と初期化は一体なわけだし、
その記法と一致させた方がよくない？ってのは有るでしょ。

でも初期化のタイミングが (ある程度は) 見かけ通りになって欲しいという感覚からは
コンストラクタの方で初期化した方が自然だよなってのも有る。

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

それもういいから

**はちみつ餃子** ◆8X2XSCHEME · 2020/09/15(火) 22:08:53.69

そういう感覚的な部分は置いてちょっと便利な使い方としては、
コンストラクタが複数あってそれぞれが初期化したい対象が違う場合に
共通する部分は宣言と同時に初期化するように書くという方法。

こんな感じね。

struct foo {
int mem_i = 1;
double mem_d = 2;
char mem_c = 3;

foo(int i) : mem_i(i) {}
foo(double d) : mem_d(d) {}
foo(char c) : mem_c(c) {}
};

以下のように書くよりはマシでしょ。

struct foo {
int mem_i;
double mem_d;
char mem_c;

foo(int i) : mem_i(i), mem_d(2), mem_c(3) {}
foo(double d) : mem_i(1), mem_d(d), mem_c(3) {}
foo(char c) : mem_i(1), mem_d(2), mem_c(c) {}
};

宣言と同時の初期化が書かれていてコンストラクタでも初期化が書かれているときは
コンストラクタでの初期化のみが有効になる。

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

今まで全部下の方法で書いてたわ
そしてやめる気もない

**はちみつ餃子** ◆8X2XSCHEME · 2020/09/15(火) 22:33:53.09

ただ、 >>375 にも良くない面はあって、
ヘッダファイルでクラス定義をして
コンストラクタの実装は .c に書いた場合、

// foo.h
struct foo {
int mem_i = 1;
double mem_d = 2;
char mem_c = 3;

foo(int i);
foo(double d);
foo(char c);
};

// foo.c
foo::foo(int i) : mem_i(i) {}
foo::foo(double d) : mem_d(d) {}
foo::foo(char c) : mem_c(c) {}

ヘッダファイルからは 1, 2, 3 で初期化するかのように見えて実際にはそう初期化しないことがある
ってのは混乱の元になるかもしれないと思う。

ワイとしてはどう運用 (使い分け) すればいいのかはっきりした見解を確立できてない。
どうすればいいんやろね？

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

struct foo {
int mem_i = 1;
double mem_d = 2;
char mem_c = 3;

foo(int i);
foo(double d);
foo(char c);
};
こういうことするとfooは文脈依存で意味が違う紛らわしい存在になる
このfoo自体存在しないでほしい

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

class foo {
foo(int i);
foo(double d);
foo(char c);

private:
int mem_i = 1;
double mem_d = 2;
char mem_c = 3;
};

これなら別にいいでしょ
全データメンバー丸出しの単純structに中途半端なコンストラクタ付けてるのが問題の本質に見える

**デフォルトの名無しさん** · 2020/09/15(火) 23:18:01.40

>>363
予想だけど実社会で蔑まれてる弱者で
こういうとこで憂さ晴らしをしてるんだろう

**デフォルトの名無しさん** · 2020/09/16(水) 01:22:34.43

>>363
誰に対していってるのか知らないけど、>>362は普通に書いただけだよ。

**デフォルトの名無しさん** · 2020/09/16(水) 06:20:12.78

カリー化して畳み込む。

**デフォルトの名無しさん** · 2020/09/16(水) 07:41:27.27

>>364
C++03にしがみついてるだけじゃん

>>377
初期化子にデフォルトがあるってだけだろ
関数引数のデフォルトで混乱するやついないのと同じ

**デフォルトの名無しさん** · 2020/09/16(水) 11:12:27.74

>>375 >>377 みたいな初期化してるとき
どんな getter が定義されるのか興味ある

**デフォルトの名無しさん** · 2020/09/16(水) 20:55:15.73

>>341,342,347
へえありがとう

**デフォルトの名無しさん** · 2020/09/17(木) 00:12:18.70

というわけで自己解決しますた！
https://ideone.com/Zz21oH

仕様としては15桁以内の10進数で、IEEE 754で表せる範囲で、
なおかつ最小桁の位が10^0以下だったら何でもおk
（原理上は最小桁の位は10^0より上でも逝けるやつは作れるが今回はパス

**デフォルトの名無しさん** · 2020/09/17(木) 16:47:32.96

いまいち、つまらんかった

**デフォルトの名無しさん** · 2020/09/17(木) 17:47:56.72

まぁ証明自体はいいと思うよ
あってるか知らんけど

あとはがんばって
>>279 の10億行の手入力のテストデータが確実に
15桁以内の10進数であるか確認しないとな
そこをスクリプトにするぐらいなら最初から書き換え案でよかったよな

**デフォルトの名無しさん** · 2020/09/17(木) 22:51:21.16

彼の手入力は完璧だから確認とか必要ないらしいぞ

**デフォルトの名無しさん** · 2020/09/17(木) 23:19:34.76

それはbionicだな

**351** · 2020/09/20(日) 10:14:33.56

色々とありがとうございました。

class TEST {
　hoge_t h(1, 2); // expected identifier before numeric constant
};

の部分を

class TEST {
　　HOGE h(1, 2);
};

にしたら大丈夫になりました。（hoge_t を使わないで HOGE のほうを）
ここで疑問が出ました。

typedef struct HOGE
{
　　...
} hoge_t;

の HOGE と hoge_t の違いはなんでしょうか。
片方がなくても動くようですが、先ほどの話のように HOGE を使ったほうが間違いがないような気がします。

そこで、

typedef struct HOGE
{
　　...
};

という風にしてしまいつつあるのですが、どういう副作用があるのでしょうか。

**デフォルトの名無しさん** · 2020/09/20(日) 10:24:48.86

>>391
そこに書かれた範囲だと HOGE と hoge_t とは同じものを指すことになるから、
そこを置き換えて大丈夫になるなんてことは無いはず。
たぶん書いてないところに問題があったんだろうと思う。

それはそれとして、その typedef には意味がないので単に struct HOGE で済ませておけばいい
という結論は問題ないと思うよ。
C で struct 省略のための typedef を変に覚えただけでしょ。

**デフォルトの名無しさん** · 2020/09/20(日) 11:36:33.24

HOGE が型名で、hoge_t が変数名、という認識は合ってますか？

**デフォルトの名無しさん** · 2020/09/20(日) 11:43:51.29

>>393 合ってませんね。

**デフォルトの名無しさん** · 2020/09/20(日) 11:53:42.36

「struct HOGE ・・・」を hoge_t 型と定義する、みたいなやつですか。
C++ 使ってる限り、忘れていい過去の遺物と思っていいんですね。

**デフォルトの名無しさん** · 2020/09/20(日) 12:05:47.95

struct Hoge{...};とtypedef stuct Hoge hoge_t;をまとめて書いてるだけ
古のCマスター様のイキリ構文だから忘れなさい

**はちみつ餃子** ◆8X2XSCHEME · 2020/09/20(日) 12:39:45.45

>>395
C++ のことだけを考えるなら typedef を使う理由はもう無くなった。
少なくとも C++11 以降は型の別名を付けるにしても using で全ての状況をまかなえる。

C では構造体タグと型名は別物として管理されていたけど
C++ ではそうではないのでわざわざふたつの名前付ける必要もあまりない。

**デフォルトの名無しさん** · 2020/09/20(日) 14:03:58.31

>>397
なんか誤解招く説明じゃね？
ミスリード狙ってんの？

**デフォルトの名無しさん** · 2020/09/20(日) 15:44:00.22

#define も使用禁止ですね判ります

**はちみつ餃子** ◆8X2XSCHEME · 2020/09/20(日) 15:51:48.80

>>398
そうか？
どのあたりが？

**デフォルトの名無しさん** · 2020/09/20(日) 15:52:26.96

気に入らなければお前が説明しなおせばいいんじゃない？

**デフォルトの名無しさん** · 2020/09/20(日) 15:53:19.29

あ、本人がレス返してた
余計だったなすまん

**デフォルトの名無しさん** · 2020/09/20(日) 18:56:35.09

_から始まって次の文字が大文字はCでも禁止？

**デフォルトの名無しさん** · 2020/09/20(日) 19:00:51.76

C89の頃から禁止だったはず

**蟻人間** ◆T6xkBnTXz7B0 · 2020/09/20(日) 19:07:53.10

#defineを使わないと、こういうソースは書けないのだよ。

https://github.com/reactos/reactos/pull/3215/files

**デフォルトの名無しさん** · 2020/09/20(日) 19:24:22.31

Cでもタグ名とtypedef識別子は衝突しないんだから
typedef hoge_t HOGE;なんてしなくていい
C++14みたいに_tと_vにするなら意味あるけどね

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

>>400
まるでC++11で初めてタグが不要になったかのように思わせかねない
C++11以降の利点を推したいんだろうがごっちゃにしたらいかんと思うよ

**はちみつ餃子** ◆8X2XSCHEME · 2020/09/21(月) 08:40:38.86

>>407
using の説明のつもりだったが、
その部分も C++11 の話に見える？
まあ見えるかもしれんな。

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

さすがにそれは国語力を疑う

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

>>407

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

>>408
そもそもusingの話(前半2行)いるか？ってことな

>>409
お前文章問題苦手だろ

**はちみつ餃子** ◆8X2XSCHEME · 2020/09/21(月) 09:54:25.81

>>411
むしろ using を使えという方が俺の言いたかったことなんだ。

しいて言えば typedef は「構造体の宣言と同時に」別名の定義もできるという点が
using ではできないけどそうする意味が失われている (ので特に優位性ではない) という意味で後半の補足を入れた。

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

あー、まぁ実質typedefは忘れた方がいい、というのは同意するけどね(初心者に教えるという意味では

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

C++ではstructをtypedefする必要は無くなった

ただ、typedef（やusing）は
typedef vector<Coord> Path;
typedef vector<Path> Pathes;
みたいな時に使っている

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

>>414
using使おうぜ

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

しかし、typedefに不満が無い人に対して、書き方が違っているだけのusingを
推進しようとするC++勢の姿勢は嫌い。
Cが好きで延長線上で使っていたのに、いつのまにかCとはまるっきり別言語に
強制されていっている。

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

>>416
typedefは文法的に非合理的なところがあるんだけど気付いてる？

typedef std::basic_string<char, std::type_traits<char>, std::allocator<char>> string;
typedef std::mersenne_twister_engine<std::uint_fast32_t, 32, 624, 397, 31, 0x9908b0df, 11, 0xffffffff, 7, 0x9d2c5680, 15, 0xefc60000, 18, 1812433253> mt19937;
↓
using string = std::basic_string<char, std::type_traits<char>, std::allocator<char>>;
using mt19937 = std::mersenne_twister_engine<std::uint_fast32_t, 32, 624, 397, 31, 0x9908b0df, 11, 0xffffffff, 7, 0x9d2c5680, 15, 0xefc60000, 18, 1812433253>;

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

using使うとtemplateも使える

template <class T>
using vec = std::vector<T>;

vec<int> vi;

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

usingはこういうのが嬉しいと思う。

// C++11
using func = void(*)(int);

// C++03 equivalent:
// typedef void (*func)(int);

>>417
文法的に非合理的？

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

C/C++みたいな低レイヤーの言語を触る時代はいつまで続くのかね

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

typedefだと本体がわかりにくいのだ

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

10年後でも100年後でも一番下のところは必ず存在する
アーキテクチャが変わってもC言語のような低水準言語は必ず出てくる

つまり世の中から『一番下』が無くなるとは思えない

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

AIによる最適化技術がコンパイラに積まれたら
C/C++みたいなのは不要になる気がする
アーキテクチャの一番下のアセンブラとかは残るとしてもね

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

>>423
AIによる最適化技術って具体的になぁに？

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

コンパイラの最適化もしらないの？？？

**デフォルトの名無しさん** · 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
「それを言うならこっちでしょ」の意味も
「合理性という論点では同じ」の意味も
「文法的に非合理的」の意味も全て分かりませんでした