【初心者歓迎】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/

**デフォルトの名無しさん** · 2018/01/17(水) 18:18:50.66

>>207
印刷はしたくないです..

**デフォルトの名無しさん** · 2018/01/17(水) 20:00:30.20

おｓ

**デフォルトの名無しさん** · 2018/01/27(土) 06:58:59.63

windowsとLinuxで動くクライアントアプリ開発してて、Linuxコンパイラは化石みたいなバージョンからgcc4.4をようやく使えるようになった
そこでC+11の一部が使えるようになったから使いたいと思ってる
ユーザにAPIを公開してるんだけど、ユーザがAPIを使うに際してはコンパイルオプションstdc++0xが必要なことにはしたくない。今までできてたのに、バージョンアップしたらコンパイルできなくなったとかいわれるからね。

ここで質問なんだけど、ユーザに公開しているヘッダファイルにC+11の記述がなければ、ユーザからの使い方は変わらないかな?手元で試してみた感じだと行けそうだって思ったけど、このへん危ないんじゃないのとか気をつけた方がいいよとかあれば意見よろしくです

**デフォルトの名無しさん** · 2018/01/27(土) 08:45:12.76

バイナリで配布するんだったらとりあえずシンボルをnmで取得して見比べてみるとか。

**デフォルトの名無しさん** · 2018/01/27(土) 10:25:52.07

ユーザからクロスコンパイラ提供してもらってバイナリ配布っす
nmコマンド、試す価値はありそうだありがとう

**デフォルトの名無しさん** · 2018/01/28(日) 06:43:38.82

以下のコードをgccでコンパイルすると

#include <iostream>
#include <functional>
using namespace std;

struct functor {
int& operator()(int& i) { return ++i; }
};

int main() {
int i = 0;
cout << functor{}(i) << endl; // 関数オブジェクトは問題なし
function<int& (int&)> lambda = [] (int& i) { return ++i; }; // コンパイルエラー
cout << lambda(i) << endl;
return 0;
}

「'main()::<ラムダ(int&)>' から非スカラ型 'std::function<int&(int&)>' への変換が要求されました」
というエラーになるのですが、どうしてでしょうか？
そもそもラムダ式は関数オブジェクトのシンタックシュガー、つまり等価なのではないんでしょうか？

**デフォルトの名無しさん** · 2018/01/28(日) 07:45:35.06

>>213
戻り値がintになってる
戻り値の型を後置で書いてやればいいかな
function<int& (int&)> lambda = [] (int& i) -> int& { return ++i; };

**デフォルトの名無しさん** · 2018/01/28(日) 22:25:05.79

>>214
ありがとうございます。
戻り値の型を明示してあげないと値渡しになってしまうということですね。
勉強になりました。

**デフォルトの名無しさん** · 2018/02/06(火) 23:57:09.32

typedef int myTypeA;
typedef int myTypeB;

class Test {
void set(myTypeA a);
void set(myTypeB b);
priate:
int A;
int B;
};

のような事例で、引数に応じて専用のセッターを用意したいのですが、
int型の2種類の引数に対して、上記のように書くとコンパイルエラーになってしまいます。
どのようにするのが良いでしょうか？

**デフォルトの名無しさん** · 2018/02/07(水) 00:04:25.80

structを使う？
struct my_TypeA{ int v;};

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

なるほど、、、確かにtypedefだと別名になるだけですね
structかclassで別の型にしないとダメですね
ありがとうございます！

**デフォルトの名無しさん** · 2018/02/07(水) 03:43:04.13

オブジェクト指向では、型による分岐処理は無くなる。
汎化

f(親型)

ここに、親型の子型であるA型・B型が入っても、正常に動くのが、オブジェクト指向

**デフォルトの名無しさん** · 2018/02/09(金) 15:21:46.70

などと訳のわからないこと(でもないが)を供述しており

**デフォルトの名無しさん** · 2018/02/11(日) 04:59:49.56

C++には強いエイリアスが無いからなあ

