C++相談室 part133

2017/11/24(金) 16:52:50.43

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

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

前スレ
C++相談室 part132
http://mevius.5ch.net/test/read.cgi/tech/1507561894/

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

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

VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

2017/12/30(土) 07:52:44.61

class A {
//...
};
class B : public A {
};

A *a = new B();
delete a; // だめ
B *b = new B();
delete b; // だめ

というようにA, Bのdeleteを禁止することはできますか。
ただしこの制約はAでつくりたいです。

2017/12/30(土) 09:33:10.52

それくらい自分でよく考えろ

2017/12/30(土) 09:45:33.24

バカな考えはやめとけ
充分な知識と経験があるやつがバカな考えと知りつつあえてやるなら勝手だが
具体的なやりかたも分からないレベルのやつが思いつきでやろうとしても
あちこちぐちゃぐちゃになって自滅するだけだ

2017/12/30(土) 11:12:47.92

A&& a{B()};
B&& b{B()};
じゃだめなん？

2017/12/30(土) 12:45:48.79

うーん諦めそう

2017/12/30(土) 13:12:04.93

やりたいことを実現するだけならA::~A()をprivateにすればいい
数多の副作用をどうするかは自分で考えろ

2017/12/30(土) 13:54:05.13

ベクトルの内積を取りたいのですがC++で実装する場合最も高速な方法はなんでしょうか

2017/12/30(土) 13:54:23.97

逆にどういう条件ならdeleteしても良い条件なのか？
コレでは一向にdelete出来ないではないか

2017/12/30(土) 14:12:38.35

事故解決しました

2017/12/30(土) 14:50:42.66

罷り間違ってもdeleteできないインスタンスとなると
核開発か深海探査か宇宙船くらいしか思いつかない

2017/12/30(土) 14:58:28.45

電源を切っても生き残るインスタンス

2017/12/30(土) 15:57:20.60

最近の時事と照らし合わせると人工心肺の回収があったな
電源を切れないデザインの電子機器があるのかもしれない

2017/12/30(土) 16:04:54.13

スタックにしか置けないとか

2017/12/30(土) 19:53:03.01

>>747
詳細は？

2017/12/30(土) 19:54:40.04

逆ですね
つまりヒープにしか置きたくないです。
Aから派生したクラスのメモリサイクルを全てGCで管理します。

2017/12/30(土) 19:58:30.81

だとしたらGCからはdeleteできないと困るんでない？

2017/12/30(土) 20:03:16.25

たとえばprivateデストラクタを呼べる状態なら
friendにすればいいかと考えています。
それができなければ単に新しいvirtual del()メンバー関数を新設するつもりです。
領域自体はfree()で解放するのでデストラクタがなくてもクラス自体は削除できます。

2017/12/30(土) 20:07:42.93

だとしたら普通newをオーバーロードするけどね

2017/12/30(土) 20:10:14.52

newは既にオーバーロードされていて
ヘッダ取り付けmallocするようになっています。
問題はnewしてAのコンストラクタが動きGCの管理化であるにもかかわらず、
deleteされたりそもそもスタック上に造られてしまうことです。

2017/12/30(土) 20:14:25.11

いまのところの案は
A のdeleteをオーバーライドして
deleteされても領域は解放されないようにすることです。
しかしこれでもスタック上に配置することはできますが。
連投失礼しました。

2017/12/30(土) 20:47:53.74

てか、C++使うな

2017/12/30(土) 21:30:00.75

GCしか使わせたくないのなら、普通にGC言語使った方がいいと思うが。
オレオレＧＣ実装とか、全くの無駄だし。
なおVC++/CLIでよければGC専用クラスを明示的に作ることは出来る。

2017/12/30(土) 21:54:06.25

おそらくid変わってます

インタプリタ作っているんです
でインタプリタでgcをサポートするためにc++でgcを書いています
ですのでなんとかc++で解決したいわけです

