【初心者歓迎】C/C++室 Ver.100【環境依存OK】 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2016/11/06(日) 22:58:02.60

エスケープシーケンスやWin32APIなどの環境依存なものでもOK。
ただしその場合、質問者は必ず環境を書きましょう。

◆ソースのインデントについて
半角空白やTABでのインデントはスレに貼ると無くなります。
そのため、アップローダーに上げるのも手ですが直接貼る場合は、
全角空白かに置換すると見栄えだけはよくなります。

【アップローダー】(質問が長い時はココ使うと便利)
http://codepad.org/ (コンパイルもできるし出力結果も得られる[]privateをチェック)
http://ideone.com/ (時間帯によってはcodepadが重い事があるのでここも利用)

前スレ
【初心者歓迎】C/C++室 Ver.99【環境依存OK】
http://echo.2ch.net/test/read.cgi/tech/1469177649/

**デフォルトの名無しさん** · 2017/02/24(金) 10:43:32.63

>>488
Linuxじゃ失敗しないよ

**デフォルトの名無しさん** · 2017/02/24(金) 10:53:37.11

もたろん割り当てるアドレス空間自体が足りなくなったとか、予め上限を設定しておいたとかいうケースは覗いてな

**デフォルトの名無しさん** · 2017/02/24(金) 11:09:14.16

16byteのメモリを積んだコンピュータで32byteのメモリ確保したら失敗するよね。

それはわかる。

逆に16byteのメモリを積んだコンピュータで7byteのメモリを二回確保して最初の7byteを開放した後に8byteのメモリを確保したら失敗するの？

**デフォルトの名無しさん** · 2017/02/24(金) 11:41:21.86

基本的にでっかくメモリ確保というプログラムは作った事がないな。
今はＳＴＬでほげほげ追加してくイメージ。

**デフォルトの名無しさん** · 2017/02/24(金) 11:47:17.85

>>491
>16byteのメモリを積んだコンピュータで32byteのメモリ確保したら失敗するよね。
そうとは限らない。一般的なLnuxの環境依存ではmallocを搭載メモリ以上行っても失敗しない
swap含めて1GBしか積んでいない環境で2GB分malloc可能。確保した領域に書き込んだタイミングで記憶する領域が足りなくなったら色々なプロセスが殺される。oom killerと言われてるもの。
>
逆に16byteのメモリを積んだコンピュータで7byteのメモリを二回確保して最初の7byteを開放した後に8byteのメモリを確保したら失敗するの？
実装による。現代的なコンピューターではページ単位(4KB)とかでカーネルからプロセスへすきなアドレスへメモリを割り当てられるから物理的なアドレスが連続している必要はない。
プロセス内に連続したアドレス空間が残っていない場合は失敗する

**デフォルトの名無しさん** · 2017/02/24(金) 11:52:16.13

仮想メモリというしくみで色々やってくれるようになって
キャパの限界付近ではややこしくなった印象

**デフォルトの名無しさん** · 2017/02/24(金) 12:48:55.46

家鯖は６Ｇ積んでるけどそれぐらいは行けるね。
てかkvmやってると、９Ｇコミットされてるもん。

**デフォルトの名無しさん** · 2017/02/24(金) 15:10:06.50

>>488
それスワップエリアのサイズ計ってるだけ

**デフォルトの名無しさん** · 2017/02/24(金) 15:25:25.94

winならGetProcessMemoryInfoなど

**デフォルトの名無しさん** · 2017/02/24(金) 17:26:32.84

>>493
> 物理的なアドレスが連続している必要はない
なるほど、長年の疑問が解消した。
493の読解力に感謝。

**デフォルトの名無しさん** · 2017/02/24(金) 18:02:34.91

>>498
望む答えだったみたいで良かったわ
熱があって若干朦朧とした頭で読み返さずに書き込んだから今読み返すと誤字とか予測変換で要らない単語入ってたり(一般的なLinux環境)とか、カッコの位置が違う(4KBとかの部分)とかあったけど。

**デフォルトの名無しさん** · 2017/02/24(金) 18:52:48.08

環境依存ならPostMessageのエラーコードかな
俺はあんま理解してないけど

**デフォルトの名無しさん** · 2017/02/24(金) 19:06:57.61

