1read 100read
2013年01月プログラム14: 【初心者歓迎】C/C++室 Ver.81【環境依存OK】 (519)
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▼
Jython、Groovy、JRuby - どれが一番効率的? (268)
★★ Java の宿題ここで答えます Part 72 ★★ (544)
【Intel】OpenCV総合スレ 4画素目【画像処理】 (551)
自然言語処理スレッド その3 (641)
推薦図書/必読書のためのスレッド 69 (468)
Visual Studio IDE環境 (568)
【初心者歓迎】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推奨:◆QZaw55cn4c←半角にして登録してくだい
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に吹いたw
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ゲームでも作るんじゃなければ気にする必要はない。 ・ミューテックスの一般的な実装をイメージするならそこまで重く無いだろう。 ディスパッチした時は負荷がかかるだろうが、常識的な作りなら1スレッドの実行で数回発生するくらいでは。 ・1スレッドごとに200回のロック・アンロック。という設計思想が良く分からない。 ロック->アンロック->ロック->アンロック->の繰り返し?それなら効率が悪いからまとめてロックしとけ。 ロック->ロック->ロック->アンロック->アンロック->アンロック?200回とか階層深すぎじゃないの? ・全てのスレッドを60fpsで動かす必要が本当にあるのだろうか。同じスレッドをたくさん起動するのだろうか。
14 : Windowsならクリティカルセクションとかインターロックの方が早いかも知れない? ttp://www.isus.jp/article/intelguide/2-3/
15 : それ、ミューテックスが重いかどうかよりそんなに同期が必要になる時点で設計がおかしいよ。
16 : うんだ。設計がおかしい。 大方、画面中のオブジェクト1個ずつに対してスレッドを割り当てて それぞれが排他しないとまずいタイミングでロックかけようとしてる んだと思うけど、設計が頭悪すぎる。
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 : >業務用アーケード基板 近からずといえど遠からずだったなw
21 : >>18 ・60fpsというのは基本的に画面表示用スレッドの周期。 画面表示の無いサーバなら60fpsで処理する意味は無い。 ・普通に考えると受信スレッドとゲームスレッドの2つで良い。 ・受信スレッドは常時受信を行い、各ユーザーからの通信メッセージを受けてリストにする ・ゲームスレッドは常にループしていて、各ユーザーの通信メッセージを順次処理していく。 通信メッセージごとにサーバ上のゲームデータを更新し、必要に応じて通信メッセージを送信する。 ・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) として1つで済ませるのと int GetX() int GetY() の2つを提供するのとではどちらがより一般的なのでしょうか?
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) として1つで済ませるのと この形の一つだけっていうのならそれは間違いなく駄目な設計 そういうクラスを実際に使うとわかるが値の取得に変数が必要ってのは明らかに使い勝手が悪い
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 : ヨタついでにもう1つ。 昔の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 : gccならスマポを使う必要がもうないのでわ?
98 : >>97 え?なんで?
99 : gcc拡張ってのがあって、配列の宣言時、要素数に変数が 指定できるのですよ。 int a; a=100; char hoge[a]; ってもC++の話じゃないね。させん
100read 1read
1read 100read TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
【Perl,Python,PHP】LL バトルロワイヤル 28【JS,Ruby】 (417)
推薦図書/必読書のためのスレッド 69 (468)
Java系スクリプト言語Groovy (847)
プログラミング言語 Scala 8冊目 (726)
スレ立てるまでもない質問はここで 123匹目 (638)
TypeScript part1 (326)
--log9.info------------------
【クレイドル】藤野もやむ総合スレその5【ナイ☆チル】 (910)
月刊コミックブレイド 62月号だけ【毎月30日発売】 (587)
和月伸宏作品総合スレ3 (552)
【魔法少女プリティ☆ベル】KAKERU【天空の扉】4 (879)
DEAR BOYS act3 Vol.24 【八神ひろき】 (523)
【PandoraHearts】 望月淳22 【パンドラハーツ】 (347)
【SQUARE ENIX】月刊ガンガンJOKER Part14【毎月22日発売】 (524)
【SQ】 月刊ジャンプスクエア総合 part129【19】 (581)
【コロコロ】スーパーマリオくん 第3ステージ (428)
【押見修造】惡の華(悪の華)Part5【別冊少年マガジン】 (610)
【トライガン】内藤泰弘69【血界戦線】 (1001)
テガミバチ 浅田弘幸スレ (726)
ポケットモンスターSPECIAL part96 (437)
【ながされて藍蘭島】藤代健総合 42重婚【かへたんていぶ】 (917)
CLAYMORE(クレイモア)八木教広総合スレ224 (393)
【本田真吾】ハカイジュウ【月刊少年チャンピオン】 (686)
--log55.com------------------
【クチャ】クチャラーが嫌い【ペチャ】
【神に愛されし】1984年〜1986年生まれ【黄金世代】
0歳児よ、ここに集え!!
【底辺】30歳以上でバイトにくるオッサンとの接し方
【醜い女】ブスは世の中のゴミ【不要】
1998〜1999年生まれの人集まれー!!
【マッタリ】昭和37年生まれが集まるスレ【進行】
70歳以上で2ちゃんやってる人