C++相談室 part130 [無断転載禁止]©2ch.net

2017/03/31(金) 08:47:49.65

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

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

前スレ
C++相談室 part129
http://echo.2ch.net/test/read.cgi/tech/1483940967/

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

■長いソースを貼るときはここへ。■
　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

2017/05/19(金) 18:14:00.03

んだよ、Pascalでwith使っとけやトーシロー

2017/05/19(金) 18:16:16.14

ｄｅｆａｕｌｔって日本人は標準という意味で使っているけれど、本当は『不履行」とか否定的な意味の単語だよ
ｄｅ　ｆａｃｔｏと間違えて使っている

2017/05/19(金) 19:01:46.55

いい加減純粋仮想関数の = 0を見直すべき

2017/05/19(金) 19:09:38.92

>>335
標準なんて意味で使っている人間はいないと思われる
「既定の」とか「省略時の」だろう。

あと複数の意味のどれかが本来の意味であとは本来じゃないなんて了見が狭いね。

2017/05/19(金) 22:09:56.69

>>333
その手のって、extern "C"では採用してんじゃん
多相的クラスやインターフェイスを作ってるとき、
キーワードvirtualのタイプ数って無駄な苦しみだと思わない？
多相的クラスでデストラクタがvirtualとか自明じゃん

2017/05/19(金) 22:28:20.75

>>338
デストラクタがvirtualなのが自明なのは継承前提のクラスだけでしょ
ランタイムオーバーヘッドを可能な限りなくしたいC++でそんなこと前提にされてもって感じだけど
まぁ確かにclassのプリフィクスにabstractとかつけたら全部virtualになるとかはあってもいいかもね

2017/05/20(土) 03:08:45.60

ヘッダファイルに、すでに他のヘッダファイルで、宣言されているクラスが　
以下のように書かれているのは、なんのためなのでしょうか？

class CHoge_1; // すでに他のヘッダファイルで宣言済み
class CHogehoge; // すでに他のヘッダファイルで宣言済み
class CTestClass : public CMainClass //派生：基底
{
.......
.......
}

よろしくお願いします。

2017/05/20(土) 03:19:15.34

>>340
「前方宣言」でググれ

2017/05/20(土) 05:47:54.27

>>339
継承を使うからってデストラクタのvirtualが自明って？
んなわけねえだろ、たとえばprivate継承を使うようなケースでは
おまえの言うとおりオーバーヘッドを重視することがあるし
インターフェイスでだっていちいちデストラクタなんぞ作んねえ
しかし多相的クラスというからにはアップキャスト前提は間違いない
俺はそこを言ったんだよ

で、
class [[abstract]] oddsandsods; //これで全部virtualということか
うん、そういうのでもいい
キーワードがちょっと気になるかな
[[polymorphic]]かなって思う

2017/05/20(土) 10:19:27.00

>>341
ありがとございます。
りかいできました！

2017/05/20(土) 15:27:14.98

お前らクラス図書いてる？
テンプレートとか関数オブジェクトとか面倒くさ過ぎなんだけど

2017/05/20(土) 16:43:45.54

完全なドキュメントよりも、動くソフトウェア
の理念の元書いておりません

2017/05/20(土) 17:47:18.38

書いたことあるけど、泣けてくるぞ
わざわざ人間がやる必要性が全く感じられないから

2017/05/20(土) 19:02:29.38

クラス図は書かないけど
コード書く前にこれとこれを用意してこれとあれがこうなってこうみたいな下書きをノートに適当に書いてる

2017/05/20(土) 19:31:29.85

ああ、それならやるね
結局、ずいぶん違ったものが出来てくるけどｗ

2017/05/20(土) 19:31:49.65

うん、正直にそれは恥だ

2017/05/20(土) 23:17:42.25

まあ、そんなもんだよなあ
考えの整理するのに書くのは良いんだけど、実装に追従しろとか実装の前に書けとか言われると怠くて敵わんわ

2017/05/21(日) 08:19:58.20

チームでやるならクラス図かいとかないとカオスにならない？

2017/05/21(日) 08:27:25.16

実装前に書いたメンテされないクラス図なんて役に立つわけねーやろ
自分の設計用に下書きだけして、あとはDoxygenに任せればよろしい

2017/05/21(日) 11:02:09.47

目的と使い方と意図がちゃんと書かれたコメントのほうが重要

2017/05/21(日) 11:42:21.53

astah UMLを使えば
　(クラス図<-->シーケンス図)→コード(自動生成)
というのがだいたいシームレスにできる

ずいぶん違ったものが出来てくるのは慣れの問題かと、
（UML自体かなり計算機の仕組み寄りで、それほど直感的な表現方法とは言えない）

