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 >>760
その例だと A[X][X][X] の３次元相当だけど３次元限定でいいの？ >>760
こういう解釈でいいかな？
template <typename T, std::size_t X>
void fillA2B(T (&A)[X*X*X], T (&B)[X*X*X], int ax1, int ax2, int ax3)
{
int i, j, k;
int& ii = (ax1==1)? i: ( (ax1==2)? j: k );
int& jj = (ax2==1)? i: ( (ax2==2)? j: k );
int& kk = (ax3==1)? i: ( (ax3==2)? j: k );
for ( i = 0 ; i < X ; ++i )
for ( j = 0 ; j < X ; ++j )
for ( k = 0 ; k < X ; ++k )
B[ii + X * jj + X * X * kk] = A[i + X * j + X * X * k];
}
int main()
{
const int N = 2;
int A[N*N*N], B[N*N*N];
int n{0};
for ( int a = 0 ; a < N*N*N; ++a )
A[a] = n++;
fillA2B<int, N>(A, B, 1, 2, 3);
fillA2B<int, N>(A, B, 2, 3, 1);
fillA2B<int, N>(A, B, 3, 1, 2);
return 0;
} 左辺が j, k ,i 右辺が i, j, k のようだが ……素直に3次元の配列にすりゃあいいんじゃねえのかなコレ
どーーーしても1次元にしなきゃいけない重大な理由が背後に控えてんのかな？ B[ii][jj][kk] = A[i][j][k];
でも通るな >>761
もちろん任意の次元を一度に扱えたら最高です。
ゆくゆくは各添字の次元を変えることも考えています。
>>762>>765
すみません。
全要素を並び替えたいです。
>>766
カラムメジャー、ロウメジャーを任意にしたいという背景があります。
また、各添字の次元が本当は任意であるということもあります。
>>763
ありがとうございます。
確かにこれで>>760はできそうです。
パーミュテーションの実装の仕方が分かりました。
原理的にはこれで任意の添字の数、次元に対応できる (それぞれ関数を作る必要はある) と思うのですが、もっとアカデミックな方法ともあるのでしょうか？ >>769
アカデミックは知らんが一般化するなら
B[ i*bi[0] + j*bi[1] + k*bi[2] + ... ]
と各次元ごとの係数を変数にして設定だな
>>760のたとえばでは bi[0] = X*X, bi[1] = 1, bi[2] = X
あとはインターフェイスにあわせてヘルパ処理を用意すればいい
f(... int x, int y, int z)
int bi[3];
bi[x - 1] = 1;
bi[y - 1] = X;
bi[z - 1] = X*X; >>770
ありがとうございます。
あとは任意個数の引数を取れるようにすれば添字がいくつあっても、各添字がどのように走っても一つの関数で対応できますね。
勉強になりました。 任意個数の引数って、まさか省略記号と可変個数実引数では・・・
と思ったらモロじゃねえか おいおい
このスレ的にはinitializer_listやtemplate parameter packだろ >>773
template parameter pack って variadic template と同じもの？
後者の呼び方には馴染んでるんだけど。 >>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を用いた設定など)
ファイルなど ■ このスレッドは過去ログ倉庫に格納されています
