C++相談室 part145

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2019/09/13(金) 17:13:24.60ID:/ygW08Jq
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。

前スレ
C++相談室 part144
https://mevius.5ch.net/test/read.cgi/tech/1563769115/

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

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

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

----- テンプレ ここまで -----
776デフォルトの名無しさん
垢版 |
2019/11/01(金) 19:25:46.93ID:4VV6x0Mu
まんぐりがえし
2019/11/01(金) 19:41:21.97ID:N2gtvXpa
comはクラスライブラリになるのかな
いろいろ面倒だけど
2019/11/01(金) 19:44:45.43ID:8Rp12Rb3
念のため確認だけど、pimplの代替手段については把握されてる前提でOK?
http://site.oukasei.com/?p=148
2019/11/01(金) 19:56:12.78ID:o5qRV/vr
リンク問題はABIの話だよな？
それはリンカのオプション次第じゃないのん？
2019/11/01(金) 20:26:50.93ID:luUnrp0t
>>779
広い意味だとABI
リンカのオプションで前のバージョンに対応してるとかの例もあるけど10年前まで対応してる例とかあるのかな？
2019/11/01(金) 20:51:10.72ID:62eq0k7o
>>778
結局、pimplのI/F用外側クラスを基底クラスに、implを派生クラスにするってだけでやってることはpimplと同じ
むしろ以下の点でより悪い
・I/F用のクラスと実装用のクラスに不必要な継承関係が導入されていらない複雑度が増える
・↑と同じことだが、実装用クラスがI/F用クラスと同じメンバ関数を実装することが強制される
・コンストラクタが使えず、独自のファクトリ関数の使い方を利用者に覚えさせる必要がある
・利用者に生ポが露出する。生ポを避けたい利用者は自分でunique_ptrなどで包まなければならない
・I/F用クラスを利用者が勝手実装して混入させることを許す

上に挙げたのはポリモさせたい場合はメリットでもあるんだが、ポリモを意図しない単独クラスに継承構造なんか入れるべきではない
2019/11/01(金) 21:03:35.70ID:gYA8Bkai
いっそのことヘッダオンリーライブラリにしようぜ
2019/11/01(金) 21:04:43.68ID:tPmTFLHa
>>766
検討はずれかどうかは意見が分かれるかもしれないけど、pimplには速度的な
オーバーヘッドが少しはあるのと、記述が分かりにくいような気がするので、
個人的にはまずは使うのを躊躇する。

ポインタのワンクッションを置いても速度的なオーバーヘッドが問題ない場合には、
単純なクラスへのポインタを使ってそのクラスの実装に依存しないようなコードを書く
ことはある。しかし、pimpleと言われているものよりずっと単純なもの。
pimplの定義もよく分からないので、それが全く同じものかどうかは分からない。
2019/11/01(金) 21:10:39.48ID:gbx33EDY
>>752
目指す理想が違いすぎるやつとは話にならん
2019/11/01(金) 21:13:24.24ID:tPmTFLHa
>>778
そういう風に、C++の抽象クラス（Javaではinterfaceと呼ばれるものと等価
だったはず）を使うと分かり易いですね。
2019/11/01(金) 21:15:27.37ID:N2gtvXpa
実装方法もいろいろでメリットデメリットもいろいろやから好きなの使えばええねん
2019/11/01(金) 21:18:26.92ID:tPmTFLHa
interface を使って、データメンバを隠したい場合は、new CXxxx にあたる部分を
どうやって実装するかの問題になるんですね。グローバル関数にしてしまう
方法もありますが、確か、デザインパターンの「Factoryパターン」というものが
それに該当したかもしれません。
2019/11/01(金) 21:34:43.52ID:aQLx28Zt
>>768
依存切りたいならpimplと言ってるところに
依存気にしてないからpimpl不要っていってるのがお前
不要ならすっこんでろって
2019/11/01(金) 22:03:59.28ID:p6e3QfJv
COM最強やな
2019/11/01(金) 22:07:08.70ID:tPmTFLHa
>>789
めちゃくちゃ使いにくい。
2019/11/01(金) 22:10:22.26ID:U/a7Wx11
>>784
目指す理想がpimpl?
確かに話にならんなw
2019/11/01(金) 22:13:09.54ID:U/a7Wx11
>>790
ただ20年間I/F変えないようにするにはあの程度の手間は必要なわけで
まあもうちょいスマートにできるんじゃないかなって思うところは多々あるけど
2019/11/01(金) 23:37:29.12ID:NpcjLENm
>>789-790