**デフォルトの名無しさん** · 2018/02/23(金) 16:21:25.57

C++じvtable参照することになるから遅いだろ

**デフォルトの名無しさん** · 2018/02/25(日) 04:05:35.43

>>216
セットする値の名称にする
例えば三角形を表すオブジェクトで底辺と高さをセットするのであれば、base()とheight()になる
プロパティとして使うのだから、setXXX()みたいに書かなくてもいい

setter単独で存在することはありえないからgetterも設けること
setterって余り必要ない
コンストラクタからの初期化で十分の場合が多い

**デフォルトの名無しさん** · 2018/02/25(日) 14:23:16.60

>>219
だぶるでぃすぱっち

**デフォルトの名無しさん** · 2018/03/03(土) 13:43:59.95

2の累乗でないときのmod演算の高速化の方法、何かありませんか？
そこらへんはコンパイラで最適化されるんですかね

**デフォルトの名無しさん** · 2018/03/03(土) 14:09:48.07

>>225
法を2進数にしたときほとんど1かほとんど0なら手間の少ない方法はある。
法が固定で何度も剰余を取るならモンゴメリリダクションがある。
どちらも乗算はそれなりに必要。

**デフォルトの名無しさん** · 2018/03/03(土) 14:14:16.62

>>226
ありがとう
ちょっと調べてくる

**デフォルトの名無しさん** · 2018/03/06(火) 00:16:25.34

ユニークポインターにキャラの可変配列をヒープからとってリセットしたはいいけど、デリーターって簡単に実装/定義できる?例が欲しい。

**デフォルトの名無しさん** · 2018/03/06(火) 00:47:05.22

mutex g_Mtx;

int g_Val = 0;

int Func( int A, int B )
{
　　int Val = A * B;

　　lock_guard<mutex> Lock( g_Mtx );

　　return g_Val = Val;
}

void ThreadFunc0()
{

}

**デフォルトの名無しさん** · 2018/03/06(火) 00:55:45.44

mutex g_Mtx;
すみません、途中で送信してしまいました。

int g_Val = 0;

int Func( int A, int B )
{
　　int Val = A * B;

　　lock_guard<mutex> Lock( g_Mtx );

　　return g_Val = Val;
}

void ThreadFunc0()
{
　　int Val = Func( 2, 3 );

　　// Valを参照する処理
}

void ThreadFunc1()
{
　　lock_guard<mutex> Lock( g_Mtx );

　　// g_Valを参照する処理
}

上記のようなスレッド関数が非同期に実行されるとき、
Func()はスレッドセーフ（g_Val書き換え中に参照されない）でしょうか？

(1)lock_guard<mutex>によるミューテックスロック
(2)g_Valの書き換え
(3)戻り値を読み出し元スレッドにコピー（あるいはムーブ）
(4)lock_guard<mutex>がスコープから外れアンロック

というシーケンスを期待しています。

**230** · 2018/03/06(火) 00:58:37.27

誤：読み出し元スレッド
正：呼び出し元スレッド

**230** · 2018/03/07(水) 00:28:47.80

すみません、他スレで聞きます。

**デフォルトの名無しさん** · 2018/03/07(水) 19:00:17.77

事情があって下記の型の関数を、
void Func1(char a);

下記の型の関数ポインタに代入して呼びたいと思っています。
int*(*p)(int*);
p = (int*(*)(int*))Func1;
p((int*)123);

動作としてはFunc1(123)と呼んだときと同じものを期待しており、
試したところそれっぽく動作しているのですが、
致命的な問題等あります？
"暴走の危険あり"など。

**デフォルトの名無しさん** · 2018/03/07(水) 19:20:05.55

スタックに積むサイズは通常int
long longとかで無ければ実害は無い

**デフォルトの名無しさん** · 2018/03/07(水) 19:29:05.35

>>233
C11の6.3.2.3の8によると、the behavior is undefinedだ。
たとえばcharが4バイトに自動昇格して、ポインタが8バイトだったりすると、
どうなるかわかったもんじゃない。鼻からなんちゃらだ。
C++は知らん。

