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

1 ：2012/11/29 〜 最終レス ：2013/01/16

エスケープシーケンスやWin32APIなどの環境依存なものでもOK。
ただしその場合、質問者は必ず環境を書きましょう。
※sage禁止です(と代々スレに書いてありますが自己判断で)。
【前スレ】
【初心者歓迎】C/C++室 Ver.80【環境依存OK】
http://toro.2ch.net/test/read.cgi/tech/1348161305/
◆ソースのインデントについて
半角空白やTABでのインデントはスレに貼ると無くなります。
そのため、アップローダーに上げるのも手ですが直接貼る場合は、
全角空白か に置換すると見栄えだけはよくなります。
【アップローダー】(質問が長い時はココ使うと便利)
http://codepad.org/ (コンパイルもできるし出力結果も得られる[]privateをチェック)
http://ideone.com/ (時間帯によってはcodepadが重い事があるのでここも利用)
NG推奨:◆ＱＺａｗ５５ｃｎ４ｃ←半角にして登録してくだい

2 ：

clangはいつになったらWindowsで普通に使えるようになりますか？

3 ：

Hoge

4 ：

foobar, foo, bar, baz, qux, quux, corge, grault, garply, waldo, fred, plugh, xyzzy, thud

5 ：

>>2
cygwin にはすでにはいっている。

6 ：

前スレ>>1000のAAに吹いたｗ

7 ：

DMC8.55が出てるが更新履歴が見当たらない
何が変わったか分かるエスパーいますか？

8 ：

質問ですが、以下のリンカエラーが多発してしまいます。
multiple definition of 'error'
で、私は error という関数を定義していません。
/usr/include/c++/4.4/new:101でかち合ってるみたいですが
何が何やらサッパリです。
何から確認すればいいでしょうか。お願いします。

9 ：

ここはエスパースレじゃないぞ

10 ：

>>8
多重定義しているんでしょう。
まずは、自分の作ったヘッダファイル全ての1行目に
#pragma once
を書いてリビルドしてみたらいかがでしょう。
それでもダメなら別の原因。

11 ：

int main(void) { return 0; }
これだけでエラーになるならコンパイラが壊れている
#include でも何でも、どうしたら再現する不具合なのかを突き止めれ

12 ：

マルチスレッドの排他処理のミューテックスって重いんすか？
10スレッド動かして各スレッドが60fpsでループ、その1スレッドの1フレーム間でロックとアンロック合計200回とかきついっすかね？
10スレッドあるのでそれだけで2000回、他の諸々入れるとそのアプリ全体で毎フレーム2200回いく予定なんすけどね
2.4GHzのデュアルコアで他に重いものは動かさない前提っす
今の設計だと上記状態になるんで、無理なら開発を進める前にまた頑張って考えて設計を変更しなきゃいけないんす

13 ：

>>12
・Cの質問でない
・ミューテックスの重さはOSによる。もっと言えば実装による。
・そもそも組み込みで無いOSが動いているなら、そのOS自体の重さを考慮する必要があるだろう。
組み込みなら2,4GHzのデュアルコアとか神レベルの速さ。
いずれにせよハイレベルの3Dゲームでも作るんじゃなければ気にする必要はない。
・ミューテックスの一般的な実装をイメージするならそこまで重く無いだろう。
ディスパッチした時は負荷がかかるだろうが、常識的な作りなら１スレッドの実行で数回発生するくらいでは。
・１スレッドごとに200回のロック・アンロック。という設計思想が良く分からない。
ロック->アンロック->ロック->アンロック->の繰り返し？それなら効率が悪いからまとめてロックしとけ。
ロック->ロック->ロック->アンロック->アンロック->アンロック？200回とか階層深すぎじゃないの？
・全てのスレッドを60fpsで動かす必要が本当にあるのだろうか。同じスレッドをたくさん起動するのだろうか。

14 ：

Windowsならクリティカルセクションとかインターロックの方が早いかも知れない？
ttp://www.isus.jp/article/intelguide/2-3/

15 ：

それ、ミューテックスが重いかどうかよりそんなに同期が必要になる時点で設計がおかしいよ。

16 ：

うんだ。設計がおかしい。
大方、画面中のオブジェクト１個ずつに対してスレッドを割り当てて
それぞれが排他しないとまずいタイミングでロックかけようとしてる
んだと思うけど、設計が頭悪すぎる。

17 ：

