C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。
前スレ
C++相談室 part143
https://mevius.5ch.net/test/read.cgi/tech/1560574313/
このスレもよろしくね。
【初心者歓迎】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/ (日本語)
----- テンプレ ここまで -----
探検
C++相談室 part144
■ このスレッドは過去ログ倉庫に格納されています
2019/07/22(月) 13:18:35.52ID:gptRHpgT
230デフォルトの名無しさん
2019/08/02(金) 17:08:25.07ID:aGnTdwVX >>229
なるほど
なるほど
231デフォルトの名無しさん
2019/08/02(金) 18:19:12.53ID:zOtmkI/7232デフォルトの名無しさん
2019/08/02(金) 18:33:35.61ID:6Fm4tKt9233デフォルトの名無しさん
2019/08/02(金) 18:46:25.31ID:v+e6jaBZ おい!
4倍精度複素数は!?
ないの!!???
4倍精度複素数は!?
ないの!!???
234デフォルトの名無しさん
2019/08/02(金) 18:49:34.26ID:qy++cDJt boost::multiprecision 使え
235デフォルトの名無しさん
2019/08/02(金) 18:51:13.74ID:OZv2fXQJ 今std::chronoとかstd::filesystemとか標準の名前空間も細分化するようにしてきてるからusing namespace std;の影響もそこまで酷くならないかもしれない
236デフォルトの名無しさん
2019/08/02(金) 18:52:43.15ID:4a7qvAUu stdの中に全部ぶちこんであるのが問題
std::header名の名前空間に入れて、std内でusing namespace header名していればいいのに
std::xxxでも使えるし、using namespace std::header名すればそのheaderの中身だけが省略して使える
std::header名の名前空間に入れて、std内でusing namespace header名していればいいのに
std::xxxでも使えるし、using namespace std::header名すればそのheaderの中身だけが省略して使える
237デフォルトの名無しさん
2019/08/02(金) 18:56:02.63ID:zOtmkI/7238デフォルトの名無しさん
2019/08/02(金) 18:59:20.11ID:zOtmkI/7 匿名性掲示板が困るのは、何かの欠点を指摘するとそれを作った当事者らしき人が
全否定をしてしまうことで話が深まらないこと。
同意する人がいればもっと良いライブラリを探す話とかに発展できる
かも知れないのに。
全否定をしてしまうことで話が深まらないこと。
同意する人がいればもっと良いライブラリを探す話とかに発展できる
かも知れないのに。
239デフォルトの名無しさん
2019/08/02(金) 19:00:52.12ID:4a7qvAUu ABI互換が問題ならextern "C"みたいに
extern ::std
みたいなので、マングリング時の名前空間を強制できる機能つければなんとかならんかね
extern ::std
みたいなので、マングリング時の名前空間を強制できる機能つければなんとかならんかね
240デフォルトの名無しさん
2019/08/02(金) 19:05:43.92ID:TY1gde0p >>237
お前の「使いやすい」と世間一般の「使いやすい」が一致してないというだけだろう。
お前の「こうあるべき」と世間一般の「こうあるべき」のズレが大きいから、今のC++はお前にとって不満の大きいものになっているんだろう。もしかすると家庭や学校、社会全体も。
お前の「使いやすい」と世間一般の「使いやすい」が一致してないというだけだろう。
お前の「こうあるべき」と世間一般の「こうあるべき」のズレが大きいから、今のC++はお前にとって不満の大きいものになっているんだろう。もしかすると家庭や学校、社会全体も。
241デフォルトの名無しさん
2019/08/02(金) 19:09:51.86ID:zOtmkI/7242デフォルトの名無しさん
2019/08/02(金) 19:10:14.38ID:TY1gde0p >>238
C++の仕様策定に関与したような人がこんなスレを覗いて低レベルな指摘にわざわざ反応するわけないだろう。想像力が豊かだな。
C++の仕様策定に関与したような人がこんなスレを覗いて低レベルな指摘にわざわざ反応するわけないだろう。想像力が豊かだな。
243デフォルトの名無しさん
2019/08/02(金) 19:12:46.85ID:yAHSp118 否定的意見はマウンティングとか強すぎるな
244デフォルトの名無しさん
2019/08/02(金) 19:12:52.67ID:zOtmkI/7 >>242
でも、オイラはそのくらいできるくらい優秀だよ。
でも、オイラはそのくらいできるくらい優秀だよ。
245デフォルトの名無しさん
2019/08/02(金) 19:15:19.48ID:zOtmkI/7 暗に陽にアメリカを褒めちぎって日本をけなすような人が5chには多い。
それで日本はめちゃくちゃに成ったんじゃなかろうか。
例えば「日本製スマホが全然駄目」などという説が5chでは大量に流布
されている。実際、そういう情報を信じて損する人は多かろう。
大問題だ。
それで日本はめちゃくちゃに成ったんじゃなかろうか。
例えば「日本製スマホが全然駄目」などという説が5chでは大量に流布
されている。実際、そういう情報を信じて損する人は多かろう。
大問題だ。
246デフォルトの名無しさん
2019/08/02(金) 19:49:20.44ID:azkiHyJD247デフォルトの名無しさん
2019/08/02(金) 21:08:13.86ID:9zV6XrP/ VSスレで暴れてたジジイと芸風が同じだな
248デフォルトの名無しさん
2019/08/02(金) 23:12:48.91ID:zqhkSChf 誰も書かなかったので仕方無いので漏れが書くが、namespaceの唯一の便利な使い方は(「唯一の」だ
、すでに衝突したあるいは衝突不可避なソースコードAとソースコードAを
namespace a { A }
namespace b { B }
と囲う等して分離できる ( こともある ) というだけやんけ
それとて完全には果たせないというあたりがいかにも行き当たりばったりで中途半端な言語要素感を醸し出してゐる
(中で::fooで呼んでたり入れ子のnamespaceを外から呼んでたりのケースは救われない
、すでに衝突したあるいは衝突不可避なソースコードAとソースコードAを
namespace a { A }
namespace b { B }
と囲う等して分離できる ( こともある ) というだけやんけ
それとて完全には果たせないというあたりがいかにも行き当たりばったりで中途半端な言語要素感を醸し出してゐる
(中で::fooで呼んでたり入れ子のnamespaceを外から呼んでたりのケースは救われない
249デフォルトの名無しさん
2019/08/02(金) 23:17:29.32ID:4a7qvAUu てかnamespaceは色々中途半端な点はあるが、便利に使える機能だろ
無いと物凄く不便
using namespace stdは使わんな
無いと物凄く不便
using namespace stdは使わんな
250デフォルトの名無しさん
2019/08/02(金) 23:19:05.25ID:jyJeqz7W 名前空間ネストして書くのが超めんどくさかったがようやく改善するとか
251デフォルトの名無しさん
2019/08/02(金) 23:37:02.96ID:DB/RmtTt 関数呼び出し時に宣言が必要か否かってCとC++では異なってたりしますか?
規格書読めないマンで申し訳ないのですがgccだとC/C++でそれぞれOK/NGと結果が異なります
規格書読めないマンで申し訳ないのですがgccだとC/C++でそれぞれOK/NGと結果が異なります
252デフォルトの名無しさん
2019/08/03(土) 00:35:18.25ID:T50aUZPM 翻訳単位超えるお話?
253デフォルトの名無しさん
2019/08/03(土) 02:27:32.85ID:m/VIbHu2 >>222は、FSMとPDAの区別もつかない
くるくる
((ヽ三/) (ヽ三/))
(((」) ___ (L)))
/ // ノヽ\\ \
( </ (● ●)\> )
\| ⌒(_人_)⌒|/
\  ̄ /
パーだおwwwwww
n「「「| 「「「h
|ー ⊃ ⊂ ー|
>ーノ___ヽー<
/ // ノヽ\\ \
( < o゚(● ●)゚o> )
\| ⌒(_人_)⌒|/
\ |┬| /
ヽノ
くるくる
((ヽ三/) (ヽ三/))
(((」) ___ (L)))
/ // ノヽ\\ \
( </ (● ●)\> )
\| ⌒(_人_)⌒|/
\  ̄ /
パーだおwwwwww
n「「「| 「「「h
|ー ⊃ ⊂ ー|
>ーノ___ヽー<
/ // ノヽ\\ \
( < o゚(● ●)゚o> )
\| ⌒(_人_)⌒|/
\ |┬| /
ヽノ
254デフォルトの名無しさん
2019/08/03(土) 07:47:52.71ID:NzOgSHrF お前らが名前空間で議論したところで何のメリットもデメリットもない事に気づけ、そしてRustを使え
ゴミ言語
ゴミ言語
255デフォルトの名無しさん
2019/08/03(土) 08:16:58.65ID:ulHqgYUF C++じゃないと出来ない事があるのでRustは使えん。
256デフォルトの名無しさん
2019/08/03(土) 08:30:10.28ID:NzOgSHrF >>255
(そのロジックを)Rustで書くことが出来ないと表現した方が正しそう
(そのロジックを)Rustで書くことが出来ないと表現した方が正しそう
257デフォルトの名無しさん
2019/08/03(土) 10:47:51.13ID:m/VIbHu2 Ristがチューリング完全かどうかについては誰もが口を濁すが
それはそうとして、これからはRustでプロトタイピングしてC++のコードを上司には提出するという
スタイルに移行するのではないかと思う
それはそうとして、これからはRustでプロトタイピングしてC++のコードを上司には提出するという
スタイルに移行するのではないかと思う
258デフォルトの名無しさん
2019/08/03(土) 11:01:51.61ID:L8lVlVkx Ristは流したけど上司に提出でふいた
259デフォルトの名無しさん
2019/08/03(土) 12:46:23.14ID:nO8f/Gbv >>234
2成分の vector<__float128> を使うことにしました
2成分の vector<__float128> を使うことにしました
260デフォルトの名無しさん
2019/08/03(土) 12:51:32.63ID:oHrDPFKS 名前空間つかうようりは、意味変数を使った方がよい
261デフォルトの名無しさん
2019/08/03(土) 13:07:00.48ID:eeu00PkY >>257
それはない。
それはない。
262デフォルトの名無しさん
2019/08/03(土) 13:47:24.37ID:ulHqgYUF >>260
意味変数って何?造語?
意味変数って何?造語?
263sage
2019/08/03(土) 15:26:08.69ID:dTS2sKLx >>261
unsafeを使わない場合の話
unsafeを使わない場合の話
264デフォルトの名無しさん
2019/08/03(土) 15:39:33.35ID:bjverAuH265デフォルトの名無しさん
2019/08/03(土) 15:51:00.92ID:bjverAuH namespaceそんなに不便かのう。
他の言語もやたらとパス掘って面倒なことになってるが。
pythonでも
import matplotlib.pyplot as plt
みたなのあるしな。
C++でやるなら
namespace plt = matplotlib::pyplot
とできるわけで、他の言語とにたりよったり
他の言語もやたらとパス掘って面倒なことになってるが。
pythonでも
import matplotlib.pyplot as plt
みたなのあるしな。
C++でやるなら
namespace plt = matplotlib::pyplot
とできるわけで、他の言語とにたりよったり
266デフォルトの名無しさん
2019/08/03(土) 16:06:05.71ID:dTS2sKLx >>264
using namespaceによって名前のバッティングのリスクはむしろ増す
なぜなら、namespaceの中身を記述する中の人がnamespaceで守られているつもりで短い名前を使いまくることがあるからじゃ
つまりnamespaceの中の人の思惑に反してusing namespaceしたとき、
namespaceは本来の言語要素としての目的とは真逆の危険なブツ(衝突の加速器)に早変わりする。
ファイルスコープでusing namespaceして書いたコードは他にもっていったとき地獄が始まる
ていうか同じものに複数の表記を許すのはそもそも美しくない
以上の理由によりusing namespaceは(特にファイルスコープでは)使ってはならない
C++から削除したほうが良い
using namespaceによって名前のバッティングのリスクはむしろ増す
なぜなら、namespaceの中身を記述する中の人がnamespaceで守られているつもりで短い名前を使いまくることがあるからじゃ
つまりnamespaceの中の人の思惑に反してusing namespaceしたとき、
namespaceは本来の言語要素としての目的とは真逆の危険なブツ(衝突の加速器)に早変わりする。
ファイルスコープでusing namespaceして書いたコードは他にもっていったとき地獄が始まる
ていうか同じものに複数の表記を許すのはそもそも美しくない
以上の理由によりusing namespaceは(特にファイルスコープでは)使ってはならない
C++から削除したほうが良い
267デフォルトの名無しさん
2019/08/03(土) 16:11:48.01ID:ve9YLJaL cout 自体使わないけど、昔のCだったら、#include <stdio.h>さえしとけば、
printf()もputs()もputhcar()もgetc()もfputc()もfprintf()もsprintf()も
vsprintf()もvprintf()もfopen()もfread(), fwrite(), fgetc() もみんな
そのまま短い関数名で使えたのに、今のC++だと、もし、
using namespace std; を使ってはならないなら、
using std::cout;
みたいな事を使う名前の文だけやらなくちゃいけないのはかなり非効率だと思う。
printf()もputs()もputhcar()もgetc()もfputc()もfprintf()もsprintf()も
vsprintf()もvprintf()もfopen()もfread(), fwrite(), fgetc() もみんな
そのまま短い関数名で使えたのに、今のC++だと、もし、
using namespace std; を使ってはならないなら、
using std::cout;
みたいな事を使う名前の文だけやらなくちゃいけないのはかなり非効率だと思う。
268デフォルトの名無しさん
2019/08/03(土) 16:15:24.12ID:eeu00PkY269デフォルトの名無しさん
2019/08/03(土) 16:21:38.24ID:dTS2sKLx >>265
namespace(やパッケージ名やモジュール名)のエイリアスえは安全性とタイピング量の効率の良い妥協点だとは思う
ただし、ファイルスコープでエイリアスしたコードを他に持っていったとき(ry
ちなRustではモジュール名の別名の付け替えはできないが、using namespaceみたいなことを
してほしいのかしてほしくないのかを中の人がモジュール名の末尾の階層を「prelude」にするという慣例で凌いでゐる
namespace(やパッケージ名やモジュール名)のエイリアスえは安全性とタイピング量の効率の良い妥協点だとは思う
ただし、ファイルスコープでエイリアスしたコードを他に持っていったとき(ry
ちなRustではモジュール名の別名の付け替えはできないが、using namespaceみたいなことを
してほしいのかしてほしくないのかを中の人がモジュール名の末尾の階層を「prelude」にするという慣例で凌いでゐる
270デフォルトの名無しさん
2019/08/03(土) 16:23:34.90ID:bjverAuH >>266
あの、.hでは使わず.cppで使う話についてなんだが
あの、.hでは使わず.cppで使う話についてなんだが
271デフォルトの名無しさん
2019/08/03(土) 16:24:37.04ID:bjverAuH >>269
だからなんでヘッダでそういうエイリアスやらを使う前提で話してんだ、おまえはバカか
だからなんでヘッダでそういうエイリアスやらを使う前提で話してんだ、おまえはバカか
272デフォルトの名無しさん
2019/08/03(土) 16:26:49.27ID:bjverAuH .cppの方は読み込むヘッダがそこに書き込まれてるんだからusingしようがaliasしようが問題ないだろと。
どこで読み込まれるかわからないヘッダに使うことと分けて考えられへんのかね、このバカは
どこで読み込まれるかわからないヘッダに使うことと分けて考えられへんのかね、このバカは
273デフォルトの名無しさん
2019/08/03(土) 16:26:57.92ID:dTS2sKLx274デフォルトの名無しさん
2019/08/03(土) 16:27:31.31ID:ve9YLJaL 大部分のここの人達の主張は、直接
std::vector, std::list, ・・・ を書くか、それが嫌なら、
using std::vector;
using std::list;
・・・
を延々と書けというんですよね。後者のやり方は、Java の import 文で
import com.sun.xxx.xxx.class1;
import com.sun.xxx.xxx.class2;
・・・
などとするのに似ていますが、それが一番の Java の欠点でも有る部分なんです。
そこを C++ は取り入れてしまった。
std::vector, std::list, ・・・ を書くか、それが嫌なら、
using std::vector;
using std::list;
・・・
を延々と書けというんですよね。後者のやり方は、Java の import 文で
import com.sun.xxx.xxx.class1;
import com.sun.xxx.xxx.class2;
・・・
などとするのに似ていますが、それが一番の Java の欠点でも有る部分なんです。
そこを C++ は取り入れてしまった。
275デフォルトの名無しさん
2019/08/03(土) 16:32:21.74ID:dTS2sKLx276デフォルトの名無しさん
2019/08/03(土) 16:35:39.76ID:s7JzQoXH stdつけるのそんなに嫌かね?
1つなら良いじゃないかと思う
長い奴は別名つけりゃいいし
IDE使っているとnamespace付きの方が候補が絞れてむしろ便利じゃね
ADLでつけなくても呼べる場面であったとしても
1つなら良いじゃないかと思う
長い奴は別名つけりゃいいし
IDE使っているとnamespace付きの方が候補が絞れてむしろ便利じゃね
ADLでつけなくても呼べる場面であったとしても
277デフォルトの名無しさん
2019/08/03(土) 16:46:08.58ID:eeu00PkY >>276
IDEのエディタは使ってないので補完機能は使わない。
IDEのエディタは使ってないので補完機能は使わない。
278デフォルトの名無しさん
2019/08/03(土) 16:52:55.00ID:M1zmWsZu IDE使え
279デフォルトの名無しさん
2019/08/03(土) 16:58:03.17ID:bjverAuH >>276
なんでstdに限定するのかな
なんでstdに限定するのかな
280デフォルトの名無しさん
2019/08/03(土) 16:59:59.07ID:bjverAuH >>275
なにが困るんだっての。
名前が被ったらスコープ内での命名が優先されるが、読み込んだヘッダの中の名前に影響は及ぼさないだろ
そして、隠蔽された名前にはnamespace名を使えばアクセスできるんだから何ら問題はない
なにが困るんだっての。
名前が被ったらスコープ内での命名が優先されるが、読み込んだヘッダの中の名前に影響は及ぼさないだろ
そして、隠蔽された名前にはnamespace名を使えばアクセスできるんだから何ら問題はない
281デフォルトの名無しさん
2019/08/03(土) 17:00:41.48ID:s7JzQoXH282デフォルトの名無しさん
2019/08/03(土) 17:08:23.80ID:dTS2sKLx283デフォルトの名無しさん
2019/08/03(土) 17:14:33.69ID:eeu00PkY >>280
その話とは関係ないかもしれないけど、以下のようなことがあった。
その時には、理由は追求しなかったんだけど、昔、Javaで
impot com.sun.xxx.xxx.*;
impot com.sun.yyy.yyy;
・・・
みたいなことをやった時、* を付けたことによって javacでコンパイル時に名前衝突が起きた
ことがあった。それで * を使うのをやめて個別に直したら衝突しなくなった。
最後の方の名前は同じで、それを限定している名前、例えば、
zzz.aaa.ccc;
zzz.bbb.ccc;
みたいなのがあって、ccc の部分が同じだから ccc だけでアクセスできるようにした場合に
衝突が起きたのかもしれない。
その話とは関係ないかもしれないけど、以下のようなことがあった。
その時には、理由は追求しなかったんだけど、昔、Javaで
impot com.sun.xxx.xxx.*;
impot com.sun.yyy.yyy;
・・・
みたいなことをやった時、* を付けたことによって javacでコンパイル時に名前衝突が起きた
ことがあった。それで * を使うのをやめて個別に直したら衝突しなくなった。
最後の方の名前は同じで、それを限定している名前、例えば、
zzz.aaa.ccc;
zzz.bbb.ccc;
みたいなのがあって、ccc の部分が同じだから ccc だけでアクセスできるようにした場合に
衝突が起きたのかもしれない。
284デフォルトの名無しさん
2019/08/03(土) 17:18:00.03ID:eeu00PkY >>283
Javaの仕様も忘れてしまったけど、
import zzz.aaa.*; // たまたま zzz.aaa.ccc というのが有ったとする。
import zzz.bbb.ccc;
↑のような場合に、ccc という名前が衝突するのかも。
Javaの仕様も忘れてしまったけど、
import zzz.aaa.*; // たまたま zzz.aaa.ccc というのが有ったとする。
import zzz.bbb.ccc;
↑のような場合に、ccc という名前が衝突するのかも。
285デフォルトの名無しさん
2019/08/03(土) 17:23:56.42ID:L8lVlVkx >>274
> 大部分のここの人達の主張は、直接
>
> std::vector, std::list, ・・・ を書くか、それが嫌なら、
これはよい
でも
> using std::vector;
> using std::list;
> ・・・
>
> を延々と書けというんですよね。
これを言ってる人いたっけ?
名前空間を明示するというポリシーに反してるからおれは使わないな
> 大部分のここの人達の主張は、直接
>
> std::vector, std::list, ・・・ を書くか、それが嫌なら、
これはよい
でも
> using std::vector;
> using std::list;
> ・・・
>
> を延々と書けというんですよね。
これを言ってる人いたっけ?
名前空間を明示するというポリシーに反してるからおれは使わないな
286デフォルトの名無しさん
2019/08/03(土) 17:28:41.36ID:bjverAuH 自分のコントロール下にあるところで機能を使うなってのは自分が上手くつかえないだけの話だわな。
ブロック作ってブロック外と同じ名前の変数作ることすら禁止しそうな勢いだな。
ヘッダで使うなってのは自分のコントロール範囲外でバッティングが生じるからだ。
ブロック作ってブロック外と同じ名前の変数作ることすら禁止しそうな勢いだな。
ヘッダで使うなってのは自分のコントロール範囲外でバッティングが生じるからだ。
287デフォルトの名無しさん
2019/08/03(土) 17:29:59.98ID:rAotfWJY そもそも名前空間の柔軟性は、C++が最強だから。
文句言うのは筋違い。
文句言うのは筋違い。
288デフォルトの名無しさん
2019/08/03(土) 17:34:07.35ID:eeu00PkY そもそも標準のライブラリなので、namespace std の中に入れる必要なかった。
下手に入れてしまったからむしろ std:: を外したときに衝突する問題が
起きる可能性が出てきてしまった。
下手に入れてしまったからむしろ std:: を外したときに衝突する問題が
起きる可能性が出てきてしまった。
289デフォルトの名無しさん
2019/08/03(土) 17:37:28.85ID:rAotfWJY290デフォルトの名無しさん
2019/08/03(土) 17:42:58.60ID:ulHqgYUF Microsoftのmin,maxマクロの事か
291デフォルトの名無しさん
2019/08/03(土) 17:46:28.08ID:eeu00PkY292デフォルトの名無しさん
2019/08/03(土) 17:47:44.86ID:rAotfWJY >>291
殺せ。
殺せ。
293デフォルトの名無しさん
2019/08/03(土) 17:48:34.32ID:rAotfWJY294デフォルトの名無しさん
2019/08/03(土) 17:50:54.20ID:eeu00PkY そういえば、min(), max() は C の時代、確かマクロ実装版が基本だったり
して複雑なことになっているのかな。よく知らないけど。
して複雑なことになっているのかな。よく知らないけど。
295デフォルトの名無しさん
2019/08/03(土) 17:53:29.88ID:3VuQ5ICx そこでBOOST_PREVENT_MACRO_SUBSTITUTIONですよ
BOOST_PREVENT_MACRO_SUBSTITUTIONを崇めよ
BOOST_PREVENT_MACRO_SUBSTITUTIONを崇めよ
296デフォルトの名無しさん
2019/08/03(土) 17:55:43.43ID:rAotfWJY マイクロソフト最大のチョンボだよな。
297デフォルトの名無しさん
2019/08/03(土) 17:59:48.03ID:3VuQ5ICx 関数は関数呼び出しが遅いから使うなマクロにしろ
処理は全部mainに入れろ
という恐ろしい時代から引きずってるから仕方ないといえば仕方ない
処理は全部mainに入れろ
という恐ろしい時代から引きずってるから仕方ないといえば仕方ない
298デフォルトの名無しさん
2019/08/03(土) 18:02:18.88ID:eeu00PkY だったら STL の方が、std::max とかじゃなくて、
std::smax とかにすべきだったような気がしますが。
std::smax とかにすべきだったような気がしますが。
299デフォルトの名無しさん
2019/08/03(土) 18:03:42.44ID:ulHqgYUF NOMINMAXしたらしたでgdiplusでエラーになったので、仕方なくusing std::min;using std::max;を書いてしまった。
300デフォルトの名無しさん
2019/08/03(土) 18:03:43.41ID:SSA79Euw >>288
どんなusingがされている箇所でもstd::をつけさえすれば確実に標準ライブラリにアクセスできるんだから、記述の一貫性を保つのに役立つよ。
どんなusingがされている箇所でもstd::をつけさえすれば確実に標準ライブラリにアクセスできるんだから、記述の一貫性を保つのに役立つよ。
301デフォルトの名無しさん
2019/08/03(土) 18:07:41.16ID:eeu00PkY 元々 min(), max() は非常に古い C時代から #define されているマクロですよね、
std::min(), std::max() と書いても結局マクロ展開されてしまうのでは
ないでしょうか???
std::min(), std::max() と書いても結局マクロ展開されてしまうのでは
ないでしょうか???
302デフォルトの名無しさん
2019/08/03(土) 18:08:18.92ID:rAotfWJY >>298
でも実際に引っかかったら、何でこういうことする!マイクロソフト死ね!!っておまえも思うはず。
でも実際に引っかかったら、何でこういうことする!マイクロソフト死ね!!っておまえも思うはず。
303デフォルトの名無しさん
2019/08/03(土) 18:10:37.82ID:eeu00PkY STL の方の min(), max() を使いたい場合は、
(min)(a,b)
(max)(a,b)
でいけるようです。C/C++ の前処理層によるマクロ展開は
マクロ関数名(
という並びが有る場合にのみ展開されますので。
(min)(a,b)
(max)(a,b)
でいけるようです。C/C++ の前処理層によるマクロ展開は
マクロ関数名(
という並びが有る場合にのみ展開されますので。
304デフォルトの名無しさん
2019/08/03(土) 18:14:26.75ID:eeu00PkY >>302
いや、むしろ逆に、std::min の設計者の方がCの常識を知らない人だな、
と思ってしまいます。
そもそも、min(), max() マクロは、1980年代のC言語の時代から有るよく
知られたものなので、後から登場した C++ 標準ライブラリは、それが
有る場合にでも当然問題なく使えるようにしなくてはならなかったが、
そうなってません。それはどちらに原因があるかは明確です。
いや、むしろ逆に、std::min の設計者の方がCの常識を知らない人だな、
と思ってしまいます。
そもそも、min(), max() マクロは、1980年代のC言語の時代から有るよく
知られたものなので、後から登場した C++ 標準ライブラリは、それが
有る場合にでも当然問題なく使えるようにしなくてはならなかったが、
そうなってません。それはどちらに原因があるかは明確です。
305デフォルトの名無しさん
2019/08/03(土) 18:19:07.11ID:dTS2sKLx >>301
左様
.cppのヘッダファイルをインクルードし終わった以降の適当な場所でおもむろに
#undef min
#undef max
インクルードしたヘッダファイルにマクロ版のmin()、max()に依存したマクロが存在せず、
かつマクロ版のmin()、max()を使わない限りにおいてこれでおk、
左様
.cppのヘッダファイルをインクルードし終わった以降の適当な場所でおもむろに
#undef min
#undef max
インクルードしたヘッダファイルにマクロ版のmin()、max()に依存したマクロが存在せず、
かつマクロ版のmin()、max()を使わない限りにおいてこれでおk、
306305
2019/08/03(土) 18:26:53.75ID:dTS2sKLx 適用条件訂正orz
正: マクロ版のmin()、max()を使わない限りにおいてこれでおk、
インクルードしたヘッダファイルに含まれるマクロ版のmin()、max()に依存するマクロ経由で
間接的にマクロ版のmin()、max()を使おうとした場合はコンパイルエラーになるからワカル
そうなった場合の処置は知らんが、コンパイルが通ったら>>305の方法で安全なはず
正: マクロ版のmin()、max()を使わない限りにおいてこれでおk、
インクルードしたヘッダファイルに含まれるマクロ版のmin()、max()に依存するマクロ経由で
間接的にマクロ版のmin()、max()を使おうとした場合はコンパイルエラーになるからワカル
そうなった場合の処置は知らんが、コンパイルが通ったら>>305の方法で安全なはず
307デフォルトの名無しさん
2019/08/03(土) 18:29:09.20ID:3VuQ5ICx 一番安全なのはこれだってboostの長年の結論だから
max BOOST_PREVENT_MACRO_SUBSTITUTION (a,b)
max BOOST_PREVENT_MACRO_SUBSTITUTION (a,b)
308デフォルトの名無しさん
2019/08/03(土) 18:29:45.19ID:eeu00PkY マクロ版 min(), max() が #define されている状態でも、
#define smin (std::min)
#define smax (std::max)
としてしまえば、smin(a,b), smax(a,b) と書くだけで
それぞれ std::min(), std:max()
が使えるでしょう。
#define smin (std::min)
#define smax (std::max)
としてしまえば、smin(a,b), smax(a,b) と書くだけで
それぞれ std::min(), std:max()
が使えるでしょう。
309デフォルトの名無しさん
2019/08/03(土) 18:32:51.04ID:dTS2sKLx310デフォルトの名無しさん
2019/08/03(土) 18:55:02.09ID:aqiFUikh この手の無駄に一般化は大抵バグを引き起こす。
312デフォルトの名無しさん
2019/08/03(土) 19:47:04.82ID:M1zmWsZu std::を書くと死ぬ人が発狂してるだけなので、std::を普通に書ける人にはしょうもない話
313デフォルトの名無しさん
2019/08/03(土) 19:50:41.99ID:XP2vdzkU これはVisual Studio 2019のバグだろうか?
C++17想定。Wandboxでは問題なし。
namespace user::math::literals {
constexpr double operator""_deg(long double deg) {
return deg * 3.14 / 180.0;
}
};
struct Test {
template<typename T = double>
constexpr double test(T t) {
using namespace user::math::literals;
return 1.0_deg * 8.0;
}
};
int main(){
}
//error C3688: リテラル サフィックス '_deg' が無効です。リテラル演算子またはリテラル演算子テンプレート 'operator ""_deg' が見つかりません
発生条件はクラス内テンプレート関数でユーザー定義リテラルを含んだ式
return 1.0_deg * 8.0;をreturn 1.0_deg;に変えると問題ない
C++17想定。Wandboxでは問題なし。
namespace user::math::literals {
constexpr double operator""_deg(long double deg) {
return deg * 3.14 / 180.0;
}
};
struct Test {
template<typename T = double>
constexpr double test(T t) {
using namespace user::math::literals;
return 1.0_deg * 8.0;
}
};
int main(){
}
//error C3688: リテラル サフィックス '_deg' が無効です。リテラル演算子またはリテラル演算子テンプレート 'operator ""_deg' が見つかりません
発生条件はクラス内テンプレート関数でユーザー定義リテラルを含んだ式
return 1.0_deg * 8.0;をreturn 1.0_deg;に変えると問題ない
314デフォルトの名無しさん
2019/08/03(土) 19:58:09.36ID:M1zmWsZu 普通にビルドできたけどプロジェクトのC++言語基準をちゃんとC++17にしたか?
315デフォルトの名無しさん
2019/08/03(土) 19:59:17.19ID:gpWi1Ho2316デフォルトの名無しさん
2019/08/03(土) 21:04:27.05ID:3VuQ5ICx using namespace はその名前空間の中の名前を私が責任持って現在の環境に導入しますという宣言だ
中身を把握してないくせにそんな事して事故った奴が全部悪いんであって、使われた側には責任はない
stdとて例外ではない
中身を把握してないくせにそんな事して事故った奴が全部悪いんであって、使われた側には責任はない
stdとて例外ではない
317デフォルトの名無しさん
2019/08/03(土) 21:27:39.99ID:dTS2sKLx >>316
使われた側の未来のふるまいまで予測してnamespaceの中身を理解などしていられない件について:
namespaceの正しい使われ方の下では、aというnamespaceに将来どんな名前が追加されようとも
bというnamespaceの名前とは衝突しないはずである
ところがaとbをusing namespaceしてしまったが最後、誰にも責任が持てないカオスが訪れる
これはnamespaceが無かったころの言語に先祖返りするだけではなく、より悪い状況を招くことに注意。
namespaceの利用によって、open、close、copy、find、vector、list、string、.....といった「自然な」名前がいっぱい使用されるからである。
namespaceは崇高だが、using namespaceはそうされることを意図されたnamespace意外には邪悪すぐる
使われた側の未来のふるまいまで予測してnamespaceの中身を理解などしていられない件について:
namespaceの正しい使われ方の下では、aというnamespaceに将来どんな名前が追加されようとも
bというnamespaceの名前とは衝突しないはずである
ところがaとbをusing namespaceしてしまったが最後、誰にも責任が持てないカオスが訪れる
これはnamespaceが無かったころの言語に先祖返りするだけではなく、より悪い状況を招くことに注意。
namespaceの利用によって、open、close、copy、find、vector、list、string、.....といった「自然な」名前がいっぱい使用されるからである。
namespaceは崇高だが、using namespaceはそうされることを意図されたnamespace意外には邪悪すぐる
318313
2019/08/03(土) 21:32:17.54ID:xzejIjJP >>314
再インストールしなおしてプロジェクトの設定をC++17なのを確認してもエラーが出た
うちの環境だけか・・・
Visual Studio 2019 Community Version 16.2.0
再インストールしなおしてプロジェクトの設定をC++17なのを確認してもエラーが出た
うちの環境だけか・・・
Visual Studio 2019 Community Version 16.2.0
319デフォルトの名無しさん
2019/08/03(土) 21:38:58.27ID:M1zmWsZu320デフォルトの名無しさん
2019/08/03(土) 21:51:26.72ID:3VuQ5ICx >>317
完全に同意
そういう事態が起きないと確信できるほど中身を理解してるnamespaceか、起きても問題ないほど狭いスコープか
そのどちらかでしか使ってはいけないものだ
using namespaceというのはそういう乱暴な機能
完全に同意
そういう事態が起きないと確信できるほど中身を理解してるnamespaceか、起きても問題ないほど狭いスコープか
そのどちらかでしか使ってはいけないものだ
using namespaceというのはそういう乱暴な機能
321317
2019/08/03(土) 21:51:59.64ID:dTS2sKLx322デフォルトの名無しさん
2019/08/03(土) 21:54:29.31ID:3VuQ5ICx323デフォルトの名無しさん
2019/08/03(土) 22:06:21.81ID:CM1VqrV7324デフォルトの名無しさん
2019/08/03(土) 22:09:28.81ID:bbhz9sWw using namespaceの話はも止めたら?
使いたい人は使えばいいし
使いたくない人は使わなければいい
でいいじゃん
大した問題じゃないだろ
使いたい人は使えばいいし
使いたくない人は使わなければいい
でいいじゃん
大した問題じゃないだろ
325デフォルトの名無しさん
2019/08/04(日) 00:06:21.11ID:gKArgCAM ダメに決まってるだろw
Coding Standardの話なのにw
Coding Standardの話なのにw
326デフォルトの名無しさん
2019/08/04(日) 01:17:09.87ID:uuq2lSJI どうでもいいだろ
C++のようなアレな言語を扱う上では些細な事さ
C++のようなアレな言語を扱う上では些細な事さ
327デフォルトの名無しさん
2019/08/04(日) 01:20:42.30ID:6uyvUJES そもそもプログラミングは間違ったことを信じている人がはっきり損をする世界
(ことあるごとにエラーが多発するとか作成に余分な時間がかかるとか完成品の質が悪いとかの話で)
リアルで誰かと作業するならともかく
ネットの向こうの間違ってる誰かなんて放っておいても損を勝手に積み立てて自らつぶれていくものだ
(ことあるごとにエラーが多発するとか作成に余分な時間がかかるとか完成品の質が悪いとかの話で)
リアルで誰かと作業するならともかく
ネットの向こうの間違ってる誰かなんて放っておいても損を勝手に積み立てて自らつぶれていくものだ
328デフォルトの名無しさん
2019/08/04(日) 01:21:14.60ID:uuq2lSJI おれはね
C++はね
正しく扱うのに本当にコツのいる言語だと思うんよ
そんな中using namespaceは割とどうでも良いよね
俺は使わない派だが、使いたければ使えばって感じ
C++はね
正しく扱うのに本当にコツのいる言語だと思うんよ
そんな中using namespaceは割とどうでも良いよね
俺は使わない派だが、使いたければ使えばって感じ
329デフォルトの名無しさん
2019/08/04(日) 01:59:42.19ID:xBRRtFJn 確かにどうでもいいな
プルリクで簡単に見つかるから
というかコンパイルや静的解析でエラーにする方法はないかな
プルリクで簡単に見つかるから
というかコンパイルや静的解析でエラーにする方法はないかな
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 【速報】「女芸人No.1決定戦 THE W」9代目女王にニッチェ! 7年ぶり3度目で悲願の優勝 [牛丼★]
- 731部隊の新資料、中国が公開 「日本が細菌戦の罪を自白」と主張 ロシアが引き渡し [少考さん★]
- 中国・ロシア両軍の爆撃機が東京方面へ向かう「異例のルート」を共同飛行…核も搭載可能、連携して威嚇か ★7 [ぐれ★]
- 【芸能】『女芸人No.1決定戦THE W』 粗品が最後にバッサリ「優勝賞金1000万円にしてはレベル低い大会」 [冬月記者★]
- 中国・ロシア両軍の爆撃機が東京方面へ向かう「異例のルート」を共同飛行…核も搭載可能、連携して威嚇か ★8 [ぐれ★]
- 【広島】ペルー女性の国保加入を誤って認め、福山市が医療費484万円を肩代わりするミス…入院して手術を受ける [ぐれ★]
- 【緊急高市朗報】WBC全試合、地上波完全生放送決定wmwmwmwmwmwmwmwmwmwmwmwmwmwmwmw [517459952]
- パン🍞つー✌まる👌見え👊😅👊
- テメェは俺を怒らせたオラァ👊💢😅💢👊🏡
- かなシコ!!許可願います!!
- 🏡パン🍞つー✌まる👌見え👊😅👊
- こち亀初期の麗子って乳放り出してたよな
