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/07/19(水) 22:25:28.38

>>823
あそれか
落ちてる理由はそこな気がしてきた...

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd94-qcL/) · 2017/07/19(水) 22:25:41.24

あっ、それからC++からC言語の関数を定義・参照するにはextern "C"を付けないといけない。

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd94-qcL/) · 2017/07/19(水) 22:31:08.38

C++関数のシンボル名は「mangling」によって変な名前になり、コンパイラーによって違うから(標準化されていない)、DLLでは使いづらいので、C言語関数にすることが多い。

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd94-qcL/) · 2017/07/19(水) 22:39:22.35

DLL内部の輸出関数にextern "C"を付けてC言語関数にする。
関数ポインター型をtypedefする。
DLLをダンプして関数シンボル名を確認する。

2017/07/19(水) 22:41:38.53

>>825
C言語の関数を定義参照するってのは.cファイルが出てきたときの話よね？

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd94-qcL/) · 2017/07/19(水) 22:43:26.89

コンパイラーによって違うが、C言語関数が__cdeclのときは、そのシンボル名は先頭に下線が付き、__stdcallのときは関数名そのままだったかと。

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd94-qcL/) · 2017/07/19(水) 22:46:12.04

>>828
C++でDLL関数を参照するときは、DLL関数がC言語関数でないと、シンボル名がややこしくなって、GetProcAddressが難しくなるよ。ダンプすればシンボル名が確認できる。

2017/07/19(水) 22:51:10.86

>>830
CでもC++でも構わないのだけどその関数のなかでクラスを呼ぼうとしてるのだけど可能なのだろうか？？

>>829も少し気になったのだけど
__stdcallしてたのにリンカエラーの時に__cdeclのリンカエラーが出ていた

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd94-qcL/) · 2017/07/19(水) 22:54:29.77

スタートメニューのVSの項目に、「なんちゃらコマンドプロンプト」というのがあるはずだ。
ソイツを起動すると黒い画面が出て来て、キーボードで「CD」コマンドで対象のフォルダに移動。
dumpbinに適当なコマンドライン引数を付けてEnter。

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd94-qcL/) · 2017/07/19(水) 22:56:32.59

>>831
DllMainにも__stdcallが必要。

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd94-qcL/) · 2017/07/19(水) 22:59:03.92

>>831
関数の引数と戻り値がC言語関数に見えれば中身C++でもOkay。

2017/07/19(水) 22:59:52.02

>>834
そうなんだ
じゃあextern cつけておいた方が安全みたいなのね
名前解決しやすいかしにくいかの話になるんだね

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd94-qcL/) · 2017/07/19(水) 23:00:31.80

__stdcallやWINAPIなどを付けなければ、デフォルトで__cdeclになる。

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd94-qcL/) · 2017/07/19(水) 23:02:59.40

コンパイラーによってはデフォルトの呼び出し規約を変更できるかも知れない。

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd94-qcL/) · 2017/07/19(水) 23:07:11.36

複数の関数を、extern "C" { ... } で囲ってもいいし、関数の直前にextern "C"を付けてもいい。

2017/07/19(水) 23:10:05.85

>>838
個々につけた方が明示的で良いように思ったので個々でつけることにします
dll難しい....

linuxのsoファイル作成のソースコードと、winのdll作成のコードを共通化しようとしたら
defineで切るしかない？？

2017/07/19(水) 23:14:11.62

質問ばかりで申し訳ないけどもヘッダファイルって作られないのかな？

dll側で定義した関数を公開するときにインポートライブラリで読み込ませるならばヘッダファイル必要になると思うのだけど
それは自身で作成することになる？？

2017/07/19(水) 23:16:07.85

>>839
Boost.DLLを使う

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd94-qcL/) · 2017/07/19(水) 23:17:50.12

>>840
Unmanaged C/C++では、慣習として、公開するヘッダーファイルは自分で書かないといけない。
それは公開する範囲を決める意味で重要な作業になる。

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd94-qcL/) · 2017/07/19(水) 23:25:33.39

WinMainやDllMainなど以外で自分で作った関数については、WINAPIよりもAPIENTRYを使うのがマナー。

2017/07/19(水) 23:28:24.94

>>843
なんだそのAPIENTRYというのは

>>841
さらに知らない単語も出てきた

2017/07/19(水) 23:30:05.93

もう面倒だからC#で作れよ

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd94-qcL/) · 2017/07/19(水) 23:32:25.59

