【初心者歓迎】C/C++室 Ver.102【環境依存OK】

**デフォルトの名無しさん** · 2017/11/04(土) 16:33:35.07

エスケープシーケンスやWin32APIなどの環境依存なものもOK
そのような質問は必ず環境を書きましょう
半角空白やタブでのインデントはスレに貼ると無くなります

コードを貼れる所
http://codepad.org/
https://ideone.com/

前スレ
【初心者歓迎】C/C++室 Ver.101【環境依存OK】
https://mevius.5ch.net/test/read.cgi/tech/1500329247/

**はちみつ餃子** ◆8X2XSCHEME · 2018/06/02(土) 19:06:46.84

>>801
Yes。テンプレートはヘッダファイルに書く必要がある。
同じ実体 (テンプレート引数も同じなテンプレート) はリンク時に統合されるので、
最終的な実行ファイルに複数の実体があったりはしない。

**デフォルトの名無しさん** · 2018/06/02(土) 19:21:25.63

>>802

ありがとうございました。

ちょっと理解できないと思うので、あきらめて

http://codepad.org/ABfo8I3a

としたところビルドできました。

ありがとうございました。

**デフォルトの名無しさん** · 2018/06/02(土) 19:22:03.75

>>803

ありがとうございました。

**デフォルトの名無しさん** · 2018/06/03(日) 17:10:25.43

ヘッダファイルについて質問です。

assert() が使いたいため、「List2.h」内に、以下のように書いたとします。

#pragma once
#include "List.h"
#include <cassert>

実は、「List.h」内にも#include <cassert>が書いてあります。

ヘッダファイルにはすべて#pragma onceを書いているので多重インクルードについて
問題はないと思います。

そこで質問なのですが、「List2.h」内で assert() を使っているため、自分としては、
必要ありませんが、「List2.h」内にも#include <cassert>を書いた方が分かりやす
いのではないかと思いました。

既にインクルードされていてもあえて、#include <> を書くという人はいるのでしょうか？

それとも、既にインクルードされていることに気付いている場合には、できるだけ
#include <> は書かないほうがいいのでしょうか？

◆QZaw55cn4c · 2018/06/03(日) 17:20:14.25

>>806
すでにインクルードされているかどうかは書いているときにはわからない、から書いとく

ただヘッダは分割コンパイルにおいて共用するデータだけを書いておくものだから
ヘッダ List.h に #include <cassert> が含まれているのは、一見、疑問だと思った

しかしテンプレート関数に assert() が入る場合があるのだから、こういったこともあり得るのかもしれないが、まだ私は体験していない…

**デフォルトの名無しさん** · 2018/06/03(日) 17:34:16.61

>>807

ありがとうございます。

＞ただヘッダは分割コンパイルにおいて共用するデータだけを書いておくものだから
＞ヘッダ List.h に #include <cassert> が含まれているのは、一見、疑問だと思った

ここのところがよく理解できないのですが、

List.h にテンプレートクラス List<T> が書いてあって、
List2.h には List<T> を継承したクラス List2<T> が書いてあります。

そして、List.h, List2.h の両方で assert() を使っています。

◆QZaw55cn4c · 2018/06/03(日) 17:36:57.15

>>808
うんうん、なるほど
テンプレートに assert() が含まれているのならば、ヘッダに #include <cassert> が入るのも止むを得ないです

**デフォルトの名無しさん** · 2018/06/03(日) 17:47:06.72

>>809

ありがとうございました。

また質問で申し訳ないのですが、今度は、全く違う質問になります。

一方向リスト用のセルである Cell<T> というクラスを作りました。
Cell<T> のメンバ変数は、

T data
Cell<T> *next

です。

List<T> には、一方向リストの先頭のセルを指すメンバ変数 Cell<T> *head およびリストに挿入したり、
リストから削除したり、リストのサイズを返したりする様々なメンバ関数があります。

List<T> は一方向リストでしたが、List2<T> は双方向リストにしたいとします。

オブジェクト指向プログラミングでは再利用が重要ということなので、
新たに、双方向リスト用のセルを作るのではなく、 Cell<T> を継承して Cell2<T> というクラスを作ることにします。
Cell2<T> には新たにメンバ変数 Cell<T> *prev を追加します。

List2<T> のほうも List<T> と共通で使えるメンバ関数があるため、再利用したいとします。その場合、気持ちとしては、
List<T> のメンバ変数 Cell<T> *head は無効にして、新たに、 Cell2<T> *head と Cell2<T> *tail をメンバ変数に
したいです。

そして、Cell2<T> に対しても使えるメンバ関数はそのまま使い、双方向リストにしたことにより、より効率的に実装できる
メンバ関数については、オーバーライドしたいです。