**片山博文MZ** ◆T6xkBnTXz7B0 · 2018/03/07(水) 19:29:59.98

sizeof(int) != sizeof(int*)の場合(例えばx64)、どうなるかな？

**デフォルトの名無しさん** · 2018/03/07(水) 19:34:38.56

そうそう、undefinedのあとはほんとに何が起きるかわからんよ。
コンパイラが何をしでかしても文句言えない。
たまたま今の環境で動いても、明日コンパイラを更新したら挙動が変わりうる。

**デフォルトの名無しさん** · 2018/03/07(水) 20:01:22.38

「事情があって」の事情を解消する方が安全だと思うけど…。
void Func1(char a); を呼び出すラッパ関数を使うのはどうだろ?

int* Func1_wrapper(int *p)
{
　uintptr_t arg = (uintptr_t)p;
　Func1((char)arg); // 縮小変換が危険
　return NULL;
}

int* (*p)(int*);
p = Func1_wrapper;
p((int*)123); // 明らかに不正アラインメントだが

**はちみつ餃子** ◆8X2XSCHEME · 2018/03/07(水) 20:34:34.64

>>233
関数ポインタ同士は互換で、お互いにキャストすることは許される。
が、呼ぶときは元の型にキャストしなおしてからじゃないとあかん。

**デフォルトの名無しさん** · 2018/03/10(土) 22:50:07.25

C++で窓出してプログラム組みたい時ってどういう風にするもんなんでしょうか
windows.hで一つ一つボタンの位置を設定してハンドルやらコールバックと格闘するもんなんでしょうか
それとも何か気の利いた便利なライブラリとかがあるんでしょうか

というかこの手のライブラリやフレームワーク的なものを探したりしたい場合はどういう場所から情報を集めるものなんでしょうか
それっぽいキーワードでgoogleで検索して探そうとしても上手く情報を見つけられないのですが、根気よくページを確認していくしかないのでしょうか

◆QZaw55cn4c · 2018/03/10(土) 23:05:33.56

>>240
基本的には win32api を使うことになり、私は C++ からwin32api( ::DefWindowProc() とか)を個別呼び出している
気の利いたライブラリのことはよく知らない

**デフォルトの名無しさん** · 2018/03/10(土) 23:18:25.22

やっぱりそういう感じになるんですね
頑張って勉強します

**デフォルトの名無しさん** · 2018/03/10(土) 23:42:00.51

>>240
Windowsに特化するなら Win32APIのほかにMFCやWTLや.NET framework(C++/CLIで良ければ)などのライブラリを使う
サードパーティならC++ BuilderのVCLとかあとはクロスプラットホームのQtとかGtk+とかwxWidgetsとか他にもあると思うけど
最近はデスクトップアプリが落ち目なのでこれという定番はなくて目的に応じて分散しているのでは？
自力で情報が集められない程度ならC++でGUIなんて止めとけという気がしないでもない

**デフォルトの名無しさん** · 2018/03/11(日) 00:23:13.22

ありがとうございます。それぞれ見てみます

**デフォルトの名無しさん** · 2018/03/11(日) 00:43:28.70

vs2010以降ならWIN32SDKベースでも雛型吐いてくれるだろうに

**片山博文MZ** ◆T6xkBnTXz7B0 · 2018/03/11(日) 03:53:08.43

>>240
ボタンの配置などは、リソースエディタでダイアログテンプレートを作ってDialogBox関数を呼べば、細かい調整ができる。
イベント駆動やメッセージ送信などについては、<windowsx.h>で提供されるメッセージクラッカーやマクロを使えば便利になる。
私が複雑なことをする場合は、MZC4という自作のクラスライブラリを使ってる。

**片山博文MZ** ◆T6xkBnTXz7B0 · 2018/03/11(日) 03:59:42.40

