C++相談室 part131 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
次スレを立てる時は本文の1行目に以下を追加して下さい
!extend:on:vvvvv:1000:512
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。
前スレ
C++相談室 part130
http://mevius.2ch.net/test/read.cgi/tech/1490917669/
このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.100【環境依存OK】
http://echo.2ch.net/test/read.cgi/tech/1478440682/
■長いソースを貼るときはここへ。■
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
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured >>773
ほっといたっていずれ覚えるだろうに何故押し付けるのか >>776
より良い代替案があるんだったらそっちに誘導すべきだろう。
実際使うべきじゃないし。 >>776
このスレ的にはって書いてあるのが読めてないのか
自分が苦手なものに触れられたくないのか
どっちだ？ >>779
最近お前みたいなニワカが増えてうんざりするわ
というかCの可変長引数がどこに出てきた？ つかぬことを伺いますが、
あるクラス内で定義した構造体を同クラス内でstatic constメンバとして宣言し、
外部で定義しようとしたところ、「〜との互換性がありません」と出て上手く行きません
どうすればよいのでしょうか
〜ヘッダ内
class Hage{
public:
struct A{
int a;
int b;
};
static const struct A M;
}
〜ソース内
#include "ヘッダ"
const struct A Hage::M; //不正 const struct Hage::A Hage::M; >>781
少なくとも Hoge::A としなけりゃダメなんじゃないか
>>771を読んでもCの可変長引数とは決めつけられなかった うわあ何でこんな初歩的なことに躓いていたんだアホらしい
>>783-784サンクス ###HUM###
000-K,AZ,0,1,
001-KI,L,I.T,DEF,11.2,TE,F,0.12235,
002-EM,OBLA,7##END >>780
うわーおまえ、それ人に聞かなきゃ判んねえの？
省略記号は右端という初歩の初歩でミスりながら
ドヤってる笑い地獄が２日前あったんだが
突っ込めなきゃせっかくボケた芸人も泣いてるだろうな >>773の「モロじゃねえか」がどっから出てきてるのか謎だ 多分Cの可変長引数なら右端以外にも書けると思ってんじゃないかな こんなイメージかな？
#define X (100)
#define f(a,b,c,d,e) ((b)[(c)+X*(d)+X*X*(e)] = (a)[(e)+X*(c)+X*X*(d)]) >const struct A Hage::M; //不正
初歩的でなく相当に高度な気がしてならない
規格の3.4.1/p7,p8,p14あたりを頭に入れていないといけない
「class NS::C;」のように何でも「::」を付ければ良いと言うわけでもないので だってグローバルスコープにも struct A; が存在したらどうなるか？
って考えればすぐわかりそうなモノじゃんね グローバルが優先される所と、グローバルよりクラスや名前空間が優先される所が入り乱れたこの言語で
どちらが優先なのかを正確に覚えてるのはかなりの変人である可能性が高い
https://ideone.com/RZTBk7 >>795
その例ではいったんA::の中に入っているから B はA::B になるけど
>>781 のはそうじゃないからな。 >>788
おーいバカ、省略記号の位置の件はわかったか？
まさか789なみの重度池沼じゃねえよな >>771は>>770を参考にして新たに考えようとしてるじゃないか。
それを>>770のやり方でまんま行こうとしている、と解釈するのは悪意があるぞ。 >>800
お前まだ分からんのか・・・
>>770のどこが大ボケなんだよ
添え字演算子の中で二項演算子の後に省略記号書いて再帰的に計算させたり
パラメータパック（またはそれを含む式）も無しに引数の左端にいきなり省略記号書いたり
なんてのはCでもC++でも出来ないの
お前みたいにCの可変長引数もvariadic templateも分かってるつもりなら
>>770を見た瞬間にこれは文面上の省略であって動くコードではないと一瞬でわかるはずなんだよ
質問でもないのにageまくるわ自分も初心者のくせして同じ初心者（あるいはそれ以上）を聞きかじりの知識でバカにしようとするわ
憂さ晴らしにしか利用しないのなら出ていけ 文面上の省略だっておｗ
大ボケに苦しい言い訳を上塗りして
アフォから超アフォに進化したなあ 驚いた、ム板にIP信者がいるとはね
嘆かわしい限りだ >>800
だったら>>771をターゲットにすればよかったんだよ
お前は>>770をも貶し続けていると見なされていたんだよ 大ボケ＋言い訳＋IP信者＋錯乱
この安定したアフォぶりは、どう見ても同一人物だなｗ %%%3%%%
000-DOK<NAZE-0.8112162>
001-3800%\73NMB/1,81,2,NB"IKKI"%
002-91.81%ML7"8.122231746668193,43@ML.4@"%^23.1444
003-1.33321444718%"YLD""SO"%{71.%{62.1339816{331.422231765%<<<NL6
004-LOOP%Go To"000"%
VCL javaやc#しかやったことないような人間がc++でもメモリ管理をきちんと身につけるには何から始めるのが手っ取り早いでしょう？ >>812
C++ ではなるべくスマートポインタを使って自動化すべきなんだけど、
その内側にあるメモリの気持ちを実感として持つには C の範囲で色々やってみるのもいいかな。 >>812-813
JavaやC#が選択肢になる状況でC++を選択する理由はない。
今C++を何に使うか決まってないのなら、JavaやC#を極める方向に努力した方がいい。 VisualStudioでMFCのSDIテンプレートを作ると、ドキュメントクラス、ビュークラス、アプリケーションクラス、メインフレームクラスができますが、
これらのポインタを初期化時にグローバル化しておいて、以後あらゆるクラスから気軽にアクセスできるようにしとくのは良くないんでしょうか？
グローバル変数はあまり使うべきではないという考えは置いておくとして、動作上問題は起こるのでしょうか？ 問題が起こらないように作れば起こらない
としか言えない MFCのtheAppには100万回ぶち切れてきたけど動作上は特に問題は無い あーこの人、こうやっちゃったんだ(ﾆﾔﾆﾔ
しながら使うもの
ARM C++ベースなんで同情するところもあるけどね グローバル変数だからといって頭ごなしにぶち切れるのもいかがなものか…
CPU視点でやるべきことに対して処理順序にあいまいさが生じないなら実行上問題無いし、
プログラマーの視点で管理できる個数なら実用上も問題無い
同一クラスの複数インスタンスが欲しければグローバルな配列にしたらやり過ごせる
ていうか仮にtheAppを根とする木構造で全てのデータを管理することを思い立ったとして、
その木の根付近をぶち切って得た2〜3の大枝をグローバル変数を根とするそれぞれ別の木にする、ぐらいの
挿し木設計は設計上のショートカットとして許されるべきや
というのは、プログラムのあらゆる箇所で
theApp()->getMemberA()->getMemberAA()->getMemberAAA()->...->getMemberZZ()->getValue()
と書かねばならなかったものが、
g_dataAA->...->getMemberZZ()->getValue()
ぐらいで済む 平気でグローバル変数を使う奴はtheAppの混じったコードを使いまわし続けて大量にデータを持たせるようになる
そして結合しまくりのクラスを他のソフトにコピペしていつのまにか神theAppができある
マルチスレッドで読み書きしてるもんだから予想外のバグが起こる
上司はそれでそれが当たり前だと思ってるから同じようにしろと俺に命令する
俺切れる >マルチスレッドで読み書きしてるもんだから予想外のバグが起こる
これはグローバル変数でなくとも起きる設計なら起きるから別件
ていうか
>CPU視点でやるべきことに対して処理順序にあいまいさが生じ(>>822)
ているケースにあたる
非同期呼び出しの同期化は呼び出される側のクラスで解決すべき、というだけ
メソッド内で完結できれば最も安全
パホーマンスや処理の粒度の関係でそれが適さない場合は
トランザクション処理をちゃんと設計汁、 >>823
アプリケーションの中で寿命の長いデータはどこにどうやって置いてるの？ >>824
ちょっと足りなかったわ
マルチスレッドでかつ複数のクラスを跨って別々の場所で読み書きされているからいつどこで変更されるかわからないことが多々ある
そうなるとあちらを立てればこちらが立たずといった感じになり、きれいに書く気力が失われてさらに汚さが加速する
>>825
必要なデータだけを引数で与えるべき グローバル変数で同期とるんじゃないぞ。そんなもので同期なんて取れないからな。
ちゃんとOSが提供する同期オブジェクト使えよ。 どんな環境でもOSがあってしっかりした同期の仕組みが有るとか思ってるお花畑がいると聞いて いやはや無知で申し訳ない。
マルチスレッド機能があって同期の仕組みが提供されない処理系があるならばご教授して頂きたい。 文脈上Windowsでの話なのははっきりしてるのに「どんな環境でも」とか >>826
>必要なデータだけを引数で与えるべき
引数を渡す側がそのデータをどこにどうやって保持すればいいのか、という問題が残るだけでは？ >>831
> 引数を渡す側がそのデータをどこにどうやって保持すればいいのか、という問題が残るだけでは？
再帰的にたどって行けばいいだけかと
プログラムの寿命とほぼ同じ寿命が必要ならmain( )で定義することになるだろうし どうしてもグローバル的なものがほしいなら、グローバルにしてしまえよ。
アクセス用の関数だけしっかり同期処理書けばいい。 んまーマルチスレッド機能有りのOSであり
(1) OSがプリエンプトしてくるのを止めるAPIが無い
(2) ユーザープログラム独自に割り込み禁止命令を実行できない（特権命令違反でトラップされる
としたらユーザー側ではフラグのread modify writeのアトミック性を保証する術がまるきり無くなる いやすまん下記も追加
(3) interlock系の命令が使えない（特権命令違反か何かでトラップされる
(3)は使えるかな普通…
>>829のは杞憂かもしれんな… しかしまあ同期処理はOSが提供すべき（理念としてだけでなく、その方が効率よく実現できるから
というのは同意
マルチスレッド機能があるOSなら必ずプリエンプトされないコード範囲を持つので、そこでなら
interlock系の命令を持たないZ-80みたいなCPUでも何も問題なくアトミックなread-modify-writeができる、 >>834-835
Compare-And-Swapとかの命令が特権命令になってるプロセッサなんてあるんだっけ？ >>837
Interlock系命令の意味で言った
正しい言葉使いかは知らん…！ atomicなread及びwriteが使えるならmutexを構成できるし、それを利用すればread modify writeも可能だよ。 ミューテックスが何だって？
くだらねえ話しやがって・・ >>831
どんどん上にたどっていく
そのデータを管理しなければいけないクラスあるいはmain関数が保持すればいい
externした変数はそのクラスが所有権を持っていることと同等なので、パフォーマンス上の都合が無ければ極力共有は避けるべき
あとコードを使いまわすときにも障害になる
ファイルにまとめて他でincludeしてもそのまま使えない >>841
＞そのデータを管理しなければいけないクラスあるいはmain関数が保持すればいい
クラスが持つっていうのはそのクラスのスタティックメンバにしろという意味？
それでは結局グローバル変数とか無名namespace内変数とあまり変わらないような気がする。 >>842
言ってる意味がわからない
クラスA内クラスBとCを宣言して
B b;
C c;
c.set_data(b);
だとか
main関数内で
Dptr d_ptr = D::get_resource();
Eptr e_ptr = E::get_resource();
F f(d_ptr, e_ptr);
f.excute();
とかこんな風にする >>843
んー
＞そのデータを管理しなければいけないクラスあるいはmain関数が保持すればいい
「あるいは」ってどういう意味？
main関数内に持つ方はわかるんですよ。
そうでなく、「クラスが保持」の方の解説をお願いしたい。ずっと保持し続けるんだから
スタティックメンバなのかな？と思った。 >>820
では、例えば初期化時にtheApp内に、Doc、View、MainFrmクラスのポインタをメンバに持たせておいて、
以降、あらゆるクラスからtheAppを介してアクセスしてもよいということですね。
こういったやり方でふとよぎった不安なんですが、
長時間アプリを起動していたとき、とあるクラスの参照ポインタがいつのまにか変わっていて、
例えばビュークラスを取得しようと「theApp.GetView()」としたときにはすでにそこにViewクラスはいない。。。なんてことは起こりませんか？ >>844
普通なパブリックなメンバでいいと思うけど
その所有権をもったクラスの寿命が尽きたら同時に開放される
>>845
もちろん参照元からは参照先の実態があることが保障されないのでよくある
特定のメンバの参照数が数百箇所になってたときは手に負えなくなったのでさすがに作り直した >>848
推敲とかしてないのである程度読み替えて言いたいことを汲み取ってね
そのクラスの変数の寿命な うん、寿命の長いオブジェクトをどうやって保持し続けるかっていう話なのにね 悩む理由がよく分からないが。適当な管理クラス作ればいいだけでは。 >>849
寿命の長いオブジェクトをどうやって保持し続けるかがテーマなので、
「a というデータはクラスBのオブジェクトbに持たせればいい」では
じゃあそのbはどこにどうやって保持し続けるのかという無限後退に陥る。
普通のグローバル変数やシングルトン
theAppにぶら下げるの
mainの中に置く
一長一短あるのでそれ以外に何かないかなという話 別に永続化、シリアライズの話までしてないわけでしょ。
mainかグローバルの2択で推奨はmain、どのスコープからも見えてアクセスしたいならグローバルもありで終わりでしょ。 >>853
あなたの意見は>>833以降ずっと一貫しているからいいですよ。
>>823の意見がわかるようでわかりにくい >>846
>>もちろん参照元からは参照先の実態があることが保障されないのでよくある
ソースコードで意図的にdeleteとか、アドレス移動する命令をいれてなくても起こるんですか？
（ガベージコレクションみたいなことが） >>829
無知を謝る必要はない
マルチコアのDSPをOSレスで使うとか >>826
パラメータで渡すべき情報と
そうじゃない情報と
がある >>852
スタティックメモリ(グローバル変数など)
auto変数(スタックやレジスタなど)
OSやAPI側の保存領域(APIを用いた設定など)
ファイルなど > プログラムのあらゆる箇所で
> theApp()->getMemberA()->getMemberAA()->getMemberAAA()->...->getMemberZZ()->getValue()
> と書かねばならなかった
本当にあらゆる箇所に重複コードを書きまくっているとしたら相当なアフォだな
関数化かキャッシュするだろふつー 最近WindowsのほうでVSを入れまして、簡単なSTGを作って遊んでいるのですが、MacOSでもC++でSTGを作ることはできるのでしょうか？
Windowsでは、DxlibといったSTG制作に特化したライブラリがありますが、MacOSではどうなのでしょうか…？実際にMacでSTG制作の経験がある方、挫折した方の話をお聞かせください。よろしくお願いします。 >>864
何かおかしなことを言っていたらすみません。
STG制作入門のホームページでそのようなことが書かれていたので、そう認識していた次第です。 それはDirectXの薄いラッパなので何に特化しているとかはない
マルチプラットフォームで作りたいならOpenGLで作れ OpenGLか…
難しそうだしまだ取っ付くべきじゃないような気がするんだけどそんなことはない？ >>845
それぞれアクセス関数が用意されているので馬鹿なことはやめなさい >>862
黙れよｷﾁｶﾞｲ
theApp()はtheAppかthisの間違いだがそれは別にして
メソッドgetMenberA()を有するクラスから始まって、
メソッドgetValue()を有するクラスFooまでの全てのクラス
が完璧にカプセル化された設計の元で
theAppから配下のFooのメンバにアクセスするアクセッサは実質的に>>862な状況を呈する
これはもう完璧なカプセル化を諦めて途中までグローバル変数にする（挿し木設計）か
インライン展開による最適化を期待するぐらいしか手が無い まあ神の視座に立てば完璧な抽象化を徹底してそんな深いアクセッサをいらなくすれば良いのだが
そんなことが最初からできるなら苦労は無い、 > カプセル化を諦めて途中までグローバル変数
ヘボ野郎 二次元配列の中身を1命令で一気に出力する方法はないでしょうか
いちいち2重ループかくのめんどくさいです ■ このスレッドは過去ログ倉庫に格納されています