Win32なら信頼のPostMessageだな

◆QZaw55cn4c · 2017/02/24(金) 22:16:12.34

またその話題ですか‥

**デフォルトの名無しさん** · 2017/02/24(金) 23:03:49.77

はよ10年前のソース出せよ

**デフォルトの名無しさん** · 2017/02/24(金) 23:06:00.45

http://i.imgur.com/OwlfgGw.jpg

**デフォルトの名無しさん** · 2017/02/25(土) 07:21:27.70

なんで2分ちょいで出てくるかね。

**デフォルトの名無しさん** · 2017/02/25(土) 08:14:13.74

自演

**504** · 2017/02/25(土) 08:21:08.89

>>503 ≠ >>504 だ。すまんなｗ

**デフォルトの名無しさん** · 2017/02/26(日) 18:42:59.30

味噌県のクセにコーミソース以外のソースを使う非国民は去れ

**デフォルトの名無しさん** · 2017/03/06(月) 07:57:48.79

#define ChannelBlend_SoftLight(A,B) ((uint8)((B < 128)?(2*((A>>1)+64))*((float)B/255):(255-(2*(255-((A>>1)+64))*(float)(255-B)/255))))
このマクロの
(2*((A>>1)+64))
この部分なんですが
なんで(A+128)じゃないんですかね？

**デフォルトの名無しさん** · 2017/03/06(月) 08:21:33.22

最初の人がコピペで作ったんでしょ。+128に定義し直してるのもあるよ

**デフォルトの名無しさん** · 2017/03/06(月) 08:30:32.82

Aが奇数のときの動作が違うね

**デフォルトの名無しさん** · 2017/03/06(月) 10:33:08.69

A、Bにはuint8を想定してますから、一瞬オーバーフローの関係かなとも思いましたが
そんなことはなく、特に深い意味はなさそうですね
ありがとうございます

**デフォルトの名無しさん** · 2017/03/13(月) 00:19:03.26

仮想関数をオーバーライドするときはどう書くのがいい作法？
void vf()
virtual void vf()
virtual void vf() override
void vf() override

**デフォルトの名無しさん** · 2017/03/13(月) 06:06:33.92

ハゲ先生によると最後の void vf() override が良いみたい。
『プログラミング言語C++ 第4版』p.592

加えてoverride指定の不整合をチェックするコンパイラオプションだね。
GCCのVersion 5から使える -Wsuggest-override とか。
他のコンパイラについては知らん。

**デフォルトの名無しさん** · 2017/03/13(月) 10:43:38.74

デストラクターに付けてる人はあんま見たこと無いな
class Derived : Base {
public:
　~Derived() override {}
};

**片山博文MZ** ◆T6xkBnTXz7B0 · 2017/03/13(月) 20:30:08.38

Bcc55でtypeofを実現するのは不可能なのかな？

**片山博文MZ** ◆T6xkBnTXz7B0 · 2017/03/13(月) 20:57:04.03

古いコンパイラを使ってる人居る？
コンパイラの名前教えて下さい。

**デフォルトの名無しさん** · 2017/03/14(火) 23:30:09.48

老人がカセットテープデッキ求めたり
熟女モノのエロ本()を求めるような感じ？

**デフォルトの名無しさん** · 2017/03/15(水) 01:04:07.22

古いコンパイラと自覚しつつも使ってるような人はこのスレには来ないだろ
時代遅れの遺物の話じゃ通じないし

**デフォルトの名無しさん** · 2017/03/17(金) 11:46:00.03

何でA、Bを（）しないんだ？

**デフォルトの名無しさん** · 2017/03/25(土) 21:37:15.77

いまだに関数マクロ使ってるようでは
（）したところで五十歩百歩

**デフォルトの名無しさん** · 2017/03/25(土) 22:37:56.47

>>460
>>465
宣言とかいろいろ確認してやっぱソースはおかしくないよねってことで
サポートに調べてもらったら理由はわからないけど正しく動作する修正方法がわかったって連絡があって
最終的には詳細は書けないけどコンパイラのバグだった

**デフォルトの名無しさん** · 2017/03/26(日) 08:58:38.45

ここはお前の日記を垂れる場所じゃない
「サポートによるとコンパイラのバグだった」で済むのに
アレやってコレやってを書くな低能

