C++相談室 part138

**デフォルトの名無しさん** (ｽﾌｯ Sd9f-fGne) · 2018/08/05(日) 18:02:36.57

次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512

C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。

前スレ
C++相談室 part137
http://mevius.5ch.net/test/read.cgi/tech/1531558382/

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.103【環境依存OK】
http://mevius.5ch.net/test/read.cgi/tech/1530384293/

■長いソースを貼るときはここへ。■
　http://codepad.org/
　https://ideone.com/

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)

VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

2018/09/19(水) 23:10:27.91

たとえば64byteのﾒﾓﾘが必要なｸﾗｽがあったとする
ｱﾎが作ったｺﾝﾃﾅでは例えば要素が5個なら
こんな感じになるとｱﾎはいってるﾜｹ

　[0][64byte]
　[1][64byte]
　[2][64byte]
　[3][64byte]
　[4][64byte]

ﾒﾓﾘの板に64*5のﾒﾓﾘｲﾒｰｼﾞが配置される
要素が1つ増えるたびに64byte必要になることになる

ﾎﾟｲﾝﾀなら（仮に32bitなら）こうなる

　[0][4byte]　←　[64byte]
　[1][4byte]　←　[64byte]
　[2][4byte]　←　[64byte]
　[3][4byte]　←　[64byte]
　[4][4byte]　←　[64byte]

ﾒﾓﾘの板に4*5のﾒﾓﾘｲﾒｰｼﾞが配置される
さらに64byteのﾊﾞﾗﾊﾞﾗのﾒﾓﾘが5個できる
つまりﾒﾓﾘﾌﾗｸﾞﾒﾝﾃｰｼｮﾝがおきることになる

2018/09/19(水) 23:14:17.43

>>69
そんな長々とオレオレ理解をオレオレ用語で説明されても困るわw
スタックで、とかメソッドチェーンで、とかにこだわりすぎだよ
言語に合わせてサクッと作れ

2018/09/19(水) 23:17:16.10

そもそもｽﾀｯｸとかいってるｵﾏｴも
相当頭悪いという自覚が必要

2018/09/19(水) 23:22:42.98

allocaって書いてあんだけど

2018/09/19(水) 23:28:50.52

さよか

2018/09/19(水) 23:50:52.77

>>71
お前が、というより最近の奴が何故
「俺の知ってる言語の『優位性』」に固執するのか甚だ疑問ではある。
ただ、お前は>>37も理解出来てないのだから、まずは「オブジェクト指向」を理解した方がいいぞ。

>>74
JavaScripterはそれ以前で、オブジェクト指向そのものを知らない奴が多いし、
他言語から来た奴は無理に「クラスベース」として捉えようとして誤解し、
しかもそれを垂れ流して間違いを再生産し、どうしようもない状況になってる。
JavaScripterには馬鹿しかいない。これは断言出来る。

