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/11/30(木) 12:26:19.48

一応いまのところこんな感じで書けるようになってる
やってることが非同期処理なので多少ややこしいのは本質的に仕方がない
int func_async( int n ){
　if( n == 0 ){ return 0; }

　a_wait() << [&]{ sleep( 10*1000 ); };
　//↑非同期で何か重たい処理
　//↑別スレッドに投げたのちyield_return;

　int resunt;
　a_sync() << [&]{ //コルーチン作成
　　resunt = func_async( n - 1 ); //再起呼び出し
　};
　//throw nanika;
　//↑仮に誰かが例外を投げれば親子関係のあるすべてのコルーチンの処理が
　//↑キャンセルされて、どのコルーチンもbarrier以降は実行しない

　//barrier前なのでresultの値は不定
　barrier();
　//barrier後なのでresultの値が決まる
　return n + result;
}
int main(){
　a_sync() << [&]{ //コルーチン作成
　　int result;
　　a_sync() << [&]{ result = func_async( 10 ); }; //コルーチン作成
　　barrier();
　　printf( "%d\n", result );
　}
　message_loop();
　return 0;
}

2017/11/30(木) 19:19:19.63

>>211
なんか無駄に複雑化してるだけに見えるが、、、

> どのみち非同期処理にC#よろしくコルーチンが使いたいわけで
なおVC++2015からはasync/yieldは使えるらしいぞ。
https://msdn.microsoft.com/ja-jp/magazine/mt573711.aspx
http://espresso3389.hatenablog.com/entry/2015/12/03/015157

2017/11/30(木) 20:12:10.25

C++の名前空間と呼ばれるのがあまり理解出来ないんだが
Javaでいうパッケージ的なやつ？
それともそれを使うためのパスワード的なやつですか？

2017/11/30(木) 20:42:22.43

>>212
複雑っていうけど、元から非同期処理なんか、どう書いたって複雑だろ
>>211はお遊びでワザとコルーチン作りまくってるだけだし
あの程度の事なら本当はこれでいけるわけで
int func_async( int n ){
　if( n == 0 ){ return 0; }
　a_wait() << [&]{ sleep( 10*1000 ); }; //非同期処理
　return n + func_async( n - 1 );
}
int main(){
　a_sync() << [&]{ printf( "%d\n", func_async( 10 ) ); };
　message_loop();
　return 0;
}
別に複雑と言うほどでもないし
非同期処理を同期処理みたいにかけるというだけ
あとはキャンセルと例外安全のためにbarrierの機能を追加しただけ

2017/11/30(木) 20:59:54.72

>>214
<future>のasync,futureじゃダメ? C++11で標準になりましたけど

https://wandbox.org/permlink/cACSVRCACSAl92OH

wait_for_allが欲しかったのでBoost使ってます
元は　https://gist.github.com/chandraprakash/8666426 で　これを少し改造

2017/11/30(木) 21:03:11.80

>>214
まず、君が書いているんだから君が好きなようにやるべきだし、
実験的な意味合いも含めて色々やること自体はいいと思うが、、、

非同期にしてるのは何故？GUIからの呼び出しでC#のasync Taskと同じ状況か？
それなら確かにどうしようもないが、しかし今見てみるとC#のasyncもだいぶ筋が悪いとは感じるね。
そのケースなら、普通にマルチスレッドした方がすっきり書けるはず。

あと、コルーチンからのthrowって、君の意図しているようにドミノ倒し的に回収できるものなのか？
これは俺が仕様を知らないだけではあるが、普通はコルーチンってそういう使い方しないと思うし。

2017/11/30(木) 22:29:42.54

>>あと、コルーチンからのthrowって、君の意図しているようにドミノ倒し的に回収できるものなのか？
そういう風にコルーチンを実装した
具体的にはコルーチンのメンバにキャンセルフラグを持たせておいて
コルーチンを外部からキャンセルしたいときはそのフラグを立てる・・・だけ
コルーチンがyieldから再開したら真っ先にそのフラグを読みに行って
もし立ってたら自発的に例外を投げてスレッドを巻き戻す