上記のようなことをどうやって実現したらよいのか分からないのですが、可能でしょうか？
可能だとして、こういうやり方は非推奨でしょうか？

**デフォルトの名無しさん** · 2018/06/03(日) 20:55:43.49

一方向・双方向リストの、ソースコードを見た方が速い

繰り返しを表す、C++ iterator みたいな、
抽象クラス・インターフェースでも使っているのだろう

**デフォルトの名無しさん** · 2018/06/04(月) 08:19:48.74

再利用など考えず
一から好きなように双方向リストを作れ

>オブジェクト指向プログラミングでは再利用が重要

は幻想

この場合で言ったらまったく逆で
もともと何か双方向リストがあって、継承して機能制限をして一方向リストに仕立て上げるなら分かるが
一方向リストを継承して双方向リストにするなどイカれてる

**デフォルトの名無しさん** · 2018/06/04(月) 09:50:25.37

>>810
一方向リストと双方向リストでどれ程共通的な処理があるのか知らんけどCellBase<T>に共通的な処理を定義してそれからCell<T>とCell2<T>を継承させるのが普通じゃね？

**はちみつ餃子** ◆8X2XSCHEME · 2018/06/04(月) 13:04:55.31

どうだろう。
総合的な判断が必要という前提はあるけども、
継承が妥当なときの基準のひとつに「is a 関係であるか？」ってのがあるよね。
XはYの一種であると言えるときはXはYを継承していい。
双方向リストは一方向リストの一種であるかというと、まあ Yes って呼んでいいんじゃないの。

ただ、それで楽に使いまわしが出来るかというとそうでもないこともあるので、楽なように作ればいいよ。

練習でやるのなら、使いまわしは置いてそれぞれを作ってみた上で、
共通な部分を探してデザインしなおしてみるというのもいいんじゃないかな。

クラス定義自体は継承関係を持たずにトレイトの方で性質を定義したりとかいったことも今どきはよくやるし、
将来的にコンセプトが入ったらそっちが主流になるかもしれん。

**デフォルトの名無しさん** · 2018/06/04(月) 13:18:55.79

>>812
もともと何か一方向リストがあって、継承して機能追加をして双方向リストに仕立て上げる
これはダメなん？継承は機能追加ダメなん？

**デフォルトの名無しさん** · 2018/06/04(月) 13:19:07.80

>>811

ありがとうございました。

>>812

本を見ると再利用が重要と強調されているので、拘ってしまいました。
ありがとうございました。

>>813

ありがとうございました。

**デフォルトの名無しさん** · 2018/06/04(月) 13:20:24.25

>>814

ありがとうございました。

**デフォルトの名無しさん** · 2018/06/04(月) 13:43:52.15

>>815
>>812はだいぶイカれてるから触らないで

**デフォルトの名無しさん** · 2018/06/04(月) 14:30:56.26

>>810
単方向リストから双方向リストを派生させると、内部構造が違うから相違を埋めるのに面倒臭い事になる
派生した双方向リストから単方向リスト内部のノード列にアクセスできたとしても
単方向リストの状態は単方向でノードが繋がっているのだから双方向リストからどうこうはできない
結局の所、双方向用のノードを単方向用ノードにアップキャストしないと格納できないし、取り出すにはダウンキャストしないといけない
もし何とかして単方向リストに双方向用のノードを双方向に数珠繋ぎ出来たら、そのリストはもう双方向リストだよ
あと、insert()の問題もある、std::forward_listの持つinsert_after()が何故そうなのかは構造的に一目瞭然でしょ
厳密に言えば、std::forward_listはコンテナ要件を満たしていないしな

単方向も双方向もLinked Listとして構造的に似ているが効率的に見ても構造的に見ても別のデータ構造だよ
is-aの関係ですら無いし、再利用ってのはhas-aの関係を考えるべきで、継承は再利用するためのものではないよ
例えば、皆、std::stringをhas-aで利用するよね、std::stackはstd::vectorやstd::listなどのアダプタだよね

**デフォルトの名無しさん** · 2018/06/04(月) 16:46:27.38

自分の勉強用だったら、継承した双方向リストクラス作ってみて
「やっぱ普通に作った方が簡単にできたな」って経験をするのもいいと思う
よく「オブジェクト指向はこうだから」って言葉にこだわって面倒くさいことしてる人いるけど
プログラムの基本としては「わかりやすさ」「シンプルさ」こそこだわった方がいいと思うから
将来拡張予定がないプログラムなんかだと無駄な継承しない方がいい

◆QZaw55cn4c · 2018/06/04(月) 19:05:36.84

キーワード「継承」もずいぶんと評価が落ちたものですねえ…