あとなんか>>12の書き方から察するに業務用アーケード基板（TAITOのとか）
くさいニオイがぷんぷんするんだけど、こんなところで質問する前に会社の
上司とか同僚に聞いたほうが早いぞ。
スレッドに分ければオーバーヘッドが減るってものではない。

18 ：

>>13-17
ありがとうございます
MMORPGを作ろうとしているニートっす
質問はMMO鯖に関するものっす
最初のユーザーの同時接続数の目標を1000にしてたので、それぞれ接続チェックごとにメッセージキューのロック＆アンロックをすると上記の感じになるっす
1スレッドで1000接続全部処理するとタイムラグが出ると思って100接続ずつに分けようと考えたんす
でもスレッドを分けると、同期がいるじゃないっすか
だけどスレッドごとにロックするとそこでまたタイムラグが発生するじゃないっか
例えばスレッドAの誰かがスレッドBの2番目(B-2)の人に攻撃したとき、そのイベントの発生がB-1の人の処理をしてる最中だったとすると、
スレッドごとロックをかけていた場合、B-100まで処理が終わってアンロックされるまでB-2のキューに攻撃されたという情報が渡らないじゃないっすか
だけど接続ごとにロックする方式なら、B-1しかロックされていないからB-2のキューに情報を積めるじゃないっすか
少し前までチョン政府の助成金を追い風にチョンゲ企業が粗悪なMMORPGを大量に送り込んできたじゃないっすか
その助成金もなくなった今、反撃のチャンスだと思ってるんす
そしてそれで稼いでニート脱出するっす
とりあえず設計しなおします

19 ：

ROエミュのAEGISでも参考にすれば

20 ：

＞業務用アーケード基板
近からずといえど遠からずだったなｗ

21 ：

>>18
・60fpsというのは基本的に画面表示用スレッドの周期。
　画面表示の無いサーバなら60fpsで処理する意味は無い。
・普通に考えると受信スレッドとゲームスレッドの２つで良い。
・受信スレッドは常時受信を行い、各ユーザーからの通信メッセージを受けてリストにする
・ゲームスレッドは常にループしていて、各ユーザーの通信メッセージを順次処理していく。
　通信メッセージごとにサーバ上のゲームデータを更新し、必要に応じて通信メッセージを送信する。
・MMOの作り方みたいな本があるはずだから読んだ方が良いかも

22 ：

>>21
その本は買ったがプログラム初歩習得ゲームはド素人みたいな人向けに
基本のキの部分しか解説してなかった。役に立つかと言えば微妙。

23 ：

>>18
便所の落書きや知恵遅れで質問するなら趣味のプログラミングは辞めたほうがいい。

24 ：

質問です。
class PointTest {
private:
　　int m_x;
　　int m_y;
public:
　　void Set(int x, int y) { /*省略*/ }
};
　　
このようなクラスにGetメソッドを用意する場合
void Get(int &x, int &y) として１つで済ませるのと
int GetX()　int GetY() の２つを提供するのとではどちらがより一般的なのでしょうか？

25 ：

struct POINT {
int x;
int y;
};
class PointTest : public POINT

26 ：

>>24
両方いれたらいいじゃん
でもよく見るのは各成分getかな

27 ：

各成分getが多いけど
別に作りたけりゃ両方作ってもいいのよ

28 ：

メンバ変数をpublicにするのはこの場合適切ではないだろ。

29 ：

>>28
変数間で保つべき不変条件でも無けりゃ private にする意味ないでしょ。
点の x, y 座標間に何かそんな関係があるか？

30 ：

元の>>24でprivateにする意図を示しているのに
publicにしたら質問の意味がなくなるだろう。
馬鹿じゃないの？

31 ：

他のクラスのメンバで
void SetPoint(const PointTest& pt);
PointTest GetPoint();
ならまだ理解できるんだが

32 ：

privateにするのは不変条件のためだけの話じゃないぞ
ブレークはったりデバッグコード仕込んだりできるのも重要

33 ：

やっぱこれだろ。
get、setは余りたくさん書きたくないからx,yくらいなら構造体でまとめる。
struct Point {
　　int x;
　　int y;
};
class PointTest {
private:
　　Point point_;
public:
　　void setPoint(Point &point);
　　Point getPoint(void);
};

34 ：

プロパティってなかったっけ？

35 ：

しかしpointごときはprivateにする必要もないと思う

36 ：

>>24
getterが
> void Get(int &x, int &y) として１つで済ませるのと
この形の一つだけっていうのならそれは間違いなく駄目な設計
そういうクラスを実際に使うとわかるが値の取得に変数が必要ってのは明らかに使い勝手が悪い

