X

C++相談室 part144

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
垢版 |
2019/07/22(月) 13:18:35.52ID:gptRHpgT
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/ (日本語)

----- テンプレ ここまで -----
0213デフォルトの名無しさん
垢版 |
2019/08/02(金) 06:16:59.13ID:DB/RmtTt
長文なのに書いてある事はスカスカだな
腐ってもプログラマーの端くれなら言いたい事は短く簡潔に書いてくれ
0217デフォルトの名無しさん
垢版 |
2019/08/02(金) 07:27:30.51ID:uj4cDNt2
だいたい標準ライブラリがvectorとあstringみたいなきわめて衝突しやすい名前を使っているのが悪い
諸悪の根源すぎて死ぬ
std_vectorとかstd_stringとか衝突しにくい名前にすれば済んだ話
しかしそれだと標準ライブラリ内部のコードがﾀﾞｻくなって逝けてないから、という理由で導入されたのがstd名前空間。
所詮センスの問題なためにいつまでたっても議論が収束しない

ここはRustのパッケージのようにパッケージが公開/非公開の唯一の境界、みたいに割り切って
名前空間の設定に論理的必然を持たせたらよかったんじゃ…
0218デフォルトの名無しさん
垢版 |
2019/08/02(金) 07:35:54.09ID:uj4cDNt2
だいたいfoo::some_symbolと書いたときfooがクラスのときご名前空間のときがあって、
それぞれやれることが微妙に違いもあるがだいたいオーバーラップしているとか嫌すぐる…
疑問に思わないのはC++に脳が汚染されている証拠

後方互換性命で変えるな派と後方互換性を失っても改良すべき派の合意が見られない事案については
前者が勝って後者は追加で我慢するというＷＩＮ-win決着で永遠に先送りされつつ混迷だけが深まっていくのがC++の宿命
0220デフォルトの名無しさん
垢版 |
2019/08/02(金) 07:42:20.24ID:uj4cDNt2
なにおうnamespaceがイミフな言語機能であることぐらいはよくわかっとるわ！
標準ライブラリ内部のコードにおいてもほとんどがテンプレートであるために、
using std;することが許されない

つまり、std_vectorやstd_stringという風に名前を長くするのに対してなんのメリットも提供されていない
0222デフォルトの名無しさん
垢版 |
2019/08/02(金) 08:15:18.88ID:WBAmTSV/
関数名_ローカル名 ってすれば全部グローバル変数でいいだろっていう主張？
0224デフォルトの名無しさん
垢版 |
2019/08/02(金) 09:13:54.00ID:9zV6XrP/
なんでこういう馬鹿が定期的に沸くんだ
ちょっと調べればなぜこんな機能が必要とされたか位わかるだろ
名前空間の問題なんてC++固有の問題じゃないのに
0227デフォルトの名無しさん
垢版 |
2019/08/02(金) 16:35:01.23ID:aGnTdwVX
インスタンス生成時に絶対に決めなきゃいけない定数をテンプレートパラメータにするかコンストラクタに渡すか迷ってる