2017/12/30(土) 22:09:40.34

それならnew/deleteでGCしようとするのが悪手

2017/12/30(土) 22:20:41.53

どうしよう

2017/12/30(土) 22:31:11.72

インタプリタの空間からは直接deleteにはアクセスできないんだろ？
だったらstd::shared_ptr使いなよ。

2017/12/30(土) 22:53:42.57

>>766
循環参照をインタプリタで考えたくないんです

2017/12/30(土) 23:08:46.89

某書籍の問題をC++で解いています。

格子状の道路を、同じ辺を通らずに（同じ格子点ではないです）
直進と左折のみで、左下から右上まで行く道は何通りあるか求めよ。

それに対して以下のコードを書きましたが、うまくいきません。
https://ideone.com/0JMvWz

MigiDame::CanGo関数の中での挙動が、こちらが期待しているようにならないのです。
＞全部trueが返る。
＞また、releaseとdebugで挙動が違う。

どなたかご助言をお願い致します。

2017/12/30(土) 23:13:41.03

>>767
論理的に矛盾している。GCは動的に確保・解放するが、C++のスマートポインターは基本的に静的にする。
それをインタプリタ側でしたくないのであれば、外部GCエンジンをインタプリタに接続するインターフェースが必要。

2017/12/30(土) 23:29:34.53

https://qiita.com/GachiNyanNyan/items/77401f60a1ded61b3952

2017/12/30(土) 23:30:58.79

http://www.nminoru.jp/~nminoru/programming/boehm-gc3.html
こちらを参考に。

2017/12/30(土) 23:33:17.06

後はクラス内部のoperator new/deleteを定義する。

2017/12/30(土) 23:46:28.29

>>763
> でインタプリタでgcをサポートするためにc++でgcを書いています
意味不明。

例えば、JavaやC#でインタプリタ書けば全く問題ないだろ。
一般的にはシステムとユーザで別ヒープ空間にしてサンドボックス化したいけど、
GC言語って一般的にGCヒープが壊れるようなアクセス方法を提供してないから、
別空間に分けなくてもそんなに酷いことにはならないぞ。
オレオレインタプリタ程度なら問題ないはず。

2017/12/31(日) 00:00:04.48

ヒープにしか置けないオブジェクトというのは、
More Effective C++ の項目27にあったな。
>>746で既に触れられている方法だけど。

2017/12/31(日) 00:16:40.38

インタプリタのメモリー管理はインタプリタ側かGCエンジン側でしないといけない。
インタプリタでは自動的にデストラクタは呼ばれないので、インタプリタ側が引き金を引かないといけない。

2017/12/31(日) 00:19:34.27

Boehm GCというGCエンジンをそのまま使えばいいからさ。

2017/12/31(日) 00:38:38.33

>>768
255行目は「return false;」じゃないの?

2017/12/31(日) 00:49:49.20

ありがとうございます。

仰る通りでした。

お恥ずかしい。

2017/12/31(日) 01:14:19.19

>>774
継承元のコンストラクタを呼べないのでそれはできないです

2017/12/31(日) 01:33:30.83

>>763
作ろうとしているインタプリタってc++の？
それなら、自分で入力のc++のソースを解析する際に問題のクラスがdeleteされたりスタック上に生成されたりするのは検知すれば良いのでは。

2017/12/31(日) 01:34:01.16

>>773
それは嫌です
既存の処理系がcで書かれている以上なんとかなるはずです
これは好みの問題かもしれませんが

2017/12/31(日) 01:57:19.48

>>781
C で書かれてても完全に C の仕様の範囲内で書いてるとは限らんのだぞ。
アーキテクチャ依存の部分を適当に #ifdef で分岐して configure でなんとかしたりする (できる) のが C/C++

2017/12/31(日) 02:23:20.14

>>780
いいえ
c++の文法は自分の手におえません