**デフォルトの名無しさん** · 2017/03/27(月) 10:03:34.57

事後報告あると参考になっていいんだけどな
今回は本人以外に状況がわからないから事後報告されてもｗ

**デフォルトの名無しさん** · 2017/03/30(木) 03:06:01.35

http://codepad.org/KMQH3TsZ

ポインタをメンバに持たせた場合のget/setの書き方が分かりません
getの方は、ポインタを返すときに返した先で値を変えられないようにconstを付けたのですが、
sizePlus10のような関数を呼びたい場合に、const_castを付けて呼ぶことになってしまいました
値の変更をするのでsetを通してやるのが良いと思うのですが、何か良い書き方ありますか？

また、setの方は、一括で設定させることはできるのですが、
data->id、data->sizeの値を個別に設定したい場合、何か良い書き方はありますか？
コメントの部分のようにsetメンバ関数を何個も書く方法しか思いつきません

**デフォルトの名無しさん** · 2017/03/30(木) 07:50:43.79

getDataの結果を修正したいのだから
杓子定規にgetDataの戻りにconst付けるのを止めればいいのではないか

そう言えばC++17(ドラフト)もstring::dataの戻りが非constに修正されたような

**デフォルトの名無しさん** · 2017/03/30(木) 08:08:59.00

memcpy ｗ

**デフォルトの名無しさん** · 2017/03/30(木) 10:48:22.67

>>525
一般論として形でただ覚えるのではなくて意味を理解しよう
理解があやしいから設計の一貫性がなく混乱してるようにみえる
・Dataをポインタで所有するのはなぜ
・ゲッター／セッターを使ってアクセスするのはなぜ
・ゲッターで返す値にconstをつけるのはなぜ
・sizePlus10がData*を受けとるのはなぜ

MyClassの設計方針にあわせるならsizePlus10をDataではなくMyClassを受けとるようにして
void sizePlus10(MyClass & mc)
{
Data newdata = { mc.getData()->id, mc.getData()->size + 10 };
mc.setData(newdata);
}
あるいは別の関数を作って
void MyClassSizePlus10(MyClass & mc)
{
Data newdata = *mc.getData();
sizePLus10(&newdata);
mc.setData(newdata);
}

これが変だとか非効率だとか思うなら
MyClassの設計が要求にあってないのでそっちを変更する

**デフォルトの名無しさん** · 2017/03/30(木) 20:11:34.52

>>528
おまえは質問の意図を理解しよう

>>525
そのsetgetでいいんじゃない？ただそのgetは俺だったらreferにするな
ついでにsetget両方使えるようにdata* operator->()みたいなの実装かな。というかむしろそっちでアクセスする方向にするな
あとはattachdetach作っておいてm_dataを置換できるにようにしちゃうな
その手のスマートポインタは至るとこで使われてるからこんなとこで聞かずにどっかのライブラリの参考にしたら？

メンバのコピーはpragma pack1でstructしておいてmemcpy

**デフォルトの名無しさん** · 2017/03/30(木) 23:27:09.74

>>529
>メンバのコピーはpragma pack1でstructしておいてmemcpy

それをすると何がいいことあるのか？

**デフォルトの名無しさん** · 2017/03/30(木) 23:45:25.72

こういえクソみたいな方法を自慢気に語り出す奴が居るところかC++の最もクソな所だよね

**片山博文MZ** ◆T6xkBnTXz7B0 · 2017/03/30(木) 23:51:55.55

デフォルトコピーコンストラクターとか構造体代入とか知らないんだろう。

**デフォルトの名無しさん** · 2017/03/31(金) 00:14:17.76

>>532
>構造体代入とか知らないんだろう
ほうほう、それは何ですか？

**デフォルトの名無しさん** · 2017/03/31(金) 01:59:49.12

やべえなおい糞コードの臭いがプンプンしやがるぜ

**デフォルトの名無しさん** · 2017/03/31(金) 02:09:29.70

>>526-529
ありがとうございます

今まではとりあえずget/setを書いてgetにはconstを付けとけば良いみたいな認識でしたが、
想定されるクラスの使われ方に合わせて適宜変更するべきでした