HANDLE_MSGマクロによるメッセージクラッカーという仕組みを使えば、ウィンドウプロシージャやダイアログプロシージャの記述が楽になる。
私はさらに、HANDLE_MSGの呼び出し先の関数の入力を楽にする自作のMsgCrackというツールを使っている。

**はちみつ餃子** ◆8X2XSCHEME · 2018/03/11(日) 04:12:58.32

WinRT が綺麗にまとまってると思う。
https://github.com/Microsoft/cppwinrt
Windows API を現代的な C++ に合わせて整理したものなので、
C++ 的にある程度まともな感じがする。

昔は仕方がなかったんだろうけど、
今にしてみればメッセージクラッカーっていかにもクソダサい方法だよな～。

**デフォルトの名無しさん** · 2018/03/11(日) 10:27:16.51

>>240
tcl/tkが一番手軽

**デフォルトの名無しさん** · 2018/03/11(日) 10:40:38.07

Win32プログラミングスレあったっけ

**デフォルトの名無しさん** · 2018/03/11(日) 10:51:25.22

Win32API質問箱 Build124
http://mevius.5ch.net/test/read.cgi/tech/1510395780/

**デフォルトの名無しさん** · 2018/03/11(日) 10:55:00.37

Win32APIスレは限定的だからGUI一般スレみたいなのの方を紹介しようと思ったが面倒なので
次の方どうぞ
↓

**デフォルトの名無しさん** · 2018/03/11(日) 11:28:30.29

>>251
どうも

**デフォルトの名無しさん** · 2018/03/12(月) 02:15:34.18

何度も呼ばれる関数内ではローカル変数をstaticにした方が速いのですか？

◆QZaw55cn4c · 2018/03/12(月) 02:19:53.88

>>254
誤差だ、
プログラミングスタイルを曲げてまですることではない

**デフォルトの名無しさん** · 2018/03/12(月) 02:23:59.34

>>255
さいですか　ありがとうございました

**デフォルトの名無しさん** · 2018/03/12(月) 02:50:45.99

皆様はプログラムを遅くし過ぎない為に気をつけている事などありますか？
速さを突き詰める為の工夫というより、誤って異常に処理時間のかかるようなプログラムを作らないようにする為にはどのような事を意識すると良いのでしょうか

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

staticの方が速い理由なんて一つも無いような
あまり呼ばれない場合はstaticの方が遅いよね、キャッシュ的に
マルチスレッドで邪魔だし、必要がある時以外は使うもんじゃないよ

**デフォルトの名無しさん** · 2018/03/12(月) 03:20:38.17

>>257
メモリアクセスのコストだあ

**デフォルトの名無しさん** · 2018/03/12(月) 03:57:56.72

>>258
多分、メモリを毎回確保し直す事や、コンストラクタを何度も呼ぶ事により処理が遅くなると考えたのではないでしょうか

**デフォルトの名無しさん** · 2018/03/12(月) 04:48:35.89

>>257
実行速度は推測ではなく測定することが鉄則だから
出来ることは気になったときに正しく測定出来るようにすることくらいだ

**デフォルトの名無しさん** · 2018/03/12(月) 08:13:41.87

>>257
ファイルアクセスのような重い処理とか深いループの中の計算処理とかは必要に応じて適切なデータ構造やアルゴリズムをあらかじめ検討しておくけど、頻度が少なく問題にならない箇所は分かりやすさ実装しやすさ優先で無理に速度は追求しないかな。
あとは将来的に性能改善が必要になることもあり得るから基本的には柔軟性のある変更に強い設計を普段から意識しておくとか。

**はちみつ餃子** ◆8X2XSCHEME · 2018/03/12(月) 12:47:06.75

計算量とかメモリ使用量のオーダーは気にするけど、オーダーが変わらないレベルの差はそんなに気にしてもしょうがない。

**デフォルトの名無しさん** · 2018/03/12(月) 16:25:47.91

>>262
>>263
ほんこれ

**デフォルトの名無しさん** · 2018/03/12(月) 17:58:03.22