COMが使いづらいと言うか、C++とstdとSTLとWindows APIとCOMの流儀が
ごちゃまぜで、メモリの確保の仕方と文字列の扱いが混沌を極めてるｗ
2019/11/01(金) 23:41:19.87ID:NpcjLENm
.NETは（特に起動の）遅ささえなければ、ずっと簡単だよな。
C#でもなんでもさ

0.5〜1秒クラスの起動速度の差が気になることやってるんで、
久々にC++使ってるけど大変すぎ

でもまあ20年ぐらい前に比べれば随分と楽になってるけど
2019/11/02(土) 03:47:26.33ID:dYVngRw/
>>791
> 目指す理想がpimpl?

違うけど、おまえなんかに説明してもチンパンジーに因数分解を教えるようなものだ
2019/11/02(土) 06:10:30.99ID:QFHeQDAU
std::filesystem はいいな。やっとまともに使えるものができたって感じ
C++17からって遅すぎだと思うが
2019/11/02(土) 07:36:04.48ID:esIitHWU
>>795
単に馬鹿にされてることに気づけよw
2019/11/02(土) 08:38:38.13ID:dYVngRw/
>>797
おまえがな
799デフォルトの名無しさん
垢版 |
2019/11/02(土) 08:48:08.81ID:E6JKa4Vv
文字コード周りの混沌ぶりに比べれば、文字列クラス乱立なぞ微々たるものよ。
2019/11/02(土) 09:26:25.84ID:esIitHWU
>>798
まさかまだ気づいてないとか？w
801デフォルトの名無しさん
垢版 |
2019/11/02(土) 09:27:02.38ID:s0WXD89V
>>776
それだ！
2019/11/02(土) 09:49:41.56ID:smHgTNTv
>>759
ver1.0とver8.0がライブラリの呼び出し規約レベルで違うならpimplでも静的にはリンクできないし、
ver1.0とver8.0がCRTレベルで違うならやっぱ静的にはリンクできないし、
ver1.0とver8.0がライブラリの呼び出し規約レベルで同じかつCRTレベルでも同じならpimplでなくとも静的にリンクできるし、

pimpl関係無くね？
2019/11/02(土) 09:57:16.61ID:l25LSbph
ライブラリだとpimplというかvoid*にして、各種操作をc関数として公開
c++ではラップしたinterfaceクラスを提供って形だろ
実装側はc++の実装クラスにstatic_castして後はc++の世界で書く

pimplは中途半端だから使わない
2019/11/02(土) 10:06:07.78ID:egbBWGD9
windowsのハンドルがそんなだね
中身どんぐらい変わってるんだろうか
2019/11/02(土) 10:06:09.13ID:smHgTNTv
void*からC++クラスのポインタ型にstatic_castってできたっけ、
2019/11/02(土) 10:12:48.91ID:l25LSbph
出来るよ
多態使いたかったらbase ptrとvoid*の相互変換をする

派生ptrからvoid*に直接変換すると危険
2019/11/02(土) 10:18:39.64ID:smHgTNTv
>>806
安全性と危険性が反対くね？
void*が指すアドレスは構造体やクラスの境界に整列している保証が無いのでは…

>>804
WIN32の内部において、ハンドルが単なるindexでなくポインタとして使われているという根拠は？
確かに正体がvoid*だったりするが、ポインタだとしたらOS視点では
INVALID_HANDLE_VALUE判定が
難しくなるのであった、（一般論として
2019/11/02(土) 10:20:03.47ID:dYVngRw/
>>800
だからおまえがな
2019/11/02(土) 10:21:28.65ID:dYVngRw/
static_cast<void*>は最派生クラスにダウンキャストだね
2019/11/02(土) 10:27:48.65ID:egbBWGD9
>>807
外見維持してることが重要なんであって中身でなにをどうしてようがはどうでもいいがな
2019/11/02(土) 10:28:34.71ID:smHgTNTv
やべービルド通るわこれ
うちのコンパイラは壊れてるな…
int g_nSomeValue;
int main()
{
int* p = &g_nSomeValue;
int* q = static_cast<int*>(p);
printf("p=0x%p\n", q);

return 0;
}
2019/11/02(土) 10:30:01.86ID:smHgTNTv
貼りまつがえた、
誤： int* p = &g_nSomeValue;
正： void* p = &g_nSomeValue;
2019/11/02(土) 10:39:33.14ID:l25LSbph
void*は型情報が完全に消えるから、
型が完全に一つだとわかっているならそのままstatic_castすればいい