MyClassのようなget/setの分け方をすると、
sizePlus10のような関数やsetで不便になってしまうので、
constを付けないget/set共用のものにしてそれを通してアクセスさせるのが適切でした
( getData()でアクセスする場合、Data * const getData() const { /**/ } みたいな )
とても参考になりました

**デフォルトの名無しさん** · 2017/03/31(金) 11:52:48.85

>>531
くそじゃない方法をおしえて

**デフォルトの名無しさん** · 2017/03/31(金) 12:09:56.69

C#じゃないからないでしょ

**デフォルトの名無しさん** · 2017/03/31(金) 13:26:56.75

>>536
コピーは=使え
というだけの話

**デフォルトの名無しさん** · 2017/03/31(金) 13:38:11.94

>>529
> メンバのコピーはpragma pack1でstructしておいてmemcpy
これ俺も理由知りたい

**片山博文MZ** ◆T6xkBnTXz7B0 · 2017/03/31(金) 17:24:06.64

typedef struct MY_STRUCT
{
int ch;
} MY_STRUCT;

MY_STRUCT a,b;
a.ch = 0;
b = a; //代入できる

**デフォルトの名無しさん** · 2017/03/31(金) 19:17:35.19

>>529
> おまえは質問の意図を理解しよう

なんか無駄に上から目線だなぁ
って思ったら

> メンバのコピーはpragma pack1でstructしておいてmemcpy

単なる老害だったでござる

**片山博文MZ** ◆T6xkBnTXz7B0 · 2017/03/31(金) 19:19:25.80

構造体の代入ができなかったのは大昔のことだ。

◆QZaw55cn4c · 2017/03/31(金) 19:35:02.95

>>540
それ，K&R1 から堕落したよね

**片山博文MZ** ◆T6xkBnTXz7B0 · 2017/03/31(金) 19:40:25.86

構造体定義を#include <pshpack1.h>と#include <poppack.h>で囲むのは、スピードよりもメモリー効率を優先するときにする。

**片山博文MZ** ◆T6xkBnTXz7B0 · 2017/03/31(金) 19:44:56.93

あるいは構造体のレイアウトを分かりやすくするときにパッキングを指定する。

**片山博文MZ** ◆T6xkBnTXz7B0 · 2017/03/31(金) 19:46:22.60

>>543
堕落ではない。進歩だ。

**デフォルトの名無しさん** · 2017/03/31(金) 19:49:13.63

> スピードよりもメモリー効率を優先するときにする
20年くらい前まではそういう老人もいたね
今はメモリレイアウトを固定したい時にしか使わないけど

**片山博文MZ** ◆T6xkBnTXz7B0 · 2017/03/31(金) 19:58:28.84

#pragma 直接指定は礼儀が悪い、昔のやり方だ。

**デフォルトの名無しさん** · 2017/04/01(土) 02:25:44.35

メモリ効率だけの問題なら大抵の場合は順番入れ替えるだけで問題ないしな

◆QZaw55cn4c · 2017/04/01(土) 07:47:47.79

>>546
サイズが無限にのびるかもしれないものをコピーするなんてだめだよ
昔はね，構造体はポインタを介してしかつかえなかったんだよ

**デフォルトの名無しさん** · 2017/04/01(土) 08:31:33.23

そうそう
スタックに自動変数とかも言語道断
全部staticじゃなきゃね

◆QZaw55cn4c · 2017/04/01(土) 13:26:49.84

>>551
スタックに自動変数はあたりまえだよ‥static おじさん，じゃないつもりなんだが‥
構造体はポインタで扱うべきもので，実体をコピーするのはなるたけ避けたいね
C++ では　void f(const C &arg) って，可能ならば const と参照の縛りをできるだけいれるよね，余計なコンストラクタを走らせないために

K&R1 は教育的な配慮に優れた実装だと思うんだ‥

**デフォルトの名無しさん** · 2017/04/02(日) 14:13:23.32

SOCKADDRが一言

◆QZaw55cn4c · 2017/04/02(日) 17:06:04.34