待て待て、>>257は速度追求の話ではないだろう
無駄なループを通らせないとかそういう話でしょ？

**はちみつ餃子** ◆8X2XSCHEME · 2018/03/13(火) 04:04:12.70

エッジケースで極端なことになってしまうって話かな？
そういうのは単に気をつけるしかしゃーない。
発覚したときに直せるような体制にしておけ～

**デフォルトの名無しさん** · 2018/03/13(火) 11:25:42.37

>>257
とりあえず注意すべきは線形探索かな
何も考えずに使われると素敵なことになる

**デフォルトの名無しさん** · 2018/03/13(火) 11:43:48.99

クラスAのメンバ関数へのアクセスをクラスBのみに許すにはどうすればいいですか？
（メンバ関数をfriend指定するのはBがAのプライベートメンバにもアクセスできてしまうのでNGです）

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

自己解決
passkeyイディオムを使えばいいんですね
言語仕様でサポートしてほしい気もしますが

**デフォルトの名無しさん** · 2018/03/15(木) 23:07:46.82

できる人にとってはくだらないことなんだと思うのですが、
char* c;
char *c;
この2つは一緒なのですか？

**デフォルトの名無しさん** · 2018/03/15(木) 23:12:48.58

char * c;
とか
char
*
c
;

も含めて一緒

◆QZaw55cn4c · 2018/03/15(木) 23:13:16.42

>>270
一緒ですが個人的に後者を推奨します

**デフォルトの名無しさん** · 2018/03/15(木) 23:21:50.62

>>270
>>271
ありがとうございます
どちらが正しいのか、機能が違うのか、よくわかっていなかったのがスッキリしました

**デフォルトの名無しさん** · 2018/03/15(木) 23:24:52.27

>>270
前者だと
char* a, b;
って書いたとaとbの型が変わっちゃうから常に後者方式で
char *a, *b;
みたく書くことをオススメする

**はちみつ餃子** ◆8X2XSCHEME · 2018/03/15(木) 23:48:02.28

ワイはアスタリスクを型名の方に寄せて、複数の変数の宣言をまとめないスタイルを推しておるやぞ。

char* a;
char* b;

まあ人によって色々やね。

**デフォルトの名無しさん** · 2018/03/15(木) 23:48:51.41

そんな迷うならtypedefしてしまえ

**はちみつ餃子** ◆8X2XSCHEME · 2018/03/15(木) 23:52:42.60

C++ なら std::add_pointer を使うのも手やぞ。
普段から使うには綴りが長い気もするな。

**デフォルトの名無しさん** · 2018/03/16(金) 00:04:03.30

ワイも後ろに寄せるスタイルの方が好きやな
別に自由ではあるけど、前に寄ってるとなんか違和感あるわ

**デフォルトの名無しさん** · 2018/03/16(金) 00:12:21.27

この話始まるとスレが荒れるわけだが。

俺は
char *a;
int & ref;
だ。

**はちみつ餃子** ◆8X2XSCHEME · 2018/03/16(金) 00:27:41.31

C++ だとスッポスッポ先生が (というより D&E の文中にあるコードが) アスタリスクを型名にくっつけるスタイルで書いてあるから、
設計者的にはこれが推しなんやろなて思うたんや。

**デフォルトの名無しさん** · 2018/03/16(金) 00:49:37.90

そもそもCならまだわかるがC++になってもこの謎仕様が改善されてないのがおかしいわな

**デフォルトの名無しさん** · 2018/03/16(金) 01:19:43.79

char *a;派だがキャストは(char*)だな

**デフォルトの名無しさん** · 2018/03/16(金) 06:18:52.71

両方に空白入れたり
両方詰めたらどうなるん

**デフォルトの名無しさん** · 2018/03/16(金) 10:14:04.60

>>275
これ

**デフォルトの名無しさん** · 2018/03/16(金) 16:35:23.76

>>274
それな
前者は誰が流行らしたんだハゲか

**デフォルトの名無しさん** · 2018/03/16(金) 18:15:24.73

