C++相談室 part135

2018/03/31(土) 20:20:06.25

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

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

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

このスレもよろしくね。
【初心者歓迎】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

2018/05/02(水) 14:47:38.93

>>494
複数のプロジェクトで使いまわせる

>>495
スマポ(かコンテナ)で大体のnewは回避できる
そのケースも回避できる

**デフォルトの名無しさん** · 2018/05/02(水) 15:02:47.22

>>495
別にnewしなくてもよくね？
なんかサンプル出してみ？
new無くしてやっから

2018/05/02(水) 16:18:42.29

>>497
class CTest
{
　CFoo cfoo;

　void CTest()
　{
　　cfoo = new CFoo();
　}
};

こんなんとかどうでしょう

2018/05/02(水) 16:23:28.41

>>498

class CTest
{
　CFoo cfoo;

　void CTest(): cfoo()
　{
　}
};

メンバ初期化子知らんのか

2018/05/02(水) 16:28:43.53

山口メンバーも初期化できたらいいのに

2018/05/02(水) 16:29:15.41

ヤバいなジャバ上がりｗ

2018/05/02(水) 16:36:00.09

ちなみに非PODならメンバ初期化子に書かなくてもデフォルトコンストラクタで初期化子される

**デフォルトの名無しさん** · 2018/05/02(水) 16:36:35.49

そもそも>>498の例なら初期化子自体いらんしｗ

2018/05/02(水) 17:10:02.19

>>499
そ、そうやって初期化したcfooはdeleteしなくてもいいんでつか？

2018/05/02(水) 17:15:22.77

>>504
変数の寿命を理解してないのか？
C/C++で変数の寿命を理解せずコード書くとメモリリークだらけになるから止めるか横着せず勉強するかしてくれ

2018/05/02(水) 17:19:29.16

>>504
何言ってんだお前は
そもそもdelete出来んだろ

2018/05/02(水) 17:35:57.58

教えてください

やりたい事は ↓
https://stackoverflow.com/questions/14706954/how-to-override-the-text-displayed-for-a-property-in-the-propertygrid

ここに出てるようなPropertyGridで、数値配列の値を16進で表示したい
[0] 0x0001
[1] 0x0002
[2] 0x0003
....
例えば↑とか、単にこれだけ

そうとう調べまくったんだが、配列の例はみつけられなかった
配列でなければ、実装例は結構見つかるんだが・・・

一見簡単そうなんだけど、俺のレベルでは不可能

2018/05/02(水) 18:09:52.99

>>507
それC++の質問なの？
.NETのライブラリ(=>C++/CLI)じゃなくて？

2018/05/02(水) 18:25:45.38

いや、c# です

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sdb3-L0fA) · 2018/05/02(水) 18:26:58.58

>>509
スレ違い

2018/05/02(水) 18:29:31.79

ごめん間違えた、ここ C++のスレだった
隣で聞きます。

◆QZaw55cn4c (ﾜｯﾁｮｲ 5360-c97c) · 2018/05/02(水) 18:52:21.12

>>504
delete しなくてもいいのです

2018/05/02(水) 19:04:04.70

>>505
>>506
>>512
み、みんな、親切にありがとう・・・

2018/05/02(水) 19:06:49.69

>>494
一度に作る分量が減るので間違えにくい
別々の人間が手分けして作れる

2018/05/02(水) 20:14:18.27

>>503
そもそも>>498はコンパイルエラー（もしくは警告）になるだろ...
class CTest
{
　CFoo* cfoo;

　CTest(int x){
　　cfoo = new CFoo(x);
　}
　~CTest(){
　　delete cfoo;
　}
　void ReNew(int x){
　　delete cfoo;
　　cfoo = new CFoo(x);
　}
};
みたいな奴を想定してたのかも知らんけどこれでもunique_ptr使えば良いだけだしね

**デフォルトの名無しさん** · 2018/05/02(水) 23:29:42.51

