【C】カンマ演算子を極めるスレ【C++】

>>165
誰もそのマクロにバグがあるとは言ってないだろ

>>166
誰も許されるとは言ってないだろ

「仕様」だと主張することは「許される」ことと同義だと思うが。

166=168 なら矛盾したことを言ってるぞ。

>>169
説明ｷﾎﾞﾝ

>>170
定義１：仕様であるならバグではない。( >>159 )
定義２：誰もバグがあるとは言っていない( >>166 )
定義３：仕様であれば許される。( >>168 )

定義１と定義３から「バグがあるから許されない」となるが、定義２と矛盾する。

ただし、166=168が定義１そのものを否定するならば矛盾はしていない。
しかし、定義１はバグの定義として一般的に広く浸透している考えなので、
166=168が定義１を否定していないものと仮定した。

定義２は完全に肯定する。（俺自身の言葉だし）
定義１は肯定するが今回の話とは無関係。>>160は俺。

なんで定義１と定義３から「バグがあるから」の言葉が出てくるのかわからん。

インライン関数にすりゃいいものを、どーしてマクロでやりたがるの?

同じことを実現する2つのやり方があった場合、
より良い方を選ばないのは、どうしてだい?

Cだから。

>>173
Cには参照渡しがないから関数でやろうとするとポインタ渡しになる。
俺はそれでもインライン関数にするけどな。

俺はC++の参照渡しを安易に使うのには反対だ。constを適切に使えばいい、という人もいるけどさ。

CFoo oFoo ;
hogehoge(oFoo) ;

とやった場合に、呼んだ側からは、実体渡しなのか参照渡しなのか、わからないのだ。

>>174
よりよいCとしてC++を使えない、
純粋なCで書かないといけない、という制限があるなら、しかたないね。

>>176
わからなくさせるための参照渡しですから。

参照か否かではなく、変更されるのかされないのかが問題

だからconstを適切に使えばいい
代入演算子をオーバーロードするときは参照をconstなしで渡すけどね

関数の引数にするときは必ずconst_cast<const T>せよということですか

そこでboost::crefですよ

>>181
まともなライブラリを使えということです。
今時のまともなC/C++ライブラリは変更しない引数にはconstがついてますから。
まともじゃないライブラリを使ってる場合はinline関数でラッパーライブラリでもいいです。
醜いconst_castが一箇所に収まりますから。

おまいら const の話ならこっちでしてくれ。過疎ってるんだ、頼む。

【C++】 const だけでメシが３杯食えちゃうスレ
http://pc8.2ch.net/test/read.cgi/tech/1078193971/

>>183
ここは？
http://pc8.2ch.net/test/read.cgi/tech/1089192049/

template みたいな大きな機能だけでなくカンマやら const やらの小ネタで独立したスレが立ってしまうのもC++ならではだよなぁ。

よし、おれいまから"register指定詞だけでギャルにモテモテになるスレ"立ててくる!!

∴∵∴∵∴∵∴∵∴∵∴∵∴∵∴∵∴∵。∴∵
∴∵∴∵:。∴∵∴∵∴: --─-　∴∵∴∵∴∵∴∵
∴∵゜∴∵∴∵∴∵　 （___ ）（___ ）　∴∵。∴∵∴∵　゜
∴∵∴∵∴:∵∴∵_　i/ ＝　＝ヽi　∴∵∴∵。∴∵∴
∴∵☆彡∴∵∵ ／/[||　 　 」　　||]　∵∵∵∵∴:∵∴∵
∴∵∴∵∴∵　/　ﾍ　| |　 ____,ヽ | |　∴:∵∴∵∴∵:∴∵
∴ﾟ∴∵∴∵ ／ヽ ﾉ　 　 ヽ＿＿./　　∴∵∴∵:∴∵∴∵
∴∵∴∵　 く　 /　　　 　三三三∠⌒＞　∴:∵∴∵:∴∵
∴∵∴∵∴∵∴∵∴∵∴∵∴∵∴∵∴∵∵∴∵∴∵
　　 ∧∧　 　∧∧　　∧∧　 　∧∧
　　（　　 ）ゝ （　　 ）ゝ（　　 ）ゝ（　　 ）ゝ　ﾑﾁｬｼﾔｶﾞｯﾃ・・・
　　 i⌒　/ 　 i⌒　/ 　i⌒　/ 　 i⌒　/
　　 三　 |　　三　 |　　三　 |　　三 　|
　　 ∪ ∪　　∪ ∪　　∪ ∪　　∪ ∪
　　三三　　　三三　　三三　　三三