2017/12/31(日) 07:16:38.47

>>779
コンストラクターが呼べない？
GC管理の範囲の切り分けができてないんじゃないの？
何から何までGCで管理する必要は無いはず。
Boehm GCの使い方を勉強しい。

2017/12/31(日) 07:28:36.53

もう言ってることもちぐはぐだしレス古事記としか思えない
スルー推奨

2017/12/31(日) 07:32:05.37

インタプリタで扱う、GC管理するクラスの基底クラスObjectBaseを定義して、そこでBoehm GCを使ってoperator new/deleteを定義する。
インタプリタ側でObjectBaseの派生クラスを必要に応じてnew/deleteすればGC管理ができる。

2017/12/31(日) 09:17:47.39

まだ自分では難しいですね
一旦中断して勉強し直します
ありがとうございました

2017/12/31(日) 10:57:38.40

>>781
そういう意味ではない。

>>787
まあ、根本的に分かってないというのは同意する。
今の君では無理だ。

君は「既存のインタプリタにGC機能を付け加えようとしている」、ここまではいいか？

インタプリタの場合、両端の柱は2つで、
A. evalラッパ
B. フルエミュ
で、結局の所これらの折衷案となる。どのポイントを目指すかは君が決めればいい。
ただし、君はここまですら到達できていない。

君はGCを自前で実装することにこだわっている。
これはGCをフルエミュすることを意味しているが、
この場合、delete等は常に自前パーサを逐一通すことになるので、その段階で弾けばいいだけだ。
君が言っているように「禁止する」必要は全くない。（ここが矛盾している。
GC管理変数をdeleteしようとしているかは、当然分かるし、分からないようではフルエミュできない)

だから俺たちはevalラッパ実装だという前提で話をしている。
こちらの場合は、システム側が持っている機能を使って相乗りになる。
混ざらないようにさえ出来ればとりあえずは動く。

コードを書く以前に、まず、仕様を固めないと駄目だ。君はここが出来ていない。
もっと上位の、エミュレーション戦略を固めないと話にならない。

2017/12/31(日) 12:02:46.05

＞この場合、delete等は常に自前パーサを逐一通すことになるので、その段階で弾けばいいだけだ
というのはインタプリタからは直接deleteが見えないことをさしていると思いますが（合っていますか？
>君が言っているように「禁止する」必要は全くない。
の理由がわかりません。
インタプリタ上のオブジェクトもC＋＋上ではただのポインタであり
delete hogehoge //このhogehogeはGCの管理下
することは文法上は可能なはずです。
これを禁止することは処理系の保守性／安全性のために必要だと考えています（というのが初めの質問につながります

そしてevalラッパというのはやらないです。
今回はメモリ管理まで実装することでその"Java"や"C#"での管理の仕組みを実装レベルで学ぶことが目的の一つだからです。
動けばいいとうわけではありません。当然出荷するわけでもありませんので大丈夫です。

＞コードを書く以前に、まず、仕様を固めないと駄目だ。君はここが出来ていない。
＞もっと上位の、エミュレーション戦略を固めないと話にならない。
ええ全くその通りでした。楽観的すぎたか単に実力不足です。

2017/12/31(日) 13:30:39.82

>>789
君が想定しているのは明らかにフルエミュ寄りだから、それで話をすると、
A *a = new A(); でまず、
自前の変数管理用ハッシュ内に valuesHash["a"] = {type: A*, value: ptr};　することになるだろ。
そして delete a; が来ると、
if (valuesHash["a"].type.canDelete) delete valuesHash["a"].value;
で対応することになる。だから、

> することは文法上は可能なはずです。
> これを禁止することは処理系の保守性／安全性のために必要だと考えています
ということ自体が間違いなんだよ。
文法的に禁止とか、全く意味が無くて、
実行時に自然に弾けるし、弾けないようなフルエミュは実装不能だから。