どうせ>>498の
CFoo cfoo;
はこれまた
CFoo *cfoo;
のつもりだったんだろう

とりあえず>>499の形にすればnewはなくせる
ポインタを保持したい場合も生ポインタはやめたほうがいいね

2018/05/02(水) 23:41:46.06

可能な限りスマートポインタを使え、そしてスマートポインタで駄目な場合はほとんどないってのはその通りなんだけど、
初心者が生ポインタをちゃんと理解したことのないままスマートポインタを使いこなせるとも思えぬ。
そこらへんはちゃんと分けて、今回の場合はまずは生ポインタを理解するという方向性で説明する場面じゃろ。

2018/05/02(水) 23:47:44.17

>>516
>>499を仰ぎますm(_ _)m

2018/05/03(木) 00:10:52.91

もうスマポはスマポとして理解させたほうがいいような気がするけどな
下手な生ポの知識は初心者に有害だ

2018/05/03(木) 01:53:27.71

ていうかコンストラクタだから返却値型いらんやん

2018/05/03(木) 02:06:40.03

ポインターをdeleteせずに扱う猛者がいると聞いて駆け付けてきた

2018/05/03(木) 02:41:54.13

delete をしない戦略ってのは無くはないよ。

アプリケーションの起動時直後にガッと大量のメモリを必要として、
終了直前に全部解放するってパターンなら、
どうせプロセスの終了と一緒にリソースは回収されるのでわざわざメモリ解放の処理を入れる必要はない。
(C++ だとデストラクタは必ずしもメモリを解放するだけではないので注意が必要だが)
だけどそういう戦略をとれるのはちゃんと理解した上で問題にならないことを確信できるだけの知識があってこそだわな。

というか、それ以上に、確保したのを解放しないのは「気持ち悪い」と感じる心が C/C++er にはある。

2018/05/03(木) 05:19:48.86

組み込みだとそもそも終了なんてものがなかったりする

2018/05/03(木) 20:37:30.17

解放しないメモリをnewとか頭湧いてんのか

2018/05/03(木) 20:40:51.26

あたまがあったまってるんだ。

2018/05/03(木) 21:00:46.14

確保済みメモリに対してのnewってあるよ

◆QZaw55cn4c (ﾜｯﾁｮｲ aa60-pRpi) · 2018/05/03(木) 21:15:35.38

>>526
placement new の意味が今でもよくわかりません…どんなときに使うのかなあ…

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sdaa-AL4z) · 2018/05/03(木) 21:18:01.47

char buf[MAX_BUF];
new(buf) MY_STRUCT(1, 2, 3);

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sdaa-AL4z) · 2018/05/03(木) 21:18:51.15

char buf[sizeof(MY_STRUCT)];
new(buf) MY_STRUCT(1, 2, 3);

2018/05/03(木) 21:19:45.60

>>527
VRAM みたいな特殊なメモリを C++ のオブジェクトに見せかけたい場合とか

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sdaa-AL4z) · 2018/05/03(木) 21:20:25.98

すでに確保したメモリーブロック上でコンストラクターを発動させる。

2018/05/03(木) 21:23:27.91

組み込みとかゲーム機のような、最初に一気に確保する環境で使うんじゃないかね
といっても確保済みのメモリに対して断片化しないように管理する仕組み作ったら、必然的にnew演算子もオーバーロードするだろうから結局placement new使わんかもしれんけど

2018/05/04(金) 04:49:56.51

クラスを丸ごとDLL化するときにはnew系をオーバーロード
しておかないと解放時にエラーになるべ。

ヒープはDLL単位にあるので集めておきたい場合はplacement使う

2018/05/04(金) 11:44:28.56

unique_ptrの配列版でメモリの再確保を行いたい場合どのように行うのがベターですか？

2018/05/04(金) 11:50:52.58

何に対してベター？

2018/05/04(金) 12:02:46.79

>>534
unique_ptr::reset( ) じゃねーの？