<windows.h>の中身を覗いてみると、Win32APIの流儀が見えてくる。時間泥棒かも知れないが、それが面白い。

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd94-qcL/) · 2017/07/19(水) 23:35:11.33

Boostという準標準ライブラリ群があって、Boost.DLLはその一部。APIENTRYマクロはWINAPIマクロの別名。

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd94-qcL/) · 2017/07/19(水) 23:39:27.90

面倒なのが嫌なら最初からC#使え。C++は素人が来るところではない。

2017/07/19(水) 23:46:25.94

>>845
開発でC++が必須なんだ..

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd94-qcL/) · 2017/07/19(水) 23:50:31.02

で、問題は解決したか？

2017/07/19(水) 23:52:51.09

それはいいけどググればすぐ解決する程度の問題をわざわざ人に聞くべきではない

2017/07/20(木) 00:02:01.05

ググれってよく見るけど、最近はググった結果がQiitaとかで余計わからなくなる人いそう

2017/07/20(木) 00:26:00.45

>>851
ぐぐった結果色々な方法がありすぎてどれが正しいか判断つかなくてここにきた

>>850
今は自習中
明日の業務で試してみます

2017/07/20(木) 00:35:16.57

色々は無いでしょ

2017/07/20(木) 11:41:47.84

>>846
<windows.h>の中身を覗いてMSの片鱗を味わったがsmallに引っ掛かって1時間ほど時間を潰した
どうしてくれるんだ

2017/07/20(木) 19:54:56.95

>>853
ひょっとしてまだやってるのか？
方法1：
1. 型をint (__stdcall *)(int,int) にする
2. GetProcAddressに渡す名前を"?AAA@@YGHHH@Z"の様な名前にする
　この名前はVisual Studio付属のコマンドで
　「dumpbin.exe /exports unko.dll」にて確認
　32ビットと64ビットでは名前が異なるので注意
方法2：
1. 型をint (__stdcall *)(int,int) にする
2. テキストファイルunko.defを作り
EXPORTS
(TAB)AAA
と書いてプロジェクトのプロパティのリンク設定でこのファイルをモジュール定義ファイルに指定する

2017/07/20(木) 23:54:34.71

winapiの流儀とか見ていて吐き気を催す

2017/07/21(金) 00:44:29.75

WINAPIのtypedefされた型を元のプリミティブ型に書き直すのが趣味です

2017/07/21(金) 00:47:34.17

F12を叩きたいのか

2017/07/21(金) 04:01:38.56

extern "C" __declspec(dllexport) int __stdcall func(int,int){}
"?AAA@@YGHHH@Z"のような吐き気催す引数無くした名前だけ出力したい場合は extern "C" を前に付けると解決

2017/07/21(金) 07:00:36.74

http://qiita.com/YukiMiyatake/items/9c099041eab9ee8b349d
uniqu_ptrに頼って生歩使わないとか、
そんなだったらはじめからC++なんか使うな
アホはC++使うなって見本

>リソースを生で使うのはアンチデザパタです！
それがどーした。パターンでしか考えられないお前

2017/07/21(金) 07:42:02.40

えらいねー。

2017/07/21(金) 07:57:26.95

所有権を持った人が自分でnew deleteするってのは確かにもうあり得ないでいいだろう。
それを「生ポインタを使わない」と表現するのは言い過ぎというか誤解を生む。

2017/07/21(金) 08:46:52.32

生保使う場面ってどんな時だろ？

2017/07/21(金) 08:47:22.86

delete禁止構文欲しいぜ

2017/07/21(金) 08:49:46.05

生ぽは、その場で文字列生成して関数に食わせる以外は参照だなぁ。

2017/07/21(金) 08:54:06.32

>>864
nullptr受け取る可能性のある古臭い設計のコードを使うときじゃね？
自分で設計するときは使わん。

2017/07/21(金) 10:34:18.10

自分でnew deleteするなんて発想が無くなってきたから別にポインタ渡しに違和感ないけどな

2017/07/21(金) 11:14:02.61

設計的にどうなんだろう。

2017/07/21(金) 11:40:31.31

生ポインタは誰が資源管理するのか曖昧になるからよくない、って主張は昔はあったと思う。
いまソースコードを検索してnew もdeleteも見当たらないという状況なら、そんなのはもう
忘れていいと思う。