君はインタプリタ自体がどう動いているのか理解できていない。
インタプリタの場合は、生きている変数を全て自分で把握してないと話にならないんだよ。
俺たちはこれは「常識」として、その先の ptr の配置先をどうするか、の話をしていた。
だから完全に空回りすることになる。

> 楽観的すぎたか単に実力不足です。
どっちもだ。
君は車を作ろうとしているが、車にエンジンとタイヤが必要なことすら理解できてない。
このレベルの馬鹿だ。自覚してくれ。

2017/12/31(日) 21:01:51.54

>>790
ありがとうございます
全く甘々でしたよ。。勉強してきます!

2017/12/31(日) 21:05:22.85

まぁ机上の空論の段階で質問してる感じはするね
まず実装してみて詰まってから質問したほうが絶対早い

2017/12/31(日) 21:10:48.47

これのやり方真似るだけじゃねえの
C++にこだわる理由とかあるのか

GitHub - python/cpython: The Python programming language
https://github.com/python/cpython

GitHub - ruby/ruby: The Ruby Programming Language
https://github.com/ruby/ruby

2017/12/31(日) 23:28:57.22

C++ということならV8もどうぞ。

V8 JavaScript Engine
https://github.com/v8/v8

つか、知らんかったけどCのインタプリタもあるのな。
https://root.cern.ch/root/Cint2006.html
https://stackoverflow.com/questions/69539/have-you-used-any-of-the-c-interpreters-not-compilers

2018/01/01(月) 15:09:24.40

特定のプログラムの音(ゲームの音やブラウザの音など)のみを録音する方法ってありますか？
ステレオミキサー経由の録音はできたのですがそれだとPC全体の音が入ってしまいます

2018/01/01(月) 15:29:07.61

全くもってスレ違い

2018/01/01(月) 16:20:46.04

C++で実装してるのですが

2018/01/01(月) 18:43:32.24

>>795
どういう環境かにもよる。

2018/01/01(月) 19:08:55.81

>>798
win10でマザボから音出してます

2018/01/01(月) 22:50:45.26

>>795
ステレオミキサーで必要な音以外をミュートにしておくのではダメなの？

2018/01/01(月) 23:04:49.88

>>800
ステレオミキサーで拾う音を選択することができるのですか？
録音デバイスのプロパティからはできないですがどうやるのでしょうか

2018/01/01(月) 23:29:57.50

めんどくさ。
DLL インジェクションでサウンド関連の API 呼出しを横取りして記憶するとかどうよ

2018/01/01(月) 23:48:05.00

まずOBSとかAfterburnerなんかの録画アプリで出来るか確かめてみれや
それでできるなら出来るだろうし出来ないなら出来ないってこった

2018/01/02(火) 00:08:23.37

>>797
録音を実現する機能はc++という言語の範疇ではないから、適切なスレで聞いてきた方がいいよ。
具体的に使うAPIなりライブラリなりが分かってやりたい処理があって、それをc++で記述する上で疑問が出てきたならこのスレでいいと思うけど。

2018/01/02(火) 02:09:46.75

>>801
Windows7だと画面右下のタスクバー上のスピーカーアイコンを右クリックして
音量ミキサーを起動すると、ミュートする音を選べるようになるよ
（各音源の一番下の青いスピーカーの部分をクリックすればいい）

2018/01/03(水) 00:50:02.27

みんなストイックに-Weverythingなの？

2018/01/03(水) 18:02:54.72

We very thing

2018/01/03(水) 18:06:12.23

「GCが欲しければObjectBaseを継承しなければならない
「さあObjectBaseを継承したまえ、GCが欲しいだろう
↑
という押しつけがましさ

2018/01/03(水) 18:08:47.07

ブランケットアンクローズドシンタックスエラー

2018/01/03(水) 19:20:51.86

switch(c) {
case '{':
aho();
break;
//...
}