>>553
手元のソースをみると
clientSocket = accept(serverSocket, (LPSOCKADDR)&clientSockAddr, &addrLen);
とか
if (connect(destSocket, (LPSOCKADDR)&destSockAddr, sizeof(destSockAddr)) == SOCKET_ERROR) {
とか，構造体のポインタを渡しているね
由緒正しき Berkeley socket では，構造体をコピーするなんて教育的ではない書き方は許していないよ

**デフォルトの名無しさん** · 2017/04/02(日) 17:31:42.61

つまり>>553はK&Rおじさんにも劣る存在

**デフォルトの名無しさん** · 2017/04/02(日) 18:21:59.15

K&R1 おじさん，と
K&R2 おじさん
は区別したまえ，若造

**デフォルトの名無しさん** · 2017/04/02(日) 19:26:19.28

どっちも時代遅れの老人でしょ
K&Rなんて昔存在したという噂でしか知らない
万葉集とか古事記みたいなもの？

**デフォルトの名無しさん** · 2017/04/02(日) 20:22:15.39

func1(a, b)
　　int a;
　　long b;
{
}

**デフォルトの名無しさん** · 2017/04/02(日) 22:22:37.63

> &destSockAddr,
> sizeof(destSockAddr)

由緒正しきBerkeley Socketも昔はこういう書き方したな
コイツは進歩が20年前で止まってるのか
今この書き方する奴は死刑でいい

**デフォルトの名無しさん** · 2017/04/02(日) 23:11:21.74

便乗で申し訳ないが、値渡し、参照渡し、ポインタ渡し、の話で
ポインタ渡しといっても、C++の場合はナマポは嫌われて、スマポを使いましょう
ってことになっていると思うんだけど、これはどう渡すのが普通？
スマポを値渡しするのか、参照渡しするのか
はたまたスマポを剥いで、ナマポで渡すのか
個人的に統一しきれないっつーか
所有権やら生存期間やらリソース管理やらが関係してくるなら
スマポで渡すI/Fじゃないとまずいだろうし
逆にそういうのが関係ないなら、スタック上の自動変数を渡したいとかも考えると
ナマポで渡すI/Fのほうが都合が良かったり、どーなんだろ
一度ナマポに戻すと二度とshared_ptrに変換できないって制限がね
言語側でなんとかせずに、ライブラリで解決しようとした弊害かな
ちょうどよいバカよけなんかも知らんが

**デフォルトの名無しさん** · 2017/04/02(日) 23:13:25.39

参照一択

**デフォルトの名無しさん** · 2017/04/02(日) 23:24:57.32

>スマポを値渡しするのか、参照渡しするのか
>はたまたスマポを剥いで、ナマポで渡すのか
スマポの値渡しと生保は使い分けが必要だが、スマポの参照渡しだけはアホの所業。
とスコットメイヤーが言っていたような

**デフォルトの名無しさん** · 2017/04/02(日) 23:43:46.05

>>560
shared_ptrはその名の通り所有権を共有する場合のみ使うもの
で、そういう場合は値渡しでもいいよ。中でmoveすれば
所有権を共有しないなら、nullptrを許容するならナマポそうじゃないなら参照
あんまり無いけど所有権を渡した先に移動させるならunique_ptr

**デフォルトの名無しさん** · 2017/04/02(日) 23:58:32.77

所有権渡したくないならunique_ptrで持っている呼び出し元がgetでナマポを渡すかdereferenceして参照渡すかだな

**デフォルトの名無しさん** · 2017/04/03(月) 00:00:55.90

ナマポで渡してもshared_ptrを再取得する方法はあるだろ
まあ前提がいるが

**デフォルトの名無しさん** · 2017/04/03(月) 00:34:15.74

うむむ、なるほど
ポインタらしき物にこれだけ多くの種類があってI/Fで縛ってしまうのは
一見面倒そうで、最近の流行というか静的型言語的には
型安全と見るべきなんだろうかしら
安易なGC言語より良いかもしれん、単純に情報量は多い
また一つC++が好きになった
うっかり循環参照したら怖いとか
コンパイラのバージョン違いでSTLやmallocの実装に
差異が有ることを前提に組まなきゃならないとか、玉にキズもあるけれど

◆QZaw55cn4c · 2017/04/03(月) 06:55:53.48

>>559
C/C++ で生書きするなら今もおなじだよ

**デフォルトの名無しさん** · 2017/04/03(月) 07:40:50.83

型に対してじゃないのに括弧つけるの？

**デフォルトの名無しさん** · 2017/04/03(月) 08:48:24.23

そこはインデントや{}の位置が人によって違ったりするアレだろ

◆QZaw55cn4c · 2017/04/03(月) 19:32:41.84

>>557
K&R2 は C89 準拠だよ‥C89 が時代遅れだというけれども，いろんなことは C89 のときからやってきていて，C99 で追認された，というだけだよ

**デフォルトの名無しさん** · 2017/04/03(月) 20:29:22.04

>>570
あいわかった
お前は今後「K&R1おじさん」(略して「K&Rおじさん」)な
どうせ定数defineや関数マクロまみれなんでそ

◆QZaw55cn4c · 2017/04/03(月) 21:53:46.44

>>571
略しないほうがいいよ‥
K&R2 おじさん＝C89 はまっとうなCer, K&R1 おじさんは時代遅れ，この二つは全然違うよ

**571** · 2017/04/03(月) 22:02:42.26

>>572
つまりお主(K&R1おじさん)は
K&R2おじさんが自分と一緒くたにされることを
申し訳ないと感じてるのだな！？

(>543)
> それ，K&R1 から堕落したよね

(>550)
> サイズが無限にのびるかもしれないものをコピーするなんてだめだよ

(>552)
> K&R1 は教育的な配慮に優れた実装だと思うんだ‥

**デフォルトの名無しさん** · 2017/04/03(月) 22:14:40.64

voidを返す関数には感心したな

生成されるコードは大して変わらないかも知れんけど

**デフォルトの名無しさん** · 2017/04/04(火) 01:00:11.73

関数プロトタイプを除けば、K&R1で十分かもしれないな
voidを返す関数? int でいいんだよ

**デフォルトの名無しさん** · 2017/04/04(火) 15:11:19.04

戻り値をどうするかはcallerの勝手だからな

◆QZaw55cn4c · 2017/04/04(火) 19:47:09.26

>>575
確かに関数プロトタイプは有用だね，これがないと結構ミスるかもしれないね
void を返す関数？int でいいんだよ

**デフォルトの名無しさん** · 2017/04/04(火) 20:27:50.00

int funca01(...);
int funca02(...);
int funca03(...);

**デフォルトの名無しさん** · 2017/04/04(火) 23:08:17.42

老人は意味とか概念を理解しようとしないから嫌
「bool? intでいいだろ」
「forループ？本質はgotoと同じ」
「enumなんてintでいいだろ」
ホントもう存在が害悪

**デフォルトの名無しさん** · 2017/04/05(水) 00:33:27.19

>>550
何が「昔はね」だよｗ
Qちゃんその当事Cなんて触ってなかったろ？
アンタ最近（たかだか数年？）プログラミングで遊び出しただけの人でしょ

**デフォルトの名無しさん** · 2017/04/05(水) 02:38:54.31

>>579
「static const intなんてenumでいいだろ」
こうですね

**デフォルトの名無しさん** · 2017/04/05(水) 04:30:52.52

奴らは#defineだ

**デフォルトの名無しさん** · 2017/04/05(水) 08:14:48.69

マジックナンバー直書きでしょ

**デフォルトの名無しさん** · 2017/04/05(水) 08:19:06.54

K&Rだと～
c89だと～
過去の異物がまだ現役だと信じて話してけるのがうざい

**デフォルトの名無しさん** · 2017/04/05(水) 09:06:55.68

それ言うならC自体が。
いまさらC++と互換性のないCを選ぶ理由がない。

**デフォルトの名無しさん** · 2017/04/05(水) 10:35:04.67

>>585
C++と互換性のないCってどんなの？

**デフォルトの名無しさん** · 2017/04/05(水) 19:40:11.14

ベターC的な所全般だな
範囲forとか2進リテラルとかスレッドライブラリとか参照とか
Cにはnullptrすら無いし細かいところでは条件演算子が右辺値とか
ようするに別言語
オーバーロードに対するtgmathとかもう糞の臭いしかしない

◆QZaw55cn4c · 2017/04/05(水) 19:44:22.68

>>585
たしかに，C99 の数々の改悪は C++ との互換性を考慮していない悪手の連発，ほとほと困ってしまう

>>584
C++ とほどほどの交換性のある C89 が最良だよ