2017/07/21(金) 12:08:08.05

例外が発生したときの後始末なんかもきちんとしようと考えると面倒くさいし、
スマートポインタは積極的に使うべきなんだろうな。

2017/07/21(金) 12:40:47.73

Qtみたいな自分でnewはするけど親オブジェクトがdeleteしてくれるようなものもある

2017/07/21(金) 17:13:44.75

unique_ptrとか中身リファレンサだろうしリファレンサとかクラスで自己実装しちゃうけどね

2017/07/21(金) 17:16:06.65

あ、unique_ptrは複製が効かないポインタか
shared_ptrと混同していたorz

2017/07/21(金) 17:18:37.74

でもイラネな
unique_ptrでメンバ全部実装やるとアタマ狂うだろ多分

2017/07/21(金) 18:24:31.33

いらないとか使わないとか言いつつ、実のところ、理解できなくて使えません、って人を現場で何人も見てきたよ。

2017/07/21(金) 18:39:26.01

うちのプロダクションコードほぼ100%はユニポだよ
リファレンスはそこらじゅうでもってるけど

2017/07/21(金) 18:56:21.10

>>876
なんでそんなやつを雇ったんだよ

2017/07/21(金) 19:36:52.29

>>878
人手不足なんじゃね？
俺が雇ったわけじゃないし、派遣さんとかだと法律上選べないでしょ。

2017/07/21(金) 21:20:11.09

誰も触れないけど、delete[] だよな？

まぁ、さておき、new使うか？
オレnew自体ほとんど使わないんだけど。。。
組み込み系だとやっぱ使うのかね？
メモリ管理なんて、スタック上とか、コンテナに任せちゃえば、いいとおもうんだ。

2017/07/21(金) 21:43:07.75

いいと思うよ
今のバージョンではnewを使わせるライブラリ以外で使う状況が無い

2017/07/21(金) 22:02:26.89

make_uniqueとmake_sharedが出来てからはな

2017/07/21(金) 22:10:51.61

templateでエラーが出された場合なんかでチェックするために
templateが展開された状態を見る手法みたいなのってありますかね？

2017/07/21(金) 22:26:33.98

make_sharedってカスタムデリータいれられたっけ？

2017/07/21(金) 22:50:57.29

Xcodeのビルドログ見たらほぼ>>883だったので>>883は取り下げます

2017/07/21(金) 23:09:04.52

使い方は解るよ
ただ、自転車の補助輪みたいだなと

2017/07/21(金) 23:15:13.65

そういうのより
std::vector<int> v;
↑これを右クリックして展開されたコードを表示するようなことがしたい

2017/07/22(土) 17:58:14.35

>>856
わざわざサンクス
全く同じことしたけども吐き気催すような名前はついたままだったからdefファイルで対応することにしたよ

2017/07/22(土) 19:30:56.71

わざわざマングルされたメソッド名をエクスポートなどせずともファクトリーメソッドにすれば良いのでは…
ファクトリーメソッド自体はextern "C"で逝ける
DLL側のコードで確保したメモリはDLL側で開放する（プロセス本体側のコードで確保したメモリはプロセス本体側で開放する）
という点は気おつけねばならないが

と流れを読まずにレス

2017/07/22(土) 20:49:40.35

ｽﾏﾝorz
誤：ファクトリーメソッド
正：アブストラクトファクトリーメソッド

アブストラクトファクトリーメソッドなら具象クラスのコードは全部DLLL側になるので安心
オブジェクトのdeleteもDLLL側でやるように関数を設けてDLLLからエクスポートしてそれを使う

2017/07/22(土) 20:53:28.27

DLLLL？

2017/07/22(土) 20:59:49.34

どぅるるる

2017/07/22(土) 21:12:32.20

DLLゲームというものがあり、この四つの規則だけでDIIをDLLに変換できるか、というのがパズルの主旨である

2017/07/23(日) 02:54:24.55

new,new[],delete,delete[]を定義すれば、全てDLL側で実装出来るでしょう？

2017/07/23(日) 11:16:55.64

CPUやOSに依存したいコーディング難しいよう

2017/07/23(日) 11:25:11.61

依存姿態？

2017/07/23(日) 11:26:02.43

>>896
しないだった

2017/07/23(日) 12:41:00.33

エンディアン
charのサイズ
負の数の表現方法

この辺がくせ者

2017/07/23(日) 12:43:24.45