>>76
俺はもう動けばいいだけなら普通に作れるんだよ。
その上で、C++の動作速度が遅く、記述がかったるいのを何とかしようと試してる。
先に言っておくが、俺はC比同速程度を目指している。
スマポ(ｷﾘｯなC++なんてJavaよりちょっと速い程度しか出ないし、それなら俺はCLIを使うからそれでいい。
ただしC流の書き方は見た目分かりにくいから、
C比で遅くならない、或いは多少程度でもうちょっとましに書けないか試している。

今回のにしたって、最速はC流の「頭で全部分確保、ポインタで細切れにして渡す」に決まっている。
ただこれは見た目何をやっているのか分かりにくいし、関数に分割もしづらい。
クラスにしたって、仮想関数なしなら速度もメモリもオーバーヘッドはない。なら使わない手はない。
そういう、C比オーバーヘッド無し（或いは僅か）程度で、どこまで分かりやすい見た目になるかを試してる。

楽に書きたいだけなら、JavaScriptが現状最強だ。
C比5倍程度であの楽さ、他の言語なんてやってられない。
速ければいいだけならCだ。ただし記述が見た目分かりにくいのは否めない。
それでC++でどこまでCを改善出来るかを試している。メソッドチェーンもそれの一環だ。

2018/09/20(木) 00:06:31.99

だったらふつうにPODの配列でいいわけだからな

2018/09/20(木) 00:08:31.80

Cでわかりにくいｺｰﾄﾞを書くには
頭悪いという才能がいる

2018/09/20(木) 00:15:44.01

allocaの寿命大丈夫？ちょっと気になった、。

**71=67** (ﾜｯﾁｮｲ 01b3-coYL) · 2018/09/20(木) 00:27:41.21

>>80
携帯とPCで書いたから同一人物とわからんかったかな
何か実現したいことがあって
＞・derived等、継承で親のメソッドを使ったときにも「呼び出し側の型」を返す為のキーワードの整備
と書いてたんだと思って、解決策になるかもしれない情報を教えてあげようと思ったら
感謝もせんとC++に対するヘイトを垂れ流すだけだったから「ああ、あいつか・・・」となったんだが

＞「俺の知ってる言語の『優位性』」に固執する
どこをどう読んだらそうなるのかわからん。というか鏡見ろ

2018/09/20(木) 00:31:01.70

遅いのはｵﾏｴのｳﾝｺｺｰﾄﾞのｱﾙｺﾞﾘｽﾞﾑのせいだからな
気にする必要ないほどのｵｰﾊﾞｰﾍｯﾄﾞが問題じゃない

2018/09/20(木) 00:50:45.72

>>72
> スタックをplacement newしたんなら自分でデストラクタ
自分でデストラクタを書かなくて済むようにコンテナを用意してるんだよ。

というか、そもそもC++の思想はそうではないか？
ある意味、クラス外のコードでデストラクタを書いたら負けだろ。
そしてコンテナを用意するだけでこれを回避出来る。
それだけの話だ。

「書けばいい」の発想もいいが、俺はもうそれは十分出来るので、
書かなくて済む物を如何に増やすか、それを試してる。
結局、スクリプト言語が楽なのはここだし。

>>83
もう動作はしてるし、結果も比較して問題ないのを確認済み。
まあ、 alloca は相当使いづらいことも分かった。

>>84
いや、ワッチョイが同一だから同一人物だと認識してる。

> 解決策になるかもしれない情報を教えてあげようと思ったら
解決策になってないし、お前はそれが間違いだとも認識出来てない。
お前の情報は何の役にも立ってない。

馬鹿が間違ったことを言ってきて「間違ってるぞ」と言ったら「それでも感謝しろ」と言われた状況だ。
そういう考え方もありだが、俺はここではそれをしないし、する必要も無いし、するべきでもないと思ってる。
ここでは、間違ったことを言った奴は叩かれるべきだ。
そうでないと馬鹿がどんどん寄ってきて、結果、レベルが下がり、誰にとっても利益が無くなる。
間違ったことを言っても感謝されたいなら、少なくともIDやコテハンが付いてる場所へ行け。
そういうところが好きなら、そういう場所を盛り上げるべきであって、ここで文句を言うべきではない。

2018/09/20(木) 00:55:35.41

まぁまぁ御託はいいからお前のコードを全部さらせよ
添削してやっから
あとベンチマークの結果も書いとけ

2018/09/20(木) 01:01:28.49

それが一番やな

2018/09/20(木) 04:25:13.14

IntelのC++ Composerってサポート期限切れのシリアルでも使用可能なバージョンがあるのね
知らなかったよ

2017 update7
>This update can be installed even if your support service has expired using your existing Serial Number.

2018/09/20(木) 22:36:33.27

はじめまして
ゼミの課題でc++でバカラのプログラムかいてこいって言われたんですけど
簡単ですか？

2018/09/20(木) 22:39:33.57

はい特定

2018/09/20(木) 22:41:55.13

まずｻｲｺﾛの運動をｼﾐｭﾚｰｼｮﾝするところから

2018/09/20(木) 22:46:32.99

https://ja.wikipedia.org/wiki/バカラ_(トランプゲーム)
客が複数いないと掛け金が流動しなくて面白くなさそう。
自分は3日あれば形にできそうではある。

2018/09/20(木) 22:48:19.01

待ち行列で客が待つのもﾎﾟｱｿﾝ分布使ってｼﾐｭﾚｰｼｮﾝする必要がある

2018/12/04(火) 23:43:54.89

devirtualizationはまだclangだけ？

2018/12/12(水) 00:15:14.25

>>95
試せば？

2019/02/04(月) 14:39:50.96

Win10で、でかいメモリを使おうとすると0xc0000017で落ちるんだけど
制限を解除する方法あったっけ？

2019/02/04(月) 15:45:55.20

「64bitのコードでコンパイルするよう指定」するやつだっけ？

「デカいメモリ」「エラーコード～でブルースクリーン」ていう
キーワードで、記憶に引っかかる感じ。

2019/02/11(月) 08:41:29.58

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0551r3.pdf

C++20で、std空間内で宣言されたテンプレートをユーザが特殊化するのを
禁止しようって提案が出てるみたいなんだけど、どうよ？

俺はhashが特殊化できないのは困ると思うんだが

2019/02/11(月) 15:16:43.87

ちょっとありえない気がする。大量のコードの互換性が失われるよね。
ostream/wostreamも存在意義を真っ向から否定するような変更では？

2019/02/13(水) 10:03:42.66

>>99
pdfは読んでいないが妥当だろう。生産性は上がる。

特殊化したければオレオレ名前空間でstdを継承し、それを使え、でいい。
stdを直接変更している糞コードなんてどこかの時点で切り捨てる必要がある。
それがそろそろだという判断だろうし、実際、妥当だと思う。

2019/02/13(水) 11:42:38.93

>>101
ちなみに、おまえさんは
std::unordered_set<my_class> the_obj; //C2280
こんなのにどう対応しているんだ？

2019/02/19(火) 02:22:21.41

別の名前空間で特殊化とか出来たっけ？？

2019/02/21(木) 07:05:37.62

しかもstdという空間名だけ、言語が特別扱いとかおかしいだろ

2019/02/22(金) 04:02:38.57

ｃ＃よりC++のほうがいいんですか？

2019/02/22(金) 04:05:58.60

どっちでもいい

2019/03/04(月) 10:10:34.95

エラー出るんだけどさ
mt19937 en;
int ep[en.state_size];
random_device rd;
generate(begin(ep), end(ep), rd); //C2280

このラムダみたいなことをやってくれる標準の何かない？
generate(begin(ep), end(ep), [&rd]{ return rd(); });

2019/03/04(月) 11:18:15.66

>>107
関数。

2019/03/04(月) 11:42:55.83

generate(begin(ep), end(ep), en)
は？

2019/03/04(月) 15:42:52.84

>>109
このあと、en.seek(begin(ep), end(ep)); とやりたいわけで。。。

2019/03/04(月) 19:55:50.41

>>107
generate(begin(ep), end(ep), ref(rd));

2019/03/04(月) 21:30:57.13

>>111
thx!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
これを待っていた

2019/04/29(月) 06:55:11.19

>>100
亀レスすまそ
なぜostream/wostreamの存在意義を否定することになるんだ？

2019/05/07(火) 18:55:08.99

そもそもP0551R3で禁止されるのは関数テンプレートの特殊化についてであって
std::hashなんかのクラステンプレートの特殊化は特に禁止されないのでは？
クラステンプレートの特殊化まで禁止されるとstd::tuple_sizeみたいなユーザによる特殊化ありきの機能が軒並み消滅する事になると思うんだが

2019/05/08(水) 10:03:00.99

あ、そうなんだ
悪りい、そこまで読んでなかった

2019/05/09(木) 13:43:19.58

>>102
>>101じゃない＆亀レスですまんけど、
普通にHasher関数オブジェクトを自作して、std::unordered_setのテンプレート第二引数として渡せばいいんじゃないか？
わざわざC2280の解決のためにstd::hashを特殊化するのはナンセンスだと思われる

example:
https://wandbox.org/permlink/mSO96qJDavoK1jqI

2019/05/09(木) 13:59:47.44

>>116
ちなみにlambda式も渡せる？

2019/05/09(木) 15:01:22.74

>>117
テンプレートへの渡し方が微妙だけど可能
autoでラムダ受け取っておいてdecltypeで渡すか、std::functionを受け皿にするかだな

example:
https://wandbox.org/permlink/qDm0vA6MWDrIksih

2019/05/09(木) 22:06:08.12

>>116
それやはやだな
せっかく第２引数を省略する方法が提供されているのに
わざわざオレオレファンクタ－作んなきゃいけないのって。。。

2019/05/09(木) 22:07:16.61

ごめ、ありえない変換ミス()しちまった

-それやはやだな
+それはやだな

俺、純血の日本人だよ
信じて

2019/05/09(木) 22:09:28.48

ウソつけ絶対大陸人だゾ

2019/05/09(木) 23:15:47.91

>>120
純潔(童貞)の日本人だろ、信じるよ。

2019/07/23(火) 17:48:26.74

C++じゃないとできないすごいこと教えて

2019/07/23(火) 17:55:03.98

作れるものと作れないものは同じだ

文法的に「すごい」のというと、たとえばラムダ式とか構造化束縛、raw-string-literalあたり
型推定もCで頭固くなっちまった人にはそこそこカルチャーショックだよ

2019/07/23(火) 21:08:02.46

>>123
ゲームだろ。

2019/07/23(火) 22:22:13.57

>>123
競プロ

2019/07/24(水) 01:36:46.76

やっぱりC++ってすごくないんだ

2019/07/24(水) 07:35:18.89

>>124
型推論は他の言語でもあるからそんなに驚きはないけどraw string literalはやり過ぎだろ

2019/07/24(水) 10:35:13.16

>>123
世界征服

2019/07/25(木) 00:54:02.58

>>123
・例えばAIライブラリは速度面からC++で組まれることが普通。
・言語コンパイラもコンパイル速度を重視すればC++が最適。
・AndroidOSそのものもC/C++で組まれる。
・Java Virtual Machineも、PC EmulatorもC/C++で組まれる。
・同程度の性能のデバイスでAndoidとiOSを比べたとき、前者が遅いといわれるのは
　全社はJava(仮想コードにコンパイルされる)、後者はSwing(native binaryにコンパイルされる)
　からが大きいと考えられる。

◆QZaw55cn4c (ﾜｯﾁｮｲ aa47-UOPh) · 2019/07/25(木) 19:08:12.49

>>130
では Java で記述されたコードをコンパイルした成果物が native binary であればいいのですね、これは商機があるかもしれませんね

2019/07/26(金) 00:27:28.49

それ30億のデバイスで走る？

2019/07/26(金) 07:00:05.65

甘いな
native binaryでありさえすればいいってもんじゃない
上手いマシン語と下手なマシン語がある

2019/07/26(金) 07:12:48.67

>>131
実は、>>133が指摘してる通り JavaやC#は言語仕様そのものが native binary
に直してもC++ほどの速度にはなりにくい。例えば遅くなる理由として
1. GC(Garbage Collection)によって自動的にfreeやdeleteさせようとする仕様。
2. 標準的にはポインタを使わない仕様。
3. オブジェクトが構造体やスタックに埋め込まれずにheapからnewされ易い仕様。
4. 二次元以上の配列がJaggyタイプに成り易い仕様。
5. バッファオーバーランの防止のため、配列の境界チェックが行われやすい仕様。
6. ライブラリが巨大なため起動時に大量のコードがディスクから読み出されるため、
　起動が遅く成り易いこと。巨大になる理由の一つはリフレクションや型に
　#includeによる静的コンパイルをせずにすますためののクラスの型情報などが
　(Javaの場合は*.classや*.jarなどの)ライブラリに入っているためだろうか。

例えば、C#も予めnative binaryに直してしまう方法も有るが、それでも起動速度は
余り早くならないらしい。起動後も1.～5.の理由のためC++程の速度にはなりにくい。

2019/07/26(金) 07:28:28.01

>>134
7. C#のリンクリストの場合、要素を削除する場合、文字列などの要素の中身か、
　要素番号を指定する必要が有る。要素Bを有る要素Aの後ろに追加する場合、
　Aの要素番号を指定する必要が有る。これが遅くなる。C/C++本来のリンクリストは
　削除や追加の場所の指定をポインタ(アドレス)で指定できることが速度上の大きな
　優位性であったのにそれが出来ない。なお、詳しくはないがC++のSTLのstd::listの場合は、
　同様の「不具合」があるためリンクリストの本来の性能が出ないかもしれない。
　しかし、それはSTLがC/C++の昔から使われていた本来のリンクリストの実装の仕方を
　していないからであると思われる。

2019/07/26(金) 12:04:17.56

Javaってランタイムがプリミティブなってるクラスを実行することがあったと思うけど、
ネーティブではそのプリミティブ型のクラスを分解してマシン語にしないといけなかった気がする。

2019/07/26(金) 12:42:19.26

vs2019なんだけどさ

void f(path&& pt)
{
auto date = last_write_time(pt);
auto val = decltype(date)::clock::to_time_t(date); //C2039
}

これどうやってtime_tもらうの？

2019/07/26(金) 16:10:27.37

decltype(ftime)::clock::to_time_t()
は、decltype(ftime) が std::filesystem::file_time_type なので、
意味的には長く書けば、
std::filesystem::file_time_type::clock::to_time_t()
となるとは思う。短くすれば、
file_time_type::clock::to_time_t()
となるけど、clock という名前空間は見つからなかったが、
std::chrono::system_clock::to_time_t()
という関数ならば存在しており、
static std::time_t to_time_t( const time_point& t ) noexcept;
という宣言にはなっているところまでは見つけた。
clock というキーワードが何なのかは不明。

2019/07/26(金) 16:16:35.83

last_write_time() の型は：
std::filesystem::file_time_type last_write_time(const std::filesystem::path& p);
file_time_type の型(?)は：
using file_time_type = std::chrono::time_point<>;
なので、
decltype(date)::clock::to_time_t() の部分は、decltype()部分を展開(?)すれば
std::chrono::time_point<>::clock::to_time_t()
と書けることは書ける。この部分は、存在することが分かっている：
std::chrono::system_clock::to_time_t()
ととてもよく似ている。

2019/07/26(金) 16:23:26.92

https://cpprefjp.github.io/reference/chrono/time_point.html
↑によれば、time_pointは
namespace std {
namespace chrono {
template <class Clock, class Duration = typename Clock::duration>
class time_point;
}}
というテンプレート・クラス。
file_time_typeは、C++20では、
using file_time_type = std::chrono::time_point<std::chrono::file_clock>;
と定義されているので、Clock=std::chrono::file_clock とされてテンプレートが具現化される
らしい。time_point<Clock,Duration>クラスには
Clock clock;
というメンバが存在するらしい。ゆえに、
decltype(date)::clock::to_time_t()は、
std::chrono::time_point<std::chrono::file_clock>::clock::to_time_t()
となり、clock=std::chrono::file_clock という意味になり、結局、
std::chrono::file_clock::to_time_t()
ということになるようだ。

2019/07/26(金) 17:00:25.26

>>140
file_clock は、仕様がまだ決まって無いらしい。

2019/07/26(金) 17:02:19.32

うん、俺もそう読んでる

auto sdat = time_point_cast<time_point<system_clock, system_clock::duration>>(date);
・・・これもうまくいかんなあ

2019/07/26(金) 17:20:06.81

autoやめるか、autoで得たものをTYPEIDに物故むか。
好きな方をえらぶのじゃ。

2019/07/26(金) 17:47:30.45

>>134-135
動的にコンテナサイズが変わるものは、遅くなる

それと、C++ でも仮想関数を使うと、関数のアドレスが静的に決まらないから、
その都度、計算するから、オーバーヘッドになる

2019/07/26(金) 20:50:40.59

void f(path&& pt)
{
auto date = last_write_time(pt);
using dt = typename decltype(date)::clock;
auto val = dt::to_time_t(date); //C2039
}

くっそー、もうAPI呼ぶしかねえのか

2019/07/27(土) 00:58:05.06

clock_castが実装されるまで待つしかなかろう

2019/07/27(土) 07:04:30.58

>>145
単純に
void f(path&& pt)
{
　auto　　date1 = last_write_time(pt);
　time_t　val1 = std::chrono::system_clock::to_time_t(date1);
}
とすればいいだけのような気がする。

2019/07/27(土) 07:52:56.55

C2664
残念。。。

2019/07/27(土) 08:21:00.74

>>148
https://code.woboq.org/llvm/libcxx/include/chrono.html
↑によれば、以下の様になっており、time_point は、一般的な
template の time_point<・・・>とsystem_clock::time_pointは
厳密には「別」で、後者は前者を特殊化したものを typedef宣言
している。そのため、 std::chrono::system_clock::to_time_t()の
(メンバ)関数宣言の
static time_t to_time_t(const time_point& t) noexcept;
のtime_pointは、chrono::time_point<system_clock>という
system_clock専用になっている。それが原因で>>147は
エラーを出すらしい。

class system_clock {
public:
　・・・
　 typedef chrono::time_point<system_clock> time_point;
　・・・
}

2019/07/27(土) 08:58:26.59

そう思ってtime_point_castしてみたんだが、それすら通らない。。。

2019/07/27(土) 09:20:37.82

>>150
time_point_cast() は根本的な「Clock」の部分は変換前後で共通の場合のみが
実装されているようです。なのでどこまでの細かい時間を表現できるかの
「時間精度」は変更できても、表現の違いのようなものまでは対応できないのかも
知れません：

namespace std {
namespace chrono {
template <class ToDuration, class Clock, class Duration>
time_point<Clock, ToDuration>
time_point_cast(const time_point<Clock, Duration>& t); // C++11

template <class ToDuration, class Clock, class Duration>
constexpr time_point<Clock, ToDuration>
time_point_cast(const time_point<Clock, Duration>& t); // C++14
}}

2019/08/16(金) 13:02:16.52

テンプレートとマクロのメリットデメリットって他にありますか？
またテンプレートとマクロの使い分けで悩んでいます

マクロのメリット
・一括置換ができる
・文字列も使用できる
・定数式にも使える（配列の要素数）

マクロのデメリット
・数式が複雑なときにミスをしやすい（＋＋を渡してはいけない、演算優先順位がミスしやすい）
・型の識別ができない
・一行記述なので大規模なのには不向き

テンプレートのメリット
・名前空間を定義できるので影響範囲をとどめやすい
・型の識別ができる
・関数なので大規模なのも書ける

テンプレートのデメリット
・定数式にしようできない
・ユーザー定義と標準定義が混ざったときのエラーを判別しにくい

こんなメリットデメリットだと思っています。
他にありますか？？

これを踏まえた上で使い分けとしては、
マクロは文字列などの簡単な定義に向いていて、テンプレートは処理（演算）を含むものと考えているのですが、
他に観点あるでしょうか

2019/08/16(金) 13:05:39.63

宿題は宿題スレで

2019/08/16(金) 13:11:19.36

マクロのデメリット
・スコープに従わない　←致命傷
・デバッガとの相性が極悪

2019/08/16(金) 13:12:45.69

>>152
「他にありますか？」の答えにはならないんだけど・・・

> テンプレートのデメリット
> ・定数式にしようできない

そんなことなくね？

> ・ユーザー定義と標準定義が混ざったときのエラーを判別しにくい

どういう状況のこと言ってるのかよくわからないけど、マクロにすればわかりやすくなる状況なのか
怪しい気がする。

ってことで、使い分けとしてはマクロでしかできないこと（トークン連結・文字列化）以外は
テンプレート使うとしたほうが簡単だと思うし、よく聞く話。

2019/08/16(金) 13:31:46.08

マクロはコンパイラが展開後のコードを見せてくれるけどテンプレートは見せてくれない

2019/08/16(金) 13:58:42.46

展開じゃないからな
typename Tに何が来ているかなんてのはcout << typeid(T).name()で監視できるんで
iocccなみに解読困難なプリプロセッサ出力がないからって困りゃせん

2019/08/29(木) 21:44:48.85

その無駄な監視についてなんも思わんてすごいね。

2019/08/29(木) 22:37:52.13

その監視というか確認の煩雑さは、マクロの方が面倒だろに。

2019/08/29(木) 23:08:09.91

>>152
マクロは、テンプレートのメタ側に位置する機能なので、テンプレートに出来ない事や、テンプレート自体のコードに変更を入れる場合につかうと良い。
まあ、リテラルレベルの置換と、プリプロセッサの入力に使えるってくらいかな。

よく使うのは、コンパイルスイッチくらいじゃないかな。
極稀にリテラルを文字列化したり、リテラルレベルでトークン連結処理したりするくらいかな。

定数はぶっちゃけどっちでも良いけど、式を含むならconstexpr を使うのが c++11の流儀。

2019/08/29(木) 23:40:06.16

>>159
こんなクソみたいな記述入れて一旦ビルドして確かめるとか正気の沙汰じゃねーわ。
cout << typeid(T).name()
マクロもたいがいダメだろうがこれをやらせるって歪んでるとしか思えん。

2019/08/30(金) 05:18:18.83

一旦ビルドしてって、テンプレートはコンパイルしないと何が来るかなんて分からんだろ
＞マクロもたいがいダメだろうが
とか雑な切り捨てしてる辺りからしても、めっちゃ初心者とみた

2019/08/30(金) 06:50:47.21

>>161
何がどうクソなんだ？
おまえさんのルールの何条に違反しているんだ？

2019/08/30(金) 08:57:04.22

>一旦ビルドしてって、テンプレートはコンパイルしないと何が来るかなんて分からんだろ
だからこれがしょうもないってことを言ってるんだが。
静的にコード見て判断しずらい仕組みをなぜ疑問なく使えるのか、そっちのがよっぽど素人感丸出しだよ。

2019/08/30(金) 11:57:51.85

へー、判断しづらいのかｗ

おまえさ、C++に向いてないよ
もうやめたら？

2019/08/30(金) 12:39:58.20

横からすまんが

cout << typeid(T).name()

はくそださいと思う

2019/08/30(金) 12:54:22.69

そもそも cout がダサいですし

2019/08/30(金) 13:01:52.10

宣言だけのテンプレートを使ってエラー吐かせてクラス名確認するのはわりとやる

2019/08/30(金) 16:22:43.35

ダサいと言っているその姿がダサいことにくらい気がつけよ
技術板で客観性を全く欠いた戯れ言ぬかしやがって

2019/08/30(金) 17:52:02.06

>>164
＞静的にコード見て判断しずらい仕組みをなぜ疑問なく使えるのか
これにはテンプレートも含むってこと？
それならまぁ言いたいことはわかる

2019/08/30(金) 20:08:16.72

>>161
言ってることは当たってる。C++は、というか、正確に言うと、C++のスレは歪んでる。

C++ってのは結局のところ、何でも出来るように設計されている。
だから、ユーザーがその機能を使うか使わないか、よくよく考えないと逆に色々面倒なことになる。
マクロもテンプレートも上手く使えば素晴らしいが、濫用すると余計に酷くなる。
○○を使えばいい、とか、逆に、○○は禁止、とか、（本来は）単純に切り分けられるものでもない。

この辺は他LL言語やJava/C#等は最初から使える範囲が決まっており、
C++から見ればかなり制限されているから、濫用は出来ない。
結果、「C++の酷いコード」よりは「C#の酷いコード」の方が数段ましなものにはなる。
逆に言えば、C++はプロ仕様で、
自身でコーディングルールをそれなりに決められる人じゃないと適切には使いこなせない。

実際の職場では大概はがんじがらめのルールが決められているはずで、
C++でコーディングルール無しのところなんてないのではないかと思う。
ところがC++のスレは勘違いした素人が多いのか、
C++の新しい文法や小手先テクニックを使って書くことが目的になっている奴が多い。
そして「長期的な保守」を全く考慮してないレスも散見される。
だからここではそういう雑音もきちんと峻別する能力が求められてしまう。
といってもそれもC++の範疇で、つまり「自分で判断しろ」でしかない。
無理ならC#等そういう「馬鹿が使ったらどうしようもなくなる機能」が最初から用意されてない言語を使え、でしかない。

ここで素人相手にマウント合戦なんて意味無いから止めとけ。
> 静的にコード見て判断しずらい仕組みをなぜ疑問なく使えるのか (>>164)
この基準は正しい。
テンプレートに問題があると認識されているのは昔からだ。
ただ、テンプレート以外に上手く同等のコードを得る方法がないから、それでもテンプレートは使われている。
いずれにしても、その機能をどこまで使うかは君が判定するしかない。
実際に動かさないと何が当たっているか分からないテンプレートなんて事実として糞だが、
それでもその方がましならそういう書き方をするときもあるだろう。
全体を見ず、個々の末端の事例でグダグダ言い争っても意味はない。

2019/08/30(金) 20:31:22.35

上っ面しか見てねえやつだな
長期的な保守性という要求から色んな仕様が発明されているのに
ついていけねえ低脳が被害者面しやがる

2019/08/30(金) 20:33:11.27

おまえらもういいから、ずーっとC++98使い続けてろよ
それで食っていける仕事があるなら俺たち別に非難しねえ
非難てのも変だけどな

2019/08/30(金) 21:07:28.93

中身のない長文書く奴はもれなくバカ