C++相談室 part137

2018/08/27(月) 16:02:00.94

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

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

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

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.103【環境依存OK】
https://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/08/27(月) 23:57:35.85

一般関数のmainとメンバ関数Cmain::main()は別物だろうよ。

2018/08/28(火) 00:05:18.35

>>20
名前空間が違っていて区別がつくから同じ名前のものがあっても大丈夫。

2018/08/28(火) 00:18:40.52

>>21,22
なるほど、それもそうですね

2018/08/28(火) 07:30:50.31

>>13 >>14
ありがとうございました。やっぱ両方なんですね

>>18
メモリープール初めて知りましたがこんな方法あるんですね
あと上司がおよそ20年に渡って継ぎ足し継ぎ足ししてきたすぱｇ秘伝のコードなので今更構造変えられんのです……

2018/08/28(火) 07:39:23.68

スマポつかえよ！

2018/08/28(火) 07:44:24.16

上司のコードに文句言いつつデリートも知らん奴がなんか言っとる

2018/08/28(火) 07:49:16.32

勇んでデリートするようなコード書きたいか？

2018/08/28(火) 08:58:31.81

>>24
リファクタリングの機会を設けないと秘伝が負債になるのがこの業界

2018/08/28(火) 08:59:48.56

auto pointer, smart pointer ?

2018/08/28(火) 10:05:03.87

rip.auto_ptr.

2018/08/28(火) 15:32:29.83

>>19
1:1のソケットを4つ用意すれば4人でチャットできますよね？送ったメッセージをサーバーサイドが受け取って他の3人のソケットに送るイメージです

2018/08/28(火) 15:45:07.84

あー、それなら合ってるね
そのままのイメージで書いてみればいける

2018/08/28(火) 19:28:50.38

>>32
それぞれのソケットの中身で違うのはポートだけってことで大丈夫ですかね？

2018/08/28(火) 19:45:32.21

まぁポートだけ、というかリスニングの処理だけ特殊とは言えるかも

2018/08/28(火) 20:36:55.08

このスレって競プロerいる？

2018/08/28(火) 23:15:21.08

>>35
いる

2018/08/29(水) 00:22:05.79

関数からreturnされる値は必ず自動的にmoveされる？

2018/08/29(水) 00:25:41.59

コンパイラと設定によると思う

2018/08/29(水) 00:26:07.98

計算機S　192.168.0.1:40000　⇔　計算機A　192.168.0.16:41769
計算機S　192.168.0.1:40000　⇔　計算機B　192.168.0.17:61544
計算機S　192.168.0.1:40000　⇔　計算機C　192.168.0.18:61568
計算機S　192.168.0.1:40000　⇔　計算機D　192.168.0.19:63490
　　　　　　　　　　　↑　　　　　　　　　　　　　　　　　　　　　　↑最初に接続する計算機のﾎﾟｰﾄは通常自動的に空き番が使われるようにする
計算機Sからみてpeerは
計算機Sが受付を待っているﾎﾟｰﾄに
接続する必要がある

2018/08/29(水) 01:16:31.78

え、TCPいうてたしサーバーのIPとポート指定して接続してつなぎっぱなしを想定してたんだけど違うのか
いちいち切って繋ぎ直すなら別だけど

2018/08/29(水) 01:39:42.75

受付嬢は一人、ご相談は各担当に回す
みたいな

2018/08/29(水) 01:56:45.22

>>37
値が rvalue でムーブコンストラクタが存在するならばムーブされる。
(lvalue も状況によっては rvalue になることもある。)
ただし、 RVO の適用条件に叶う場合は RVO が適用されるかもしれないのでコピーもムーブもされないことは有りうる。

2018/08/29(水) 13:02:14.24

Hogeというクラスがあったとして、
Hoge getHoge();
という関数があるときに、
Hoge &hoge = getHoge();
と参照で受けて問題ない？

2018/08/29(水) 13:31:26.82

ダメ
getHoge()の返却値はprvalueなので
constのない左辺値参照で受けることはできない

右辺値参照か、
constのついた左辺値参照が必要

2018/08/29(水) 15:21:15.25

>>43
getHoge() の返却値は一時的なオブジェクトなので
原則としては完全式の終わりに解体されることに
なっているが、 >>44 の述べる通りの方法で参照で受けたときに限って
例外的に寿命が延長される規則がある。
参照のスコープの終わりがオブジェクトの寿命になる。

RVO が発動するだろうから、そもそも参照で受ける意味があんまり無いと思う。

2018/08/30(木) 00:25:01.05