両者にはどういう思想の違いがありますか？
0228デフォルトの名無しさん
垢版 |
2019/08/02(金) 16:54:49.60ID:Bzyz7IRB
なんかLinus TorvaldsがC++ディスってる記事でnamespace絡みで
｢Cならmy_foo()って名前にするね、やっほー、grep my_fooが機能するぜ！｣
みたいな話があったような気がするんだけど検索しても見つからない(´・ω・`)
0231デフォルトの名無しさん
垢版 |
2019/08/02(金) 18:19:12.53ID:zOtmkI/7
>>218
aaa::bbb::ccc::ddd みたいな名前が大量に必要になったりして、
STLの設計者は設計が下手だと思う。
0235デフォルトの名無しさん
垢版 |
2019/08/02(金) 18:51:13.74ID:OZv2fXQJ
今std::chronoとかstd::filesystemとか標準の名前空間も細分化するようにしてきてるからusing namespace std;の影響もそこまで酷くならないかもしれない
0236デフォルトの名無しさん
垢版 |
2019/08/02(金) 18:52:43.15ID:4a7qvAUu
stdの中に全部ぶちこんであるのが問題

std::header名の名前空間に入れて、std内でusing namespace header名していればいいのに

std::xxxでも使えるし、using namespace std::header名すればそのheaderの中身だけが省略して使える
0237デフォルトの名無しさん
垢版 |
2019/08/02(金) 18:56:02.63ID:zOtmkI/7
>>232
なんでも初期状態で使いやすいことが重要。
使いやすくするには各自でやれというのは設計が下手な証拠。
0238デフォルトの名無しさん
垢版 |
2019/08/02(金) 18:59:20.11ID:zOtmkI/7
匿名性掲示板が困るのは、何かの欠点を指摘するとそれを作った当事者らしき人が
全否定をしてしまうことで話が深まらないこと。
同意する人がいればもっと良いライブラリを探す話とかに発展できる
かも知れないのに。
0239デフォルトの名無しさん
垢版 |
2019/08/02(金) 19:00:52.12ID:4a7qvAUu
ABI互換が問題ならextern "C"みたいに
extern ::std
みたいなので、マングリング時の名前空間を強制できる機能つければなんとかならんかね
0240デフォルトの名無しさん
垢版 |
2019/08/02(金) 19:05:43.92ID:TY1gde0p
>>237
お前の｢使いやすい｣と世間一般の｢使いやすい｣が一致してないというだけだろう。
お前の｢こうあるべき｣と世間一般の｢こうあるべき｣のズレが大きいから、今のC++はお前にとって不満の大きいものになっているんだろう。もしかすると家庭や学校、社会全体も。
0241デフォルトの名無しさん
垢版 |
2019/08/02(金) 19:09:51.86ID:zOtmkI/7
>>240
そういう話がやっぱり、「ポジショントーク」だと思うんだよ。
そこまでして人の意見を全否定するには何らかの背景事情があると
しか思えない。
0242デフォルトの名無しさん
垢版 |
2019/08/02(金) 19:10:14.38ID:TY1gde0p
>>238
C++の仕様策定に関与したような人がこんなスレを覗いて低レベルな指摘にわざわざ反応するわけないだろう。想像力が豊かだな。
0245デフォルトの名無しさん
垢版 |
2019/08/02(金) 19:15:19.48ID:zOtmkI/7
暗に陽にアメリカを褒めちぎって日本をけなすような人が5chには多い。
それで日本はめちゃくちゃに成ったんじゃなかろうか。
例えば「日本製スマホが全然駄目」などという説が5chでは大量に流布
されている。実際、そういう情報を信じて損する人は多かろう。
大問題だ。
0248デフォルトの名無しさん
垢版 |
2019/08/02(金) 23:12:48.91ID:zqhkSChf
誰も書かなかったので仕方無いので漏れが書くが、namespaceの唯一の便利な使い方は（「唯一の」だ
、すでに衝突したあるいは衝突不可避なソースコードAとソースコードAを
namespace a { A }
namespace b { B }
と囲う等して分離できる　（　こともある　）　というだけやんけ
それとて完全には果たせないというあたりがいかにも行き当たりばったりで中途半端な言語要素感を醸し出してゐる
（中で::fooで呼んでたり入れ子のnamespaceを外から呼んでたりのケースは救われない
0249デフォルトの名無しさん
垢版 |
2019/08/02(金) 23:17:29.32ID:4a7qvAUu
てかnamespaceは色々中途半端な点はあるが、便利に使える機能だろ
無いと物凄く不便
using namespace stdは使わんな
0251デフォルトの名無しさん
垢版 |
2019/08/02(金) 23:37:02.96ID:DB/RmtTt
関数呼び出し時に宣言が必要か否かってCとC++では異なってたりしますか？
規格書読めないマンで申し訳ないのですがgccだとC/C++でそれぞれOK/NGと結果が異なります
0253デフォルトの名無しさん
垢版 |
2019/08/03(土) 02:27:32.85ID:m/VIbHu2
>>222は、FSMとPDAの区別もつかない
くるくる

（(ヽ三/)　　 (ヽ三/))
　 (((｣) _＿＿ (L)))
　／ ／／ ノヽ＼＼ ＼
（　<／ (●　●)＼>　)
　＼｜ ⌒(_人_)⌒｜／
　　 ＼　　￣　 ／

パーだおｗｗｗｗｗｗ

　　n｢｢｢|　　　｢｢｢h
　 ｜ー ⊃　 ⊂ ー｜
　　>ーノ_＿＿ヽー<
　／ ／／ ノヽ＼＼ ＼
（　< oﾟ(●　●)ﾟo>　)
　＼｜ ⌒(_人_)⌒｜／
　　 ＼　 |┬|　／
　　　　　ヽノ
0254デフォルトの名無しさん
垢版 |
2019/08/03(土) 07:47:52.71ID:NzOgSHrF
お前らが名前空間で議論したところで何のメリットもデメリットもない事に気づけ、そしてRustを使え
ゴミ言語
0257デフォルトの名無しさん
垢版 |
2019/08/03(土) 10:47:51.13ID:m/VIbHu2
Ristがチューリング完全かどうかについては誰もが口を濁すが
それはそうとして、これからはRustでプロトタイピングしてC++のコードを上司には提出するという
スタイルに移行するのではないかと思う
0260デフォルトの名無しさん
垢版 |
2019/08/03(土) 12:51:32.63ID:oHrDPFKS
名前空間つかうようりは、意味変数を使った方がよい
0263sage
垢版 |
2019/08/03(土) 15:26:08.69ID:dTS2sKLx
>>261
unsafeを使わない場合の話
0265デフォルトの名無しさん
垢版 |
2019/08/03(土) 15:51:00.92ID:bjverAuH
namespaceそんなに不便かのう。
他の言語もやたらとパス掘って面倒なことになってるが。
pythonでも
import matplotlib.pyplot as plt
みたなのあるしな。
C++でやるなら
namespace plt = matplotlib::pyplot
とできるわけで、他の言語とにたりよったり
0266デフォルトの名無しさん
垢版 |
2019/08/03(土) 16:06:05.71ID:dTS2sKLx
>>264
using namespaceによって名前のバッティングのリスクはむしろ増す
なぜなら、namespaceの中身を記述する中の人がnamespaceで守られているつもりで短い名前を使いまくることがあるからじゃ
つまりnamespaceの中の人の思惑に反してusing namespaceしたとき、
namespaceは本来の言語要素としての目的とは真逆の危険なブツ（衝突の加速器）に早変わりする。

ファイルスコープでusing namespaceして書いたコードは他にもっていったとき地獄が始まる

ていうか同じものに複数の表記を許すのはそもそも美しくない

以上の理由によりusing namespaceは（特にファイルスコープでは）使ってはならない
C++から削除したほうが良い
0267デフォルトの名無しさん
垢版 |
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;

みたいな事を使う名前の文だけやらなくちゃいけないのはかなり非効率だと思う。
0268デフォルトの名無しさん
垢版 |
2019/08/03(土) 16:15:24.12ID:eeu00PkY
>>267
誤：みたいな事を使う名前の文だけやらなくちゃいけないのはかなり非効率だと思う。
正：みたいな事を使う名前の分だけやらなくちゃいけないのはかなり非効率だと思う。
0269デフォルトの名無しさん
垢版 |
2019/08/03(土) 16:21:38.24ID:dTS2sKLx
>>265
namespace（やパッケージ名やモジュール名）のエイリアスえは安全性とタイピング量の効率の良い妥協点だとは思う
ただし、ファイルスコープでエイリアスしたコードを他に持っていったとき(ry

ちなRustではモジュール名の別名の付け替えはできないが、using namespaceみたいなことを
してほしいのかしてほしくないのかを中の人がモジュール名の末尾の階層を「prelude」にするという慣例で凌いでゐる
0272デフォルトの名無しさん
垢版 |
2019/08/03(土) 16:26:49.27ID:bjverAuH
.cppの方は読み込むヘッダがそこに書き込まれてるんだからusingしようがaliasしようが問題ないだろと。
どこで読み込まれるかわからないヘッダに使うことと分けて考えられへんのかね、このバカは
0273デフォルトの名無しさん
垢版 |
2019/08/03(土) 16:26:57.92ID:dTS2sKLx
>>270>>271
.hでは使わず.cppで使う話してるんだけど…
ひょっとしてファイルスコープでusing namespaceするというのを.hで使う意味だと
この暑さで短絡しているのでは…
0274デフォルトの名無しさん
垢版 |
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++ は取り入れてしまった。
0275デフォルトの名無しさん
垢版 |
2019/08/03(土) 16:32:21.74ID:dTS2sKLx
>>274
Javaのimport文も一応「*」でusing namespaceと同じようなことができるはず…
問題なのは、中の人の意図がusing namespaceしてほしくないケース（namespace内で短い名前を使いまくっている（>>266））
においてもusing namespaceできてしまうことにある
0276デフォルトの名無しさん
垢版 |
2019/08/03(土) 16:35:39.76ID:s7JzQoXH
stdつけるのそんなに嫌かね？
1つなら良いじゃないかと思う
長い奴は別名つけりゃいいし
IDE使っているとnamespace付きの方が候補が絞れてむしろ便利じゃね
ADLでつけなくても呼べる場面であったとしても
0280デフォルトの名無しさん
垢版 |
2019/08/03(土) 16:59:59.07ID:bjverAuH
>>275
なにが困るんだっての。
名前が被ったらスコープ内での命名が優先されるが、読み込んだヘッダの中の名前に影響は及ぼさないだろ
そして、隠蔽された名前にはnamespace名を使えばアクセスできるんだから何ら問題はない
0282デフォルトの名無しさん
垢版 |
2019/08/03(土) 17:08:23.80ID:dTS2sKLx
>>280の言っている「問題にならないケース」はusing namespaceしなければ
そもそも名前が被ったりしないことから尻拭いの手間が生じないケースなので
using namespace擁護としては意味がない

既存の型と短い名前の組み合わせでも名前が衝突しないようにnamespaceという仕組みを設けたというのに
その崇高な理念を忘却しし、衝突させておいてから尻拭い可能だからおk、というおよそ合理精神0のが>>280の主張
0283デフォルトの名無しさん
垢版 |
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 だけでアクセスできるようにした場合に
衝突が起きたのかもしれない。
0284デフォルトの名無しさん
垢版 |
2019/08/03(土) 17:18:00.03ID:eeu00PkY
>>283
Javaの仕様も忘れてしまったけど、
import zzz.aaa.*; // たまたま zzz.aaa.ccc というのが有ったとする。
import zzz.bbb.ccc;

↑のような場合に、ccc という名前が衝突するのかも。
0285デフォルトの名無しさん
垢版 |
2019/08/03(土) 17:23:56.42ID:L8lVlVkx
>>274
> 大部分のここの人達の主張は、直接
>
> std::vector, std::list, ・・・　を書くか、それが嫌なら、

これはよい
でも

> using std::vector;
> using std::list;
> ・・・
>
> を延々と書けというんですよね。

これを言ってる人いたっけ？
名前空間を明示するというポリシーに反してるからおれは使わないな
0286デフォルトの名無しさん
垢版 |
2019/08/03(土) 17:28:41.36ID:bjverAuH
自分のコントロール下にあるところで機能を使うなってのは自分が上手くつかえないだけの話だわな。
ブロック作ってブロック外と同じ名前の変数作ることすら禁止しそうな勢いだな。
ヘッダで使うなってのは自分のコントロール範囲外でバッティングが生じるからだ。
0287デフォルトの名無しさん
垢版 |
2019/08/03(土) 17:29:59.98ID:rAotfWJY
そもそも名前空間の柔軟性は、C++が最強だから。
文句言うのは筋違い。
0288デフォルトの名無しさん
垢版 |
2019/08/03(土) 17:34:07.35ID:eeu00PkY
そもそも標準のライブラリなので、namespace std の中に入れる必要なかった。
下手に入れてしまったからむしろ std:: を外したときに衝突する問題が
起きる可能性が出てきてしまった。
0289デフォルトの名無しさん
垢版 |
2019/08/03(土) 17:37:28.85ID:rAotfWJY
>>288
標準ライブラリとバッティングさせるようなバカはその場で処刑したほうが良いのでは。
標準ライブラリくらい暗記しとけよ。
0292デフォルトの名無しさん
垢版 |
2019/08/03(土) 17:47:44.86ID:rAotfWJY
>>291
殺せ。
0293デフォルトの名無しさん
垢版 |
2019/08/03(土) 17:48:34.32ID:rAotfWJY
>>290
あれは許せんな。
いや、許してはならない。
いつかレッドモンドに爆撃機を送り込むべき。
0294デフォルトの名無しさん
垢版 |
2019/08/03(土) 17:50:54.20ID:eeu00PkY
そういえば、min(), max() は C の時代、確かマクロ実装版が基本だったり
して複雑なことになっているのかな。よく知らないけど。
0296デフォルトの名無しさん
垢版 |
2019/08/03(土) 17:55:43.43ID:rAotfWJY
マイクロソフト最大のチョンボだよな。
0297デフォルトの名無しさん
垢版 |
2019/08/03(土) 17:59:48.03ID:3VuQ5ICx
関数は関数呼び出しが遅いから使うなマクロにしろ
処理は全部mainに入れろ

という恐ろしい時代から引きずってるから仕方ないといえば仕方ない
0298デフォルトの名無しさん
垢版 |
2019/08/03(土) 18:02:18.88ID:eeu00PkY
だったら STL の方が、std::max とかじゃなくて、
std::smax とかにすべきだったような気がしますが。
0299デフォルトの名無しさん
垢版 |
2019/08/03(土) 18:03:42.44ID:ulHqgYUF
NOMINMAXしたらしたでgdiplusでエラーになったので、仕方なくusing std::min;using std::max;を書いてしまった。
0300デフォルトの名無しさん
垢版 |
2019/08/03(土) 18:03:43.41ID:SSA79Euw
>>288
どんなusingがされている箇所でもstd::をつけさえすれば確実に標準ライブラリにアクセスできるんだから、記述の一貫性を保つのに役立つよ。
0301デフォルトの名無しさん
垢版 |
2019/08/03(土) 18:07:41.16ID:eeu00PkY
元々 min(), max() は非常に古い C時代から #define されているマクロですよね、

std::min(), std::max() と書いても結局マクロ展開されてしまうのでは
ないでしょうか？？？
0302デフォルトの名無しさん
垢版 |
2019/08/03(土) 18:08:18.92ID:rAotfWJY
>>298
でも実際に引っかかったら、何でこういうことする！マイクロソフト死ね！！っておまえも思うはず。
0303デフォルトの名無しさん
垢版 |
2019/08/03(土) 18:10:37.82ID:eeu00PkY
STL の方の min(), max() を使いたい場合は、
(min)(a,b)
(max)(a,b)
でいけるようです。C/C++ の前処理層によるマクロ展開は
マクロ関数名(
という並びが有る場合にのみ展開されますので。
0304デフォルトの名無しさん
垢版 |
2019/08/03(土) 18:14:26.75ID:eeu00PkY
>>302
いや、むしろ逆に、std::min の設計者の方がCの常識を知らない人だな、
と思ってしまいます。
そもそも、min(), max() マクロは、1980年代のC言語の時代から有るよく
知られたものなので、後から登場した C++ 標準ライブラリは、それが
有る場合にでも当然問題なく使えるようにしなくてはならなかったが、
そうなってません。それはどちらに原因があるかは明確です。
0305デフォルトの名無しさん
垢版 |
2019/08/03(土) 18:19:07.11ID:dTS2sKLx
>>301
左様

.cppのヘッダファイルをインクルードし終わった以降の適当な場所でおもむろに
#undef min
#undef max

インクルードしたヘッダファイルにマクロ版のmin()、max()に依存したマクロが存在せず、
かつマクロ版のmin()、max()を使わない限りにおいてこれでおk、
0306305
垢版 |
2019/08/03(土) 18:26:53.75ID:dTS2sKLx
適用条件訂正orz
正： マクロ版のmin()、max()を使わない限りにおいてこれでおk、

インクルードしたヘッダファイルに含まれるマクロ版のmin()、max()に依存するマクロ経由で
間接的にマクロ版のmin()、max()を使おうとした場合はコンパイルエラーになるからﾜｶﾙ
そうなった場合の処置は知らんが、コンパイルが通ったら>>305の方法で安全なはず
0307デフォルトの名無しさん
垢版 |
2019/08/03(土) 18:29:09.20ID:3VuQ5ICx
一番安全なのはこれだってboostの長年の結論だから
max BOOST_PREVENT_MACRO_SUBSTITUTION (a,b)
0308デフォルトの名無しさん
垢版 |
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()
が使えるでしょう。
0311◆QZaw55cn4c
垢版 |
2019/08/03(土) 19:39:31.49ID:NDKzILOT
>>267
ふつうに std::cout << "hello, world!" << std::endl;
と地の文として書いていますが、そういうのは駄目なのですか？
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況