◆QZaw55cn4c (ﾜｯﾁｮｲ ea60-rhJv) · 2018/01/03(水) 22:18:43.34

https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

＞that Intel's CPUs speculatively execute code potentially without performing security checks.
...
＞That would allow ring-3-level user code to read ring-0-level kernel data.

投機的実行が仇になったようだね、リング3 コードがリング0 カーネルデータを読み込める、というのは最悪だねえ‥

2018/01/03(水) 23:20:34.97

intelのCPUに重大なバグ。修正により性能30%ダウンは確実。もちろんcoffeeも対象 [589351131]
https://leia.5ch.net/test/read.cgi/poverty/1514960738/

＞インテルのCEOが関連性は不明だが2017年11月にCEOを最低維持できる25万株残して株式を売却している

ヤバいで

2018/01/04(木) 00:19:22.89

>>812
http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table

2018/01/04(木) 00:25:51.35

>>813
https://www.theguardian.com/technology/2018/jan/03/major-security-flaw-found-intel-processors-computers-windows-mac-os-linux

2018/01/04(木) 00:34:08.27

関連記事がまとまっていた
https://news.google.com/news/story/dxTQx3jGZ4VUkpMLaUSX33-gnbA8M?hl=en-GB&;ned=uk&gl=GB

2018/01/04(木) 00:45:09.37

えっやばくねこれ

2018/01/04(木) 02:42:39.95

なんか>>811にめちゃめちゃ書いてあるらしく実際そんなヤバないらしいよ

2018/01/04(木) 06:34:15.00

やってみろよ
ム板でそういう発言恥ずかしくないのか

2018/01/04(木) 08:34:28.43

システムコール呼び出すたびにアドレス空間を切り替えるパッチを当てるみたいだから、
io叩きまくるコンパイル作業はモロに影響うけるかもね。
arm64版にもパッチを当てるみたいだけど、禿大丈夫か…

2018/01/04(木) 18:57:44.39

intel抜けてる
intel割れてる

2018/01/05(金) 22:53:49.25

c++で例外は使ってますか？
また使う場合std::exceptionを継承しますか？

2018/01/05(金) 23:16:55.81

最後の門番がstd::exceptionなんで継承して使う