符号付整数の右シフトとwrap aroundは未定義動作
だがあんま認識してる人が居ないという

2017/07/23(日) 12:47:13.35

charが16bitや32bitだと、
8bit単位のデータを扱うのが非常に面倒
現実的にはパック形式も必要になるので

2017/07/23(日) 12:48:45.60

負の数もいろいと
00...0はトラップ値だったり

2017/07/23(日) 12:49:28.11

80...00の間違い

2017/07/23(日) 12:50:38.60

near farとか
各種pragmaとかアラインメントとか

機種依存しないコードなんてのは実際には妄想

2017/07/23(日) 12:52:19.16

使用可能リソースがそもそも違う

2017/07/23(日) 14:01:31.88

stdintじゃいかんの？

2017/07/23(日) 14:22:24.82

それで何が解決する？

2017/07/23(日) 14:38:32.39

そういうのは必要な人がパッチを書けばいい
プロジェクトのメインの開発者は一般的なPC用CPUだけ想定していればいい

2017/07/23(日) 15:01:31.12

組み込み機器を完全に無視した発言

2017/07/23(日) 16:52:13.50

エンディアンへの注意と
sizeof演算子への注意と
unsignedか否か
この辺を注意すればまずは良いんだね

2017/07/23(日) 16:57:12.36

互換性のポリシーをはっきりすること
最近のPCだけならエンディアンやアラインメント、charのサイズやintのサイズは関係ないし
汎用なら>>898も考えないと

2017/07/23(日) 17:23:53.30

難しいな
色々なPCで動作させようとするのは

ところでdllでもsoでも使えるようなコード書きたいんだけども
呼び出し部分だけifdef切るのとソースコード自体わけるのとどちらが良いんだろ？

2017/07/23(日) 17:27:19.50

dllと言えばdllの呼び出し口以外の内部で完結してるような関数ってどうやってテストするんだろう
俺それやったことねえや

2017/07/23(日) 18:02:24.35

そもそもpublicでないものをテストする必要は無い

2017/07/23(日) 18:04:39.20

日本は未テスト納品が当たり前だからな。

2017/07/23(日) 18:10:47.08

>>913
パブリックでなくとも動作検証は必要ではないか？って思い始めた
関数単位でのテストが積み重なって一番大きなdllのテストに移る的な

設計上に多重継承が現れたんだけど多重継承って設計的にどう？？

2017/07/23(日) 18:20:48.79

テストの目的にもよるな。
仕様に対する保証という意味でならば当然公開しないものはテストの必要がないが、
開発するうえではモジュール毎にテストできた方が問題の発見に役立つし。
テストコードはスタティックリンクするのがお手軽なんじゃないかな。

2017/07/23(日) 18:39:25.88

>>915
多重継承は気をつけて使えば問題ない

2017/07/23(日) 18:52:38.36

>>916
俺の意図的にはそんな感じだね
関数ごとにテストして品質を担保する的な
ただdll内で呼ばれている関数を静的リンクできるん？？

>>917
気を付けるのが難しそう
よくよく考えたら多重継承ではなくクラスの中でクラスを定義する方が自然だった

2017/07/23(日) 19:04:55.28

継承をextendとして使う場合は多重継承しやいほうがいい

2017/07/23(日) 19:26:40.53

>>918
>ただdll内で呼ばれている関数を静的リンクできるん？？

objで取り込むかlibかソースか、やり方はいろいろあるだろうけど普通にできるでそ。

2017/07/23(日) 19:32:13.78

書いたらテスト、これ常識
関数単位ぐらいの細かい単体テストは、呼び出し元込みの結合テストで境界条件を尽くせる（それぐらい簡単な関数である
という論理的見通しがある場合のみ省略できる
>>913は常に書きっぱなしでテストしないと宣言しているに等しい

>>918
dll内の関数のテストはソースファイルを単体テスト用のプロジェクトと共有して単体テスト用のプロジェクトでやるとか、
dll内にテストコードを埋め込んでテストしてテストが終わったら#if/#endifで切り離す
みたいな

2017/07/23(日) 19:47:00.96

単体テストってGoogleテストとかのドライバ的なやり方をさしてんのか？
それともvisual studioに機能としてついてるやつをいってんのか？

2017/07/23(日) 20:14:53.55

>>899
>符号付整数の右シフトと (中略) は未定義動作
右？
それは規格のどこに書いてあるのですか？