>そのケースなら、普通にマルチスレッドした方がすっきり書けるはず。

あくまでこれは例だからなぁ
上で書いた内容もそうだけど、ひとつコルーチンがシングルスレッドというのがミソになってて
マルチスレッドだと排他処理が非常に面倒なことになる場面でも
コルーチンはシングルスレッドだから問題にならない
ただ、yieldの前と後ろで時間的につながりが無いことが問題になるので
誰かが何かを書き換える前にbarrier()を設けるルールを作って、他のコルーチンを無効にする
非同期処理なんかまともにやったら頭がおかしくなるに違いないので
横断的に静的に管理したいなぁと

今までコルーチンは全然使わなかったし、完全にマルチスレッド脳だったんだが
コルーチンはかなり脳の負担が少なくてよい
自分が動いているときは必ず他人は止まっているという性質が良い
yieldの前後だけ気を付ければ後は完全にシングルスレッドのノリで排他処理が要らない
ただ逆に同期オブジェクトをLockしたままyieldしたら終わるという

>C#のasyncもだいぶ筋が悪いとは感じるね。
正直、あれの使いどころは俺もよくわからないんよなぁ
複数のコルーチンが同時並行で走ったら危ないから結局画面をロックせざるを得ないんじゃないかとか
キャンセルを受け付けられるようにするためには例外安全についても考えないとダメなんじゃないかとか
色々思うところは有るが、実はよく知らん

2017/11/30(木) 23:00:20.60

>>216
async/awaitのしくみはawaitするタスクの完了時に呼ばれるべきコールバック関数登録の糖衣構文にすぎないとかそんな感じ、
ttps://qiita.com/ryosukes/items/db8b45c8ea42f924f02f
（まんまC#の関数で説明したページもあったはずだがどっかいったのでJavaScriptの例↑

で、ネイティブスレッドX上でasync/await呼び出しをいくつ書いても上記コールバック関数は単一スレッドで実行されるので
Xに対して同期的なデータへのアクセスはロック不要

ウィンドーズホンのGUIをぬるぬる動かすのがほぼ唯一の存在意義

2017/11/30(木) 23:07:19.56

つまり同一スレッド内であればasync/awaitをいっぱい書いても複数のコルーチンが順不同でresumeされる感じにはなるが真に同時並行で実行されることにはならない

2017/11/30(木) 23:13:29.49

なお順不同なresumeというｼﾁｭは、関数A内でawaitされるasyncタスクB内でタスクCをawaitする…とかいったケースで容易に生じる
この場合A内のawaitに引き続くのコードと、B内のawaitに引き続くコードのは順不同でどっちが先にresumeされるかわからん
しかし真に同時並行ではなく、同期的

2017/11/30(木) 23:19:09.22

ttps://stackoverflow.com/questions/1724036/splitting-templated-c-classes-into-hpp-cpp-files-is-it-possible

Your template classes must represent only data structures not the algorithms.
This enables you to hide more valuable implementation details in separate non-templatized class libraries,
the classes inside which would work on the template classes or just use them to hold data.

この回答の具体的な例を教えて頂けないでしょうか。

std::vector（データ）とstd::algorithm（アルゴリズム）と思ったのですが、
std;;algorithmはnon-templatized classではないですよね。。。

2017/11/30(木) 23:40:55.16

>>217
> あくまでこれは例だからなぁ
もしかしてコルーチンを自動的にマルチスレッド展開して加速させる為のラッパを用意してるってことか？
それならまあそのコードの感じになるのかもしれん。

ちなみに言っておくと、俺が普通に実装したら>>215と同じようなものになる。
単純に、「ディスパッチして、joinを待って、commitする」としか読めないコードにする。
ただこれは君ももちろん分かっていて、あのコードなのだとは思う。