書籍スレで聞いたらスレチ（？）と言われたので質問させて下さい(m´・ω・｀)m
C++で新し目（出来れば2016年以降に発売したもの）の入門書でオススメがあれば教えていただきたいのですが…
よろしくお願い致します。

2018/08/30(木) 01:05:42.98

ありません( ｰ`дｰ´)ｷﾘｯ

2018/08/30(木) 02:11:48.32

Effective Modern C++は読んどいたほうがいいけど入門書じゃねえな
うーん

2018/08/30(木) 02:18:12.89

>>43
全く問題ない。
規格にもしっかり書いてある。

2018/08/30(木) 05:39:20.37

>>49
どこに？

2018/08/30(木) 07:30:44.91

>>46
あるわけいだろ
C++は入門言語じゃない

2018/08/30(木) 07:40:22.80

>>46
このへん

ISBN-10: 4797394633
日本人の著者では柴田氏の作風が俺的にはお奨め
入門だからって抜いちゃいかんことを押さえてる

ISBN-10: 4798119598
C++といえばこの人
出版が2011年とやや古めだが
プログラミングの地頭を鍛えてくれる

2018/08/30(木) 08:03:54.88

そもそも、何も知らない初心者がなんで「2016年以降」とか限定するんだ？
何か根拠があるわけでもないだろう。

2018/08/30(木) 08:35:46.61

古い本だと古い規格で説明されてるから、初心者には良くないって点はあるね。
#include <cstdio.h> みたいな中途半端な古さは特にやっかい。

『プログラミング言語C++』第4版を読んどきゃええじゃろ、と思ったけど
初版が2015年3月だから「古い本」だな。

2018/08/30(木) 09:34:44.57

2016年に何かあったの？

2018/08/30(木) 10:11:29.31

> #include <cstdio.h>

こんな時代あったか？

2018/08/30(木) 10:17:39.13

ときどきＣがわかってない日本人が入門書書いてたりして余計路頭に迷わせたりする

2018/08/30(木) 10:25:15.01

>>48
effective 「modern」 c++ って良いの？
ただの effective は良いってほぼ全員認めてるが、more とか modern はあまり勧められないしどうでも良い本なのかと思ってた

2018/08/30(木) 10:56:25.83

math.hとcmathってどっちがいいの？
そもそもcmathインクルードしてもM_PI使えんしよく分からない

2018/08/30(木) 10:58:18.11

>>58
effectiveならいいっていう老害なんだろ

2018/08/30(木) 11:01:43.96

>>52
柴田の本は辞めとけ
初心者には無理
あれは大学の講義でかわされるやつ

2018/08/30(木) 11:49:16.45

>>61
初心者つーかオマエだろ？
大学の授業についていけない二回転５

難癖ばっかりつけてないで
幼児用のC++の本を出してみな

2018/08/30(木) 12:34:40.85

>>59
cmath を使うべき。
C のヘッダは互換性のために残されているだけで、積極的に使うようなものではない。

M_PI は C の規格にも C++ の規格にもないマイクロソフト独自の拡張だから、
マイクロソフトがどういう気持ちで用意しているのかは知らないけど、
_USE_MATH_DEFINES マクロを #define しておけば Visual Studio では有効になるらしいぞ。

https://msdn.microsoft.com/ja-jp/library/4hwaceh6.aspx

2018/08/30(木) 12:46:26.01

C++17でcmathが大幅強化されたね
ISO/IEC29124の特殊関数を取り入れた

2018/08/30(木) 12:52:55.39

>>58
modernはC++11以降を使うなら必読だぞ
むしろ素effectiveやmoreの方が古くてあんまり役に立たなくなってる

2018/08/30(木) 13:14:44.70

>>63
gccの独自拡張じゃねえの
むしろMSはそれに合わせてる

長いものには巻かれろ、ってヤツだ
長い方はMSじゃなくgcc

2018/08/30(木) 13:37:08.32

柴田の本は昔から悪書扱いされてる
あえて読むことはないと思うわ

2018/08/30(木) 13:37:55.22

だから読んでないわけか

2018/08/30(木) 13:58:51.87

昔は読んでたよ
20年以上前かな
いまでもjavaやc++のやつは図書館でたまにペラペラしてみるけど
読みづらくて全然合わないと感じる

同じジャンルで山田祥寛の本があったらそっちを読む

2018/08/30(木) 14:09:38.78

つまり読んでないってことだろ

図書館でペラペラってなぜそんなことをするんだ
C++を20年以上やってるんだろ

2018/08/30(木) 14:38:25.23

人にC++言語について教える時に、人口に膾炙した書籍の表現を使うのが無難だからでしょ。

54 (ﾜｯﾁｮｲ 9593-kT/R) · 2018/08/30(木) 15:34:47.96

>>56 すまん <cstdio.h> は変ね。<stdio.h> と <cstdio> が混ざってしまった。
<cstdio.h> というヘッダが存在する処理系もあるか知れんけど、
#include で使えと教えてる本はないだろうな。

主旨は「半端に古い本だと」で変わらないけど、良い例が出せんわ。

2018/08/30(木) 15:49:06.15

>>72
それを言うなら
<stream.h> //cfront 1.0
<iostream.h> //ARM
<iostream> //C++98
じゃね？

2018/08/30(木) 16:04:11.38

質問なんだがコンパイル時間の観点から見て、ヘッダをインクルードするときは必要でない限りcppファイルでincludeするべき？

2018/08/30(木) 16:13:39.13

#includeのネストを避けろということか？
そう主張する連中もいるが、俺は反対

2018/08/30(木) 16:18:52.75

>>74
ちょっと質問の意図がよくわかんないんだけど、逆に言えば
「ヘッダファイル (*.h) が他のヘッダファイルを include するのはコンパイル時間を増大させるか？」という意味？

あんまり関係ないよ。
よっぽど大きいプロジェクト (gcc とか) ならちょっとしたことで結構な差が出ることは無いとは言えないけど、
それでもプリコンパイルヘッダとかを活用すればだいぶん時間は短縮できるし、
更に高速化したいならキャッシュサーバを使うコンパイラもある。

https://github.com/yrnkrn/zapcc

・小さいプロジェクトでは気になるほどの差はない
・大きいプロジェクトではツールで解決しよう

2018/08/30(木) 16:23:45.00

コンパイラは可能な限り高性能なマシンで使うべし

2018/08/30(木) 16:52:55.72

例えばstd::stringをhoge.hでは使わずhoge.cppのみで使われている場合
hoge.hで#include<string>と書くと、他のファイルからhoge.hをincludeしたとき無駄が出るはず
だからhoge.cppで#include<string>と書いた方がいいのが、それとも些細な差なので全部hoge.hにぶち込んでもいいのかということ

2018/08/30(木) 16:55:06.24

なるほど、実装で使うだけで宣言にはいらないものか
だったらhoge.cppで#includeしたほうがいいね

2018/08/30(木) 17:19:10.16

http://www.geekpage.jp/programming/linux-network/select.php

なんかソケットごとに違うポートを割り振るものだと思ってたのですが、

listen(srcSocket, 1);//第二引数はクライアント上限数

この第2因数をいじったら同じポートでも普通に接続できました。
このまま気にせずselect処理書いていっても大丈夫ですかね...？
通信関係あまり知らないのでバグったりするとどうなるか分からずちょっと怖いです。

相手用のソケットは
int dstsocket[5]の様な感じで作って中身は全部一緒です

2018/08/30(木) 17:49:39.07

>>78
その場合だと .cpp に書いた方が当然良い。

2018/08/30(木) 18:56:44.69

プリコンパイル済みヘッダを、いちいち書かなきゃいけなくなるのがあれだから使わない方がいいと言われたことがある
なぜそれでコンパイルが遅いって文句言ってるのか分からない・・・

2018/08/30(木) 21:34:38.22

https://ezoeryou.github.io/cpp17book/
辞書にするならこれ。役に立ったら書籍版買ってあげよう。

2018/08/30(木) 22:17:19.27

書いても大丈夫だが、そういうやりかたにするならselectでﾌﾞﾛｯｸしないように注意したほうがいい
selectをﾌﾞﾛｯｸしたままの状態にすると、当然、そのあと永遠にacceptされない
きっとｽﾚｯﾄﾞにしたほうが簡単

2018/08/30(木) 23:08:40.56

>>78
hoge.hでstd::stringを使ってないのに#include<string>を書く、という発想が理解できない
#include<string>はstd::stringを使ってるところに書く、使ってないところには書かない、でいいじゃん

変更があって使わなくなったのに#includeは残ってるのがありがちで嫌なところ
静的解析とかで指摘して欲しい

2018/08/30(木) 23:48:27.87

>>80 ひきすう

2018/08/31(金) 14:08:47.35

>>80
変な心配せずに書いて覚えた方が早いよ
あと最初TCPって言ってたよね？
もしTCPで通信ごとにポート変えなきゃいけないなら、Yahoo見に行く時毎回ポート変えてんの？
HTTPは80番って決まってるやろ？
あと何のためにその第二引数があるの？

2018/08/31(金) 19:45:34.91

恥ずかしながら char と signed char が違うものだって知りませんでした…（独り言）

2018/08/31(金) 19:48:20.37

処理系による

◆QZaw55cn4c (ﾜｯﾁｮｲ 6360-zBrR) · 2018/08/31(金) 19:53:07.91

>>88
signed char とか unsigned char とか明言されず、ただ char としか書いていない場合、
その char が signed char になるのか、それとも unsigned char なのかは
「処理系依存」・コンパイラ依存だった、という経緯が C の時代からあったのでした

「signed char でも unsigned char でもない『「alternative な char』がある」
という意味ではないのです
"alternative char"…なんかだ魅惑される響きだと感じ入ってしまうのは、私だけですか…

2018/08/31(金) 20:24:19.94

>>90
char は signed char でも unsigned char でもないです。
C でも C++ でも。

2018/08/31(金) 20:30:14.89

？
charとsigned charとunsigned charは全部別の型だろ。

2018/08/31(金) 20:39:51.15

char は (型システム的には) signed char でも unsigned char でもないけど、
符号付きか符号なしのどちらかではあり、
その表現は処理系によって signed char か unsigned char のどちらかと実質的に等しいことになってる。

だいたいは暗黙の型変換が自然にうまいことやってくれるんだけど、
C++ だとオーバーロードの解決にかかわるところとかややこしいな。

2018/08/31(金) 20:40:27.43

std::byteとかいうゴミはどう使えばいいんだ？

2018/08/31(金) 20:41:47.58

>>89-90
そういう話じゃなくて文字列型にはchar, unsigned char, signed charの3つがあるって話じゃないの？

2018/08/31(金) 20:50:33.26

>>94
数値計算のための演算子が定義されてないのが重要なポイントだな。
なんらかの入力をビットパターンとして処理したいときに使える。

ビット表現に関する C/C++ での規則は未定義の部分もあって、
数値とビット表現の対応付けは処理系 (アーキテクチャ) によるので、
数値としての演算の結果 (の数字をビットパターンとして見た場合) は一意ではない。
std::byte でデータを保持しておけばうっかり数値計算してしまったりしない。

std::byte があることで特にできるようになることがあるわけじゃないけど、
うっかりを防止するために防衛的に使うもんだと思う。

◆QZaw55cn4c (ﾜｯﾁｮｲ 6360-3+v7) · 2018/08/31(金) 20:57:38.41

>>91
https://ideone.com/5zhQcP
…なるほど、そういう風に解釈するんですか！？
また一つ賢くなりました

2018/08/31(金) 21:21:37.54

>>97
もうひとつ面白い点としては、そこから void f(char c) の定義を消すと
char c = -12; f(c); という呼出しは解決できずエラーになる。

char, unsigned char, signed char は「順位」が同じなので、
呼出し候補としては同格になってしまい、ひとつに絞れないから。

もしも char が unsigned char か signed char かのどちらかなら、
どちらが呼び出されるにしてもひとつには絞れるのでこういう問題にはならないのだけれど。

ストリームに対する operator<< が char と unsigned char と signed char のそれぞれに用意されているのは、
そういう曖昧さが起こらないようにするため。

2018/08/31(金) 22:36:19.33

>>95
文字列型はchar
signed char, unsigned charは小さい数を格納する

2018/08/31(金) 23:16:56.24

「文字列型」という言葉を使うと語弊がある気がするぞ。

2018/08/31(金) 23:21:39.46

現在時刻(またはPCやexe起動からの経過時間)をmillisecondsで取得する方法ってありますか？
mm-dd-yyみたいな形式ではなくて全部数字で取得したいです

2018/08/31(金) 23:24:08.56

exeだからwindows
つまりGetTickCount()

◆QZaw55cn4c (ﾜｯﾁｮｲ 6360-3+v7) · 2018/08/31(金) 23:59:05.22

>>101
https://ideone.com/H6bajN

2018/09/01(土) 00:01:43.12

なんでCの頃にcharを符号付きを許したのかが謎
文字は負の値にならないとかいうルールまで定めながら
charをunsignedと定義することを頑なに拒んだ古代の連中は一体何を守ろうとしたのか

2018/09/01(土) 00:06:54.80

charのsignedとunsignedの処理系依存の混乱さえなければ今でもmalloc()はchar*（サイズ1の型のポインタ）を返してくれて便利だったかもしれんのに、

2018/09/01(土) 00:09:21.94

asciiは7bit

いまでもC++はどんなｵﾌﾞｼﾞｪｸﾄでも(char*)でｷｬｽﾄすることは
仕様で許されてる

2018/09/01(土) 00:09:26.78

>>99
そうであればよかったんだけどstreamsでの扱いは全部文字型なんだよな。
おかげでuint8_tをstreamに出力したら文字が出てくる羽目に。

2018/09/01(土) 00:15:47.63

>>106
Ｅ　Ｂ　Ｃ　Ｄ　Ｉ　Ｃ　は　８　b 　i　 t 　じ　ゃ　わ　！

>>106
キ　　ャ　　ス　　ト　　し　　た　　だ　　け　　で　　は　　c h a r *　　か　　な　　に　　か　　の　　中　　間　　変　　数　　に　　代　　入　　せ　　ね　　ば　　
標　　準　　の　　言　　語　　規　　格　　で　　は　　+ +　　や　　- -　　が　　で　　き　　ん

2018/09/01(土) 00:21:54.31

ｽﾏﾝ訂正；
誤：キ　　ャ　　ス　　ト　　し　　た　　だ　　け　　で　　は　　c h a r *　　か　　な　　に　　か　　の　　中　　間　　変　　数　　に　　代　　入　　せ　　ね　　ば　　
正： v o i d * 引　　数　　は　　キ　　ャ　　ス　　ト　　し　　た　　だ　　け　　で　　は　　c h a r *　　か　　な　　に　　か　　の　　中　　間　　変　　数　　に　　代　　入　　せ　　ね　　ば　　

2018/09/01(土) 00:24:45.17

知見が狭い低学歴知恵遅れの世界では
伝統的なﾃｷｽﾄがacsiiをさしてることすら
わかってないらしいわ

普通に古代のﾈｯﾄﾜｰｸで7bitのﾈｯﾄﾜｰｸとかあったからな

char*の変数に代入しないと
ﾎﾟｲﾝﾀｰをｲﾝｸﾘﾒﾝﾄできないとかあたりまえやんけ
C++とか関係ない

相変わらず低学歴知恵遅れはなにをいってるのか意味不明

2018/09/01(土) 00:28:15.78

昔、なんでﾒｰﾙがiso-2022-jpしかかたくなにﾀﾞﾒといわれてたか
きっとその理由も分かってない

2018/09/01(土) 00:36:37.58

>>110
えっっつ！？
伝統的なテキストの7 bitの文字コードはISO 646のことじゃないの；

ていうかASCIIが7 bitで表現できることはなんでCの頃にcharを符号付きを許したのか（>>104）を完全には説明しない
charをunsguned charにキめとけばアドレス全般を現す型としてのvoid*なんてものを別途作り出す必要も無く全員ニッコニコー☆だったかもしれんのに…

2018/09/01(土) 00:37:24.15

>>106
「どんなｵﾌﾞｼﾞｪｸﾄﾎﾟｲﾝﾀｰでも」の間違い？

2018/09/01(土) 00:42:50.43

MSBに1がたってるｵｸﾃｯﾄが1つでも入ってたら
それはﾊﾞｲﾅﾘだ

ｵﾌﾞｼﾞｪｸﾄを(char*)を普通にｷｬｽﾄできる
低学歴知恵遅れのどうでもいい感想やどうでもいい願望なんか関係ない
そういう仕様だからな

安全なPODは普通にｷｬｽﾄされることがある

2018/09/01(土) 00:44:26.13

ｵﾌﾞｼﾞｪｸﾄﾎﾟｲﾝﾀｰなのは
あたりまえ

2018/09/01(土) 01:14:05.21

7ビットでも8ビットでも表現できる言語の数は変わらないから

2018/09/01(土) 06:51:29.42

acsiiってなあに？低学歴知恵遅れさん

2018/09/01(土) 07:13:19.96

>>117
涙拭けよ老眼

2018/09/01(土) 07:40:58.94

>>110

2018/09/01(土) 07:48:51.59

情報系大学3年生
恥ずかしいことに今までやっていた言語がC++じゃなくてCだったことを知った…
（だってVisualStudio起動するときにC++開発モードを選ぶように言われたんだもの）
そういうわけでC++はどんなもんかなと本屋でちらっと明解C++を手に取ってみたら全く別物じゃねえか…
わかんねえよ……ネットで調べてみたら複雑らしいし
Cならatcoderで緑色になるくらいは書けるけど、でも就活のときCしか書けませんC++わかりませんってかなり致命的？