**はちみつ餃子** ◆8X2XSCHEME · 2018/06/05(火) 02:58:20.15

C++ からクラスが無くなることは無いだろうが、
構成の仕方の流行はだいぶん変わってて、
コンセプトが入ったら一気に再編されるかもしれない。

クラスの継承ってそんなに万能じゃないよ。

**デフォルトの名無しさん** · 2018/06/06(水) 12:11:26.28

ま、そういうことです
単方向リストを継承して双方向リストにするのは悪手
やってみるまでもなくわかるだろJK
結局ほぼすべてのメソッドを上書きしないといけないから意味ない
しかも一から双方向リストを書いた方が分かりやすいし速い

**デフォルトの名無しさん** · 2018/06/06(水) 12:24:14.11

この場合、どうしても手抜きしたかったら
大は小を兼ねるの考えで、双方向リストのみを作って
単方向リストを使う場面でも双方向リストを使えばよい
それがベストだろうというアンサーがちらついてるからこそ、余計に
単方向リストを継承して双方向リストってのが悪手に見えるんよなぁ
余談だけどC++には　std::list　っていう双方向リストがあるけど単方向リストは提供されてないし
単方向リストなどその程度の扱い、必要ない

**デフォルトの名無しさん** · 2018/06/06(水) 15:11:28.97

>>824
>余談だけどC++には　std::list　っていう双方向リストがあるけど単方向リストは提供されてないし
std::forward_list など無かった

**デフォルトの名無しさん** · 2018/06/06(水) 18:07:41.59

>>824
いやあ、単方向リストはそれはそれで使い道はあると思うよ
大体、キャッシュに載り易くメモリ効率も良いstd::vectorで十分だけど
挿入操作を多用するならstd::listやstd::forward_listの方が良いよね
std::forward_listは、std::listよりも要素N個 x ポインタサイズ分のメモリ消費量を抑えられるし
イテレータを使ってO(1)で連続してpush_back()みたいなことも出来る、pop_back()みたいなことはO(1)で出来ないけどね

必要性を問うよりも、その特徴を理解して適切に効率的に使うことが大事なんじゃないかな
まあ、std::mapやstd::setは使うのを躊躇するけどな
O(log n)で値を取り出せて、イテレータでソートされた要素に順次アクセス可能を売りとするけど、メモリ効率が悪すぎる
他の言語のそれらが大体ハッシュテーブルで実装されているのを見るに連想コンテナはunordered系で十分な気もする

**デフォルトの名無しさん** · 2018/06/06(水) 19:32:54.16

言葉が足りなくて申し訳ない
俺もリンクリストを使うことは有るけど、大概切迫していてカリカリカスタマイズしたいときに使うものだから
汎用のテンプレートのリンクリストを使ったためしがない
一方向リストなら、なおのこと使わない

**デフォルトの名無しさん** · 2018/06/06(水) 20:16:30.41

単方向リストを継承して双方向リストを作ることは無いと思うけど、コンポジットすることはあると思う。
ゼロコストの原則の視点に立つと、単方向リストを実装に流用して、双方向リストを作成するのもあり。

**デフォルトの名無しさん** · 2018/06/06(水) 20:30:07.38

STLのコンテナにstd::unique_ptr突っ込むと、カスタムアロケーター使えないよな？

**デフォルトの名無しさん** · 2018/06/06(水) 20:32:29.81

>>826
O(1)で10個挿入したら、O(1)*10なんだから、結局O(N)じゃないの？

**デフォルトの名無しさん** · 2018/06/06(水) 20:34:19.38

もしかして、std::unique_ptrを突っ込むのがすでに間違いで、std::anyを使えってことなんだろうか。

**デフォルトの名無しさん** · 2018/06/06(水) 21:03:14.93

>>827
std::forward_listとそのイテレータだけでFIFOのQueueを実装できたりするよ
イテレータを介したinsert_after()になるから要素を入れるコストはイテレータのコピー分、std::queueよりも高くなると思うけど
std::queueはstd::dequeかstd::listを利用するから、std::forward_listで実装した方がメモリ使用量は少ない
単方向リストを使用して独自実装した方が低コストに抑えられると思うけどね

まあ、再利用も良し悪しって事だね

**デフォルトの名無しさん** · 2018/06/06(水) 21:09:23.87

>>830
ごめん書き方が悪かった、1つの要素の挿入にO(1)って意味ね
Linked Listは、挿入場所への移動にO(n)かかり、挿入にO(1)かかるから
最後の要素を指し示すイテレータを保持してたらpush_back()みたいなことも出来るよって話ね

**デフォルトの名無しさん** · 2018/06/09(土) 00:34:24.48