2018/05/04(金) 15:25:56.64

スマポ使うときは最初にnewするもんなんじゃ…

2018/05/04(金) 15:29:55.09

make_unique使ってね

2018/05/04(金) 15:47:45.28

配列伸ばしたいなら素直にvector使え

2018/05/04(金) 22:00:12.15

いろんな意味にとれるから質問の答えは未定義

2018/05/05(土) 18:32:19.19

[][][] [[[ ] X_[[[ [] ][ [] ][][[[]

2018/05/06(日) 13:23:46.73

以下のように、派生クラスのメンバ関数で基底クラスのメンバ関数を呼ぶように
基底クラスが派生クラスに強制する方法はないでしょうか？
ttps://wandbox.org/permlink/K4IHMYwOsutPQz3i

2018/05/06(日) 14:01:54.85

FAQやな
インターフェースとカスタマイズポイントを分けろ

struct base {
　void f() { //非仮想
　　cout << "base" << endl;
　　this->f_custom();
　}
private:
　virtual void f_custom(){}
};
struct child : base {
　void f_custom() override {
　　cout << "child" << endl;
　}
};

2018/05/06(日) 14:08:44.77

>>542
NVIじゃね？
https://wandbox.org/permlink/zjVuc2KjEPYsahYS

**542** (ﾜｲﾓﾏｰ MMaa-UBB+) · 2018/05/06(日) 14:59:52.15

レスありがとうございます。
NVIというのがあるのですね。
（大昔に勉強したような…しかし思い出せず）

2018/05/06(日) 15:57:13.38

大昔とかの問題じゃなくて基本だぞ

2018/05/06(日) 19:15:44.52

>>544
pure virtualなのに関数定義することなんてできたのか…
f()とbase::f()は同じ関数なんだよね？

2018/05/06(日) 19:32:29.01

}]] [[《_["[[]]" 〈[]》》 [][][]0,1》》〈〉 [] } } "B,V,0%%%,*1BVLO,SASA1`}}//%\\0,1\"VL"\

2018/05/06(日) 19:37:26.47

>>547
俺も知らんかった...
規格上も正しいみたい
https://cpplover.blogspot.jp/2013/11/blog-post_24.html

2018/05/07(月) 05:32:12.66

>>547
12行目のbase::f()はvirtualを抑止してpure virtualを呼び出す
13行目のf();は動的結合でchid::f()を呼び出す

baseは抽象クラスでnew base{}できないので
13行目の動的結合がbase::f()を呼び出すということは起こりえない
だからif(typeid(*this) != typeid(base))のようなチェックをしていない

2018/05/07(月) 22:52:31.63

ちょっと根本的な質問を。

C#が既に普及しているなかあえてC++に固執する理由ってある？

2018/05/07(月) 23:34:15.98

MSのOSしか使わないなんちゃてPGならC#で十分じゃないの

2018/05/08(火) 09:42:55.49

mono/Xamarinはしんどいと言う事を知らない世界の内はいいんじゃない？
大体Win限定だとしても高速化するのにC++で書いたのをdllimportするだろう

2018/05/08(火) 10:29:13.38

ざまりんが苦しい人は信仰が足りないのです
　
　僕は信仰の自由を主張しますけどね

◆QZaw55cn4c (ﾜｯﾁｮｲ aa60-pRpi) · 2018/05/08(火) 17:04:15.75

>>551
余計な依存関係をかかえないのが嬉しいです

**デフォルトの名無しさん** · 2018/05/09(水) 03:49:30.68

Boostとか使ってると余計な依存関係をかかえてしまうけどな

C言語が一番

2018/05/09(水) 10:07:16.66

一番多くの環境で使えるのはC言語
RAMが数十バイトしかないような非常にチープな8bitマイコンでも使える

2018/05/09(水) 10:29:31.98

数十バイトだとスタック領域ももパンクしそう、厳しいのではないか？

2018/05/09(水) 10:34:17.87

流石に盛り過ぎ

2018/05/09(水) 10:54:36.47

知らないで盛ってると言うのはどうかと
昔6ピンpicでｃ使ってたけどRAMは16バイトだった気がする

2018/05/09(水) 11:01:43.78

調べたら勘違いで自分の持ってたのはSRAM64バイトのpicだった

2018/05/09(水) 11:58:05.29

ＰＩＣ１２Ｆ６０９とかでもプログラム領域は1Kwあるけど
数十バイトしかない奴の型番教えてくれくれ

2018/05/09(水) 12:00:11.72

PIC10F200はRAMが16バイトですね
制約は当然ありますがC言語で開発出来ます

2018/05/09(水) 12:00:58.98

C++どころかCすらやってはいけないレベルだな
恥ずかしいやつ

2018/05/09(水) 12:02:35.51

>>562
ROMとRAMの区別がつかない人がなんでこのスレにいるのか？

2018/05/09(水) 12:04:25.14

ハーバードアーキテクチャのデータメモリサイズだけ書くの
卑怯だと思うの。プログラムメモリは２５６ワードあるじゃん

2018/05/09(水) 12:07:19.83

>>557を受けての話だから
そのチープなマイコンで開発にCが使えてる

2018/05/09(水) 12:09:43.50

だから盛り過ぎでしょ

2018/05/09(水) 12:10:13.60

>>568
じゃあできないというのか？

2018/05/09(水) 12:45:08.73

>>551
競技プログラミングとかunity覚えるの面倒とか？

2018/05/09(水) 13:09:28.13

>>566
RAMってしっかり書いてるじゃん
チープなマイコンだとROM/RAMに別れてるのが普通だよアーキテクチャー関係無しに

2018/05/09(水) 18:42:26.74

スタックの話だよね
スタックはRAMであることが絶対条件なので
ROMがどんだけあろうが関係ない

2018/05/09(水) 18:49:54.96

C# と C++ は世の中でどちらのほうが使われているのでしょうか？

いま、 C++ の本（ロベール）を読んでいますが、無駄ですか？
柴田望洋訳の分厚い本も買ってしまいました。

**デフォルトの名無しさん** · 2018/05/09(水) 18:54:28.74

C++は無駄とは言い切れないがロベールは無駄

2018/05/09(水) 18:59:28.28

>>574

ありがとうございます。

結局、どのプログラミング言語を習得するのがおすすめでしょうか？

Python のような言語は除いて。

2018/05/09(水) 19:01:30.85

何をやりたいと考えているか次第

2018/05/09(水) 19:05:22.21

>>576

趣味でアルゴリズムとデータ構造を勉強しています。
プログラミングコンテストの問題(Aizu Online Judge)を解いたりもしています。

もし、プログラマーになるとした場合、もっとも必要とされる言語を使って、
アルゴリズムとデータ構造の勉強をすれば効率的かなと考えています。

セジウィックとウエインの本や講義動画を読んだり見たりするときには、
Javaの入門書を見たりしています。

2018/05/09(水) 19:07:11.19

>>576
コンピューターサイエンスを広く学ぶ上で一番適した言語がいいかなとも考えています。

2018/05/09(水) 19:16:40.18

C++のスレで言うのもどうかとは思うが、
初心者が覚えるのに相応しい言語はJavaじゃないかなと思う
アルゴリズムだけを学びたいなら、C言語が良いかもしれない
他の人の意見も聞いてね

◆QZaw55cn4c (ﾜｯﾁｮｲ aa60-pRpi) · 2018/05/09(水) 19:47:49.06

>>577
そういうのがやりたくて、しかも今 C で片言がしゃべれるのなら、そのまま進めるのが一番いい

2018/05/09(水) 20:02:47.70

>>579
>>580

参考になりました。
ありがとうございました。

2018/05/09(水) 21:19:28.33

>>578
アセンブラかVerilog/VHDLあたりじゃね？
今の伝統的言語はユニプロセッサに源流があって
直列一辺倒の弱点が浮き彫りになっている昨今
【広く】学ぶうえでは却って足かせになるぞ

2018/05/10(木) 12:15:01.11

>>578
Occam2 とか XCが最凶かもな

2018/05/10(木) 12:20:40.60

Cはアルゴリズム勉強にはあまり向いてないと思う
以前各言語向けのアルゴリズム辞典みたいのを見比べてみたけど
Cのだけ異質な感じ
forのカウントいじってあったりして勉強しにくい

少なくともオブジェクト指向入れた言語じゃないと後で生かしにくい

2018/05/10(木) 15:18:57.11

オブジェクト指向が導入されているべきかどうかというよりも、単純に C は抽象化の能力が低いんだよ。
下層レイヤを上手く隠せないから段階的に積み上げていくというのがやり難い。

学習段階では上から下まで見えているって方が分かりやすいということはあるかもしれないので、
どちらが良いかというのは考え方とか好みにもよるので一概には言えないと思う。

2018/05/10(木) 15:24:31.29

アルゴリズムの仕組みが言語の内部に隠されると理解を妨げるだろう
オブジェクト指向については、別の機会に学べば良い

2018/05/10(木) 15:59:00.64

そうとも言えない。
複雑なものを理解するには「分解する」は基本的なアプローチのひとつで、レイヤを切り分けるのは有用だよ。
それが >>585 に書いた「段階的に積み上げていく」の意図ね。

かといってそれで全体像が見通しにくくなってもそれはそれでアレだし、何がベストかなんて言えないよ。
やりやすいと思った方でやるしかしょうがないんじゃね。

2018/05/10(木) 16:46:33.01

C言語で書かれたアルゴリズムが読み解けるようでないと
後で困るだろう

2018/05/10(木) 17:51:59.26

C以外だとリストのシャッフルはshuffleだけで済ませられる
Cだとshuffleの中身を書かないといけない

C以外だと「Combination()を使おう」
Cだと「Combination()を実装しよう」
くらいの差がある

アルゴリズムがどこまで指すのか分らないが、楽しいことから先にやればいいんじゃねえの、ということで、C以外から

2018/05/10(木) 18:15:07.55

アルゴリズムを学習するって、その実装の中身を理解することだろう

2018/05/10(木) 18:39:39.67

個人的には、各種ソートや基本的なデータ構造の操作を自前で書くようなシンプルなところから入った方が分かりやすいかと思うけど、まあ人それぞれかなと。

2018/05/10(木) 18:45:52.70

みなさん、ありがとうございます。

セジウィックとウエインのアルゴリズムの本に載っているのは、おそらく
ジェネリクスを使っているので一般性もあって、かつ効率もいいプログラム
だと思います。

ライブラリのようなクオリティーでプログラムを作るというのが理想です。

2018/05/10(木) 18:51:57.46

アルゴリズムの本というと C 言語でプログラムが書かれた本が多いですが、
やっと C++ で書かれた日本語の本が最近出版されましたね。

セジウィックとウエインの本よりももっと初歩的な本のようですが。

データ構造とアルゴリズム (電子情報通信レクチャーシリーズ B-8) 単行本 ? 2018/2/1
岩沼宏治 (著), 美濃英俊 (著), 鍋島英知 (著),

2018/05/10(木) 19:17:25.91

アルゴリズムの抽象的な部分(オーダーとか適用するデータ構造の再帰性や対応関係)を学ぶならCよりML系の方が向いてるは向いてると思う
ただ環境構築なんかの障壁もあるだろうし最終的にCは触るだろうけどアルゴリズム以外の所で詰まりにくいという意味でC#を推してみる

2018/05/10(木) 19:18:39.74

>>594
勿論F#でもいいし理想はそうだが好みというかネットの情報量の多さ的にC#を挙げた