37 ：

同時性にこだわる俺っち、別に潔癖症とは思ってない
C++ の const は性的だし♡

38 ：

有用を悩む程度のメンバアクセスにはアクセス専用の一時クラス通すんだよ

39 ：

適当な型を扱う時に
デバッグ用にブレーク貼れるようにする
クラステンプレート作ってるわ

40 ：

const Point& GetPoint() const；のがいいきがする

41 ：

山椒がピリリと引き立つわけですか

42 ：

Pointぐらいならpublicにしてもいい気はするけど、あとで何か処理が追加されるかもしれない事を考えてgetter,setterを用意するほうが良い

43 ：

C++初心者です
cout/wcout/printf/wprintf 全てを共存する一般的な方法はありますか？

44 ：

ラップ

45 ：

書き込むごとにフラッシュして使い分けるだけだろ

46 ：

Print()を作ってパラッパラッパー♪

47 ：

>>43
そもそも「共存」ってどういう意味なんだ？　そこがはっきりしないと答えようがない。

48 ：

説明するより見てもらったほうが早そうなのでコードを提示します。
http://ideone.com/WqXlDH
http://ideone.com/zzCBLZ
http://ideone.com/jx3wJU
http://ideone.com/rrhy6C
http://ideone.com/OeHtaM
http://ideone.com/1L9R8J
http://ideone.com/zRmV7N
http://ideone.com/Xdzc9r
こんな結果です。
msvcならバッファのflushに注意すれば大丈夫な気もしますが
gccでは諦めるしか無い？

49 ：

printfとwprintfは_tprintf
std::coutとstd::wcoutは共存しない

50 ：

>>43
仕様上はstreamにはorientationという概念があってnarrowとwideのI/Oを
同一のストリームに混在させられないことになってる
MSVCだと一見平気で混ぜられるけど、_O_U8TEXTみたいなモードは
orientationに基づいてるみたいで、その場合は混ぜられないよ

51 ：

>>50
解説したブログが見つかり納得するまでにはいかないけど
理解することは出来ました。
reopenするとかで何とか出来そうなこともなさそうだけど
コストが高そうなので諦めます。
ありがとう。

52 ：

>>50
orientationなる単語で検索したところ //←コピペミスで抜けてました。
解説したブログが見つかり納得するまでにはいかないけど
理解することは出来ました。
reopenするとかで何とか出来そうなこともなさそうだけど
コストが高そうなので諦めます。
ありがとう。

53 ：

イクリメント、デクリメントの後置きってどういう動作になってるんですか？
＞後置きの場合にはインクリメント演算子による演算以外の処理を先に行います。
ググるとこんな感じの事が書いてあるし、自分でもそうだと思ってたんですが
最後に後置きのイクリメント、デクリメントの処理がされると思ってるとなんかおかしい事になります
環境はwindows7でVC++2010Expressです

54 ：

>>53
×イクリメント
○インクリメント
例えば、j = i++はj = i, i = i + 1と等価だと考えればいい。

55 ：

>>52
普通はずっと片方を使い続ける

56 ：

副作用完了点(sequence point)で調べな

57 ：

しれっとstdout/stderrに出力するオープンソースのライブラリは結構あるので
そういうの使う時はorientationには要注意
そういうライブラリはまず間違いなくnarrowで出力していると思うが

58 ：

MC68000上で開発された名残がそこかしこに。

59 ：

インクリメントでした。恥ずかしい・・・
訂正ありがとうございます
副作用完了点でググったら一つの式で一つのオブジェクトの値の変更は一回しかできない、とありました
自分がやろうとしてたのは一つの式で一つのオブジェクトの値の変更が二回になっていたのでたぶんそのせいですね
ありがとうございました

60 ：

>>50
このような手当てが必要な理由はなんでしょうか？

61 ：

tcharの、charの前のtは何から来ているの?
あと　L"あ"の時のLは何から来ているの？
wide文字だよって示すならwprintf見たいに、w"あ"って感じにしたほうがいいような

62 ：

Lはlong
tはtext
wにしなかったのは、多分整数と合わせたんじゃないのかな

63 ：

LPCTSTR lpszText;

64 ：

long pointer constant text string long pointer string zero-terminated text

65 ：

long pointer ってなんですか？

66 ：

長いポインタです

67 ：