std::array の empty()メソッドって意味があるのか？と最近思ったので質問させてください
arrayは通常 array<int, 固定値>のように宣言してから使うと思うのですが、
empty()メソッドの戻り値は <int, 0> 以外は全てfalseでした。
つまり通常<int,(0より大きい整数)>で宣言して使う場合empty()はfalseしか返ってこない
気がするのですが、このメソッドは意味があるのでしょうか？

**デフォルトの名無しさん** · 2018/06/09(土) 05:56:11.66

>>834
テンプレートを使って異なる種類のコンテナに共通に使える処理を書くときに、他のコンテナ達と共通の関数を備えていると都合がいいからかなと思う。

**デフォルトの名無しさん** · 2018/06/09(土) 12:31:35.52

>>834
そのメンバの存在意味の有無に関わらず、コンテナ要件の1つだからね
他のオブジェクト指向言語でのインターフェイスや抽象クラスを用意していないだけで
コンテナとして共通の要件（インターフェイス）が設けられている
例えば、size()、empty()、begin()、end()など

本来、動的なポリモーフィズムをするためにインターフェイスや抽象クラスを設けるけど
vtableは高コストだから、ゼロオーバーヘッドの原則に則り使用していないのよ
まあ、コンテナ自体STLの1つだからオブジェクト指向的な機能は意識していなかったと思うけどね
余談だが、聞いた所によるとテンプレートって最初マクロで実現しようとしてたらしいね

**はちみつ餃子** ◆8X2XSCHEME · 2018/06/09(土) 12:50:19.63

具体的にコンテナに求められる要求はここでまとめられているので参考になれば。
http://ja.cppreference.com/w/cpp/concept/Container

クラスに求める要求を表現するための機能「コンセプト」は C++ の悲願としてずっと前から温められているのだけれど、
なかなか仕様に入らずに先送りされてるという状況。

**デフォルトの名無しさん** · 2018/06/11(月) 16:42:05.03

ファイルから読み込んだバイト列の先頭部分を参照して、
それがJPEGファイルなのか、PNGファイルなのか、などを判定したいのですが、
どの程度の判定をすればよいものなのでしょうか。
例えばJPEGファイルなら、先頭3バイトを{0xFF, 0xD8, 0xFF}とmemcmp()で十分なのでしょうか。

**デフォルトの名無しさん** · 2018/06/11(月) 16:50:15.52

十分かどうかは時と場合による

**放置された蟻人間** ◆T6xkBnTXz7B0 · 2018/06/11(月) 16:51:12.74

画像ファイルには、過去にいくつか脆弱性が確認されている。使用において、脆弱性の存在が致命的ならば、きちんとチェックすべきだし、
処理スピードを優先するなら、memcmpで十分。

**デフォルトの名無しさん** · 2018/06/11(月) 17:03:57.96

すいません、十分というのは、ファイルの破損や脆弱性関連は置いておいて、
他の形式の正常なファイルも拾ってしまわないかということです。
JPEGの場合、先頭の3バイトを判定すれば、他の正常なファイルが引っかかることはないのでしょうか。

**デフォルトの名無しさん** · 2018/06/11(月) 17:06:17.81

中身見ないなら、拡張子でもできそうだが

**デフォルトの名無しさん** · 2018/06/11(月) 17:12:32.50

3バイトをランダムなデータと比較する場合、1/16777216の確率で誤認する
ファイルを最後までパースして、JPEGデータとして読み込めるかどうかチェックするのが確実だが

**はちみつ餃子** ◆8X2XSCHEME · 2018/06/11(月) 17:40:03.88

>>841
POSIX には file コマンドがあってファイルの種類を判定できるけど、その実装はヒューリスティックだよ。
参考になるとは思うから読んでみるのもいいんじゃない？
ライセンス的に OK ならそのまま流用してもいいかも。

どの程度の精度で判定すべきかは状況によるので総合的に考えてとしか言えない。
例えば、 jpg ではないファイルが多数ある中から jpg を探すというような状況だったら、
先頭をちょっとだけ読んで jpg っぽかったら全部を読んで詳細に判定するというのでもいい。

ほとんどが jpg なのだったら、いちいち詳細に判定するのは速度的に遅くなるけど、それが許容できるのか、
許容できないのであればどの程度まで緩い判定にしていいのか、バランスの問題。

**デフォルトの名無しさん** · 2018/06/12(火) 12:54:07.45

なぜ多数から探すかどうかで判定方法が変わるのか

**はちみつ餃子** ◆8X2XSCHEME · 2018/06/12(火) 13:09:55.18

>>845
速度とかとのバランスだって書いてあるつもりだけど、わかり難かった？

**デフォルトの名無しさん** · 2018/06/12(火) 13:15:57.78