多態だと派生型からvoid*に直接変換してしまうと、void*から戻す場合に基底ポインタには戻せる保証がない
2019/11/02(土) 10:39:40.95ID:RcR6NuMm
>>802
依存している構造体のサイズやレイアウト変わったらアウトだろ
2019/11/02(土) 10:45:21.22ID:RcR6NuMm
>>803
C++でラップしてる時点で中途半端なのはかわらない
むしろ手間増えてる
2019/11/02(土) 10:46:18.05ID:pWYzNK5/
過去の遺産のCOMなんて使いにくいて横で話ししてるやろ
10年後の環境のことまで気にする必要ないんだよ
ばっさり捨ててその時代にあったものを作るべき
無理に資産転用とか互換性とか気にするからクソが生まれる
2019/11/02(土) 10:47:10.74ID:l25LSbph
pimplで実装隠したところで、
引数に例えばstd::string使うだけでコンパイラバージョン変えたときの保証は無くなるしなぁ
2019/11/02(土) 10:56:15.43ID:vl/bFsjF
要するに>>759は知ったかが無理矢理考えたアホストーリーと言うことでいいかな？w
2019/11/02(土) 10:57:17.10ID:vl/bFsjF
>>808
ああ、もうそういう返ししかできないのか…
高い理想とか笑えるわw
2019/11/02(土) 11:06:42.79ID:smHgTNTv
>>814
pimplだと構造体の実装はライブラリ側に完全隠蔽なのでその観点はおかしい
つかｊコンパイラのバージョンも関係無い
2019/11/02(土) 11:16:21.46ID:smHgTNTv
>pimplだと構造体の実装はライブラリ側に完全隠蔽なのでその観点はおかしい
何が言いたいのかというとライブラリ使用側がライブラリが依存する構造体メンバに直アクセスする前提なら
そんなライブラリはpimplにできんだろとゆーこと
つまりpimpl対非pimplの比較の想定が変
非pimpl条件のライブラリのインターフェース仕様だけ抽象度を下げて議論しても仕方が無い
2019/11/02(土) 11:16:32.42ID:EX+sUHBj
>>816
そんなライブラリ誰が使いたがるんだよ
2019/11/02(土) 11:23:46.22ID:l25LSbph
オープンソースやクローズドでも社内での話だったらソースごと提供すれば終わる話だし
社外提供なら多言語で使えるようにcのAPIを出すのが普通じゃないのか
その上で各言語用のラッパーも提供されるってのがありがちなパターン
2019/11/02(土) 11:37:12.15ID:pWYzNK5/
>>822
現時点で有用なら使うでしょ
逆に10年前からメンテされてなくて現時点でも使われてるライブラリなんてある？
メンテされてるかよりその時代に即したものに乗り換えてくでしょ
2019/11/02(土) 11:50:05.18ID:EX+sUHBj
いやメンテなり機能追加はしろよ
仕様がらっと変わるのわかってるもんなんて使いたくないわ
作り手も使う側めんどいだろ
826デフォルトの名無しさん
垢版 |
2019/11/02(土) 12:26:20.48ID:DuRHh2CY
D なぜ流行らなかったし
Go 突き抜けてる
Rust ちょっと意識高い系
Nim 有望
JULIA 話にならない
2019/11/02(土) 12:50:14.99ID:esIitHWU
>>824
ライブラリじゃないけど例えばExcel2003とかまだCOM経由なら動かせるでしょ
COMの泥臭いインターフェースだから面倒だけどね
2019/11/02(土) 12:54:19.41ID:pWYzNK5/
>>827
動かせるけどクソだよね？
だから新しいのつかうじゃん？
つうかoffice系は延々と互換性意識してメンテされ続けてるじゃん
2019/11/02(土) 13:22:43.30ID:esIitHWU
>>828
俺が言ってるのはCOMの話な
Excelの話はケースバイケースだからなんとも言えんし俺には関係ないからどうでもいい
2019/11/02(土) 13:28:52.76ID:pWYzNK5/
>>829
COMの中身詳しくないんだけど一切メンテされてないの？
今までwinは山ほど脆弱性をupdateしてるけど、そういう中にCOM周りの修正とかなかったの？
間違いなくあったと思うんだよね。
COMに限らず現状使えるMS産のもので10年間内部が未修正のものなんて多分存在しないんじゃない？
だから10年後のことだけなんて考慮する必要なくて将来に渡り有益ならどうせメンテされるし一時的なもので将来無益になるなら消え去るんだよ
2019/11/02(土) 13:32:28.90ID:pWYzNK5/
>>829
なんか前後で俺の主張がずれてる感じで申し訳ない
2019/11/02(土) 13:52:05.38ID:esIitHWU
>>830-831
インターフェースの話とインターフェースの先にあるライブラリとかCOMサーバーの話をごっちゃにしてないか？
2019/11/02(土) 14:07:55.01ID:RcR6NuMm
>>821
勘違い甚だしい
ライブラリ使用者に無関係で見せたくないからpimplで隠すという話をしてる隠さなかったら無用にincludeが増えるし、最悪そのinclude先の仕様変更で互換がくずれる場合もあると
2019/11/02(土) 14:12:10.51ID:RcR6NuMm
>>823
そう、それが結局いまだによくも悪くもベストプラクティス
わかってないやつ多いんだよ
いきってc++で自称モダンな設計で作り上げてあとで泣きながらcのインタフェース作るはめになる
たいてい機械的なラッパーではすまないからな
2019/11/02(土) 14:34:01.62ID:SXOl8GCi
void*的な「ハンドル」を経由して操作するやーつ
C由来のインターフェースは強いな
2019/11/02(土) 14:53:41.66ID:QFHeQDAU
>>827
> ライブラリじゃないけど例えばExcel2003とかまだCOM経由なら動かせるでしょ