>>183
呼び出しているところだけを見ても、変更される可能性があるかどうか
わからないという話なので、関数がどう宣言されているかは関係ないと思います！

constじゃない参照は使わないというポリシーじゃないと、これの解決策に
なりません！

> constじゃない参照は使わないというポリシー

それが良識です。

というか常識です。

参照は言語仕様からはずしてconst指定すると自動的に参照渡しになるように変更でFA

>>192
operator [] () とかを実装できなくなるからダメ。てか、カンマの話をしようぜ。

out引数かどうかなんてのは結局ポインタ値渡しだったとしても関数呼び出し見ただけでは判らないんじゃないのか？

ちょっと前のBlitz++ライブラリでは、カンマ演算子が配列への代入に使われていた。
初めて見たときはちょっと感心した。

>>195
>>15, 25

ていうかlistとvectorで定義を分ける必要はないんだが>>25
set, hash_set等でも同じことができるように container_traitsがﾎｽｨ

昔、計算とリターンを一行でやりたくて、

　　return a+=b, b;

って書いたら、bが返却された覚えがあるんだけど
これって正しい記述方法なの？

カンマ演算子について調べろ。

>>194

とりあえずC言語時代には、
int n ;
foo(n) ;
bar(&n) ;
とあったら、fooはinでbarはoutだよね。

その慣習からすれば、
constの参照で渡す場合はin、ポインタで渡す場合はout、というのが自然じゃないか?

多値をカンマで返す処理系(perlやluaなど)はカンマ演算子ないよな

LISPなら prognがカンマ演算子に近いかな。

(progn 式1 式2 … 式n)
式1 から式n を順に評価して式nの値を返す。

するとCは複文を式中に書けないのが原因だな
GCCではできるんだが

>>199
const * でもない限りは in/outかoutとは考えても out onlyとは先ず想定しないだろ。
foo(int &n)の場合、inの見た目を持ったoutかも知れない、というのはあるが、それはbar(int *n)だって同じこと。
引数でデータ返そうとする時点で紛らわしくなるのはもう仕方のないことだろう。

>>203
ちょっとはスレの前のほうを読もうぜ
>>176-191

空気読めてないのは君だよ…。

>>200
カンマに２通りの意味があったらややこしいもんな
何かわかりやすい違い(関数呼び出しとそれ以外、とか)があれば別だが

Schemeの場合
カンマ演算子的なもの:(begin 1 2 3)
多値:(values 1 2 3)

まあ元々プロシージャの中に式は並べて書けるんだが

つーかCの引数の区切りも無理にカンマにせんで良かったんでは。
いや、今更変えられたら困るが。

>>207
それを言うなら、カンマ演算子に他の記号を使ってもよかったんでは？
てか、そもそもC的にカンマ演算子の必要性が見出せんのだが・・・
C++なら多少はカンマ演算子があるおかげで楽をできる場面があるから
わからんでもないんだが。

returnやgotoが「文」なのがいけないと思う
throwは「式」なのに・・
いっそのこと全部式にしてしまって、return文廃止にしたらどうだろうか。
・・まあ妄想はここまでにしておこう。

return は文のままでも、
return (a) ;
とかって書けるじゃないか。

関数の引き数だって、foo( (a, b, c), d) とか書けるんじゃないか?

そんなのわかってるよ^^
だから何？^^

>>209
return式の評価中にreturn式やgoto式が出たときの動作をどうするんだろ・・・

return flg ? (return a) : (goto lbl) みたいな奴

>>212
コンパイルしてみればわかる。

>>212
throwの結果の型は確かvoidだったと思う。
それと同じようにreturnやgotoも結果の型をvoidにしてしまえばいい。

>>214
ああそうか。C++はreturn void;を許していたんだな。最初これを見たときは
（　 Д ） 彡 ゜ ゜ﾎﾟｶｰﾝだったが。