明らかに一致しない時は瞬時に判断出来る
ヘッダですぐにわかるので

jpgではあるんだけど
非対応フォーマットとか一部化けてて表示出来ないとか
そういう判断が難しい

**デフォルトの名無しさん** · 2018/06/12(火) 13:34:24.68

はちみつはJPGを扱ったことが無いってのがよく分かる

**はちみつ餃子** ◆8X2XSCHEME · 2018/06/12(火) 14:45:14.29

>>847
えっ？だからまずは先頭をちょっとだけ読んでみる (この判定だと false positive はあっても false negative はない) という話なんだけど。

**デフォルトの名無しさん** · 2018/06/12(火) 16:23:32.57

元の >>838 の質問に戻れば「どんなファイル群を扱うのかによる」としか
言いようがないんじゃないか?

極端な話、行儀の良いファイルだけなら拡張子で判定しても大丈夫。
(拡張子が間違ってるけど)一般的なファイルばかりなら先頭の何バイトかで判定。

悪意を持って偽装ヘッダや追加情報エリアまで利用してる可能性を気にすれば
JPEGの規格に準拠してるファイルでさえ危険、というレベルまであるかも。

**はちみつ餃子** ◆8X2XSCHEME · 2018/06/12(火) 16:44:07.95

ある程度は信じて割り切るしかしょうがない。

**デフォルトの名無しさん** · 2018/06/12(火) 17:43:08.97

JFIF以下のJPEG出す機材って監視カメラ以外見たことないなぁ
実運用上はJFIFとEXIF以外は対象外でも良いのかも

**デフォルトの名無しさん** · 2018/06/12(火) 17:56:59.93

ポインタでないなら、継承した関数を呼び出すときに、仮想テーブル参照による動的オーバーヘッドはないのですよね？

**はちみつ餃子** ◆8X2XSCHEME · 2018/06/12(火) 18:20:08.25

>>853
Yes

それが仮想関数であろうとも、
オブジェクトへのアクセスがポインタ経由でないならば
どの関数を呼び出すのかコンパイル時に確定可能なので、
仮想関数テーブルにアクセスする必要はない。

(はずだと思うが言語仕様での保証はないだろうし、
実態がどうなってるか確かめたことはないんで、
誰かやってみてくれんかな。)

**デフォルトの名無しさん** · 2018/06/12(火) 18:35:01.32

>>849
ファイル判別の一般論じゃなくてjpgの判別ですよ
jpgの判別方法を語ればいいんです

文字コードと違ってあやしいとかはなくて
APPnの中数バイト見れば簡単にわかるんですよ
文字でJFIFとかExifとか書いてあるわけなんで

偽装が無いならこれで十分

あとは
対応フォーマットであるのか
正しいフォーマットであるのか
実際にデコード出来るのかどうか
などを判別する必要があるかどうかでその先が決まる

**デフォルトの名無しさん** · 2018/06/12(火) 18:43:20.13

>>855
baka?

**デフォルトの名無しさん** · 2018/06/12(火) 18:57:45.80

>>854
ありがとうございます

**はちみつ餃子** ◆8X2XSCHEME · 2018/06/12(火) 20:19:36.50

>>855
何言ってんの？
その偽装があるかもしれん (ということも想定に入れるかどうは場合による) という話なんだけど。

**デフォルトの名無しさん** · 2018/06/13(水) 00:32:03.88

>>841を読んでの発言？
日本語が読めないの？

**はちみつ餃子** ◆8X2XSCHEME · 2018/06/13(水) 01:55:04.01

>>859
なるほど、偽装に騙されるのは脆弱性の内 (で、それはないという前提が提示された) という解釈？

判定を誤りうる (データを作れる) のとセキュリティ的な欠陥をなんとなく区別してたけど、
質問者の感じからすると、確かに偽装で騙されるのは脆弱性の内かな。

**デフォルトの名無しさん** · 2018/06/13(水) 01:56:34.26

>>855
JPEGの規格書を読んだ事が無いだろう

**デフォルトの名無しさん** · 2018/06/13(水) 07:50:57.05

昔ゲーム機のハックで偽装した画像ファイルを読み込ませるってのがあったような気がする。

**デフォルトの名無しさん** · 2018/06/13(水) 08:14:06.81

>>838 >>841 を合わせた質問の意図からすると、
JPEG以外で先頭3byteが {0xFF, 0xD8, 0xFF} のファイル形式が存在するか、
普通に出回ってるか? という問題じゃないのかな。

**デフォルトの名無しさん** · 2018/06/13(水) 09:42:34.58

ゲロトラップとして普通に出回ってないかね？

**デフォルトの名無しさん** · 2018/06/13(水) 09:46:09.42

