CとC++は似たようなモノか？ 297
ストーリー by makeplex
違和感がないならまだ初心者ということか？ 部門より
違和感がないならまだ初心者ということか？ 部門より
saitoh 曰く、
プログラミング言語のカテゴリ分けで、CとC++は一緒にされることが多い。Q&AサイトやSNS等でも「CとC++」というように同類視されている。 先日の当/.jpのアンケートでも、プログラミング言語に関する設問はこうなっている。
□C/C++
□C#
□Objective-C
CプログラマとしてはCとC++を一緒にされて迷惑している。実際, ネット上での質疑応答でも「まず CかC++どっちの質問？それを書いてくれないと答えられないよ」ってのが最初の応答だったりもするし。 個人的には、言語の「同類度」という観点では Cだけ別にしてオブジェクト指向という共通点がある C++/ObjectiveC/C#を一緒にするほうが妥当に感じるのである。
言語のグループ分けの際にどれとどれを同類にするのが妥当か、皆さんはどうお考えだろうか。
「私は C++ プログラマです」の中身に踏み込めない (スコア:2, 興味深い)
という職業プログラマがまとまった数として存在するんじゃないだろうか。そういう人は、
集計するときに C なのか C++ なのか不明確だから、区別しない方が面倒が少ない、とか。
Re:「私は C++ プログラマです」の中身に踏み込めない (スコア:3, すばらしい洞察)
もっというとVisual C++上のC言語しか扱えないC++プログラマもいますよね。
そういう人は往々にしてswprintf(libc)とwsprintf(Windows API)の違いを理解していないです。
Re:「私は C++ プログラマです」の中身に踏み込めない (スコア:2)
ライブラリ関数がどこに入っているかという意味ではswprintfとsprintf、openとfopenのどっちでもいいです。それにwsprintfに対応するのは_stprintfですよ？
openとfopenは引数が違うから論外…いまどきK&Rじゃあるまいしコンパイラが指摘します。
wsprintfをあげたのはlibcとWindows APIの違いがわかっていない、OSのバージョンによって差異があり得る、それを理解していないということはどのヘッダファイルに宣言されているのかわかっていない、そしてコメントされているように関数の機能を理解していない（%fをサポートしない）。
なのでwsprintfをUNIXでも使おうとしたりするわけですよ。UNIXでは用意されておらず使えないことを経験し、その理由を理解していればいいのですが、そういう経験のないVisual C++専門の人が一定数いるだろう、というコメントです。
結局UNIXと同じように安定してリンクできるlibc相当がOS側にも欲しい、ってことでしょう。ちなみにlibcのswprintf、user32.dllのwsprintfよりも下層にもう１つswprintfがあります（ntdll.dll）。どんだけ～
Re:「私は C++ プログラマです」の中身に踏み込めない (スコア:1)
むしろアセンブリ言語を一緒くたにされるほうが困ったりして。
Re:「私は C++ プログラマです」の中身に踏み込めない (スコア:1)
> C のスキルしか持っていないけれど、作業環境がたまたま C++ コンパイラ
その人が書いているプログラムはC/C++どちらなのでしょうか？
通常想定される作業環境は「C/C++を切り替えて使えるコンパイラ」ですので、
プログラマは必ず「どちらで書いているか」を意識していると思うのですが。
過去に一度だけ、C++の現場で、Cしか書けないプログラマが何人かいて、
その方々にはメソッドの中身を埋める仕事だけやってもらったことも
ありますが、そういう人が「まとまった数」いるというのは考えたくない...
＃ 普通ならC++からライブラリ切り出してCで書いてもらうとかやるとか、
＃ テスターとかの支援作業側に回ってもらうとかするんだけどね...
Re:「私は C++ プログラマです」の中身に踏み込めない (スコア:4, おもしろおかしい)
> その人が書いているプログラムは
あー、malloc()/free() が new/delete になっているだけの C でした…。
Re:「私は C++ プログラマです」の中身に踏み込めない (スコア:2, すばらしい洞察)
「関数がstaticメソッド、構造体がインスタンスになっただけのＣ言語」という
Javaプログラマだって、日本にはたくさんいるんだぞ。
＃さすがにＡＣで。
Re:「私は C++ プログラマです」の中身に踏み込めない (スコア:2, おもしろおかしい)
私も // だけは良く使っています。
何と比べるかによる (スコア:2)
何と比べるかによるでしょう。 C# や Objective-C はよく知りませんが、 C, C++, Java のように並べるなら C と C++ が近いとは思いません。 C と C++ を一緒にするのは一方しか知らない人だけでしょう。一方、 C, C++, Java, Scheme と並べるなら C, C++, Java なんてどれも同じようなものだと思います。
僕は極めて普通の一般人 [srad.jp]なので、 C も C++ も Java も Scheme も HTML も全部同じにしか見えませんけどね :P
似てるとしたら Objective-C++ かな (スコア:2, 参考になる)
C89 ⊂ C++ だけど C99 ⊄ C++ だから、C 言語と言っても色々あることを考えないといけません。また、C# は C と似てないだけでなく、C# はオブジェクト指向言語だけど C++ はオブジェクト指向言語ではないので、C# が比較対象として出てくることが信じられないですね。C# が C++ と同類の言語だと思ってる人って多いんでしょうか？
C++ は C++0x から言語の方向性をジェネリックプログラミングの方へ大きく拡張させるので、このトピックで挙がっているどの言語とも似ていない言語にどんどん近付いていくと思います。
また、本文では挙がっていませんが、C++ を丸ごと含んでいるという意味で一番似ているのは Objective-C++ かな。
Kenta MURATA
Re:似てるとしたら Objective-C++ かな (スコア:3, 参考になる)
古いC++は存じませんが、C89 ⊄ C++98 です。(例えば関数外 const int i = 0; のスコープ。)
Re:似てるとしたら Objective-C++ かな (スコア:2, すばらしい洞察)
そういう区別が付く人はいいんです。それらの違いがわからず「自分はCが書けるからC++もわかっている（拡張子.cppのファイルに有効に機能するコードが書ける）」と思い込んでる人がC/C++なる選択肢を選ぶから酷いことになるんですよ。
既にコメントが付いていますが、似てる似ていないは主観によるところが大きいですが、各種構文、言語として用意されている演算子と優先順位、関数の呼び出し方法などなど似てる点は多いと思いますよ。「異なる点があるから似ていない」というのは間違っています。異なる点があるからこそ「同一」ではなく「似てる」と言っているのですから。
それからオブジェクト指向的でない書き方もできるからと言って「C++ はオブジェクト指向言語ではない」と結論づけるのもどうなんでしょう。libjpeg [wikipedia.org]のソースを読むと認識が変わりますよ。これはC言語で書かれていますが、れっきとしたオブジェクト指向だと思っています。
Re:似てるとしたら Objective-C++ かな (スコア:2, 参考になる)
複数の言語を比較する場合、各言語が第一級で何を表現する能力を持っているかを考えたほうがいいです。
たとえば、C言語は、手続きとしての関数、構造体、整数、浮動小数点数、ポインタなど。C++ は手続きとしての関数、構造体、数値、ポインタ、クラス、クラステンプレートと関数テンプレート、のような感じです。C# は無名関数を第一級で書けたりしますよね (C++ も C++0x から書けるようになるんでしたよね)。このような第一級で扱える概念の比較が、言語の比較だと私は思うのです。
各言語は第一級で表現できない概念を複数持っていますが、第一級で表現可能なものを組み合わせることで、ほとんどの場合について説明的に実装する事が可能になります。その例の代表として、Tsann さんが挙げられている libjpeg であるとか GObject や libobjc のような C 言語で実装されたオブジェクト指向システムがありますよね。これらはオブジェクト指向を実装しているのであって、C言語がオブジェクト指向を第一級の概念として記述できているわけではありません。こういうものまで入れてしまうと、極論として各プロセッサの機械語だってオブジェクト指向を記述できていわけですから、同じになってしまうでしょう。これは言語の比較ではありませんよね。
Kenta MURATA
Re:似てるとしたら Objective-C++ かな (スコア:1)
> C# はオブジェクト指向言語だけど C++ はオブジェクト指向言語ではない
それはさすがに言いすぎでは... Smalltalk みたいな古い言語から見てもどっちもどっちだと思いますが。
Re:似てるとしたら Objective-C++ かな (スコア:1)
また、本文では挙がっていませんが、C++ を丸ごと含んでいるという意味で一番似ているのは Objective-C++ かな。
何を以って「似てる」と云うかに依りますが, あの角括弧だらけのソースを見て C++ と似ていると云うのは, 人によっては難しいのではないでしょうか?
議論するにはまず前提となる知識が必要 (スコア:2, おもしろおかしい)
C -> C# -> C++
と進化してきました。[49] より詳しくは
C -> C2 -> C# -> CX -> C++ -> Visual C
のように進化してきました。[52]
今まで何年もプログラマーやってましたが知りませんでした。
Re:議論するにはまず前提となる知識が必要 (スコア:3, おもしろおかしい)
アスピリン=C
バファリン=C++
みたいな関係だと思うが、頭痛薬のグループ分けの際にどれとどれを同類にするのが妥当か、皆さんはどうお考えだろうか。
Re:議論するにはまず前提となる知識が必要 (スコア:4, おもしろおかしい)
＃何に対する「やさしさ」なのかなぁ
＃「優しさ」か「易しさ」かでも大分違いそうですが
演算順序と演算結果 (スコア:2)
本題に添った形で・・・ (スコア:1)
とおもったがそんな言語気にしてるやつはいないって時点で違う気が^^;
Minder
C#は完全に別物でしょう？ (スコア:1)
Re:C#は完全に別物でしょう？ (スコア:2, 参考になる)
> C#は文法こそCやC++に似ているとはいえ、.NET Framework上で動いていますから別物でしょう。
wikipediaのC#の記載http://ja.wikipedia.org/wiki/C_Sharp [wikipedia.org]の「言語仕様」にも
書かれていますが...
C#はCLIの仕様を反映した言語ですが、言語仕様として.netを前提としているわけではありません。
また、CやC++も言語実装・ランタイム実装によっては「.net上で動いている」ものもあるでしょう。
「言語仕様」と「言語実装・動作環境」を混同してませんか？
Re:C#は完全に別物でしょう？ (スコア:1)
> Objective-Cはよく知りませんが、名前からするとC++と同類でいいのでしょうか？
同類にはならないでしょう。往時、C++と比較して、オブジェクト指向の手法が従来の C の記述と
かけ離れているというのが、Objective-C に対する批判にあったくらいですし。(今でもあるのかも
知れませんが)
Re:C#は完全に別物でしょう？ (スコア:2, すばらしい洞察)
J#が重症なのは同感ですが、C#は結構使われてますよ。
C++/CLIが普及する前、C++をそれまで使っていた人が.NET Frameworkが便利だからなどの理由でC#に定着していたりします。
C++/CLIがある今、存在意義が薄くなっているのかもしれませんが、Javaから乗り換える人にはやさしい言語だと思っています。
ちなみに、僕はVB.netを主に使う奇人ですがｗｗ。
Re:「CプログラマとしてはCとC++を一緒にされて迷惑している」 (スコア:2, すばらしい洞察)
そもそも言語を基準にして何のプログラマというのが間違いなのかもしれない。
純粋なC言語でプログラムを書くような用途って、ドライバとか、ランタイムのサイズを削るためだったりとか、高速化のためだったりとか、特殊な背景とセットになっていることが多いと思う。一般的なC++プログラマとは持っている知識セットが違う。けどそれはC言語に関する知識ではないよな。
Re:「CプログラマとしてはCとC++を一緒にされて迷惑している」 (スコア:2, すばらしい洞察)
それですね。プログラマを分類するなら「何を使って」書いたかより「何を」「どう」書いたかが分類キーですよね。
例えば、どこぞの変態ライブラリみたいにtemplateを虐待して関数型に近い事をしているC++もあれば、「構造体と関数、あ！あとマクロとかマクロとかマクロしか使ってませんが何か？」なC++もありますし。関数型を見ても「beginとsetしか使ってません・・・てへっ」とか。
あと「無駄に複雑な業務ロジックだけどとにかく正しく動かせ！計算機資源が足りない？金で解決しろボケ！」で使うプログラマ脳と、「どんな手を使ってでもこのホットスポットを平均100clk短縮しろ！鬱はコレ終わってから発病しろ！」で使うプログラマ脳は別腹で・・・
Re:「CプログラマとしてはCとC++を一緒にされて迷惑している」 (スコア:1)
Cプログラマだけど、C++も使えると思ってもらえたらむしろラッキーではないでしょうか？
C は使えるけど C++ はさっぱりなので, "C/C++" という一緒にされた選択肢を選ぶときは申し訳ない気持ちになります.
C++ が C を拡張したマルチパラダイム言語ということを考えると, D と似ていると云えるのだろうか?
D は全く知らないので, 誰か教えて.
Re:「CプログラマとしてはCとC++を一緒にされて迷惑している」 (スコア:1)
> 高度なCプログラミングの世界は、C++の標準的なプログラマが知らないような側面を持っているのも事実。
そういう世界があることは知ってるけど、少なからぬ人がコンパイラの実装とか CPU のアーキテクチャを
理解してることが高度なプログラミングだと思っているフシがある。環境に依存するのではなく環境に応じて
どういった手段を適用するのかを幅広く定量的に導くことができるのが、真に高度な技術だと愚考するのですが
なかなか理解されません。
職人芸ではなく工学技術としての高度性を語る人にお出まし願いたいところ。
# 私はもちろん工学的素養などありませんので...
Re:互換性があるからいいんじゃね？ (スコア:2, すばらしい洞察)
世の中に C C++ C# Java しかなかったら別のカテゴリが良いかもしれないけれども。
C C++ C# D Java JavaScript Smalltalk Basic Cobol Ruby Python Lisp Scheme Haskel Erlang ml OCaml ...
まあ C/C++ は一緒ってカテゴリで良いのじゃないかな。
Re:互換性があるからいいんじゃね？ (スコア:2, おもしろおかしい)
Objective-CもCの攘夷互換ですよ。
http://ja.wikipedia.org/wiki/Objective-C [wikipedia.org]
Re:互換性があるからいいんじゃね？ (スコア:1)
ひとくちにCと言っても規格にって差異があります。
C99だとC++ではできない事もできちゃったりします。
それだけが根拠ではありませんが、私はCとC++は「別の言語」だと思います。
Cは、ドライバ等、比較的低級なもの、小さいものを書くのに適しています。
大規模なアプリケーションや、何らかの世界・環境をコンピュータに落とし込んだ「仮想世界シミュレータ」を作るならやはりC++です。
CとC++の共通点といえば、基本的な思想として、何でもプログラマが面倒を見なければならない（＝プログラマが自由に面倒を見られる）という点くらいだと思います。
アンマネージドな高級言語であるという程度のグルーピングしかされないということです。
Javaが興隆を極めたので、そういったマネージド言語に対して
「C/C++か、Javaか」
というスキルマップが描かれるようになったのでは…と思っていますが、これは多分に個人的な憶測です。
憂鬱本はオブジェクト指向プログラミングの学習に適切か？ (スコア:4, 参考になる)
この本を絶賛してるプログラマーが多いけど、そいつらって本当にわかってんのか疑問符が付くことが多かったな。
ここでもC言語を関数型言語と言っちゃう程度だし。
で、その憂鬱本なんだがオブジェクト指向プログラミングの勉強として不適当だと思う。
会社入って一年目のとき憂鬱本を読んだが「なぜオブジェクト指向プログラミングでなければならないのか」「オブジェクトって結局なんなのか」って疑問が解消されなかった。
結局得られたのは世間一般でなんとなく広まっているオブジェクト指向プログラミングがわかったような気になれる話だけ。
継承を使ったインタフェースやサブタイププログラミングとメッセージパッシングのごちゃまぜになったそれっぽい話ばっかりだけど、
そんな程度の知識や理解なんて憂鬱本である必要が無いよね。
オブジェクト指向プログラミングって何なのかって疑問が解消されずその後もちょこちょこ本や記事を読んだけど、
俺が最終的に満足できる解答は 「オブジェクト指向入門 バートランド・メイヤー (著), 酒匂 寛 (翻訳) 」を読んでやっと得ることが出来た。
これからC++やJavaでオブジェクト指向プログラミングを勉強したいって人は憂鬱本は辞めてオブジェクト指向入門を読むことを勧めるよ。
憂鬱本はオブジェクト指向プログラミングの学習に最も不適切（フレームの元：-0.001) (スコア:3, 参考になる)
>>「憂鬱なプログラマのためのオブジェクト指向開発講座―C++による実践的ソフトウェア構築入門 (DDJ Selection) (単行本)」
>この本を絶賛してるプログラマーが多いけど、そいつらって本当にわかってんのか疑問符が付くことが多かったな。
全く本当にそう思います。
あの本は９０年代を代表する有名な超ダメ本ですよ。
http://d.hatena.ne.jp/minekoa/20080503/1209799681 [hatena.ne.jp]
＞＞読んだことないけど、その本もしかして憂鬱なプログラマになるための本？
一緒に仕事をするプログラマを憂鬱にさせるための本かも。
アレを良いと言うような人は、C++プログラマを名乗っちゃいかんと思う。
いっそプログラマを廃業した方がいいくらいです。
( ﾟ∀ﾟ)ｱﾊﾊ八八ﾉヽﾉヽﾉヽﾉ ＼ / ＼/ ＼ (スコア:2, 興味深い)
＼(^O^)／の人 [asahi-net.or.jp]が今は亡きDDJ日本版の連載コラムであの本を推薦してましたな。
まあ元がDDJ連載記事だからってこともあるんでしょうけど。
俺もその書評を真に受けて購入しましたが、結果は人生ｵﾜﾀ＼(^o^)／
Re:憂鬱本はオブジェクト指向プログラミングの学習に最も不適切（フレームの元：-0.001) (スコア:2)
＞同年代に出版されている本でちゃんとした物があったことを示した上でないと
「オブジェクト指向入門」Bertrand Meyer、アスキー (1990/11)
http://www.amazon.co.jp/dp/4756100503/ [amazon.co.jp]
「オブジェクト指向プログラミング入門」ティモシイ・A. バッド (著)、トッパン (1992/10)
http://www.amazon.co.jp/dp/4810180484/ [amazon.co.jp]
「デザインパターン」GoF、ソフトバンククリエイティブ (1995/10)
http://www.amazon.co.jp/dp/4890527974/ [amazon.co.jp]
＞「９０年代を代表する有名な超ダメ本」と評するのは
「憂鬱なプログラマのためのオブジェクト指向開発講座」、翔泳社 (1998/05)
http://www.amazon.co.jp/dp/4881356194/ [amazon.co.jp]
これでは弁護する余地はないかと。
Re:オブジェクト指向と構造化プログラミング (スコア:3, すばらしい洞察)
いやいや、Cは「関数型言語」じゃないです。
http://ja.wikipedia.org/wiki/%E9%96%A2%E6%95%B0%E5%9E%8B%E8%A8%80%E8%AA%9E [wikipedia.org]
人に本を読ませる前に、自分に読むべき本があるのでは。
Re:オブジェクト指向と構造化プログラミング (スコア:2)
Cでオブジェクト指向することだって可能です。ただ、少しオブジェクト指向に向いてない言語なので、実装が面倒なだけです。
Re:オブジェクト指向と構造化プログラミング (スコア:2)
意図されたリンク先は松田裕幸『Scheme: 抽象化能力をもつ goto-less 手続き型言語』 (1994 年) [nii.ac.jp] ですね。これって、 Scheme が関数型言語でないという意味で「手続き型言語」と呼んでいるのでしょうか。本文中で「Scheme においては基本的には関数型プログラミングによるコーディングが期待されている」 (2.6 節先頭の段落) と書かれている通りで、それなら (純粋でない) 関数型言語と呼んで差し支えないのではないかと思うのですが。
例えば Scheme なら
とか書けばできますね、という話ではないと思うのでそこは措いて、たぶん関数が二つ以上の引数を取ることを問題にしているのだと思いますが、それってそんなに関数型プログラミングにおいて不便でしょうか。
Haskell などではカリー化された 2 引数の関数を map 関数に渡すときに部分適用と flip 関数を使って
のように書けて多少綺麗という気はしますが、それも引数が多くなると部分適用だけで済む場合以外はあまり綺麗でなくなって結局
という書き方をしたくなりますし、それならカリー化されていなくても大差ないような気がしてしまいます。
Scheme も Haskell も最近ほとんど使っていないので、僕の感覚がずれているかもしれませんが。
Re:逆なら見るけども (スコア:2, すばらしい洞察)
Cならコールバック関数を使う場面が、C++だと仮想関数になるわけですけども、
そうするとオブジェクトが必要になるわけですね。
で、そのオブジェクトを動的に構築していた場合は使い終わったらdeleteしないといけないんですけども、
上位側ではdeleteしたけども、下位側はdeleteしたことを知らずに幽霊オブジェクトを保持していて
仮想関数呼んじゃってアボーン、というバグに遭遇することがとっても多くて、これもすごく腹が立ちます。
コールバックにとって本質的なのは関数であってオブジェクトじゃないのに、その非本質的な、
言語仕様の都合によって導入された部分によってバグが呼び込まれるってすごく理不尽だと思うんですよね。
Cならこんなこと絶対起きないですから。
Re:逆なら見るけども (スコア:2, 興味深い)
同じく？組み込み屋ですが、C++も使ってます。
> オブジェクト指向で嫌なのはやたらnew/deleteを使うところですね。
別にオブジェクト指向設計とnew/deleteの使用は必ずしも直結しないと思っているので、
状況に合わせてオブジェクトの静的・動的生成使い分けてます。
ほとんどのケースでは静的なインスタンスを使い続けるか、
起動時・終了時に動的確保・生成を行うのみで、定常状態での動的操作は不要ですね。
バッファ管理など、どうしても定常状態で獲得・解放が必要なケースでも、
malloc()/free()並みの自由度が必要なケースはほとんど無いので、
自前の固定長領域管理などでnew/deleteをオーバーライドして使ってます。
ヒープのフラグメントも怖いですし。
なお、自分の経験上、C++実装でnew/deleteを使用するべきケースでは
C実装でもmalloc()/free()もしくはそれに類する動的領域管理が
必要になりますので、C++だから、オブジェクト指向だから、
というところでの違いをあまり感じることはありません。
確かにそういうところに気を使って実装しないC++プログラマの方もいますが、
同程度に組み込みなどの特性に配慮しないCプログラマの方もおられますので、
言語の問題ではなくスキルの問題なのではないでしょうか。
＃ 先の読めない再帰処理動かしたり、巨大な構造体を引数やauto変数に置いて
＃ スタック飛ばしたりとか、定常処理でmalloc()/free()繰り返して
＃ ヒープフラグメント引き起こしたりとか。
Re:逆なら見るけども (スコア:3, すばらしい洞察)
Re:考えられる理由 (スコア:2)
C++使いはエラー処理を例外処理に頼り切る傾向があるため、Cを使わせると異常時処理がボロボロになる傾向があります。
似ていても違うんです。別物なんです。
｜C++よりはObjective-Cの方がCに近い気がするが
同意。
Objective-C は Cを拡張しただけの言語です。
クラスメソッドとインスタンスメソッドが区別される変態処理系ですけど。
(拡張部分はSmalltalkに近いとか言われている様ですが、Smalltalkは使ったことがないので実体は知りません)
従って、無理にグルーピングするなら、C/Objective-C, C++/java/C# でしょう。
# もっとも、Cを別扱いするなら全て別扱いにした方が良いと思うけど。
# つ～か、Cの系譜にC#を混ぜるのはやめれ。
notice : I ignore an anonymous contribution.
Re:わかりにくいってんだよ！ (スコア:2)
Re:/* C も C++ も一緒！ */が結果ですが (スコア:3, 参考になる)
#1566914 [srad.jp] のプログラムも #1566926 [srad.jp] のプログラムも、 C 言語標準では結果は未定義であり、 if 文のどちら側が実行されても、どちらも実行されなくても、実行が終わった後なぜか変数 C の値が 42 になっていても、実行時エラーになっても、コンパイルエラーになっても、文句は言えません。 C FAQ 3.1, 3.2, 3.3, 3.8, 3.9 [kouno.jp], 11.33 [kouno.jp] を参照してください。 C++ 言語標準でも、 C FAQ 3.8 の説明とは少し違う説明が必要ですが同様に未定義です。
どのような場合に結果が未定義になるかという正確な条件は、僕は理解していないので知りたければ言語仕様を読んでください。式の中のある箇所で変数の値を変更し、同じ式の中の別の箇所で同じ変数の値を参照すると、二つの箇所の評価順が言語仕様で決まっている場合を除き未定義になる、と思っておけば、そうそう間違ってはいないと思います。両方とも変更でも同様です。
Re:わかりにくいってんだよ！ (スコア:2)
> これって未定義動作になりませんか？
その未定義なことについて議論するのが
このストーリーのお題ですよ(違) ;-P
Re:わかりにくいってんだよ！ (スコア:2)
Re:わかりにくいってんだよ！ (スコア:2, すばらしい洞察)
「わかりにくい」
というのはつまりわかってないってことなので
「わからないならすっこむなり、勉強するなりして来い！この物知らず！」
といいたくなるわけですが、そういうと角が立つのでより婉曲に/優しく
「（知らない貴方にはわからないかもしれないですが）それには意味があるんですよ？（微笑）」
となってるんじゃないかと。
Re:高級アセンブラの代替としてのC (スコア:2)
「ビット単位で」と修飾されるとビットフィールドも含むことになると思いますが、ビットフィールドほど自由にならない機能もないですね。MSBから埋めるかLSBから埋めるか、環境によって違うし、ビット単位での配置が重要な場合はまず使いません。バイト単位ならある程度コントロールできますけど。
そんなわけで、ハードウエアデバイスのレジスター定義にビットフィールドを使っているソースを見ると、これを書いたやつは何を考えていたんだと問い詰めたくなりますね。
struct is class (スコア:2)
structはクラスじゃない？省略時のアクセス制御が違うだけで。
C++STD2003
9 Classes
L4 A structure is a class defined with the class-key struct;
its members and base classes (clause 10) are public by default (clause 11).
Re:高級アセンブラの代替としてのC (スコア:2)
#1567512 [srad.jp] の人の答え通りなのですが、ついでに書くと、 RTTI の仕様も POD type に vtable を追加しないで済むようになっています。例えば、 dynamic_cast は原則として仮想関数を持つ構造体・クラスに対してしか使えないことになっています。