【初心者歓迎】C/C++室 Ver.100【環境依存OK】 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2016/11/06(日) 22:58:02.60

エスケープシーケンスやWin32APIなどの環境依存なものでもOK。
ただしその場合、質問者は必ず環境を書きましょう。

◆ソースのインデントについて
半角空白やTABでのインデントはスレに貼ると無くなります。
そのため、アップローダーに上げるのも手ですが直接貼る場合は、
全角空白かに置換すると見栄えだけはよくなります。

【アップローダー】(質問が長い時はココ使うと便利)
http://codepad.org/ (コンパイルもできるし出力結果も得られる[]privateをチェック)
http://ideone.com/ (時間帯によってはcodepadが重い事があるのでここも利用)

前スレ
【初心者歓迎】C/C++室 Ver.99【環境依存OK】
http://echo.2ch.net/test/read.cgi/tech/1469177649/

**デフォルトの名無しさん** · 2017/07/12(水) 13:41:52.51

そんで俺はちょっと思ったんだけど
Cはポインタを配列のように扱えるのが便利だなぁと
逆に配列名を参照したらポインタ値になるし
あと他、関数ポインタを普通の関数のように扱えたり
逆に関数名を参照したらポインタ値になったり
意味の上で別解釈しようがないからそれでいいだろ、的な
二つに共通しているのは
(1)参照しても意味のある値が得られなそうなシンボルは自動的にポインタ値に成り下がってもらおう
(2)その上でポインタに対していろいろな演算 ()[] が出来るようにしておこう
というもので、これでシームレスになるしタイプも減るから便利だろう、と
でもそういう方針なんだったら何故我々は「.」と「->」を
使い分けなきゃならないんだ？と思わんこともない
意味の上で別解釈できたり不明瞭だったりは無いのに
ただ、Cの構造体は(1)を満たしていない
もし(1)を満たすようにしてしまうと、構造体を参照するとポインタ相当に成り下がってしまうので
代入演算子で代入したり、関数に値渡ししたりが出来なくなる
ただし、C言語がそのような仕様になっていた可能性は十分にあると思う
というのも配列がまさにそうであって、代入でコピーできないし、関数に値渡し出来ないから
アセンブリレベルでは配列も構造体もレジスタに入りきらないという意味では同じで
先頭アドレスからのオフセットでアクセスするのは同じであるから
そういう着想に基づけば、構造体も配列と同じようにポインタに成り下がる仕様に
なっていた可能性はあると思う
構造体は代入できないからmemcpyしろ、がCの常識だった可能性はある
そんで、「.」演算子は構造体のポインタに対して有効、となって、「->」は無くなる
で、そうはしなかった代わりに「->」演算子が有る、とも取れる

**デフォルトの名無しさん** · 2017/07/12(水) 13:42:12.78

気まぐれか、意図的か、歴史的事情か、生い立ちに由来するものか、知らんが、そうなっている
だが実際これが大当たりで、もしそうじゃなかったらC++が全く成り立ってこない
C++のクラスはCの構造体を拡張したものだが、オブジェクトが勝手にポインタに成り下がる仕様だと
代入したり、関数のreturnで値として返したりができない
となれば独自のクラスを定義して、まるで基本型のように振舞わせたり、メソッドチェーンをしたりが出来ない
もしやるとしたらnewして返すしかないので、GCが無いとどうにもならなかっただろう
(実際C++とCの配列は相性が悪く、std::vectorかstd::arrayを使わないと上手くいかない場合も多い
　ポインタ相当に勝手に成り下がってしまうので代入ができない)
ただ、このことが本当に良かった事なのかどうなのかは分からない
GCは有ったほうが良かったかもしれないし、C++の代入やコピーコンストラクタに関する話題は後を絶たない
他の言語のほとんどがオブジェクトを参照で扱うのを見てると
Cの配列のように勝手にポインタに成り下がって代入できない考え方のほうがスタンダードなのかもしれない
C++のクラスは、状況に合わせて、これを選べる、という立場になってるが
もしCの構造体が配列のような仕様だったなら、どうなっていたか分からなかった事を考えると感慨深い

**デフォルトの名無しさん** · 2017/07/12(水) 13:43:43.81

よくよく考えてみればなかなかに奇妙
まず常人が普通に考えたら、配列や関数名を参照したらポインタ値が得られることにしようっていう発想がない
プログラマは基本的に几帳面で、整合性を気にする生き物だから
ポインタ値は「&」を付けたら得られることにしよう、と決めたのだから
&arrayとか&funcとか書かせたくなるのが普通だろう
そして(*array_ptr)[1]とか(*func_ptr)()とか書かせたくなるものだろう
ところがCは、レジスタに乗らないもの、演算できないもの、を
勝手にポインタと同等に格下げするというルールを設けたうえで
そのポインタに対して各種演算子を定義することで整合性を保ちつつタイプ数を減らすという
ウルトラCをやってのけた
ここまででも俺ではちょっと思いつかないなーと感心するわけだが
逆にこんなすごいことを思いついたんなら、全部このルールで行きたくなってくるのが凡人
その方が整合性がありそうな気がするから
なのに構造体はそうなっていなくて、代わりにアロー演算子が定義してある
だから配列と違って構造体は代入ができるし関数に値渡ししたり、値で返したりが出来る
それはそれで奇妙なことだと思ったりもするが、とにもかくにも
この辺がC++の基本方針や特色にものすごく影響が出てる
GCが無いのもそうだし、最近でも右辺値参照が追加されたりとか、結構尾を引いていて
C++特有のややこしさの一端でもあり、他には代えがたいメリットでもある
ある意味で、Cの配列の考え方のが、他言語のオブジェクトの考え方に近いというのが何とも
そして構造体をベースとするC++とCの配列は相性が悪いという
C言語の功罪は凄い