``int* p;''と``int *p;''はどちらが正しいですか
http://www.libjingu.jp/trans/bs_faq2-j.html#whitespace

まあハゲの影響はあると思う

**デフォルトの名無しさん** · 2018/03/16(金) 18:16:24.05

偉い人が前で統一させてたから倣ってる

**デフォルトの名無しさん** · 2018/03/16(金) 19:01:00.72

>>285
マイクロソフトじゃないか？

**デフォルトの名無しさん** · 2018/03/16(金) 22:46:14.86

［］演算子は変数の後ろしか置けないので迷いがない

**デフォルトの名無しさん** · 2018/03/16(金) 22:50:13.34

変数との間に空白を入れるか入れないか選択の余地がある

**デフォルトの名無しさん** · 2018/03/16(金) 23:05:45.65

正直、選択の余地が無い方が嬉しい

**デフォルトの名無しさん** · 2018/03/16(金) 23:17:53.08

ある意味欠陥の1つ

**デフォルトの名無しさん** · 2018/03/16(金) 23:24:49.74

>>289
リテラルの後ろにも置ける

**デフォルトの名無しさん** · 2018/03/16(金) 23:28:34.45

あと数字の後ろにも置けるよな確か
x[2]は2[x]でも普通に動作するらしい、使ったことはないが

**デフォルトの名無しさん** · 2018/03/16(金) 23:32:56.43

参照型&ってあまり使われないのか

**デフォルトの名無しさん** · 2018/03/17(土) 02:01:02.93

>>293
宣言の中の型としての*の位置を問題にしてるのだから、式の中での*が使える位置については別の話でしょ。

**デフォルトの名無しさん** · 2018/03/17(土) 17:02:13.24

インデントってタブ文字使うよりもスペース使った方がいいんですか？

**片山博文MZ** ◆T6xkBnTXz7B0 · 2018/03/17(土) 17:07:21.02

>>297
見た目とコンパイル速度のどちらを優先するかによる。

**デフォルトの名無しさん** · 2018/03/17(土) 17:32:05.08

タブコードはエディタの設定に見た目が左右されるので使わない方がいい

**デフォルトの名無しさん** · 2018/03/17(土) 17:39:18.45

うーん、やっぱりタブは使うべきではないんですね

**デフォルトの名無しさん** · 2018/03/17(土) 17:41:47.51

昔は1バイト当たり単価が高かったからね

**デフォルトの名無しさん** · 2018/03/17(土) 20:01:33.65

エディタの機能向上による要素が大きいな。
インデントやその削除にキーを何度も叩かなきゃならない状態だったらTABがまだ主流だったろう。

**デフォルトの名無しさん** · 2018/03/17(土) 22:45:16.37

>>294
初めて知ったw

**はちみつ餃子** ◆8X2XSCHEME · 2018/03/18(日) 04:35:20.62

>>294
他にも変な仕組みは色々とあるけど、これはひとつとして使いどころが思いつかんよな。

**デフォルトの名無しさん** · 2018/03/18(日) 06:08:40.04

int a[10]; で a[5] でも 5[a] でも同じようにアクセスできるのは、
a[5] と *(a + 5) が同等で + 演算子の交換可能性から *(5 + a) も可、
それなら 5[a] も同じじゃなきゃ片手落ちだよね、って発想というか、
過去のコンパイラの実装とも関係がありそうな気がする。

もちろん、古いCコンパイラとのソース互換性が問題になるほど
みんなが使ってた書き方とは思わないけど。

◆QZaw55cn4c · 2018/03/18(日) 11:53:22.56

>>304
IOCCC …

**デフォルトの名無しさん** · 2018/03/20(火) 16:56:43.36

i++ と ++iって最適化すればほとんど変わらないか、あるいは++iの方がちょっと速いくらいですよね？
なんでi++の方がデファクトスタンダードみたいになってるんでしょう？
ほぼ無視できる程度のメリットしかないとしても、++iと書くデメリットがないと思うのですが