Excelとか以前に、DirectXやシェル（エクスプローラー）そのものがCOMだから
2019/11/02(土) 14:55:12.97ID:QFHeQDAU
>>832
そうそう。脆弱性の話はCOMじゃなくてDCOM。

もちろんCOMも脆弱性とは無関係ではないんだけど、
それはC++がバッファーオーバーフローと無関係ではないのと
同じようにCOMの設計自体の問題じゃない
2019/11/02(土) 15:00:15.19ID:4213U75y
ComPtr使ってる？
2019/11/02(土) 15:04:46.15ID:i1zx37WV
Essential COMの第1章で、C++からいかにしてCOMに至るか書いてあるけど、あの流れすごい好き
2019/11/02(土) 15:07:11.40ID:QFHeQDAU
std::filesystem はようやくできたかって感じだが、環境変数でまたorz

なんでこう、使う道具がまともに作られてないんだろうな
C++はメモリ管理ばっかり気にしてる気がする。
2019/11/02(土) 15:09:57.95ID:esIitHWU
>>836-837
> Excelとか以前に、DirectXやシェル（エクスプローラー）そのものがCOMだから
だからCOMとその先を区別してくれよ
COM自体は単なるインターフェース規約で実装は別
脆弱性とかは実装の不具合だから見つかり次第修正されてる
インターフェース規約も仕様バグとかありうるけどCOM自体の仕様バクは聞いたことない
2019/11/02(土) 15:13:34.66ID:OyXmLdGY
　　　　　　　　　　　　　　　　　　　＿
　 　 　 　 　 　 .:⌒: 、 　__　＞: : : : : : :.　　 ＜
　　　　　　　　 |: : : :/´ : : : : : : : : : : : : :. 　　 　｀ﾞ　　､　
　　 　 　 ‐.､／: : : : : : : : : : : : : : : : : : : i　　　　　　
　　　　 　У: : : : : : : : : : : : : : : : : : : : :/　　 　 　 　 　 　 ＼
　　　　　/: : : : : : : : : : : : ', : { : : : : : : :}　　　　　　　　 __　　 ＼　　
.　 　 　 ｊ: : ;彡': : : : : : : : : ' : ', : : : : : ﾘ　　 　 　 ／ : : : : : : . .　＼
　　　　 : : : : : : : : : : : : : : : }: :ト : : : : ′　　 　 /: : : : : : : : : : : ヽ　'.
　　　　: : : : : : : : : : : : : : :ノ :∧: : : : { 　 　 　 / : : : : : : : : : : : : : : ｖ
. 　 　 i: : : : : : : : : : , ‐＜ ＞: :∧: : : :',　 ＞‐:'―: : : : : : : : : : : : : : :.
. 　 　 | : : ／⌒y:／　　 /: : : : : _ヽ: : ／: ヽ: : : : : : : : : : : : : : : : : : :|
　　　八: : {　 　^　 　 　 {: : : Ｙ´ 　 ∨: : : x ― - . . __: : : : :__, : : : : }
　　　 　 ｰ′　　 　 　 　У: : j　　　 {: : : ﾉ　／: : : : : : :￣: : : : : : イ
　　　　 　 　 　 　 　 　 〈: : :/＾　　 　 ｰ^ ／ : : : : : : : : : : : : : ＜
　　　　　　　　　 　 　 　 ^彡　　　 　 　 /: : :ヽ -‐=　 　￣￣
　　　　　　　　　　　　　 　 　 　 　 　 　 {: : :ノ
　　　　　　　　　　　　　　　　　　　 　 　 ゞ´
2019/11/02(土) 15:31:17.24ID:QFHeQDAU
>>841
俺に言うなよ。俺はCOMは使われてるとしか言ってない。
シェル（エクスプローラー）をCOMで操作できるという
基本的な機能の互換性をなくすとか考えられん。
2019/11/02(土) 15:36:48.55ID:16zH/LAn
>>840
環境変数は昔から標準化されてるだろ。設定は微妙だけどデファクト標準関数があるし。
2019/11/02(土) 15:56:49.53ID:QFHeQDAU
>>844
std::cout << なんとか("PATH");
のように一行でやる方法教えて
もちろん脆弱性などで非推奨と言われるようなやり方は禁止

俺はここまでできて「使える道具」だと思ってるよ
2019/11/02(土) 16:32:02.24ID:neC/7x9U
>>843
だからCOMの話にその先であるエクスプローラの話を混ぜるなよ…
ところでExplorerってCOMで操作できたっけ？
Internet Explorerの話じゃないよね？
2019/11/02(土) 16:32:29.90ID:neC/7x9U
>>845
なぜに一行縛りなの？
2019/11/02(土) 16:50:16.72ID:TAka4wsD
OpenStack, Terraform でも、クレデンシャルなどの環境変数は、1つのファイルにまとめる

それでプログラム内で、os.environ[ 'OS_PASSWORD' ]
みたいに取得する

直接、設定ファイルに書いて、git に保存するのは禁止！
849デフォルトの名無しさん
垢版 |
2019/11/02(土) 17:09:24.74ID:orbX83iK
>>845
curl
env()
2019/11/02(土) 18:41:30.33ID:QFHeQDAU
>>847
実現可能な最小の行数

（一行でできるようにすることは他の言語で実現されてることからも明らか）
2019/11/02(土) 18:44:29.21ID:QFHeQDAU
ちなみにさっきオレオレで20行ぐらいの関数を書いて
一行で環境変数を取得できるようにしたよ。
でもこういうのは標準ライブラリで用意してあるべきもの
2019/11/02(土) 18:44:52.66ID:RcR6NuMm
こいつアホだろ
2019/11/02(土) 18:46:14.06ID:neC/7x9U
>>850
短ければ偉いとか思ってる？w
2019/11/02(土) 18:48:21.60ID:QFHeQDAU
>>853
俺が思ってるかどうかじゃなくて、
お前が、こういう理由で短いのがいい or だめと
"お前の意見" を書け
2019/11/02(土) 19:23:54.18ID:neC/7x9U
いや、お前がそう思ってるならいいんじゃね？w
2019/11/02(土) 20:10:41.91ID:QFHeQDAU
ん？反対意見があるんじゃないのか？
ないんだね。

お前がなにか思ってるだけかよｗ
2019/11/02(土) 20:16:14.52ID:FTVoAoH0
この手のバカでもたった20行で作れるんだろ
やっぱりC++は偉大じゃないか
2019/11/02(土) 20:17:34.65ID:QFHeQDAU
車輪の再発明。ってか他の言語使ったほうがいいよ。
2019/11/02(土) 20:28:57.58ID:16zH/LAn
>>845
だったらはじめから「僕はこうじゃなきゃヤなんだー」って言ってくれないと何も伝わらないぞ
2019/11/02(土) 20:32:42.04ID:QFHeQDAU
はじめから言ってる

> std::cout << なんとか("PATH");
> のように一行でやる方法教えて
2019/11/02(土) 20:36:29.98ID:dYVngRw/
> 車輪の再発明

典型的なアイディアキラー！　マジ死ねよ

ガタガタくだらねえこと言ってねえで
本能のままにやってみたいことに暴走しなきゃ
何もできちゃ来ねえんだよ

そういう生産物の上にあぐらかいて怠けているゴミ共にわかるわけねえ！
2019/11/02(土) 20:42:10.52ID:QFHeQDAU
std::filesystemができたように、
std:envも作れってだけの話なのにね
何がそんなに気に触ったんだろう？
2019/11/02(土) 20:49:43.64ID:16zH/LAn
>>860
はあ？845が初出じゃん

getenvでいいだろ。
未定義時のエラー処理まで自動でやってほしいのか？
2019/11/02(土) 20:58:09.22ID:wdMk8lAB
一行じゃないとヤダとか条件を後出ししたからじゃね
2019/11/02(土) 21:01:20.92ID:dYVngRw/
> 何がそんなに気に触ったんだろう？

とぼけてんなよ、はっきり書いてんだろ
車輪の再発明と貴様はほざいた
撤回も修正も今さらいらねえ
2019/11/02(土) 21:08:11.55ID:QFHeQDAU
>>864
そんな下らないことで（笑）

一行とかそんなの重要なところじゃなく、
stdの名の元でまともなライブラリを作ってくれって話だよ
仮にも「標準」ライブラリなんだからさ

昔ながらのgetenvやその安全版はstd:stringが使われてないし、
std::getenvも、なぜかstd::stringではなくchar*が使われていて
使うとエラーとされるレベルの非推奨関数だし、当然ワイド文字版もないし
使おうと思った人なら、まともじゃないの意味ぐらいわかるはず

あ、使ったことない人が噛み付いてきたのかｗ


あと環境変数の未定義は正常な状態としてありえるのでエラーではない
細かくてすまんなｗ 適当な発言は気になるんだよ。
2019/11/02(土) 21:09:21.56ID:QFHeQDAU
>>865
噛み付いてばかりじゃなくて、"自分の意見"を言うだけの
知識はあるのかい？
2019/11/02(土) 21:11:47.48ID:RcR6NuMm
c++の標準ライブラリにプラットフォーム抽象の機能求めるってのは筋が悪いんだよ
filesystemだって結局はposixをテンプレートの味付けで焼き直した程度でファイルの監視もできないだろ
envとか別に標準で提供されなくても何も困ってない
1行かどうかなんてさらにどうでもいい
あと標準ライブラリが提供する範囲の機能で足りてるアプリ作ってるやつは
c++以外の言語使うことを考えた方がいい
2019/11/02(土) 21:29:52.49ID:neC/7x9U
>>856
> お前がなにか思ってるだけかよｗ
うん、バカな縛りだなと思ってるw
2019/11/02(土) 21:36:05.57ID:lCdDFN2K
組み込み系なんてenvどころかfilesystemとかそもそもねぇの普通な環境も多いしね
2019/11/02(土) 21:56:35.34ID:dYVngRw/
>>867
本能の枯れた人生の搾りかすめ
2019/11/02(土) 22:00:29.09ID:jnnO2x8F
ここは毎回しょうもないことで荒れるな
これだからC++界隈って嫌い
2019/11/02(土) 22:07:02.10ID:lY37zOLC
まあもともと広いレンジで使われることを目的とした言語だし
いろんな輩が入ってくるのはしゃーない。
しかしc++11以降は明らかに開発してないクソガキが増えたなという印象はある。
2019/11/02(土) 22:52:35.22ID:egbBWGD9
ないなら作りゃいいのに
なんのためプログラミングなんだろか
2019/11/02(土) 22:57:03.69ID:l25LSbph
せっかくhas_includeみたいなのも出来たのだから、環境ごとに存在しない場合機能提供されないようなものも標準化進めていったらいいんだよね
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況