2017/05/21(日) 11:43:44.12

コードに書かれていることが何よりも真実というのは同意

2017/05/21(日) 12:59:09.81

>>353
これな

2017/05/21(日) 13:00:19.74

ただ、コメントすらメンテされなくなるのが辛いよ…

2017/05/21(日) 13:37:07.31

コメントのバグは検出不能なのが厄介

2017/05/21(日) 13:58:18.34

自分は書いてるよ。
大枠だけ書いて細かなクラスは表現しない(したくない)から、むしろツールは使わずに手書きで書いてる。

2017/05/21(日) 14:15:03.88

この手の議論で特徴的なのが書かない派の殆どは
自分が書けなかった理由を書かなくて良い理由にすり替えていること

2017/05/21(日) 17:51:48.31

「ほとんど」でうまく逃げてるな

2017/05/21(日) 19:37:38.96

設計書に書いたことをまたコードに書いたら
メンテの手間が増えるじゃないか

2017/05/21(日) 23:17:17.16

コードの他に何か残すなら、単体テスト（コード）とか試験仕様書とかを書けば良い
単体テスト（コード）や試験仕様書なら、少なくとも書いた範囲についてコードとの不一致は有り得ないのだから

2017/05/23(火) 07:38:45.51

enumの中身を漏れなくする方法はないの？

2017/05/23(火) 07:54:11.86

>>364
?

2017/05/23(火) 08:12:47.34

>>364
ほれ
namespace himitsu {
enum more {aaa};
}
using more = himitsu::more;

auto e = more::aaa;

2017/05/23(火) 09:32:50.64

今ならenum classやろ
enum class more{aaa};

2017/05/23(火) 22:40:27.44

>enumの中身を漏れなく(イテレート)する方法はないの？

2017/05/24(水) 07:25:20.05

>>368
ちょっとはググれカス
https://zenmai.wordpress.com/2009/11/11/enum%E3%81%AE%E3%82%A2%E3%82%A4%E3%83%86%E3%83%A0%E3%82%92foreach%E3%81%A7%E4%BD%BF%E3%81%86%E3%80%8Cc/

c# foreach まで入力したら enum が補完されるぐらいだからそう言うことをやりたい奴は多いのかも

2017/05/24(水) 08:14:20.55

安定のﾄﾞｺｸﾞﾛMM

2017/05/24(水) 14:16:08.43

Cの時代からenumは未だに慣れない

2017/05/24(水) 22:12:49.22

むしろCでintや#defineだらけのenumを使わないコードがずっと疑問だった

2017/05/24(水) 22:17:53.05

enumに文字列定義でけんの？

2017/05/24(水) 22:57:19.03

>>369
何故C#？

2017/05/25(木) 05:00:36.62

>>374
すまん寝ぼけてた
C++ は無理そうだな
Range-based for で何とかしてくれると嬉しいんだけどね

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sdbf-eUT2) · 2017/05/26(金) 20:36:20.09

言語ではenumの列挙はサポートされてないから、そのまま必要なデータを手書きで記述するか、
プリプロセッサマクロと#includeで汚く書くしかないね。

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sdbf-eUT2) · 2017/05/26(金) 20:41:12.76

DEFINE_HAGE(baka)
DEFINE_HAGE(boke)
...
こういった内容のテキストファイルを用意し、別のソースでマクロDEFINE_HAGEをテキトーに定義して#includeで
読み込むという素人お断りのテクニックがある。

2017/05/26(金) 23:46:38.90

http://i.imgur.com/VFje2sYh.jpg

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sdbf-eUT2) · 2017/05/27(土) 01:04:47.55

生き残ってますか、人間ども？

2017/05/27(土) 02:22:34.43

キミも相変わらずだねｗ

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sdbf-eUT2) · 2017/05/27(土) 02:29:51.07

前日はrosのfreetypeを2.8に更新するパッチを作って人ひとり助けた。

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sdbf-eUT2) · 2017/05/27(土) 02:32:13.02

１日に百人助けられる頃には大金持ちになっているだろう。

2017/05/27(土) 02:53:52.81

百日に一人助けて大金持ちになるような仕事をしなければだめだよ

2017/05/27(土) 17:46:08.41

>>376
enumの列挙って何？

baka,
boke,
じゃあかんの？

2017/05/27(土) 18:09:13.93

for ( auto i : enum_class )

2017/05/27(土) 20:21:56.11

マクロで定義と同時に配列に詰め込めばいいんじゃないか

2017/05/27(土) 23:42:50.86

enum定数はenum定数やし、
C#のIEnumerator的なﾌﾞﾂはC++でも書けるし

