C++相談室 part152
■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
2020/07/12(日) 13:42:20.13ID:TX1mpKr6394デフォルトの名無しさん
2020/09/20(日) 11:43:51.29ID:gADwnK29 >>393 合ってませんね。
395デフォルトの名無しさん
2020/09/20(日) 11:53:42.36ID:YAin65a3 「struct HOGE ・・・」 を hoge_t 型 と定義する、みたいなやつですか。
C++ 使ってる限り、忘れていい過去の遺物と思っていいんですね。
C++ 使ってる限り、忘れていい過去の遺物と思っていいんですね。
396デフォルトの名無しさん
2020/09/20(日) 12:05:47.95ID:dGmNK3yI struct Hoge{...};とtypedef stuct Hoge hoge_t;をまとめて書いてるだけ
古のCマスター様のイキリ構文だから忘れなさい
古のCマスター様のイキリ構文だから忘れなさい
397はちみつ餃子 ◆8X2XSCHEME
2020/09/20(日) 12:39:45.45ID:7quNJlhN >>395
C++ のことだけを考えるなら typedef を使う理由はもう無くなった。
少なくとも C++11 以降は型の別名を付けるにしても using で全ての状況をまかなえる。
C では構造体タグと型名は別物として管理されていたけど
C++ ではそうではないのでわざわざふたつの名前付ける必要もあまりない。
C++ のことだけを考えるなら typedef を使う理由はもう無くなった。
少なくとも C++11 以降は型の別名を付けるにしても using で全ての状況をまかなえる。
C では構造体タグと型名は別物として管理されていたけど
C++ ではそうではないのでわざわざふたつの名前付ける必要もあまりない。
398デフォルトの名無しさん
2020/09/20(日) 14:03:58.31ID:rXNNPQAl399デフォルトの名無しさん
2020/09/20(日) 15:44:00.22ID:0QrwQpRm #define も使用禁止ですね判ります
401デフォルトの名無しさん
2020/09/20(日) 15:52:26.96ID:ujAaBpzc 気に入らなければお前が説明しなおせばいいんじゃない?
402デフォルトの名無しさん
2020/09/20(日) 15:53:19.29ID:ujAaBpzc あ、本人がレス返してた
余計だったなすまん
余計だったなすまん
403デフォルトの名無しさん
2020/09/20(日) 18:56:35.09ID:HMivgeXQ _から始まって次の文字が大文字はCでも禁止?
404デフォルトの名無しさん
2020/09/20(日) 19:00:51.76ID:dGmNK3yI C89の頃から禁止だったはず
405蟻人間 ◆T6xkBnTXz7B0
2020/09/20(日) 19:07:53.10ID:JknVjK4K406デフォルトの名無しさん
2020/09/20(日) 19:24:22.31ID:PidwIaps Cでもタグ名とtypedef識別子は衝突しないんだから
typedef hoge_t HOGE;なんてしなくていい
C++14みたいに_tと_vにするなら意味あるけどね
typedef hoge_t HOGE;なんてしなくていい
C++14みたいに_tと_vにするなら意味あるけどね
407デフォルトの名無しさん
2020/09/21(月) 01:11:32.44ID:YHO9o1ct408はちみつ餃子 ◆8X2XSCHEME
2020/09/21(月) 08:40:38.86ID:sulqQktu409デフォルトの名無しさん
2020/09/21(月) 09:07:56.01ID:apXLM6YN さすがにそれは国語力を疑う
410デフォルトの名無しさん
2020/09/21(月) 09:08:40.94ID:apXLM6YN411デフォルトの名無しさん
2020/09/21(月) 09:29:06.87ID:uGOMtfu/412はちみつ餃子 ◆8X2XSCHEME
2020/09/21(月) 09:54:25.81ID:sulqQktu >>411
むしろ using を使えという方が俺の言いたかったことなんだ。
しいて言えば typedef は「構造体の宣言と同時に」別名の定義もできるという点が
using ではできないけどそうする意味が失われている (ので特に優位性ではない) という意味で後半の補足を入れた。
むしろ using を使えという方が俺の言いたかったことなんだ。
しいて言えば typedef は「構造体の宣言と同時に」別名の定義もできるという点が
using ではできないけどそうする意味が失われている (ので特に優位性ではない) という意味で後半の補足を入れた。
413デフォルトの名無しさん
2020/09/21(月) 10:26:30.49ID:YHO9o1ct あー、まぁ実質typedefは忘れた方がいい、というのは同意するけどね(初心者に教えるという意味では
414デフォルトの名無しさん
2020/09/21(月) 17:14:51.54ID:zhVYtERB C++ではstructをtypedefする必要は無くなった
ただ、typedef(やusing)は
typedef vector<Coord> Path;
typedef vector<Path> Pathes;
みたいな時に使っている
ただ、typedef(やusing)は
typedef vector<Coord> Path;
typedef vector<Path> Pathes;
みたいな時に使っている
415デフォルトの名無しさん
2020/09/21(月) 17:16:28.09ID:Y5gLvI08 >>414
using使おうぜ
using使おうぜ
416デフォルトの名無しさん
2020/09/21(月) 17:28:58.81ID:5fzDdes6 しかし、typedefに不満が無い人に対して、書き方が違っているだけのusingを
推進しようとするC++勢の姿勢は嫌い。
Cが好きで延長線上で使っていたのに、いつのまにかCとはまるっきり別言語に
強制されていっている。
推進しようとするC++勢の姿勢は嫌い。
Cが好きで延長線上で使っていたのに、いつのまにかCとはまるっきり別言語に
強制されていっている。
417デフォルトの名無しさん
2020/09/21(月) 17:54:21.89ID:PNFNM3Vd >>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>;
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>;
418デフォルトの名無しさん
2020/09/21(月) 19:06:32.78ID:IzAwgxqY using使うとtemplateも使える
template <class T>
using vec = std::vector<T>;
vec<int> vi;
template <class T>
using vec = std::vector<T>;
vec<int> vi;
419デフォルトの名無しさん
2020/09/21(月) 19:11:20.08ID:BKUa/6+Z usingはこういうのが嬉しいと思う。
// C++11
using func = void(*)(int);
// C++03 equivalent:
// typedef void (*func)(int);
>>417
文法的に非合理的?
// C++11
using func = void(*)(int);
// C++03 equivalent:
// typedef void (*func)(int);
>>417
文法的に非合理的?
420デフォルトの名無しさん
2020/09/21(月) 19:15:17.99ID:IzAwgxqY C/C++みたいな低レイヤーの言語を触る時代はいつまで続くのかね
421デフォルトの名無しさん
2020/09/21(月) 19:15:52.15ID:J2iLBa+b typedefだと本体がわかりにくいのだ
422デフォルトの名無しさん
2020/09/21(月) 19:33:47.96ID:zhVYtERB 10年後でも100年後でも一番下のところは必ず存在する
アーキテクチャが変わってもC言語のような低水準言語は必ず出てくる
つまり世の中から『一番下』が無くなるとは思えない
アーキテクチャが変わってもC言語のような低水準言語は必ず出てくる
つまり世の中から『一番下』が無くなるとは思えない
423デフォルトの名無しさん
2020/09/21(月) 19:40:50.05ID:IzAwgxqY AIによる最適化技術がコンパイラに積まれたら
C/C++みたいなのは不要になる気がする
アーキテクチャの一番下のアセンブラとかは残るとしてもね
C/C++みたいなのは不要になる気がする
アーキテクチャの一番下のアセンブラとかは残るとしてもね
424デフォルトの名無しさん
2020/09/21(月) 19:49:44.87ID:NkrhQtlS >>423
AIによる最適化技術って具体的になぁに?
AIによる最適化技術って具体的になぁに?
425デフォルトの名無しさん
2020/09/21(月) 19:58:28.08ID:IzAwgxqY コンパイラの最適化もしらないの???
426デフォルトの名無しさん
2020/09/21(月) 20:04:55.13ID:NkrhQtlS >>425
現行のLLVMとかによる最適化なら知ってるけど、まだ実現されてないAIによる最適化ってなにかなぁと思って。
現行のLLVMとかによる最適化なら知ってるけど、まだ実現されてないAIによる最適化ってなにかなぁと思って。
427デフォルトの名無しさん
2020/09/21(月) 20:11:19.83ID:I28tUppa typedefがわかりにくいのではなくてC言語以来のポインタ定義構文がおかしいんである
これは聖典『プログラミング言語C』でも「批判を浴びることがある」みたいに書かれている
これはどうせCベースの言語なら乗り越えねばならない関門なのでノーカンとして、
単に型のエイリアスが欲しいときはtypedefで十分やし、
定義型をテンプレートにしたいとか別の型にしたいときはクラスにしたら宜しい
かと
これは聖典『プログラミング言語C』でも「批判を浴びることがある」みたいに書かれている
これはどうせCベースの言語なら乗り越えねばならない関門なのでノーカンとして、
単に型のエイリアスが欲しいときはtypedefで十分やし、
定義型をテンプレートにしたいとか別の型にしたいときはクラスにしたら宜しい
かと
428デフォルトの名無しさん
2020/09/21(月) 20:12:23.44ID:IzAwgxqY 普通に考えて
機械語を入力としてそれと等価で高速に動作する機械語を出力する
作業をAIに任せるってことなんじゃないの(たぶん)
機械語を入力としてそれと等価で高速に動作する機械語を出力する
作業をAIに任せるってことなんじゃないの(たぶん)
429デフォルトの名無しさん
2020/09/21(月) 20:13:49.74ID:I28tUppa 同じことをするのにいくつも書き方があるようだと
C++はますますプログラミング言語界のPerlになってしまうま、
C++はますますプログラミング言語界のPerlになってしまうま、
430デフォルトの名無しさん
2020/09/21(月) 20:19:15.08ID:I28tUppa AIによる最適化はそもそも最適な最適化が何なのかは計算不能(コルモゴロフ複雑性
というのはどうすんじゃ………
というのはどうすんじゃ………
431デフォルトの名無しさん
2020/09/21(月) 20:20:24.50ID:NkrhQtlS >>428
ごめんね、喧嘩売ってるつもりじゃないんだ。
コンパイル最適化技術は興味あるんだけど俺の知識が数年前で止まってるので新しい知識として取り入れたかっただけ。
>機械語を入力としてそれと等価で高速に動作する機械語を出力する
それってAIと関係なく何十年も前からあるなんの変哲もない最適化だと思うの。
ごめんね、喧嘩売ってるつもりじゃないんだ。
コンパイル最適化技術は興味あるんだけど俺の知識が数年前で止まってるので新しい知識として取り入れたかっただけ。
>機械語を入力としてそれと等価で高速に動作する機械語を出力する
それってAIと関係なく何十年も前からあるなんの変哲もない最適化だと思うの。
432デフォルトの名無しさん
2020/09/21(月) 20:27:18.34ID:WONfy98d433デフォルトの名無しさん
2020/09/21(月) 20:29:32.74ID:WONfy98d >>428
AIなら何でも解決するとか思ってそうw
AIなら何でも解決するとか思ってそうw
434デフォルトの名無しさん
2020/09/21(月) 20:32:17.31ID:IzAwgxqY >AIによる最適化はそもそも最適な最適化が何なのかは計算不能
AIって解析的に解くわけじゃないから計算不能でもいい感じに動いてくれるんじゃないの
>それってAIと関係なく何十年も前からあるなんの変哲もない最適化だと思うの。
最適化技術は素人だから知らないけど現状が割と決まった最適化ルールに当てはめてる
だけだとしたら改善の余地はあるんじゃないのかな
想像だけど
AIって解析的に解くわけじゃないから計算不能でもいい感じに動いてくれるんじゃないの
>それってAIと関係なく何十年も前からあるなんの変哲もない最適化だと思うの。
最適化技術は素人だから知らないけど現状が割と決まった最適化ルールに当てはめてる
だけだとしたら改善の余地はあるんじゃないのかな
想像だけど
435デフォルトの名無しさん
2020/09/21(月) 20:33:13.25ID:IzAwgxqY >>433
わりとまじでそう思ってるけど
わりとまじでそう思ってるけど
436デフォルトの名無しさん
2020/09/21(月) 20:39:34.82ID:NkrhQtlS もちろん、LLVMのようにJITの結果をAOTしてくれるような俺の脳味噌で考えられる最大限の最適化より、もっと進んだ技術が将来的に出てくるとは思うんだよ。
最近そういう技術から離れてたので、俺の知らないうちに新しいブレークスルーがあったのかと思って純粋な興味で質問しました。
最近そういう技術から離れてたので、俺の知らないうちに新しいブレークスルーがあったのかと思って純粋な興味で質問しました。
437デフォルトの名無しさん
2020/09/21(月) 21:20:09.92ID:PNFNM3Vd >>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の話ではないけど
合理性という論点では同じことだよ
それを言うならこっちでしょ
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の話ではないけど
合理性という論点では同じことだよ
438デフォルトの名無しさん
2020/09/21(月) 21:21:22.91ID:PNFNM3Vd >>418
そう、だからtypedefはもういじるのやめてtemplate化はできないまま放置されてるんだよな
そう、だからtypedefはもういじるのやめてtemplate化はできないまま放置されてるんだよな
439デフォルトの名無しさん
2020/09/21(月) 21:22:17.03ID:WONfy98d440デフォルトの名無しさん
2020/09/21(月) 21:25:30.85ID:I4V/hlGb 深層学習、機械学習のことをざっくりAIと呼ぶ人は
まぁおおよそ技術わかってない人だろうね
まぁおおよそ技術わかってない人だろうね
441デフォルトの名無しさん
2020/09/21(月) 21:36:38.22ID:REl65Gaj プログラミングを知らない人が「こんぴゅーたって何でも出来るんでしょ」って言ってるのと似てる
442デフォルトの名無しさん
2020/09/21(月) 21:39:42.46ID:PNFNM3Vd >>441
そう聞こえちまう発言を見かける頻度が高すぎてやだよな
そう聞こえちまう発言を見かける頻度が高すぎてやだよな
443デフォルトの名無しさん
2020/09/21(月) 21:40:29.70ID:BKUa/6+Z444デフォルトの名無しさん
2020/09/21(月) 21:55:50.30ID:PNFNM3Vd >>443
では言い方を変えようか
関数識別子でも型識別子でもそれを一覧しやすいところに集めやすいことを合理性と言っている
概要と詳細はどっちを先に書くべきかってことだよ
typedefは右端に宣言対象の識別子
usingは左端から7文字目という決まった位置に宣言対象の識別子
trailing-return-typeも5文字目という決まった位置に宣言対象の識別子がある
可読性という観点からどう思う?
では言い方を変えようか
関数識別子でも型識別子でもそれを一覧しやすいところに集めやすいことを合理性と言っている
概要と詳細はどっちを先に書くべきかってことだよ
typedefは右端に宣言対象の識別子
usingは左端から7文字目という決まった位置に宣言対象の識別子
trailing-return-typeも5文字目という決まった位置に宣言対象の識別子がある
可読性という観点からどう思う?
445デフォルトの名無しさん
2020/09/21(月) 22:03:23.74ID:REl65Gaj typedefは変数宣言を流用した手抜きだからこんな糞みたいなのも書けてしまう
typedef int are, kore, sore, dore, *hare, **yore, (*more)(float, long), (*ore)[42];
typedef int are, kore, sore, dore, *hare, **yore, (*more)(float, long), (*ore)[42];
446デフォルトの名無しさん
2020/09/21(月) 22:18:42.28ID:PNFNM3Vd typedef int (*more)(float, long); //この書き方に抵抗は全くないが
using more = int (*)(float, long); //それでも俺はこっちが好き
using more = int (*)(float, long); //それでも俺はこっちが好き
447デフォルトの名無しさん
2020/09/21(月) 22:19:03.41ID:BKUa/6+Z >>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;
}
その点については統一感あってむしろ美しいと思うけど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;
}
448デフォルトの名無しさん
2020/09/21(月) 22:21:35.15ID:PNFNM3Vd int are, kore;
変数のareとkoreが本質的に同じ型であることが重要なときに統一できるのはいいけどね
intの同義語をそんなに量産してどうするんだと
変数のareとkoreが本質的に同じ型であることが重要なときに統一できるのはいいけどね
intの同義語をそんなに量産してどうするんだと
449デフォルトの名無しさん
2020/09/21(月) 22:22:41.71ID:I4V/hlGb usingとtypedefでいうと関数ポインタ、配列の扱い違うよね
あのあたりよくわかってない
誰か解説して
あのあたりよくわかってない
誰か解説して
450デフォルトの名無しさん
2020/09/21(月) 22:34:38.79ID:IzAwgxqY >>440
まるでさも自分がわかってるみたいな言い方
まるでさも自分がわかってるみたいな言い方
451はちみつ餃子 ◆8X2XSCHEME
2020/09/21(月) 22:58:02.34ID:VM5g8L/y 別のスレでちょっと書いたことがあるが……。
人工知能 (AI) ってのは人間の知能を代行するものという意味合いで私は考えてる。
昔はコンパイラそのものが人工知能の枠内で扱われていたこともある。
それ以前にルールベース、つまり if 文の羅列のようなものまで人工知能の一種だった。
でもそれらが分野として確立されたら人工知能とは呼ばれなくなっていた。
機械でやるのが当たり前のものになったから。
普通の道具になったから「知能」ではなくなったんだ。
人工知能を実用化するってのは人工知能を人工知能でなくすること。
逆に言えば人工知能と呼ばれている間は曖昧模糊としてよくわからんのが当たり前なんだと思う。
これはいろんな使い方をされる「人工知能」という言葉について私なりの解釈であって
正しさを主張するつもりはないが、それなりに実態に合った解釈ではあると思う。
人工知能 (AI) ってのは人間の知能を代行するものという意味合いで私は考えてる。
昔はコンパイラそのものが人工知能の枠内で扱われていたこともある。
それ以前にルールベース、つまり if 文の羅列のようなものまで人工知能の一種だった。
でもそれらが分野として確立されたら人工知能とは呼ばれなくなっていた。
機械でやるのが当たり前のものになったから。
普通の道具になったから「知能」ではなくなったんだ。
人工知能を実用化するってのは人工知能を人工知能でなくすること。
逆に言えば人工知能と呼ばれている間は曖昧模糊としてよくわからんのが当たり前なんだと思う。
これはいろんな使い方をされる「人工知能」という言葉について私なりの解釈であって
正しさを主張するつもりはないが、それなりに実態に合った解釈ではあると思う。
452デフォルトの名無しさん
2020/09/21(月) 23:08:20.77ID:PNFNM3Vd かなり酔ってるな
ビール? 今日何本目?
ビール? 今日何本目?
453デフォルトの名無しさん
2020/09/21(月) 23:08:24.99ID:I4V/hlGb そんなこねくり回した理解いる?
たんなる学術分野を指すだけの言葉じゃん
意味が広いだけ
たんなる学術分野を指すだけの言葉じゃん
意味が広いだけ
454はちみつ餃子 ◆8X2XSCHEME
2020/09/21(月) 23:13:49.84ID:VM5g8L/y455デフォルトの名無しさん
2020/09/21(月) 23:33:11.93ID:I28tUppa 最適化方面へのAIの適用というと、
高度なルールベース(80年代のAI)までいったん後退したものに
収束が必ずしも保障されない最適化処理(有限ステップで終わる保証がないからもはやアルゴリズムと呼ぶのは抵抗があるがGAとか
を組み合わせたものになりそうなヨカン
FPGAの論理合成エンジンみたいなやつを考えたら宜しいかと、
もはや冪等性は気体できない
ビルドをやるたびに結果が変わるorz
高度なルールベース(80年代のAI)までいったん後退したものに
収束が必ずしも保障されない最適化処理(有限ステップで終わる保証がないからもはやアルゴリズムと呼ぶのは抵抗があるがGAとか
を組み合わせたものになりそうなヨカン
FPGAの論理合成エンジンみたいなやつを考えたら宜しいかと、
もはや冪等性は気体できない
ビルドをやるたびに結果が変わるorz
456デフォルトの名無しさん
2020/09/21(月) 23:38:03.83ID:I28tUppa この場合LPはAIに含めて良いものかどうか、
457デフォルトの名無しさん
2020/09/22(火) 01:59:39.72ID:ZtayyY2i458デフォルトの名無しさん
2020/09/22(火) 02:02:23.48ID:xLdkMK4R >>447
やめてくり〜
やめてくり〜
459デフォルトの名無しさん
2020/09/22(火) 03:43:14.70ID:sfaT76Ga 文字列の内容を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++;
}
以下のプログラムだと一部の文字しか抽出できていませんでした
完全が必要な点を教えてください
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++;
}
460デフォルトの名無しさん
2020/09/22(火) 03:58:17.38ID:ZtayyY2i datalistに行ごとに抽出するならiとj逆のような気もするけど
とりあえずdatalistの方にも、各行の終わりに\0(文字列の終端)が必要じゃね?
ゼロ終端文字列として扱わないとか、最初にmemsetしてるなら別だけど
とりあえずdatalistの方にも、各行の終わりに\0(文字列の終端)が必要じゃね?
ゼロ終端文字列として扱わないとか、最初にmemsetしてるなら別だけど
461デフォルトの名無しさん
2020/09/22(火) 04:01:42.12ID:WeU5fM2j >>459
こんなプログラム書いてるようじゃ無理
こんなプログラム書いてるようじゃ無理
462デフォルトの名無しさん
2020/09/22(火) 04:05:50.78ID:EwzeVKsQ >>449
違わない
違わない
463デフォルトの名無しさん
2020/09/22(火) 04:30:48.29ID:5FJrAAJE464デフォルトの名無しさん
2020/09/22(火) 07:14:47.66ID:iby+25bn465デフォルトの名無しさん
2020/09/22(火) 08:00:49.11ID:xLdkMK4R >>459
このレベルで人に聞いてるようでは使い物にならんな
このレベルで人に聞いてるようでは使い物にならんな
466デフォルトの名無しさん
2020/09/22(火) 09:27:17.92ID:5FJrAAJE467デフォルトの名無しさん
2020/09/22(火) 10:13:21.77ID:Zd6n0i5+468デフォルトの名無しさん
2020/09/22(火) 10:52:41.92ID:GaogVwml >>467
>444 を読むと、言いたかったことはわかる。
> 関数識別子でも型識別子でもそれを一覧しやすいところに集めやすいことを合理性と言っている
言葉のチョイスはおかしいと思うけどね。単に「読みやすさ」「読みにくさ」とか言えばよかったところ。
>444 を読むと、言いたかったことはわかる。
> 関数識別子でも型識別子でもそれを一覧しやすいところに集めやすいことを合理性と言っている
言葉のチョイスはおかしいと思うけどね。単に「読みやすさ」「読みにくさ」とか言えばよかったところ。
469デフォルトの名無しさん
2020/09/22(火) 10:52:56.79ID:iby+25bn >>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);
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);
470デフォルトの名無しさん
2020/09/22(火) 15:44:58.47ID:Zd6n0i5+ >>468
個人的に数学記号のようなもの解読する値から強い方だからかも知れないが、
usingがtypedfよりも特に読みやすいとさえ思わない。
ただし、
#define 名前 定義内容
と
using 名前 = 定義内容;
で順序に対応関係が有ることはある。
しかしながら、C/C++では、
型名 変数名; // (100)
の順序な分けで、LL言語に多い、
var 変数名 : 型名;
の順序ではないので、統一と言う点では、typdefは(100)と美しく統一されている。
個人的に数学記号のようなもの解読する値から強い方だからかも知れないが、
usingがtypedfよりも特に読みやすいとさえ思わない。
ただし、
#define 名前 定義内容
と
using 名前 = 定義内容;
で順序に対応関係が有ることはある。
しかしながら、C/C++では、
型名 変数名; // (100)
の順序な分けで、LL言語に多い、
var 変数名 : 型名;
の順序ではないので、統一と言う点では、typdefは(100)と美しく統一されている。
471デフォルトの名無しさん
2020/09/22(火) 15:58:07.27ID:fNKq19I/ ほぼ満点だったってネタじゃなかったのかよwww
472デフォルトの名無しさん
2020/09/22(火) 16:00:22.94ID:iCejn/78 typedef int (*funcA)(float, long), (*funcB)(float, long), (*funcC)(float, long);
↑
の代わりに
typedef int (*(funcA, funcB, funcC))(float, long);
とか描けないよな
↑
の代わりに
typedef int (*(funcA, funcB, funcC))(float, long);
とか描けないよな
473デフォルトの名無しさん
2020/09/22(火) 16:17:29.92ID:EdpAH8NO474443
2020/09/22(火) 16:18:39.11ID:EdpAH8NO メール欄と名前欄間違えた
475はちみつ餃子 ◆8X2XSCHEME
2020/09/22(火) 16:34:37.47ID:Q5rCUsEX >>470
> しかしながら、C/C++では、
> 型名 変数名; // (100)
> の順序な分けで
「型名 変数名;」ではなく「型指定子 宣言子;」な。
(実際には宣言子は複数書けるがそれはわきに置く。)
順序はある程度は好みだろうとは思うが、
変数を宣言するにあたって「型名を与えているわけではない」んだ。
たとえばポインタ型の変数だと
int* a;
みたいに宣言できるが、
このとき int という型指定子と *a という宣言子から成る。
a の型名は int* であるが、
宣言のときには int は型指定子の側について * は宣言子の側についてるわけ。
typedef は変数宣言の文法と一致させているという意味では一貫していることに合意するが、
そもそも型名を途中で分断するかのような変数宣言の文法がイケてないので、
そっちで統一するのが本当にうれしいのかね? という点で疑問を提示する。
いや、それでうれしいというのならそれでもいいんだが、
前提がそれほど一貫してないのに一貫性をもちだしても仕方なくね?
> しかしながら、C/C++では、
> 型名 変数名; // (100)
> の順序な分けで
「型名 変数名;」ではなく「型指定子 宣言子;」な。
(実際には宣言子は複数書けるがそれはわきに置く。)
順序はある程度は好みだろうとは思うが、
変数を宣言するにあたって「型名を与えているわけではない」んだ。
たとえばポインタ型の変数だと
int* a;
みたいに宣言できるが、
このとき int という型指定子と *a という宣言子から成る。
a の型名は int* であるが、
宣言のときには int は型指定子の側について * は宣言子の側についてるわけ。
typedef は変数宣言の文法と一致させているという意味では一貫していることに合意するが、
そもそも型名を途中で分断するかのような変数宣言の文法がイケてないので、
そっちで統一するのが本当にうれしいのかね? という点で疑問を提示する。
いや、それでうれしいというのならそれでもいいんだが、
前提がそれほど一貫してないのに一貫性をもちだしても仕方なくね?
476デフォルトの名無しさん
2020/09/22(火) 16:38:32.20ID:Zd6n0i5+477デフォルトの名無しさん
2020/09/22(火) 16:43:05.81ID:EdpAH8NO int* a;
int* b;
int c;
//int[42] d;
↑こう書きたいという勢力と…
int *a, *b, c, d[42];
↑こう書きたいという勢力があるんやろね
好みというかその人のバックグラウンドというか
int* b;
int c;
//int[42] d;
↑こう書きたいという勢力と…
int *a, *b, c, d[42];
↑こう書きたいという勢力があるんやろね
好みというかその人のバックグラウンドというか
478はちみつ餃子 ◆8X2XSCHEME
2020/09/22(火) 16:48:28.25ID:Q5rCUsEX >>476
* は (文法的には) 宣言子の側についてるからそちらにくっつくもんなんだろうが、
型名としては int* だから int* と書く方が好ましいと考えている。
文法的な解釈はともかく「型名 変数名;」に近い書き方の方がわかりやすいという考え方だ。
あと、 C++ の設計者自身が * を左に寄せる書き方をしてるから私はそれに巻かれている。
C として書くときは * は変数名の側にくっつけて書くようにしてる。 (K&R ではそういう書き方になってるので。)
* の両側に空白を入れる流儀も存在するようだ。
* は (文法的には) 宣言子の側についてるからそちらにくっつくもんなんだろうが、
型名としては int* だから int* と書く方が好ましいと考えている。
文法的な解釈はともかく「型名 変数名;」に近い書き方の方がわかりやすいという考え方だ。
あと、 C++ の設計者自身が * を左に寄せる書き方をしてるから私はそれに巻かれている。
C として書くときは * は変数名の側にくっつけて書くようにしてる。 (K&R ではそういう書き方になってるので。)
* の両側に空白を入れる流儀も存在するようだ。
479デフォルトの名無しさん
2020/09/22(火) 17:23:35.93ID:Zd6n0i5+ >>478
>あと、 C++ の設計者自身が * を左に寄せる書き方をしてるから私はそれに巻かれている。
>C として書くときは * は変数名の側にくっつけて書くようにしてる。 (K&R ではそういう書き方になってるので。)
Cの設計者は数学的、C++の設計者は凡才的。
>あと、 C++ の設計者自身が * を左に寄せる書き方をしてるから私はそれに巻かれている。
>C として書くときは * は変数名の側にくっつけて書くようにしてる。 (K&R ではそういう書き方になってるので。)
Cの設計者は数学的、C++の設計者は凡才的。
480デフォルトの名無しさん
2020/09/22(火) 18:25:41.01ID:iCejn/78481デフォルトの名無しさん
2020/09/22(火) 18:27:35.58ID:iCejn/78482デフォルトの名無しさん
2020/09/22(火) 18:44:14.87ID:PYPDpGOY わしは自身がハゲてきてビヨヨーン先生を師と仰ぐようになったから左寄せ派
483デフォルトの名無しさん
2020/09/22(火) 19:04:01.34ID:fNKq19I/ 俺も左寄せ派だわ。
*は明らかに型の一部なのに変数宣言のときだけ型でないふりしてるのがいただけない
*は明らかに型の一部なのに変数宣言のときだけ型でないふりしてるのがいただけない
484デフォルトの名無しさん
2020/09/22(火) 19:05:41.48ID:EdpAH8NO int *aを
int* aと書きたい人は
int (*f)()を
int(* f)()と書けば満足するのだろうかという不思議はある
そういうときこそtypedefですよ、ってことなんだろうか
int* aと書きたい人は
int (*f)()を
int(* f)()と書けば満足するのだろうかという不思議はある
そういうときこそtypedefですよ、ってことなんだろうか
485デフォルトの名無しさん
2020/09/22(火) 19:07:53.44ID:7BIH7/M6 古典ネタはもうええっちゅうねん
486デフォルトの名無しさん
2020/09/22(火) 19:09:48.55ID:EwzeVKsQ >>484
int*を返す関数じゃないんだから不思議はないと思うが
int*を返す関数じゃないんだから不思議はないと思うが
487デフォルトの名無しさん
2020/09/22(火) 19:13:34.90ID:lX2VmDiW 時代はauto
488デフォルトの名無しさん
2020/09/22(火) 19:14:45.07ID:6pKbcXJi どうでもいいわ
489デフォルトの名無しさん
2020/09/22(火) 19:32:53.07ID:EdpAH8NO >>486
なるほど
int*p // 左に*寄せる
int (*f)() // 寄せない
int (*a)[42] // 寄せない
int* (*f)() // 戻り値側だけ左に寄せる
こういう感じでやっていくのかな
なるほど
int*p // 左に*寄せる
int (*f)() // 寄せない
int (*a)[42] // 寄せない
int* (*f)() // 戻り値側だけ左に寄せる
こういう感じでやっていくのかな
490デフォルトの名無しさん
2020/09/22(火) 20:39:49.00ID:iby+25bn いつも老害呼ばわりされてる俺が
今日ほどこいつら老害と思ったことはない
今日ほどこいつら老害と思ったことはない
491デフォルトの名無しさん
2020/09/22(火) 22:46:59.09ID:GaogVwml 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.
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.
493はちみつ餃子 ◆8X2XSCHEME
2020/09/22(火) 23:30:22.08ID:Q5rCUsEX >>484
元からイケてない変数宣言の文法を部分的にどうにかすっきり見せる
って程度の話なんで、複雑な事例を更に複雑にするような変なルール
にしたいわけではない。
C++ 的な方向に振るなら int (*f)(); は
std::add_pointer_t<int()> f;
か
std::decay_t<int()> f;
かなぁ……。
冗長だけど変に入り組んだ感じがなくなるので type_traits はそれなりに取り入れてもいいと思うよ。
元からイケてない変数宣言の文法を部分的にどうにかすっきり見せる
って程度の話なんで、複雑な事例を更に複雑にするような変なルール
にしたいわけではない。
C++ 的な方向に振るなら int (*f)(); は
std::add_pointer_t<int()> f;
か
std::decay_t<int()> f;
かなぁ……。
冗長だけど変に入り組んだ感じがなくなるので type_traits はそれなりに取り入れてもいいと思うよ。
■ このスレッドは過去ログ倉庫に格納されています