>>65
32ビットのポインタ。従来の16ビットポインタより長いという意味。
昔、16ビットと32ビットのポインタを混在して区別する必要があった時代のなごり。
今じゃ(少なくともWindowsやLinuxでは)サイズの異なるポインタが混在することはないから気にするな。

68 ：

>>67
far とは違うものなの？

69 ：

>>68
同じ

70 ：

>>68
違う。あっちはセグメント。

71 ：

どっちなの？

72 ：

http://msdn.microsoft.com/ja-jp/library/ff381404%28v=vs.85%29.aspx
P は "ポインター (pointer)"、LP は "ロング ポインター (long pointer)"
の略として使われてきました。ロング ポインターはファー ポインター (far
pointer) とも呼ばれますが、16 ビット Windows の名残で、現在のセグメント
の外にあるメモリ範囲をアドレス指定するのに使用されていました。LP プレ
フィックスは、16 ビットのコードを 32 ビット Windows に簡単に移植できる
よう、予約されていました。現在ではこの区別は存在せず、単にポインターと
呼ばれています。

73 ：

>>71
far pointerはsegment16bit * 16 + offset16bitで20bit(1MB)のメモリ空間を表すもの。

74 ：

>>73
しかしリアルモードではCPU 自身がセグメントを16ビット、オフセットを16ビットと持ち、12ビット分を重ねるのはCPU内
したがって記述レベル、たとえばアセンブリ言語で記述するときもセグメント、オフセットそれぞれに word=16bit の領域を準備することが多い
大概のC処理系でもそう。(sizeof(void far *) = 32)

75 ：

>>74
同じことしか言ってないように見える
最後4だし

76 ：

>>73
long pointer は FAR で定義されている
FAR を far で定義するか空定義にするかは環境次第

77 ：

farなんていうのは16bit x86（16bit プロテクトモードを含む）の
化石だよね。だから>>74がリアルモードに限定しているのは間違い。
16bit x86の設計は8bitCPU8080のコードをポーティングしやすくする
ためにアドレス空間も8080と同じ64KBを基本とした。
この範囲のプログラムはポインタも16bitで良かった。
だが時代が進みコードサイズが爆発的に増えた結果、オフセット
だけでは不足してきたので、セグメントとペアで扱うことにした。
だがC言語的にはポインタはポインタでしかないので、ポインタが
アドレス可能な範囲は実装依存だった。
でもオフセットのみのポインタとセグメントとペアのポインタは区別して
扱わないと開発上問題になる。そこで予約語farを定義して、farがつく
ポインタはセグメントとペア、それ以外はオフセットのみと定義すること
にした。
一般的にはfarのつくポインタだけをセグメントとペアのもの、つかない
ポインタはオフセットのみという認識だが、あえて両者を区別しやすく
するという意味でオフセットのみのポインタを「nearポインタ」と呼ぶ場合
もある。でも今となっては用済みのテクノロジでどうでもいいヨタ話。

78 ：

>>77
概ね同意です。

79 ：

ヨタついでにもう１つ。
昔の16bit x86用Cコンパイラには「メモリモデル」なるものが存在した。
詳しい話は英文だけど
ttp://www.c-jump.com/CIS77/ASM/Directives/D77_0030_models.htm
このへんを参照。
んで、開発を始める前にプログラム規模をまず見積もり、メモリモデル
のどれを採用するかを慎重に決める必要があった。なぜなら途中から
メモリモデルを変更するとコード全体に波及する可能性があったから。
大抵のプログラムでは単一コードセグメント、単一データセグメントで
間に合うものだったが、後々の保険にということで複数セグメント前提
にしてポインタを全部farにする、なんていう「大は小を兼ねる」判断も
行われていた。

80 ：

MS-DOS陣営と違い意外に知られていないが、Mac-OSも680x0の時代は
32KBのコードリソースに入るサイズで切り分ける必要があった。
コードリソースと言う制約自体はMac-OSをベースにしていたPalmOSにも受け継がれた。

81 ：

32KBのコードリソースっていうのはおそらくMC680x0における
ショートジャンプ（PC相対とかレジスタ相対ジャンプ）の範囲で
おさめるための策だと思われる。
時代背景から考えて現実的とは言えるけど、単なるウィンドウ
システム側の制約なだけ。MC680x0はリニアなアドレス空間で
16MBまでアクセスできた。

82 ：

LPは16-bit時代の遺産だからな
farポインタの存在する環境であればfarポインタになるのだが
32-bit環境以上なら普通のポインタと同じ

83 ：