ここでのenum定数の列挙ができるかできないかというのは
糖衣構文によるサポートの有無の違いでしかないと言える、
希ガス、

2017/05/28(日) 08:54:39.55

最近Python使い始めたけどすげー書きやすいわこれ
感動を覚えるレベル
やはりC++は糞

2017/05/28(日) 10:29:47.18

>>387
> C#のIEnumerator的なﾌﾞﾂはC++でも書けるし
書いてみてよ

2017/05/28(日) 11:07:21.67

enumの要素数とか最大値最小値って取れる？

2017/05/28(日) 12:05:13.52

>>389
なんか期待値が高まり杉な気がするが、
IEnumeratorについてはReset()とMoveNext()とCurrent()を宣言して、派生クラスで実装するだけにょ？
列挙するデータは派生クラス（具象クラス）側に>>386式の配列データを受け取るようなコンストラクターでも設ければ良いし、

もしC#のEnum.GetValues()とかEnum.GetNames()みたいなやつが欲しくなってもstd::mapとか使えば動くものがｷﾞﾘ作れるだろJK

なお上記のようなやり方がC#と比べようが無いぐらい面倒臭いという批判は
>糖衣構文によるサポートの有無の違いでしかないと言える、(>>387)
で予防炭、

2017/05/28(日) 12:09:37.75

>>377
Eigenみたいな？

2017/05/28(日) 12:30:50.04

>>391
> IEnumeratorについてはReset()とMoveNext()とCurrent()を宣言して、派生クラスで実装するだけにょ？
糖衣構文に期待しすぎ w

2017/05/28(日) 13:42:05.12

糖衣構文様に対して「違いでしかない」とか頭が高いぞ

**デフォルトの名無しさん** (JP 0Hbf-ozZu) · 2017/05/28(日) 13:43:10.88

>>390
俺はいつも
enum class Hoge {
　　None = 0,
　　Fuga,
　　Foo,
　　Woo,
　　Size
}
ってしてる

**デフォルトの名無しさん** (JP 0H49-zUMb) · 2017/06/01(木) 02:15:55.12

すみません、どなたか教えてください
独自のイテレータを実装するにはどうしたらいいのでしょうか？
ググってみたら、c++17でstd::iteratorがdeprecateになったらしいのですが、
独自のイテレータを作るときにstd::iteratorを継承するのはbad practiceってことになるのでしょうか？

2017/06/01(木) 06:36:46.84

>>396
boost::iterator_adoptor

2017/06/01(木) 06:54:03.34

>>396
ググってるならこの手のページもヒットすると思うが...

http://faithandbrave.hateblo.jp/entry/2016/09/12/145923
標準ライブラリの範囲では、イテレータは最初から最後まで自分で定義することになります。

2017/06/01(木) 08:18:50.46

イテレータの要件さえ満たしておけば実装はなんでもいいのでは

2017/06/01(木) 08:23:03.98

>標準ライブラリの範囲では、イテレータは最初から最後まで自分で定義することになります
高橋昌は規格のドラフトも読まないほどモウロクしたのだろうか？

2017/06/01(木) 10:32:18.97

昌？お前も相当モウロクしてるぞ

2017/06/01(木) 11:36:05.93

ワロタw

2017/06/01(木) 12:37:41.54

そういえば「日」が三つだった気がしてきた
俺もモウロクしたようだ

2017/06/01(木) 12:42:26.29

結局何が正解なんだよ

2017/06/01(木) 12:45:46.15

>>369に対してはN4659のAnnex D(D13.1)が正解
C++20で使えなくなる可能性があることを理解した上で使えということ

**デフォルトの名無しさん** (JP 0H49-zUMb) · 2017/06/01(木) 14:18:15.64

>>398
えっと、何て言えばいいのかな？
最初から最後まで自分で定義するとして、std::iteratorをそっくりそのまま書き写したmy_iteratorみたいなのを継承する、
あるいは、それと同等な方法でイテレータを定義するのは問題ないのかな、と思って質問しました。
自分で定義したとしても、std::iteratorに付随するもの、たとえばiterator_categoryやvalue_typeを使えば、
それは廃止されるstd::iteratorを使ってるのと大差ないですよね？　そういうのはいいのかな？と思って

2017/06/01(木) 15:08:52.32

>>406
はい問題ないです
むしろstd::iteratorはイテレータを自作するためのただのヘルパーであって、
要求される型や関数を持っていればイテレータを作るために特定のクラスを継承しなきゃいけないとかはないです

2017/06/09(金) 13:26:36.03

int hoge={1,2,3,};
配列末尾のカンマは許されてますか？

2017/06/09(金) 18:17:06.50

paiza.IO, codepad などに、ブラウザで書き込んで、確かめれば？