なお俺はC#のasyncは設計ミス、
・UIコンポーネントがUIスレッドからでしか触れないこと
の対策だと思っている。あれが無いと毎回invokeするとか、ちょっと回りくどい書き方をするしかない。
実際、Thread->backgroundWorker->Task->async Task だったっけ？何度も変更されていて、
こういう場合は通常、
・修正している奴が馬鹿だから修正のたびに新たなバグを仕込んでしまい、収拾がつかない
わけだが、ヘルズバーグとMSがそこまで馬鹿なはずも無く、もう一つのケース、
・根本の問題を修正せずに表面的に対策をしているから、収拾がつかない
のだと思っている。そして、根本の問題は、最初に書いたUIガー、って奴。

これについて「根本のUIスレッドの問題直せやボケエ」ってをずいぶん前にC#スレで議論した覚えはあるが、
UIをマルチスレッドにして悲惨だった歴史が既にあるらしく、
「オメーがラップすりゃいいだけだろボケエ」と返され、あ、確かにそうだな、と思って終わった。
ま、とにかく、UI関係のコードをスッキリさせる為の物だから、気になってないのなら放置でいいと思う。

> yieldの前後だけ気を付ければ後は完全にシングルスレッドのノリで排他処理が要らない
コルーチンの方がいいケースについてか。
うーん、どうなんだろうなあ？俺もコルーチンはほぼ使ってきてないが、
マルチスレッドする場合にはほぼ干渉しない場合に限っていたから、
逆に言えば、コルーチンを使えばもっと並列化できるということか？

2017/12/01(金) 09:48:37.54

Eigenで透視投影変換行列を作るのは次の書き方でいいんでしょうか？
なんか結果をみても微妙にずれているのですが．．．

Eigen::Matrix4f perspectiveMatrix(float left, float right,
float bottom, float top,
float near, float far)
{
Eigen::Matrix4f m;
m << 2.0f*nearZ/(right-left), 0.0f, (right+left)/(right-left), 0.0f,
0.0f, 2.0f*near/(top-bottom), (top+bottom)/(top-bottom), 0.0f,
0.0f, 0.0f, -(far+near)/(far-near), -2.0f*far*near/(far-near),
0.0f, 0.0f, -1.0f, 0.0f;
return m;
}

2017/12/01(金) 09:59:25.68

await/asyncのコルーチンは並列化じゃなくて非同期処理を同期処理っぽく書くための物だとおもうよ
「これを実行して、終わったらこれを実行してね」
っていうときに、スタックの内容がそのまま残ってるからデータの受け渡しが楽というだけだろう
ただ>>220が言ってるように順不同のresumeが起こったらアブナイので
何か書き込む前にbarrierを張って自分に関係が無い実行中のコルーチンを全部キャンセルして始末してしまおうという
(実際にはbarrierだけじゃなくawaitのタイミングでも始末するようにしているが)
ただキャンセルするために例外安全性とかも重要になってきて
ここでもbarrierとコルーチンの仕組みがそのまま活躍するのが、なんか不思議な感じなんだが
読み込みオンリーだけどキャンセルできるセクションと、書き込みできるがキャンセルできないセクションに
処理を分けるというアイデアはなかなか汎用性が有るんじゃないかと
で、二つのセクションは別関数にせずにコルーチンでつないで一つの関数に収めbarrier前/後とし
barrier前ならawaitも使える、と、2,3のことが同時にかたづいて気持ちが悪い

2017/12/01(金) 10:56:33.99

>>224
今日もA-10学校に、まで読んだ

2017/12/01(金) 11:05:05.82

exec execve などいくつかあるけど
こいつらの違いを理解できない
ここの人たちはmanページを読んで理解できるもんなの？

2017/12/01(金) 11:40:18.96

>>223
https://msdn.microsoft.com/ja-jp/library/cc372887.aspx
これを参考にしてみては
右手系の場合はRH、あと行列の扱い方によっては転置が必要だけど

2017/12/01(金) 15:52:06.92

>>227
解決しました。あれで合ってました。
間違ってのはモデル変換行列の方でした。