コードリソースの32kBというサイズはPC相対アドレッシングの制約からきたものかも
知れないが、セグメント間はA5相対JSRでアクセスするようコンパイラが判断するから、
関数ポインタを使いたいような場面でもない限りプログラマが意識する必要はなかったな。

84 ：

昔のコンパイラは
switchがショートジャンプなので
延々と処理を書くと
適当なとこにジャンプしてた

85 ：

>>84
「適当」って「適切」じゃなくて「いい加減」という意味ですか？
怖いですね。

86 ：

昔のコンパイラと言うかそのコンパイラが手抜k

87 ：

飛べねーぞごらぁ って言うのは見たことあるけど、変なとこに飛ぶコードを吐く奴は
さすがに見たことない。

88 ：

質問させてください。
http://www.geocities.jp/ky_webid/cpp/language/007.html
上記のURL中に
「デストラクタですが、これはクラスのインスタンスが解体されるときに、
解体の直前で自動的に呼び出されます。
解体されるタイミングは、そのインスタンスのスコープを抜けるときです。 」
とあるのですが、
では
IProduct* createFactory(Content* content)
{
switch( content->id )
{
case PARTS_ID_A:
return new ProductA( content );
default:
return NULL;
}
}
ProductA* product = createFactory(content);
のようなコードはなぜ正常に動くのでしょうか？？
createFactory内でnewしたProductAはすぐreturnされてスコープを抜けてしまうので
その時点でデストラクトされ、
productに代入されるポインタはすでに使えないものになっているのではないのでしょうか？
理屈がよくわからないのですが、教えて頂けると嬉しいです。

89 ：

newで作成したインスタンスはスコープを抜けても勝手にデストラクトされない

90 ：

>>88
new で得たポインタはdeleteしない限り無効にはならない
new で得たポインタは関数を超えても生き残り続ける
new したものはdeleteせよ、という宗教もここからきているかと

91 ：

C#だとnewばっかで滅多に削除を明示しない

92 ：

なるほど！
ありがとうございますm(__)m

93 ：

C++でもスマートポインタ使うから滅多に削除を明示しないよ。

94 ：

構文レベルの予約語なのに滅多に記述されずラップして使われるのは
言語としてヤバイ状態なんじゃないかな

95 ：

何がヤバイんだ

96 ：

gotoみたいなもんだ
下手に使うと危険だが、上手く使えば効果的

97 ：

ｇｃｃならスマポを使う必要がもうないのでわ？

98 ：

>>97 え？なんで？

99 ：

gcc拡張ってのがあって、配列の宣言時、要素数に変数が
指定できるのですよ。
int a;
a=100;
char hoge[a];
ってもC++の話じゃないね。させん

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

Perlについての質問箱 57箱目 (373)
サウンドプログラミング5 (697)
proce55ing　プログラミングアート全般 (636)
Ruby 初心者スレッド Part 50 (947)
VBScriptについて必死に話し合うスレ (374)
データ構造とアルゴリズム総合 (604)
--log9.info------------------
【西内まりや】Seventeen Part99【鈴木友菜】 (383)
【プロ書評】吉田豪のR人生10【コピペ】 (367)
【人非人】週刊新潮＆週刊文春スレPART4【御用達】 (490)
【25ans】エレブロガー＆BMpart9【珍獣】 (658)
【昇給停止】光文社再建は可能か?vol.21【サビ残】 (967)
週刊ポスト＆週刊現代総合スレ3 (491)
Oggi◆オッジ◆Part3 (586)
女性自身＆週刊女性＆女性セブン総合スレ (647)
フリーライター限定　〆切り29日過ぎました (308)
【豆R】 テレビ誌 TV雑誌 【角川】 (834)
★角川グループについて語りましょう★1 (956)
★★★【光文社】VERY Vol.1【ヴェリィ】★★★ (642)
■■　週刊プレイボーイ２　■■ (864)
FRIDAY・FLASH総合スレ (404)
リアルライブ＞＞＞＞＞＞サイゾー (504)
【町内会】ファミ通町内会14【四コマ単行本】 (324)
--log55.com------------------
2019夏の甲子園　好投手ランク付け ２
【頑張れ】滋賀県高校野球スレ147【湖国球児】
【最弱地区】 関東の高校野球 ８７９ 【雑魚】
宮城県の高校野球47
第101回全国高等学校野球選手権大会 勝敗予想スレ 4
【急募】星稜が智弁和歌山勝てる方法
千葉県の高校野球 Part834
愛知県の高校野球155