2017/06/09(金) 18:38:38.05

確かめてもその環境では出来ると言う事しかわからないので

2017/06/09(金) 18:41:26.39

コンパイラの実装が全てにおいて正しい

2017/06/09(金) 19:06:37.15

自分が持ってる本では配列末尾に全てカンマがありますよ

許されてるはず！

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd43-QXxp) · 2017/06/09(金) 19:49:56.35

>>408
https://cpprefjp.github.io/lang/cpp11/trailing_comma_following_enumerator_list.html

2017/06/09(金) 19:51:04.81

最後に余計なカンマが付いているのだから、普通はコンパイルエラーになるはずだろ

それがエラーにならないのなら、その構文は正しい

2017/06/09(金) 20:01:26.03

enumができるのはとっくに知ってます

>>414
その環境でエラーにならない事がわかるだけなので意味ないです

2017/06/09(金) 20:23:58.14

>>408
時代による
大昔はダメ

2017/06/09(金) 20:40:16.86

>>415
規格の8.5p1を読むか、
C++14の前後のN3797(8.5p1)とN4659(11.6p1)の内容から規格を推察するしかない

2017/06/09(金) 21:34:47.00

そういえば>>408のコードにはどこにも配列が登場しないな
一行目はフェイクなのだろうか

2017/06/09(金) 23:23:34.86

>>408
n4659によるとあり

2017/06/10(土) 09:38:34.51

で、結局hogeに何が格納されるの？

2017/06/10(土) 12:33:50.86

>>414
正しい構文はエラーにならない
けど
エラーにならないからと言って正しい構文とは限らん

2017/06/10(土) 13:30:36.94

規格的にはどうなのか調べる気にもならないけど
Cでも80年台の終わりくらいには俺の知ってる全てのコンパイラで最後のカンマ許されるようになってたと思う
今C/C++でエラーにするコンパイラなんてあるのかね？
もしあるならそんなコンパイラは色々ヤバいから使わないほうがいい

2017/06/10(土) 13:43:34.09

だから規格的にもありだって

2017/06/10(土) 13:44:18.36

列挙部分をスクリプトか何かで生成する時に、
ちょっと楽ちんだなと思った事はある

2017/06/10(土) 13:50:38.86

カニハン第二版にも、要素末尾後ろのカンマは合法て書いてあったような。
まさにスクリプティング時の便宜を図るため。

ただ、C89とかだとenumだけは許されてなかった気が。

2017/06/10(土) 18:16:29.78

「規定クラス」とかいかにも公式に定義されてるっぽい言葉を使いながら
抽象化だよわかるだろ、とか
省略だよわかるだろ、とか

2017/06/10(土) 19:06:50.38

規格と簡単に言うけど、日本の産業界には言語規格を知っている人が、そもそもいない。
MISRA-C の日本の委員会の人でも、規格は知らないから、
欧州に問い合わせながら、本を書いたらしい

日本の産業界から、そうそうたるメンバーを集めても、規格は謎だらけ

日本では規格に詳しいのは、C++ 標準化委員会の、
ドワンゴ江添亮、επιστημη（エピステーメー）ぐらいだろ

2017/06/10(土) 19:17:08.33

>>426
誤爆ってるぞ...
どこの誤爆かもわかるけど w

2017/06/10(土) 19:36:14.26

>>427
エピスは全然詳しくないだろ…

2017/06/10(土) 19:46:32.90

>>427
ドラフトがネットでタダで手に入るんだから誰でも詳しくなれるだろ
金払えば規格も買えるんだし
標準化委員会にいないと詳しいとは言えないのか？

2017/06/10(土) 20:03:52.30

規格は、JISなどが翻訳しただけで、翻訳者には意味は分からない。
規格から、その条文に合った例題を、誰も作れない

だから、MISRA-C の日本委員会では、その条文を説明するための、
例題を作っては、欧州に問い合わせて、間違いが無いかどうかを確かめている

文章一つでも、解釈の仕方が一杯あるから、例題が無いと説明できない

法律の民法などと同じ。
TAC、伊藤塾など各社が、法律を解釈する受験本を、たくさん出しているだろ。
最高裁の判決を載せて、条文がどう解釈されたか、書いているのと同じ

規格だけがあって、それを読んでも、どうにもならない。
MISRA-C みたいに産業界から、数十人が集まって議論しても、条文の意図が分からない

2017/06/10(土) 20:32:33.27

>>431
意図がわからない条文ってどれ？
ちょっと具体的にあげてみようか

2017/06/10(土) 20:40:48.55

mainの戻りのvoidが規格違反かどうかについて「otherwise」という表現の解釈で議論が始まってしまうレベルのウンコ文書
もとの英文が宜しくない