2017/12/01(金) 18:53:54.97

C++17が出たけど既にN4700しか読んでない

2017/12/01(金) 19:27:41.27

>>224
最終的に何をしたいんだ？
俺にはそこが見えない。

一つずつ詰めると、頭三行
> await/asyncのコルーチンは並列化じゃなくて非同期処理を同期処理っぽく書くための物だとおもうよ
> 「これを実行して、終わったらこれを実行してね」
> っていうときに、スタックの内容がそのまま残ってるからデータの受け渡しが楽というだけだろう
については同意する。これは>>218-220含めて3人の共通理解でいい。
(ただし俺には逆に、君自身は「並列化の為に」async/awaitを使おうとしているように見える)

> ただ>>220が言ってるように順不同のresumeが起こったらアブナイので
これについては、一般的には逆だ。順序が逆になったら危ないような物を非同期にしてはいけない。
違う言い方をすると、非同期の結果をbarrierを張ってキャンセルするのではなく、
barrier後に非同期にして、結果は必ずcommit出来る構造にする。

ちなみにJavaScriptの連中はここら辺が分かっていなくて、
(というより連中は制御構造云々を議論できるレベルではないのでこれ以前なのだが）
同期前提の制御構造で非同期を扱おうとするからおかしなことになる。
JavaScriptには非同期しかないんだから、選択の余地もないんだが。

C#のasyncはこれとはちょっと違って、イベントで起動するから必ずUIスレになるんだが、
それにジョブをやらせるとUIがカクつくから他スレッドを起動しろ、
しかしそれだと結果を画面に表示できないからそこだけUIスレッドを呼び戻せ、
ただこれだとソースが汚いから、asyncというキーワードをつけ、あたかも全てUIスレッドが処理しているように見せる、
みたいな、なんだかなあ、という状況になっている。
つまり処理順と処理スレッドを入れ替える為の糖衣構文のようなものであって、
本来のasync/awaitのように、非同期を同期的に書くための物自体ではない。ただしそうとも使えるから流用してるが。

それで話を戻すと、君は非同期部分に一般とは逆の「非同期の結果を普通にキャンセルできる構造」を作ろうとしているようだが、
これは何故？或いは何のメリットがあると考えている？

2017/12/01(金) 19:37:06.05

Java厨はハードの基本がわかってないニワカなんちゃってPGが殆どだからな

2017/12/02(土) 00:35:41.73

最近長えレスが多くて辛えぞえ

2017/12/02(土) 00:43:05.07

予告犯でホリエモンもどきがシンブンシにそんな事言っていたな

2017/12/02(土) 01:17:01.05

コルーチンをキャンセルとか意味わかんない事言ってるから途中から読んですらない。

2017/12/02(土) 02:10:43.54

漏れはもう説得をあきらめたゾ

2017/12/02(土) 03:07:38.26

>>226
引数が違うだけで、内部的には、どれも同じだろ。
つまり、ラッパー関数

OS をすべて知っている奴は、いない

だから皆、神の書と呼ばれる、この本を枕にして寝ている。
著者は、man ページの作者。
この本が翻訳されているのは、日本だけ

Linux プログラミング・インタフェース、2012

2017/12/02(土) 17:32:32.90

>この本が翻訳されているのは、日本だけ

もうだめだこの国

2017/12/02(土) 20:34:54.85

Linux 資格の、LPIC 取得者も、半分以上は日本人だろ

日本は、Linux 大国

2017/12/02(土) 20:40:02.69

pthreadとかPOSIX系は扱い易い

2017/12/02(土) 21:04:09.64

Linuxは日本に入ってきたのが早かったし、最初期に一気に広まった。
日本がLinux王国というのは間違いではない。
しかし、それを生かせなかった。
なんでだろ。

2017/12/02(土) 21:06:05.55

PC98がMSDOSを採用し続けたせい

◆QZaw55cn4c (ﾜｯﾁｮｲ 4a60-CnPo) · 2017/12/02(土) 21:14:00.87

>>240
PC98 のリソースが freebsd に注がれ、linux への移植が遅れたため

2017/12/02(土) 21:25:07.65

当時書店でBoWとか売ってたけど、そのせいで遅れたような感じはしなかったけどなあ。
むしろLinuxでX11動かすのに四苦八苦してた頃、すでにコンソールで日本語が使えてたのは、
UNIXの人たちのおかげのような気がする。

2017/12/02(土) 21:38:52.02

検索してみるとコンパックショックが1994年なんだな。
DOS/V機自作したのが1993年だからもうちょっと前かと思ってたけど。
正規流通前にショップが輸入して売ってたんだろか。

2017/12/02(土) 22:17:42.90

その当時、漏れは、Windows 3.1 で、UNIX プログラミングやってた。
テキストエディタ MIFES を使っていた

Oracle で、銀行とか、新幹線とか

◆QZaw55cn4c (ﾜｯﾁｮｲ 4a60-CnPo) · 2017/12/02(土) 22:46:06.08

>>245
＞銀行とか、新幹線とか
暗号方式はなにを使っていましたか？

2017/12/02(土) 23:44:03.24

PANIXの遅さはすごかったな

2017/12/03(日) 01:07:06.72

NECは当時経営陣が自社の社員が開発したソフトを押し退けてＭＳのソフトをごり押ししてたからな
終わっているよな

2017/12/03(日) 01:40:24.23

>>248
そんなに糞だったのか自社製ソフト

2017/12/03(日) 08:02:49.76

派生クラスのデストラクタでなにもしないなら、
基底クラスのデストラクタを仮想にしなくてもいいですか？

2017/12/03(日) 08:56:43.57

>>250
自由にクラスを設計すればいいよ。
デストラクタを仮想クラスを必ず定義しておかなければならないとか、そんな義務はない。
あらかじめ定義しておくと、仕様変更があった時などで、派生クラスで、デストラクタを使いたい時に、基底クラスをいじらずに定義できるだけだよ。
仮に、複数人で、アプリを作ってるなら、基底クラス担当がいたとして、わざわざ基底クラスをいじりますよーとか連絡しないでいいという利点はあるかもな。
もし、基底クラス担当で、他人に基底クラスを触らせたくないなら定義しておいたほうがいい。
基底クラスをいじられて、変なバグとか追加されても困るｗ

2017/12/03(日) 09:05:51.65

>>251
頓珍漢すぎて笑えない...

2017/12/03(日) 09:26:11.28

うん、これは頭悪い発言スレでやればウケてた

2017/12/03(日) 09:31:06.52

>>250
規格は知らんが問題が発生するコンパイラは存在しないと思う。が、デストラクタで何もしないというのはデータメンバーも含まれるからね。
派生クラスにstd::stringのメンバーが居るだけでアウト
そんな事を気にするより素直にvirtual付けるか基底クラスでdeleteされないようにする方が有意義に時間を使えると思うよ。

2017/12/03(日) 09:49:40.40

>>254
>派生クラスにstd::stringのメンバーが居るだけでアウト
それだけでアウトなのではない
DerivedがBaseの派生だとして、実体はDerivedなのにコンパイラからはBaseにしか見えないケースで問題になるだけ
DerivedをDerivedとして宣言したらスコープを抜けたらちゃんとDerivedのデストラは呼ばる

問題なやつの例：
　Derived g_d;
　void foo() {
　　Base* p = (Base*)&g_d;
　　/*...*/
　　delete p; // Base::~Base()は呼ばれるがDerived::~Derived()は呼ばれない
　}

2017/12/03(日) 09:53:01.97

ごめ、一点抜けた
誤：実体はDerivedなのにコンパイラからはBaseにしか見えないケース
正：実体はDerivedなのにコンパイラからはBaseにしか見えない状態で当該オブジェクトが破棄されるケース

なお、（規格でどういう言葉使いをしているかわ知らんが、）
Derivedが多態性をきちんと実装してあるなら、Derivedは「コンパイラからはBaseにしか見えないケース」には該当しない

2017/12/03(日) 09:53:10.45

ごめ、一点抜けた
誤：実体はDerivedなのにコンパイラからはBaseにしか見えないケース
正：実体はDerivedなのにコンパイラからはBaseにしか見えない状態で当該オブジェクトが破棄されるケース

なお、（規格でどういう言葉使いをしているかわ知らんが、）
Derivedが多態性をきちんと実装してあるなら、Derivedは「コンパイラからはBaseにしか見えないケース」には該当しない

2017/12/03(日) 09:57:14.66

>>255
だから
「基底クラスでdeleteされないようにする方が」
って言ってんだろ

2017/12/03(日) 09:58:13.14

大事なことなので2回ry

まあ一般論として、>>255の問題なやつがプログラム内に存在しないことの確実で安価で
ウザく無い検出方法というものはこの世に存在しないので、
継承関係を使うならデストラクタを見たらvirtualにするパブロフの犬に徹するべきではある

2017/12/03(日) 10:48:30.75

＞delete p; // Base::~Base()は呼ばれるがDerived::~Derived()は呼ばれない

~Derived()が呼ばれないけど、
呼ばれたとして何も仕事をしないのであれば、呼ばれなくても不都合ないのでは？

2017/12/03(日) 11:01:45.65

なにも仕事をしないデストラクタという前提がおかしいのですか？

2017/12/03(日) 11:06:05.82

メイヤーズが言ってる
ポリモーフィズムを目的とした基底クラスはvirtualデストラクタにする
それ以外はしないってルールでいいだろ

2017/12/03(日) 11:12:49.55

>>261
Yes
デストラクターの仕事はプロクラマーの書いたコードだけではない

2017/12/03(日) 13:16:36.90

>>260
このあたりで話題になったことがある。
https://echo.5ch.net/test/read.cgi/tech/1478440682/651-
結論から言うと不都合は有る。

少なくとも言語仕様上は未定義に踏み込むのでクラッシュしても泣かない強い心を持ち合わせているのでなければやらない方が良い。

2017/12/03(日) 13:39:28.04

>>254
暗黙的なメンバー変数の破棄が呼ばれるべきってのはあるけど、何もアウトなことはないぞ？

2017/12/03(日) 13:42:24.66

>>265
お前質問読んでないだろ

2017/12/03(日) 13:52:29.29

>>259
その考えはどうかと思うけどな
vtblが邪魔になるような、メモリ上では純粋にデータしか持たないクラスとか作れなくなるぞ

2017/12/03(日) 16:06:00.67

>>267
> 継承関係を使うなら

2017/12/03(日) 16:29:14.83

継承関係を使う＝vtbl
と考えてしまうような無知な者には理解するのは難しい
他人の作ったものも構わずナマポをdeleteしておいて「virtualにしておけば安全」というのはマッチポンプと言えよう

2017/12/03(日) 16:39:32.89

正直何を言いたいのかはよくわからん w
まあ>>251みたいな頓珍漢野郎なんだろう...

2017/12/03(日) 17:09:40.29

>>270
いや、この件に関してはお前の方が無知だぞ

2017/12/03(日) 17:12:44.51

結局のところ
何も仕事をしないデストラクタはあるが、（空のデストラクタかつメンバ変数なし）
基底クラスのデストラクタだけで派生クラスをdeleteすることが未定義だから
基底クラスのデストラクタは仮想にしないとダメという理解でよろしいでしょうか。

2017/12/03(日) 17:28:04.25

デストラクタは仮想にしておくことにより通常の仮想関数と違って継承元辿って全自動ですべて呼び出されるから基底はやることなくても以後継承で実装を変更することがあるのなら空の{}で括っておいたほうが良いよ

2017/12/03(日) 17:49:35.39

=defaultじゃだめなん？

2017/12/03(日) 17:50:12.92

>>271
まあそう思ってりゃいいんじゃね？ w

2017/12/03(日) 19:52:12.45

もしかして本当に継承使ったPOD型に思い至ってないのか

2017/12/03(日) 19:55:36.14

くそー>>254の簡潔すぐる日本語のせいで暗黒の日曜日になってしまったわ、

だいたい質問者の>>250も簡潔すぐる
初心者質問と思ったし、だいたい理解している上で確認の意味で質問しているのならそう書いてﾎｽｲ、

2017/12/03(日) 20:15:25.15

もうここ完全に初心者様質問無しにしろよ
上級者様もそれで満足だろ

◆QZaw55cn4c (ﾜｯﾁｮｲ 4a60-CnPo) · 2017/12/03(日) 20:16:39.17

>>278
それは困ります…

2017/12/03(日) 20:21:06.32

>>278
漏れのように語りたい初心者は一体どうすれば…orz

2017/12/03(日) 21:05:16.05

>>278
自殺乙

2017/12/04(月) 12:17:24.94

祝・C++17発行！

2017/12/04(月) 12:38:47.34

これまでinlineを関数に適用するとインライン展開されるんじゃなかったでしたっけ？
c++17の説明を読むと翻訳単位で共通のアドレスになるって書いてあるのだけど仕様が変わった？

2017/12/04(月) 12:45:21.76

何を言っているんだお前は

ISO/IEC 14882:1998 7.1.2/p4
An inline function with external linkage shall have the same address in all translation units

2017/12/04(月) 12:56:42.17

>>284
ナンダッテー

2017/12/04(月) 13:08:03.78

以前void f(A &a, int num)をa.f(num)みたいに呼べる機能が追加されるとかされないとかを見た気がするんだけど知ってる人いたらURLか機能名を教えてほしい

2017/12/04(月) 13:10:08.18

unified call syntax

2017/12/04(月) 13:22:55.68

>>287
ありがとう

2017/12/04(月) 14:58:45.86

ウニファイドコールシンタックスは死んだのだ。
よみがえれ！

2017/12/04(月) 15:48:40.92

残念だったな

2017/12/04(月) 16:16:56.14

はう。

◆QZaw55cn4c (ﾜｯﾁｮｲ 4a60-CnPo) · 2017/12/04(月) 18:00:57.88

accelerated c++ をやっている人いませんか？
今やりなおしているけれども、5年ほど前の自分の回答をなくしてしまった…
4章章末練習問題4-6の回答を、よろしければお見せいただけませんか？
この章、EOLine と EOFile を std::cin の eof フラグ 1　個でなんとかしようとしているのが非常にまずいと分かりましたが
逆に教科書掲載のプログラムでうまくいっているのが不思議です…取り組まれた方のコメントをお待ちしています…

普通 getline() をつかうんだろうけれども、なんでこんなに変てこな実装になっているのだろう？
教科書の内容 https://ideone.com/rdtZWG

>>44-45 悪書を薦めてしまいました、ごめんなさい

2017/12/04(月) 19:13:30.50

>>289
メソッドチェインしたいだけなら拡張メソッドの方が筋がいいだろ。そっち応援してやれよ

2017/12/04(月) 19:27:49.25

拡張メソッドってデコレータパターンで充分なのに、なんで最近の言語には結構ついてんだろ。

◆QZaw55cn4c (ﾜｯﾁｮｲ 4a60-L6cJ) · 2017/12/04(月) 19:43:03.25

>>292
>>44-45
結局のところ、std::stringstream を使うべきだという結論になりました。（std::stringstream は今回初めて知った）
教科書本文（64ページ、項4.2.3、70ページ、項4.5）
https://ideone.com/F761bo

73ページの練習問題4-5の方は
https://ideone.com/H9iE4j

このように >>42 は多大な努力を強いられる教科書ですので、お勧めです、強くなりたい人はどうぞ
私はもう強くなくてもいいから、この本はもういいです…

教科書をお持ちでない人には関係ない話ですみません

2017/12/04(月) 21:39:45.95

>>282

2017/12/04(月) 21:40:55.38

ん？

2017/12/04(月) 22:43:49.08

>>285
別に驚くほどのことじゃないし…
関数のインライン展開と、同じ機能の非インライン関数の存在は両立する
>>284の規定は関数のアドレスをとられたときのため用

◆QZaw55cn4c (ﾜｯﾁｮｲ 4a60-CnPo) · 2017/12/05(火) 10:37:05.67

>>151
template の話もお願いしていいですか？
型安全を優先するあまりに instantiate（これいい訳がないね）してまで、という思考と void * を許してしまう思考の両方について、比較していただくとうれしいんですけれども

◆QZaw55cn4c (ﾜｯﾁｮｲ 4a60-CnPo) · 2017/12/05(火) 10:45:00.72

>>168
std::make_shared はあっても unique 版はない、とかなんとか、そこらへんが徹底されていない、とか、確かあったような気が

◆QZaw55cn4c (ﾜｯﾁｮｲ 4a60-CnPo) · 2017/12/05(火) 10:50:30.93

>>150-152
ファイルのopen/close とか、RAII ／デストラクタが Java にもあればなあ、と思っています。
あと、Java　の syncronized って、結局、テキトーなダミー変数を mutex 代わりにしちゃう、とかありません？

◆QZaw55cn4c (ﾜｯﾁｮｲ 4a60-CnPo) · 2017/12/05(火) 10:53:52.88

>>115
古来ゆかしき Boehm GC を思い出しました。これ、C++11 later とかの対応はどうなんだろう？
http://www.hboehm.info/gc/　よくわからん…

◆QZaw55cn4c (ﾜｯﾁｮｲ 4a60-CnPo) · 2017/12/05(火) 10:58:49.04

>>101
＞K&Rも「関数ポインタも使えるよ」としか書いて無い。あれはもっと力説されて然るべきだった。

これが本題かな？
いや、関数ポインタってそんなに特筆すべきものだったかな…むしろ setjmp()/longjmp() の方がインパクトが、ってこれはexception として広く採用されていましたっけね
いや、関数ポインタってコールバック(とvtable）は別として、何か使えるネタが他にあるかなって考えてました、今のところ思いつかないな…

◆QZaw55cn4c (ﾜｯﾁｮｲ 4a60-CnPo) · 2017/12/05(火) 11:06:41.81

>>99
＞(instance.method()とstaticMethod(instance)の実行時の違いがほぼ無い、
うーん、Java　で、これでもか、これでもか、と this が null でないことをチェックするのを読んだことがあります。
C++ だと(virtual でなければ）普通に this = 0 にして this->method() できちゃうんですが、この this の null チェックって、広く行われているのでしょうか？http://codepad.org/gtEBWFKR

◆QZaw55cn4c (ﾜｯﾁｮｲ 4a60-CnPo) · 2017/12/05(火) 11:20:19.80

これでおしまい
try～catch はいいとして、finally って使いにくい、というか使い方がわからないんですが、finally って意味あるんでしょうか？

2017/12/05(火) 12:10:12.56

> RAII ／デストラクタが Java にもあればなあ、と思っています

RAIIは7年前にジャバに入った筈だが
何を言っているのだろうか

2017/12/05(火) 18:56:58.67

>>305
C++ 的にはなるべくデストラクタで後始末がつくようにやれというスタンスっぽい

2017/12/05(火) 19:00:20.98

>>304
C++ ではヌルポインタからメンバ関数を呼び出すのは未定義だよ。
メンバ関数内でデータメンバにアクセスする要素がなかったとしても未定義。

◆QZaw55cn4c (ﾜｯﾁｮｲ 4a60-CnPo) · 2017/12/05(火) 19:12:28.94

>>308
え！

2017/12/05(火) 19:18:52.02

this->method()は(*this).method()と等価で、ぬるぽに*適用したらその時点で未定義だからアウト

2017/12/05(火) 19:33:35.46

未定義だけどvirtualじゃなきゃ大抵動く
だからNULLチェックも意味がある