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 >>501
すみませんでした
こっちで質問してみます c++に限った話じゃないんだけど参考書
とかだとメソッドの後にフィールドが
書かれてる事が多いようだけど、それが
一般的なの？ ちがう
一般的にはフィールドたるメンバ変数の方が先に来る
学習の都合で、メンバ変数を先に説明した方が、どう考えてもラク
メンバ関数を先に説明すると、入門書を読むレベルの初心者は間違いなく混乱するので、そんな参考書はまず見かけない
そもそもメソッドの中で使う変数は始めに宣言しておかないと使えない
結論としてはあなたが用語の取り違えをしてる……としか レイアウト、というとデータの並び順の意味にとられかねず語弊がある public、protected、privateの順に書いていくと
自然と変数はpublic関数の次に来るわ 普通アクセス修飾子の順じゃなくてフィールド→メソッドの順じゃないの
カプセル化するから変数なんてほとんどprivateだろうし
変数は変数でまとめて書いてもらわないと混乱する ユーザーにとって重要な項目から順に書く
つまり、public→protected→privateで
ユーザーに見せる必要のないprivateは一番下で 変数の宣言と関数の宣言の順序がどうでも良いのは自明
メンバ関数の定義がメンバ関数内で使用するメンバ変数の宣言に先行する場合も実験する限り合法
（規格に具体的にどういう文言で規定してあるのかは知らん
まあ定義時点で不完全な型やら値やらはテンプレートの定義で頻出するから
あんま定義と宣言の順序にこだわらない処理系の作りなのだと納得しておく
しかしなぜかテンプレートの引数でない型の定義（または宣言）と使用には厳格な順序を求められる…
次のコードはビルドが通らない
class Baz {
// struct Bar; // 左のコメントアウトを外したら逝ける
void foo(Bar& b);
struct Bar { int x, y; }
};
多分Cとの互換性のために仕様がﾜｹﾜｶﾒになった例 ルールが存在してwell documentedで、ガバナンスがきいていることが重要
お前らのオレオレ哲学なんかどうでもいい ああそっか、プロトタイプ宣言しなきゃいけないんだっけC++は
C#の脳で考えてたわ >変数の宣言と関数の宣言の順序がどうでも良いのは自明
自明かねぇ
C++11は問題になる例が思いつかないがC++98,03,14はどうでも良くない コンストラクタ実行時のメンバ変数の初期化の実行順が、初期化子の記述順ではなくクラス定義での並び順に従うっていうのがあった気がするけど、新しい規格では変わったんだっけ？ >>516
うそーん、初期化子の記述順＞クラス定義の並び順だと思ってた。
てか、宣言の並び順は無関係？
そら、警察官も道行く江添さんに聞きたくもなるわｗ >>516
微妙な表現以外、特に変わったという話は聞いたことがない
C++03 12.6.2/5
Then, nonstatic data members shall be initialized in the order they were declared in the class definition (again regardless of the order of the mem-initializers).
C++20 draft 15.6.2/(13.3)
Then, non-static data members are initialized in the order they were declared in the class definition (again regardless of the order of the mem-initializers). >C++11は問題になる例が思いつかないがC++98,03,14はどうでも良くない
とか書いてるから何か制約が無くなるような変更があったのかと思って聞いたんでない？ ちな漏れがどうでもよい（どんな順序でも問題ない）と言ったのは
変数の宣言と関数の宣言の順序（どちらを先にするか）だからな
これ豆な C++11でもこれがあったか
struct A {
int m;
decltype(m) /*←mは先に宣言が必要*/ f() { return m; /*←mは後でもいい*/ }
};
C++11で緩和されたのは11章のどっか(忘れた) static メンバ関数と friend 関数の使い分けについて教えてください
どちらも似た機能だと思ってしまうのですが‥ あ〜、そんなこと考えたことなかったけど、クラス (メンバ関数) 内部から見たら近いっちゃ近いのかも？
クラスを定義する側じゃなくてそのクラスを使う側の気持ちで考えて。 friend 関数は public で，static メンバ関数は private で，て感じでこの前は書きました
普通はどうするものかをお聞きしたいところです すまんけど自明すぎてどう使い分けるとか説明できない。
使い分け以前にそもそも理解できているか怪しいと思う。 何度も宣伝するようで気が引けますが，前に書いたのは >>158
演算子のオーバーロードに絡むものは基本 friend で，内輪で使うものは private の static メンバ関数で，
くらいの線引きをしています．
書いてみてわかったのは「自明」という感じはしないこと，かな，考えてみれば friend 関数って他の言語にはなさそうです 何で？ operatorはグローバルに出さなくても多重定義候補に挙がるぞ
俺は別の理由でoperatorをグローバルにする傾向があるが >>527
http://codepad.org/8Z3c2obA
ほー，これは不思議だなあ‥
friend をはずすとコンパイルできない
friend をつけてしまうと public に置こうが private に置こうが関係ない，という認識であっていますか？ 何が不思議？
friendを外すとメンバoperator+に過剰な仮引数となりエラー
friendは「メンバではない」のでアクセス指定は無関係
1点だけ気になるのが、friendは当該クラス自体と同じスコープに新しい識別子を導入しないはず・・・
識別子はoperator+で、これのみは某か標準のヘッダで既に宣言されているということか？ >>529
＞operator+に過剰な仮引数となりエラー
つまり operator+ の >>528 とは違うもう一つの呼び出し書式にしないといけないわけですね．
でもこの場合は private に置くとコンパイルできない
http://codepad.org/RLo9fKuI
friend はアクセス制御如何にかかわらず「強引にpublic にする」ように見えますね‥わからない‥ friendなら、その人のプライベートにアクセスできる。それだけの意味。 ある人のfriendなら、その人のプライベートにアクセスできる。 >>531
>>522 をどうかよろしくお願いいたします． >>530
強引にpublic・・・で憶えやすいならそれでいいんじゃね？
ちな俺の憶え方はメンバでないものをどうやってprivateにするんだ、だ あるクラスX内部のstaticでpublicな関数fは、Xのインスタンスの存在に関係なくX::fという名前でアクセスできる。
あるクラスX内部のfriendな関数gは、X内部のプライベートなメンバーm_aにアクセスできる。 >>534
確かに friend 関数は「メンバーじゃない」ですか‥main() と同じような普通の関数なわけですね‥ friendは他のクラスのメンバかも知れない
そういうときも俺の憶え方なら動揺せずに済む メンバ関数より、メンバでもfriendでもない関数を使おう
って誰かが言ってた 欲しい機能がメンバでない関数で使えないとなれば
それはクラスの設計ミスないしはダサい設計だかんな
クラックできちまうのと違う提供すべき機能の欠落 >>530
(1) friendが無い場合
「z = x + y;」に出くわしたコンパイラは
1. インスタンスxに対しするC::operator+(y)（1引数）の呼び出し
2. グローバルな関数C operator+(C const& a, C const& b)（およびその亜種）の呼び出し
のあてはめを順次試みるがどちらの関数も宣言が存在しないからあてはまるものが無くエラーになる
(2) friendがある場合
friendがつくことでoperator+()はCのメンバ関数ではなく、グローバルな関数として宣言されたことになる
このとき「z = x + y;」に出くわしたコンパイラは、上の1、2の順で当てはめを試み、
グローバルな関数C operator+(C const& a, C const& b)の呼び出しと解釈する。
本来この関数はクラスCのprivateメンバにアクセスできないが、friendの力でそれができ、めでたくビルドできて動く。
細かい話は規格の人がフォローして☆ﾎｽｲ >(2) friendがある場合
最も近い(内側の)名前空間の関数になる(11.3/6-7)
friend関数がメンバーではないことがC++14に明記されていなかったようで、C++17ドラフトに追記された模様(N4659 12.2/2)
＜おまけ＞
宣言の場所がクラス内という事情により、リンカーはともかくコンパイラーから存在が見えにくい関数となる
この関数を使うには
・名前空間スコープで明示的に宣言し直す
C operator+(C const& a, C const& b);
・ADL(argument dependent lookup)でクラススコープの検索を発動させる
>>541でoperator+が呼び出せているのはADLによる つまりクラスの外で定義された関数をイメージすればいい
struct A { friend void operator+(A,A) {/**/} };
↓
struct A { friend void operator+(A,A); };
void operator+(A,A) { /**/ } // ただしADLが無いと見えない ドット拡張とかすればいいのにね
int static_value.fanction() = 0; // function専用
vid functionx.function(char*p){} // function専用
ファイル内スコープなんて今時ほとんど使わないから無視するか識別子重なったら同一と見做すかして
ついでにドット型はファイル内の前方参照も無くし宣言を省けるようにするとかさ >>541
＞friendがつくことでoperator+()はCのメンバ関数ではなく、グローバルな関数として宣言された
なるほど，そんなところだろうと >>528 で考えておりました．
件のライブラリもどきでは，operatorX のみクラス外に公開できればいいので，friend 関数で公開しておりました
その他は(基本的に）（公開すらしたくなかったため）static メンバ関数でのprivate 宣言となりました．
そうしたいようにそう書けばいいのですが今一つ統一感を見えてなかったかもしれません．
>>540
すみません >>522
static関数とfriendは全然違うし似てるとこなんてない >>546
みなさんこれが典型的ななんの役にも立たない回答の好例です >>546
static 関数をpublic に置くか，friend 関数にするかの判断がよくわからないのです．
なにか指針があればうれしいのですが 呼ぶときにクラス名を書きたいか書きたくないかで判断
コンパイルした結果には大した差はない クラスの外の関数とオーバーロードさせたければfriend
https://ideone.com/Bfcfbq staticはメンバを触れない。friendは触れる。
それくらいしか違いないけどなぁ。
俺、フレンド関数はほとんど書いたことない。 違ったっけ。
staticってthisもってないんじゃなかった？ https://ideone.com/qDEfdG
勘違いやったわ。ごめんなさい。
一個勉強になった。 メンバ変数をprotectedにする人ってなんなの？露出狂なの？ そういう人が日本に一人二人いるかも知れないけど、気にするだけ損だよ 継承しても触れるようにするためだけど。継承自体がほとんどない。 クラス内に定義されたstatic関数は、そのクラスのオブジェクトが存在しなくても使える関数ってのが本来の意味。
動的なオブジェクト状態には依存せず、静的なクラス構造のみに依存するからstaticね。
対してfriendは、自分をさらけ出す人を指定するめのもの。
stream のから呼び出されるオペレーターを定義する時には、既に完成している stream （だけ）に対して自オペレーターをさらけ出してしまうのがいろいろな意味で最も効率的。
以上から、friend関数は、静的ポリモーフィズムを関数レベルでお手軽に実現したいときに使うと思っている。 表層的に言うと
staticはグローバル関数をクラススコープにして、かつアクセス制御も効くようにしたもの
friendは>>531の通り
ただそれだけのこと >>561
なんで素っ裸でコートきてんの？露出狂なの？って聞かれて
コート脱いだらちんこ見えるようにする為だよって答えてんのと同じだぞ
まったく…露出狂は社会に出ちゃいけない存在なんだから、もう二度とプログラミングするんじゃないぞ >>565
うまい事言うなあ
friendは「なんで俺にだけ素っ裸見せんの？露出狂なの？」と聞かれて
「だってお前友達じゃん。だからお前にだけ俺の裸見せてやんよ」と言ってるわけだしな」 あれだろ
日本語のガールフレンドと
英語のgirl friendじゃ意味が違うというアレ >>565
あんたに決められる筋合いはねー。災いあれ。 friendはクラスの役割を適当に分担しながら実装の隠蔽を図るのにはまあ妥当な仕組みだろうな 継承をほとんど使わないってどんな分野だろう
俺んとこではポートを叩くときのプロトコルが
似ているようで少しずつ違うなんての普通にあるし 複数のクラスのfriendが可能
staticは1個だけ >>567
親しき仲にも礼儀あり。
アクセサぐらい用意するよね。 >>565
＞もう二度とプログラミングするんじゃないぞ
わかりました，もう止めます‥ C++のfriendが現実世界の友達と違うのは、最初に決めたやつ以外にfriendを増やすことは全く好ましくない、
という点だろう >>569
publicにしてあるほうが、まだかわいげがあるよ
もう、これからはすべてpublicにしなさい friendじゃなくfamilyが良かった気がする >>578
#define family friend
で行ける？ printf("We are the World."); ←わかる
cout << "We are the World" <<endl; ←わからない
printfは「関数」だからわかります。
coutの<<はシフト？よくわからないです。
なぜC++はこんな文字の出力のさせ方にしたんでしょうか？関数じゃダメだったんですか？ >>583
<<は演算子オーバーロードだけどcoutなんて使う必要ないよprintfでOK >>583
それはまさにC++の作者（以下、禿）が
彼の著書でアピールしていたことだ
coutとは何か？ <<とは何か？
記号と意味はどこでどのように関連付いているのか
意味は関数で表記することにしよう
<<の意味を表記する関数の関数名をoperator<<としよう
プログラム言語の命令とデータは動詞と目的語だ
動詞は関数と1対1対応でよいが目的語の定義は動詞の蓄積だ
・・・てな具合 >>583
シフト演算子を全く別の意味に使う
ひどい設計だと思う cout.<<("We are the World"). <<(endl);
があれば少しはマシだったかね。 >>583
演算子のオーバーロードのよいお題ということで無理矢理ねじこんだんじゃないかな using namespace std;
double value = 1.23;
cout << "value = " << value << endl; >>587
お約束を破っているが流し込んでる感が出ているので芸術点高い +-*/と違って<< がシフト演算子なんて決まってないから「本来と違う」なんて意味なさない vectorオブジェクトが破棄されるとき、要素の解放順は要素順であることは保証されていますか？ >>593
いや決まってる
ライブラリを抜きにした純粋な言語ではシフトの意味しかない
元の言語のC言語も同じ
* の方がいろいろな意味で使われている >>596
べつにc/c++の話じゃなく、一般に<<をIOの意味で使ってもなんとも思わんでしょ
+-*/はさすがに刷り込まれている 数学の演算子とプログラム言語の演算子のことじゃないかな。
+ - は数学とプログラム言語で一致
* / は数学と違うけど文字セットに乗除の記号がないし妥当な代用
<< をシフトに使うのはC系プログラム言語の独特の使い方
だったら << が出力になってもええじゃないか、という話。 向きは違うけどbashみたいなイメージだと思ってた 数学では、比較してずっと小さい、ずっと大きいという意味で<<、>>を使うことがあるみたいだが。 ■ このスレッドは過去ログ倉庫に格納されています