テンポラリオブジェクトについて質問です。

ロベールの本ですが、

「
Hoge Two() {
Hoge n(2);
return n;
}

int main() {
Hoge hoge(1);
hoge = Two();

とした場合、基本的には n のコピーがいったん作られて、それが hoge に
代入される形になります。このコピーこそが、テンポラリオブジェクトになる
わけです。
」

と書かれていますが、なぜわざわざ n のコピーを作るのでしょうか？
n は Two() 関数を抜けたら消えてしまいますが、これを消さずに、
返した方が効率的な気がします。

**デフォルトの名無しさん** · 2018/06/13(水) 10:17:19.41

・テンポラリオブジェクト = n のコピー
・代入により、 hoge にテンポラリオブジェクトがコピーされる。

これはなんか非常に無駄なことをやっているように思ってしまいます。

hoge に捨てずにとっておいた n を参照させれば十分のように思います。

**838** · 2018/06/13(水) 10:17:36.81

みなさんありがとうございます。
話が難しい方向に進んでしまってすいません。
勉強させていただきます。

元々の疑問は>>863の言われるとおりで、
他の形式の画像をJPEGだと誤判定してしまわないか、
さらに言うと、先頭が{0xFF, 0xD8, 0xFF}以外のJPEGファイルも存在していて、
JPEGファイルを見逃してしまうことがあるのか、ということでした。

**デフォルトの名無しさん** · 2018/06/13(水) 14:58:14.75

>>865-866
そういう時こそ右辺値参照ですよ

hoge = std::move(Two());

でもこんな事をしなくても大抵戻り値最適化(RVOやNRVO)でコピーコンストラクタは呼び出されない
明示的にムーブコンストラクタを無効にするとコンパイルエラーが発生するはず

Hoge(Hoge&&) = delete;

**デフォルトの名無しさん** · 2018/06/13(水) 14:59:33.86

そしてこの場合代入演算子をオーバーロードしてやるとそちらが使われる

Hoge& operator=(const Hoge& hoge) {
　 std::cout << "assign operator called." << std::endl;
return *this;
}

**デフォルトの名無しさん** · 2018/06/13(水) 20:08:20.11

（最適化をおいとくと）値渡し/値返しってそういうもんじゃん
Two()内の変数nは自動変数だからスタックに作られる
とっとけないじゃん

**デフォルトの名無しさん** · 2018/06/13(水) 21:00:21.79

まあ2回コピーされるのを1回に抑えるための最適化でしょう

**デフォルトの名無しさん** · 2018/06/13(水) 21:08:53.19

確実なのは戻り値じゃなくて参照、もしくはポインタにすること

**デフォルトの名無しさん** · 2018/06/13(水) 21:40:28.10

>>872
それヤバくね？関数を抜けた途端消える存在を参照するとか

**デフォルトの名無しさん** · 2018/06/13(水) 22:09:20.49

呼び出し元から参照を渡してそこに返してもらえってことじゃなくて？

**デフォルトの名無しさん** · 2018/06/13(水) 22:13:11.63

もちろんそう
昔ながらの方法

**デフォルトの名無しさん** · 2018/06/13(水) 23:23:40.79

-Wreturn-local-addr みたいなwarningじゃなくて規格でエラーにすれば873みたいな勘違いは無くなるのにな

**デフォルトの名無しさん** · 2018/06/14(木) 10:53:47.52

普段c#使っているのですが、c++/cliでデータベース絡みのdllを作ってて、わからないことがあります。
SqlConnectionやDataSetのDispose()がインテリセンスでは候補に上がるのに、コンパイルで「メンバーではありません」とエラーになります。
スコープを抜けると破棄されるので何もしなくてよいという認識でよいのでしょうか？
また、この理屈で、c#の勝手に破棄してくれるusing相当の機能はない、と言うか、必要ないのでしょうか？

**デフォルトの名無しさん** · 2018/06/14(木) 14:30:10.48

>>877
IDisposable使ってる？
スコープ抜けてもGCによって回収されるタイミングは保証できない
どうしてもすぐにGCしたいなら

GC.Collect();

をする。

多分ジェネレーション0だろうから

GC.Collect(0);

でいいのでは

**デフォルトの名無しさん** · 2018/06/14(木) 15:24:59.55

>>878
レスをござます。
作ってるクラスがIDisposableを継承しないとダメってことですか？
作ってるのはインスタンス作らなくてもいいstaticクラスなんですけど。

GCは効果の程を確認できないですが、やってみます。

**デフォルトの名無しさん** · 2018/06/14(木) 15:25:54.47

>>879
レスありがとうございます。です。

**デフォルトの名無しさん** · 2018/06/14(木) 16:42:09.02

>>879
https://qiita.com/haniwo820/items/ba0ab725c25673c20338
こんなのとか

staticクラスだとファイナライザーを書けないから内部で他のクラスをnewした場合が問題
それとメンバ変数もstaticでなければならない
となると普通はアプリケーションが破棄されるまで残る

IDisposableをstaticクラスが継承するとエラーになる
というかstaticクラスはインターフェイスを継承できない
むしろusingを使えない理由が分からない

http://ufcpp.net/study/csharp/oo_dispose.html

こういうのだとstaticクラス風にファイナライザーを走らせられる

それかStreamみたいのでClose()したいのならClose()メソッドを書けばいい
SqlConnectionやDataSetはいちいちClose()する必要があるのかな？

**デフォルトの名無しさん** · 2018/06/14(木) 22:51:20.07

>>877
ここの記述を信じるなら、全部Yesってことになるのかな。
http://mag.autumn.org/Content.modf?id=20050506023118

**デフォルトの名無しさん** · 2018/06/15(金) 09:10:59.15

>>879 です。
VS2013 c++のCLRコンソールアプリを新規作成したやつです。

include "stdafx.h"

using namespace System;
using namespace System::Data;
using namespace System::Data::SqlClient;

int main(array<System::String ^> ^args)
{
Console::WriteLine(L"Hello World");

String ^constr = "xxxxx";
SqlConnection ^connection = gcnew SqlConnection(constr);

connection->Open();

connection->Close();
connection->Dispose();

return 0;
}
この Disposeでエラーになります。
ここには書いてませんがDataSetも
Disposeでエラーになります。

上記コードの場合 Dispose抜きで問題ないのでしょうか？

>>882
まさにこれを読みました。c#のusingがc++にはない認識です。
この理由がこの通りならDisposeなしで心配ないのですが。

**デフォルトの名無しさん** · 2018/06/15(金) 10:38:59.49

共同ツール 1
https://seleck.cc/685

https://trello.com/
ボードのメニュー → Power-Upsから拡張可能 Slack DropBoxなど
Trello Chrome拡張機能　elegant
ttp://www.kikakulabo.com/service-eft/
trelloのオープンソースあり

共同ツール 2
https://www.google.com/intl/ja_jp/sheets/about/

共同ツール 3
https://slack.com/intl/ja-jp
https://www.dropbox.com/ja/
https://bitbucket.org/
https://ja.atlassian.com/software/sourcetree
https://www.sketchapp.com/
ttp://photoshopvip.net/103903
ttps://goodpatch.com/blog/sketch-plugins/

Trello Chrome拡張機能プラグイン集
https://chrome.google.com/webstore/search/trello?_category=extensions

Slackプラグイン集
https://slack.com/apps

Sketchプラグイン集
https://sketchapp.com/extensions/plugins/
https://supernova.studio/

**デフォルトの名無しさん** · 2018/06/15(金) 19:01:40.09

>>882によると、自動でDisposeさせたい場合は以下のようにする、
と書いてあるように見える。(手元に環境がないので未確認)

SqlConnection connection(constr);
connection.Open();
connection.Close();

**デフォルトの名無しさん** · 2018/06/16(土) 06:42:53.11

>>883
そのコードでconnection->Dispose();を消すだけだとDisposeは呼ばれない。
C++/CLIでDisposeを呼びたい場合「delete connection;」と書く。
C#のusing相当のことをしたい場合は>>885
詳細は↓を参照。
https://loafer.jp/mixi/diary/class.xsp?2007-09-07-23-55

**デフォルトの名無しさん** · 2018/06/18(月) 12:02:02.44

Dispose の件で質問してた者です。
自作のIDisposableを継承したクラスを作って確認したところ delete で Disposeが通る事を確認できました。
不慣れで詰まらない質問してしまってすみませんでした。

**865** · 2018/06/20(水) 12:43:56.50

みなさん、いろいろありがとうございました。
参考にさせていただきます。

ところで、

Cとアセンブリ言語で学ぶ計算機プログラミングの基礎概念 - プログラムはプロセッサ上でどのように実行されるのか
角川裕次
https://www.amazon.co.jp/dp/4627848315/

この本を読んだ人はいますか？

かなり自分にとって理想的な本のようですので、買ってみようと思います。
こういう本を読めば、少しは言語の設計者の気持ちが分かるようになるのではないかと期待します。

**デフォルトの名無しさん** · 2018/06/22(金) 23:22:38.51

あちらこちらでC++はひどい言語だって叩かれてるけどその割に広く使われている
つまりこれはC++を頑張って覚えればその分見返りも大きいということではなかろうか。なにしろ人の嫌がること高いスキルが必要なことはそれだけ報酬も高いはずで

◆QZaw55cn4c · 2018/06/23(土) 00:11:02.67

C++ はひどい言語だ。これは、多くの平均以下のプログラマーが使ってるために
さらに輪をかけてゲロゲロになっていて、どうしようもないゴミが
簡単に生産されるようになってる。正直いって、C を選ぶ理由が C++ プログラマーを
追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。

C++ はトンでもなく悪い設計の元になりうる。どうせこの言語ではいつも STL やら
Boost やら、その他ゲロゲロベロベロの「素敵な」ライブラリの機能を使って、
それがあんたのプログラムに「役立つ」んだろうが、以下のことが起きる:

- うまく動かないときにもたらされる際限のない苦痛 (あと STL とか、特に Boost が
安定してるとか移植性があるとかいう奴は、どいつもこいつも大ウソつきで、
もはや笑えるレベルを超えている)

- 非効率な抽象プログラミングモデルで、2年たった後にこれらが実はそんなに
効率的じゃなかったことに気づくケース。でもそのときにはすでに全部の
コードがその素晴らしいオブジェクトモデルに依存していて、直すためには
アプリ全体を書き直さなきゃなんない。

言いかえれば、唯一まともで、効率がよくて、システムレベルで使えて、移植性がある
C++ ってのは、基本的に C で使える機能だけに限ったときなんだ。そして C だけに
限定するってことは、他の人がそれをめちゃくちゃにしないってことで、
ついでに沢山のプログラマが実際に低水準の問題を理解することができて、アホらしい
「オブジェクト・モデル」のたわごとを持ちこまないってことだ。

**デフォルトの名無しさん** · 2018/06/23(土) 10:31:52.34

抽象化とコード(バイナリ)の質は相反するものだから

**デフォルトの名無しさん** · 2018/06/23(土) 11:45:24.39

alignas(32)とかalignas(64)とかつけなくても大体アライメント揃ってる気がするんですけどつけた方がいいんですか？

**デフォルトの名無しさん** · 2018/06/23(土) 12:58:59.14

リーナスのそれがいっちばん有名なC++批判よね

◆QZaw55cn4c · 2018/06/23(土) 13:53:36.35

>>893
linus は昔から C++ を批判していたが、git 開発に関する 2009 年のこれが、最も効果的な批判になっていますね
これを読むと C++er は一瞬自分がわからなくなりゲシュタルト崩壊に陥りますね、もう c++11 over を追いかける気力も失せてしまいました…

**デフォルトの名無しさん** · 2018/06/23(土) 14:43:13.01

抽象的な思考ができる人とそうでない人が居るというだけだな
>>890もSTLやboostの使い方が理解できない、良い抽象モデルが作れない人が愚痴ってるだけにしか読めんが

**デフォルトの名無しさん** · 2018/06/23(土) 14:54:08.05

抽象化が目的になって
パフォーマンスとか使用リソースとか工数を軽視する人が実務経験の浅い人に多い

ってのが問題であって
言語自体には罪はない

◆QZaw55cn4c · 2018/06/23(土) 15:32:24.63

>>895
＞良い抽象モデル
が役に立つとは限らないのでは？
抽象化を目的とするあまりに YAGNI を忘れてしまうのでは、これは重大な思考的欠陥なのでは？
あれほどもてはやされていた GoF は、すくなくとも C++界では、もうみるかげもなく凋落の一途をたどっているのは、どうみるのでしょうか？

**デフォルトの名無しさん** · 2018/06/23(土) 16:46:26.83

デザインパターンって廃れたんですか？

だとすると、なぜ、デザインパターンは流行り、そして廃れたのでしょうか？

一度は流行ったということは確かに役に立つものだったのではないでしょうか？

一度は役に立つと認められたものがなぜ、否定されたのでしょうか？

**デフォルトの名無しさん** · 2018/06/23(土) 16:51:17.93

日本人は基本すっ飛ばして銀の弾丸欲しがるからな

**はちみつ餃子** ◆8X2XSCHEME · 2018/06/23(土) 17:00:49.94

>>898
デザインパターンってのは典型的なパターン (に名前を付けたもの) ってだけだよ。
基礎として押さえておくと便利だし、価値が失われたわけではないけど、
何もかもが既存のパターンに当てはまるわけではないという当たり前の話。

**デフォルトの名無しさん** · 2018/06/23(土) 17:15:09.64

>>897
抽象化とYAGNIは関係ありません
こういう意見が出てくるあたりが良いモデリングを理解してない証拠ですね

**デフォルトの名無しさん** · 2018/06/23(土) 17:29:02.45

>>898
別に廃れたわけではなく、使われるものは当たり前に使われてて取り立てて言われなくなっただけ。