2018/01/05(金) 23:33:54.58

] ][][[[ [][] [[["][ [ ]]]["04"

2018/01/06(土) 01:45:54.07

>>821
標準コンテナとか含めて new 使ったら bad_alloc 受けることになるんだから
ほとんどの場合に使ってると言えそうなんだけど「継承しますか？」って話に繋がってるってことは
「使う」＝自分で例外クラスを定義して使うって話なのかな？

2018/01/06(土) 02:11:45.78

英単語の前後にスペースを挿入するのはこだわり？

2018/01/06(土) 02:48:37.95

>>825
TeX で英数字からなる語の前後に空白を入れないと単語境界がうまく認識されないという問題があったので、この習慣は広く定着してる。
ただ、 pTeX などでは自動で境界を認識して適切な幅を取るようになっているのでむしろ空白文字を入れるとダメってのもある。
どっちでも上手いこと処理するのもあるし、そのへんごちゃごちゃしてややこしいんだわ。

ウェブブラウザでも物によって幅の取り方が違う。

まあ個人的には、バッドノウハウだという自覚はあるが、 html やプレーンテキストでは英単語の前後には空白を入れた方が見やすいと思う。

2018/01/06(土) 02:53:16.08

たしかに

2018/01/06(土) 02:59:22.25

>>825 https://www.google.com/search?q=%E8%8B%B1%E5%8D%98%E8%AA%9E%E3%81%AE%E5%89%8D%E5%BE%8C%E3%81%AB%E3%82%B9%E3%83%9A%E3%83%BC%E3%82%B9

2018/01/06(土) 09:05:07.05

>>824
そうです。c++の本など見ても標準の例外を説明して終わりな事が多いし、しまいにはnoexceptなるキーワードまで出来てるし実際使ってるのかなと。

2018/01/07(日) 19:05:16.44

標準の例外はexception&で捕獲できる
ただそれだけのこと

独自定義の例外を標準の例外とは区別したいのなら
exceptionを継承しないという手も当然ある
教条主義にとらわれるやつ＝自分の頭で考えないやつは
こういう判断が極度に苦手だ

**デフォルトの名無しさん** · 2018/01/07(日) 23:12:25.29

>>825
Linux の日本語ドキュメントの読み書きに慣れてると自然と空白空けちゃうね。
http://linuxjf.osdn.jp/JFdocs/jf-styleguide.html#s2

2018/01/08(月) 02:30:58.74

標準のライブラリがやってることっていうのはだいたいその言語における「普通」なので、
原則としてはそれに合わせるというのは良い方法だよ。

あえて原則に逆らいたいとき、逆らった方が便利なときというのももちろんあるけれど、
たいして強い動機もないのに独自の設計を選択するのは混乱の元。
つまり、例外クラスは std::exception を継承するのが好ましい。
その上でそのデザインが問題を起こす場合があるなら見直せばいい。

2018/01/08(月) 03:33:16.23

動的例外がまだ廃止されていない頃に設計されたものが
今のC++に対して本当に「普通」なのか考えたことがあるか？
（別にここで答えなくてよいが）
誤った前提のうえに立つ主張はただの戯れ言で
そうなっていないことは確認してからぬかせ

2018/01/08(月) 04:19:16.37

std::exceptionを継承しないメリットって何かある？

2018/01/08(月) 05:20:35.84

僅か数レスの流れくらい読め

2018/01/08(月) 06:27:14.93

std::exceptionを継承しないデメリットもようわからん…
std::exceptionは一体何をやっているのや？

std::exceptionを継承しなくとも
　throw 1; --> catch (int)で捕捉
　throw "Hello World!"; --> catch (const char*)で捕捉
とかやれるようになったのって比較的最近？

2018/01/08(月) 06:38:24.96

>>834
ないよ
std::exceptionを継承しても独自例外は区別できるし、>>830は反例になってない
std::exceptionを継承しないのは、普通にアンチパターンだからやめたほうがいい

2018/01/08(月) 09:47:56.66

クラス以外を投げるのはdeprecatedになってたような…(自信なし)

とはいえstd::exceptionを継承しなければならない強い理由もあんまりないような気がする
JavaのThrowableやらPythonのExceptionやらはGCの都合だし
あくまでstd内の例外を組織化するための基本クラスでしょstd::exceptionって

2018/01/08(月) 09:53:10.93

>>838
テスティングフレームワークとか、ロギングフレームワークとか魔改造したくないでしょ
おとなしくstd::exception継承しとけ、デメリットが多すぎる

2018/01/08(月) 10:38:49.41

std::exceptionおよびその派生クラスを受け取る標準のロギングフレームワークってありましたっけ…
STLはなんか例外を投げる側しかサポートしていない印象

そもそも例外の捕捉のしくみは「知ってる例外のみ捕捉して処理する/知らない例外はさらに呼び出し元に送る」戦略なので、
受け取る側に既存のフレームワークが無いんなら、投げる側の例外が高度に統一されている必要は実はそんなには無いｷﾓｽ

せいぜいコピーしたときリークするようなクラスではあってほしくないという願いがあるぐらいで実は何だって良いのでは…

2018/01/08(月) 11:10:23.18

>>840
「フレームワーク」にあたるかどうかはわかんないけど、
catch(std::exception& e) で e.what() を拾うっていうよくあるエラー処理のパターンがあるんだよ。
https://github.com/search?utf8=%E2%9C%93&;q=%22catch+std%3A%3Aexception%22+what&type=Code

だから、 std::exception 派生にしといてもらわないとまともなエラーメッセージが出なかったりして困る。