C言語よりC++を先に習っても問題ないですか？

教えてください。

うるさいなあ

言語を習得する順序の話題は異常に盛り上がるけど、正直、ぜんぜん実のないスレになりがち。

単発スレ立てるなヴォケ

でも結論から言えば、別に構わない>>1

C++から始めるとしてももちろんベターCの部分をみっちりやれよ。

最近似たような奴が単発質問スレ立てまくりな件。

>>5
ベターCとはなんですか？教えてください

釣りだろこれ。

じゃあどっちから習ったほうが効率がよいのですか？

>>7
C++は単にCとしても使え、しかもCより改善されているので
C++固有の機能を使わずともお得。そんなC++のC相当の部分のことをベターCという。

>>10
なるほど、わかりました。
ありがとう

C++しか知らなくたっていいんだから、どんな順序で習ったっていいんだよ。
Cを知っていることがC++の理解の妨げになることだってあるだろうし。
使いたい言語を使えばいいだけ。

わかったらさっさと削除依頼出してきなさい。

そうでしたか、お邪魔しました。

ここのスレは仲良く共有してください
お疲れ様でした

brainfuck

# shutdown -h now

変にCをやってからC++に入ると、Cの知識が邪魔になる部分もある。
でも、C++はいきなり学ぶには複雑すぎ。

C → Java → C++
が効率よさげにみえる

AC++ﾏｼﾞｵｽｽﾒ

>>16
C++の全部の機能を一度にマスターしようとすればの話だろ。
C++の規模は、かの巨大言語PL/IやAdaをしのぐと言われているから、
どんな人でも一度に覚えるのは無理だと思う。

>>9
習うとか言ってる時点で・・・

>>17
それに一票
JAVAやってから、C++すると
トリッキーなコードが減る

かといって下手にJavaの癖がついても困る。

「Javaの癖」って何？？

>>23
多重継承を使わない(使えない)OO。ジェネリックに自由度が低い。

>>1
理解しきれる頭脳があればかまわないと思う。

あげ

>>9
本買って独学のほうがいいよ
こんなもんは、習うもんじゃぁない。

今さらC/C++を教えてるところなんてあるの？
電気電子系ぐらいでしょ

>>24
実装の多重継承は使わない方が無難なので大丈夫
インターフェース多重継承なら、お手の物のハズ
ジェネリックは・・・・敷居高そうだね
解ると死ぬ程便利なんだけど
最新のJAVAは「簡易ジェネリック」が有るので何とかなるかと

age

どうでもいいからお前らRubyやれ

>>1
とりあえずプリプロセッサとか多重継承演算子オーバーロードとか
くだらん無駄なもんは覚えるな。
Javaに必要なものだけ覚えろ

さすればJavaへの以降も容易になる。

>>29
> >>24
> 実装の多重継承は使わない方が無難なので大丈夫
> インターフェース多重継承なら、お手の物のハズ
> ジェネリックは・・・・敷居高そうだね
> 解ると死ぬ程便利なんだけど
> 最新のJAVAは「簡易ジェネリック」が有るので何とかなるかと

あれは簡易ジェネリックとは呼ばない。
タイプセーフジェネリックスと呼ぶのが相応しい。
タイプセーフなだけにバグも少ない。
かといってタイプセーフでないものが敷居が高いと言いきるのは
何か変だ。

CやC++でポインタの概念を覚えてから
Javaを学び始めたほうがいいような気もする

Javaでポインタは学べませんか？

ポインタというものがあるということだけは学べます。

ぬるぽ

>>36
C/C++のように直接メモリ管理をユーザーに委ねる事はしないが、実際は殆どの高級言語はポインタを持っている
C厨はそれがCの優れたところと思っているが、実際はバグの温床でメリットになっていない事のほうが多い

>>37
お前の技量が低いせいだと思うが？

技量に頼るのがC言語の特徴ですね

>>38
誰が俺の話をしたと言ってる
ちょっと前までは世の中のセキュリティホールの大半はC言語のポインタが原因であってもか？

未だに諸悪の根源はC言語ですね
.NETならそんなこと皆無なのに

>>40
無論だ。
そんな話は聞いた事がないからな。
ちょっと前なんて曖昧な表現されてしまったからいくらでも言いようがあるんだろうが。

それにＣはポインタを配列のように扱えることも特異だ。

ポインタを配列のように扱えるのではない。
ポインタ参照を配列参照のように扱えるのだ。

求道者なら最初から C++ をやりたまえ
以上

フランス語より先に英語を習ってもいいですか？
くらいな気がする。

大阪弁より先に東北弁を習ってもいいかもしれない。

>>46
それは先に英語をやるべきだろう。
フランス語(を含むラテン語に近い言語)は日本人には難解に思える。
#寧ろいっそ、フランス語よりもスペイン語のほうが突き抜けていて面白いかも。

いつになったら>>40の言い訳が聞けるのだ。

保守

>>48
言い訳をしてもいいわけ？

>>40
PHPやPerlでもセキュリティーホールありまくりだろよ。

書く奴に問題がある
言語として致命的な欠陥があればとっくに是正されてる

>>52
最近になってC言語にセキュリティ対策のライブラリが追加されたのに
まだ言うか

最近に　とか曖昧な表現使う奴の言うことなど信用できんよ

クラスについて知りたいならJavaがいいんじゃないかと思う。

C++は、Cを引きずってるので
先に習ってもいいけど、結局Cを学んでるような。
つーか、覚えること多いよ。

ポインタについて学びたければアセンブラが

初習者なら普通にJavaかC#だろうな
いまさらC/C++を学ぶ奴の気が知れん

>>53
VC8の_sのことを言っているつもりなら、それは所詮VCの独自拡張。
Cに未だC99より新しい規格は無い。

ＶＢプログラマ　Ｃプログラマのお仕事
http://www.vb-c.net/

>>57
まてまて、_sは次期標準Cライブラリに追加される予定で、現在ドラフトまで来てるものだぞ

hosy

javaかじったけど意味不明ー

問題ない。

C++とCの作り方、全く違う。
classの設計に6〜8割の時間を費やさないとC++らしくいかない。
Cは行き当たりばったりで、作ることもできる。
C++を本当に習得したら、逆にCに戻れないだろう。

>>63
逆だ。寧ろCでもC++流で書いてしまう漏れガイル。

C++はややこしいが慣れればこっちのほうが使いやすい

C言語のscanfが面倒だからC++でcinを使います、便利だぁ

文字の表示の際に、引用するにも変数の型に応じて%d、%lfだの%cだの
そういう面倒もないC++、マンセー！

何も考えずにprintfとscanfに同じ書式渡して
設定ファイルをパース出来るCマンセーｗｗ

>>68
本当に何も考えないと罠に嵌るよ。
C++のiostreamならそんな罠は無いかと言えばそういうわけではないけれど。

ネットワーク関係やるんだったらCは避けて通れないだろ

FORTRAN最強。

C言語を先にやってから、C++を学び始める、と単純に言うが、
具体的に、どの程度C言語を使えるようになってから始めたらいいのか曖昧だな。

逆にC++を先に習うといっても、ベターC相当の部分だけでかなりの時間をかけていて、
実質的にはCをやってからC++に入るのと同じようなものだということも考えられる。

文字列関連とか、今はC言語の文字列処理関数は一部除いて要らなくね？

言語なんて方法論にすぎないので、それに拘るのは如何なものかと思います。
それよりもコンピュータとOSの基礎的なことと、
構造化設計とオブジェクト指向の本質（要するにプログラムの作り方）を
学んだ方が良いですよ。
それにはまず作ってみることが重要。
個人的には言語はC言語だけで十分だと思います。
基礎＋デザイン方法＋C言語を理解していればどんな言語でも簡単に習得できます。

これはひどい

>>75
人間の思考が、使用する言語にかなり影響されているという、言語的相対論を少しでも考えたことがあるなら
そんなこと軽々しく言えないはずだけどな。

表面的な文法を簡単に習得できたとしても、その言語がもつパラダイムを習得することとは別問題。
オブジェクト指向言語を用いずにオブジェクト指向の本質を学ぶだなんて、本末転倒も甚だしい。

コボちゃんに謝れ

んも〜

きんも〜

ミモ〜

CやってJavaやってC++覚えろ
特化されてる言語やってごった煮言語使うのがソースへの思いやり

将来システム設計とかしたい俺はCを勉強してたりするけど、何か間違いっぽいな・・・・。

>>83
CとかC++なんてお古なんだから、おニューのC#でもやったら？あと、javaな。

>>77
言語的相対性に基づいて考えたとしても，
プログラム言語の場合，最終的にコンピュータにどのような事をさせるか，
つまり「入力→処理→出力」に帰着すると思うので，抽象的な性質を持つ言語を
先に習得してしまうと，その言語から逃げられなくなるかと思われます。
なので，言語はシンプルなものから学んだ方が良いと思います。
（まぁ，その当たりは好み次第かもしれませんが）

あと，オブジェクト指向言語はオブジェクト指向的な要素を持つだけであり，
それで作られたプログラムがオブジェクト指向で設計されているかといえば
必ずしもそうではありません。
というより，世の中に出回っているプログラムにはそうでない物の方が多いです。
単純にクラスを使うのがオブジェクト指向ではありません。
そこから一歩踏み込んだデータや機能を階層的に設計する事の方が重要だし，
それこそがオブジェクト指向の考え方の要です。
なので，オブジェクト指向言語でなくてもオブジェクト指向は理解できるし，
何より（機能面での）階層化設計をおこなうには構造化設計の理論が必要です。
そういった事から，逆にオブジェクト指向言語でオブジェクト指向を学ぶと
間違った方向で理解してしまう危険性もあります。
（中には自ずと気付く天才肌もいますが）

ただし，そういった事は実際に場数を踏まないと分からないと思うので，
まずは言語は何でも良いからモノ作りをしてみることが重要ですが。

今からやる奴にはこの順番でやることをお勧めする。
C# -> Java -> C -> C++

>>86
→
←　　　　どっちの順番やねん

C#優先

>>85
突っ込みどころが多すぎて行数が足りないって言われるんだがｗ

日本語でおｋ

>>85
2chでは3行以上の文は読まれない。

>>88
そうなのか・・。サンキューベリーマッチング。

>>85
>言語的相対性に基づいて考えたとしても，

全然わかってないんじゃんｗ

>>89
野次馬としては、複数レスにしてでも書いてほしい。
勿論それを75=85がどう返すかが見物だ。

非OOPLでOOPやる方が
よほど才能が要ると思うんだが…

それならCじゃなくてもいいじゃない。

企業のメーカーさんとかだと、C++は使えない場合もあるのでは？
C++の機能を使えないケースとかもあると思う。
需要はどっちがあるんだろう？

＞C++の機能を使えないケースとかもあると思う。 

IPAの作ったCのコーディングルールとか、ポインタの演算も禁止だもんな。

・C 言語の中には、インラインアセンブラが書けるものもある。
また、C++ 言う C を拡張したオブジェクト指向言語もある。
なぜか、C++ は大嫌いなのである。実行ファイルは大きいし、動作スピード
も遅い。しかし、最近は C++ で作る人がほとんどと思う。

なんかC++ってできる人が少ないらしいよ。
だからあんまり募集が少ないという話をよく聞く。
しかし、なんで学びたいのかそれによるんでないかな？

C言語→C++じゃないと意味ないんじゃないの？
C++にもCの命令も入ってくるんじゃ？

>99
C++のでもCのようにインラインアセンブリが使えることは多い。
あとD&E読め。C++はCと変わらない速さで動くことを常に目標として作られてきた。
ただ今では気を付けないと大きさもぶくぶく膨らむし遅くもなる。
（逆に言えばちょっと気を付けるだけでだいぶ違う）
それだけ言語が巨大になったと言うこと。

あとパソコンでは、実行ファイルの大きさも遅さも多少は気にならないほどに
性能が上がったということも影響はあったと思う。

99は外人かよ。

>>98
；´Д｀) なにそれ？

ポインタ演算なんて、禁止した方が会社のためだぞw

えっ？ポインタ演算なし？
文字列の部分的な置換をどうやってやるの？

http://sec.ipa.go.jp/download/files/report/200504/coding_guide.pdf

ポインタの演算を行う場合には，ポインタの指す範囲に気を付ける。
1.5 (1) ポインタへの整数の加減算(++,--も含む）は使用せず，確保した領域への参照・
代入は[ ]を用いる配列形式で行う。
(2) ポインタへの整数の加減算(++,--も含む）は，ポインタが配列を指している場合だ
けとし，結果は，配列の範囲内を指していなければならない。

--
前に見たときとちょっと変わってるかな?
以前は単に禁止だった。

そんなの当たり前の話じゃん
Cの初歩の初歩だよ

Cを初めに覚えた方がいいって言うから悪いんだ
構造化プログラミングの手法と、ポインタについて理解してからC++を習いなさいと言えば判りやすいのでは?

それ同じ・・・

ポインタに配列型式でアクセスするようにして、なにがどう安全になるかわからんね。

ポインタ（間接参照演算子ほか）を使うよりは安全になる気になれる。

演算子+-や[]を再定義してそこで範囲チェックして
アクセス違反が出るケースで例外出せばいいだけなのに

・・・と、ここまで書いて

配列を参照しているポインタが配列のサイズを認識出来ないのを思い出した漏れ

もうDまで1.00になったこのご時世なんだから
CもC++も言語自体使用禁止でいいんだよ
腐ってんじゃん

いや、C++だったら範囲外の要素にアクセスしようとしたら例外を投げる配列クラスとか
（ポインタの代わりの）イテレータクラスとか作れるだろ。

Cでも専用の構造体とアクセス用の関数作ればいいだけ。

>>114

>>107 がそのことに言及していない件

当たり前だ。
107はC、114はC++を対象にしている。

>>117

>>107 が >>115 に言及していない件

なんという過疎スレ、スレタイを見ただけで（ｒｙ

１０７で、ポインタが配列範囲の一個後ろを指すことを禁止してる件について

while(*dst++ = *src++);

Cで"Hallo Waurd"と表示して、こんなの俺がやりたい事じゃない！って思って
C++てGUI始めました。今は満足してる
暇があったら覚えてやんよ

何故かC++の書籍も入門サイトもC言語知ってる前提なんだよね
C++前提で進めるものが増えればC++から学ぶ人が増えると思うんだが…

ﾊｰﾊﾞｰﾄｼﾙﾄのC++の標準講座がC知らない前提だった

C++プライマーも一応C前提ではないな

C++の入門書が前提とするC言語の予備知識なんか初心者でも
1、2週間で習得できるんだから、さっさとCを勉強すればいいのに。

>>125
そういう考えもあるね。

C言語と共通な部分を入れると本が巨大になる。
値段が上がる。高くてぶ厚い本が売れるのか。
C言語と共通なのにC++を学ぼうという人にしか本が売れない。

C知らないでC++に手を出すって事は
ぬかるんだ足場で背伸びするようなもの

>>127
よくわからないけど、CとC++は似て非なる言語だから、別にCを知らなくっても問題無いよ。

どっちかつーと、泥濘に渡した板の上で作業するのがC++って希ガス。
泥濘に板を渡すのは標準ライブラリ(std::string, STLなど)がやってくれているので、
泥濘がどうなっているのか気にしたくないときは気にしないで済む。
Cではプログラムを書く際に(俺様ライブラリがあれば別だが)毎回泥濘に板を渡さないといけない。
#この喩えだと、C#は泥濘にプレハブ工場が乗っかっているようなもんだな。
#ちょっと違う作業をやろうと思うと一々どっかから工場が飛んでくる羽目になる。

悩んでる暇があったら（ry

言語仕様覚えるだけならそんな難しい事じゃない

板じゃなくてビニールシートだろｗｗｗ

>>131
板になるかビニールシートになるかは使う人次第じゃね?w

使う人の体重次第と言うべきだな

最初はCだけやって、そのあとC++やるってんじゃ
先人らがオブジェクト指向に苦労したのと同じ道を歩む羽目になる。
最初からC++やって、C言語との違いも適当に調べていけばいいよ。

>>134
ややこしくすんなよ
C++使えるならC使えるのは当然って決め付けちゃったほうが周りが楽だろ
オブジェクト指向に苦労する奴は覚えた言語の順序のせいにするのか・・・

OOPだって別に手続き指向的なことを全くしないワケじゃないしな
どう頑張ってもアルゴリズムが無くなるワケじゃない

ただ、C言語は基礎を学ぶのに微妙に不向きな言語って気がする

…ま、その意味じゃC++は更に基礎を学ぶに不向きな言語だが。

四則演算習う前に微分積分教えろっつってもなー

C++の見通しの悪さに我慢できず、C言語でC++と同じように関数をインデックス定義してオフセット呼び出しするようにしてしまった。

typedef struct _hoge {
int a, b;
hoge * (*fuga)();
void (*~fuga)();
hoge * (*setA)(hoge *this, int a);
hoge * (*setB)(hoge *this, int b);
} hoge;

_hoge
しね

つーか先頭にアンダースコアを使う奴ってなんなの？
お前はいつからコンパイラベンダーになったんだよって突っ込みたくなる

ライブラリ実装者になった気分で、全てはライブラリの独自拡張ということにしよう。

>>134
C++って( C言語 + OOP )なんだから、C言語から覚えれば、楽だと思うんだが...
どっちみち、C言語の呪縛からは逃れられない運命な訳だし...

C やっててさらにオブジェクト指向知ってると C++ に乗り換えるのはそんなに大変じゃないんだけど

それだと無駄な時間掛かるという意味で
初学者が C やらずにいきなり C++ から学んだ方が良いというなら
その可能性もあると思う

しかし本当に良いのかどうかは自分がそうじゃないから分からんな

C++からやっても何も知らないなら
結局ポインタの概念とか覚えるわけで
それは結局はC学んでるのと変わらんよね
Cは文法だけ覚えて、設計とかプログラムの仕方は
C++でオブジェクト指向を学んだらいいと思う。

C++でオブジェクト指向を学べると思ってるのか？ｗ

学べます。必要なら、C++に限らずどんな言語であろうとも。

Perl ではやりたくないお

漏れは日本語で学んだよ。

てみる

>>147
俺は昔「如何にしてCのみでオブジェクト指向設計をするか」
という趣旨の文章を読みながらOOPを学んだぞ。

今からすれば時間の無駄にも思えるが、その時に培った概念理解が今も生きていると思う。

FILE *fp;

そういえばネットで、CはわからんがC++はわかる、って人がいたな。
何かの変なグラフの描画にC++を使ってる人。
既出かもしれないが、目的にもよるだろ。
趣味ならもうお好きにどうぞ・・・みたいな。

まったく問題が無い。

なぜなら俺がそうだったから。

ちなみにC++を普通にマスターしてれば

(別に上級者とかでなくても)Cは１日で理解可能。

別に誇張とかではなくて、思いっきりゆっくりやっても3日で完了する。

ただ、その逆は無い。

禿もCを先に習う必要はまったく無いって言ってるしな

C++よりJavaを先に習っても問題ないですか？

問題ない

どうしてそんなにC++を押すのかが分からない・・・
C++ってそもそもCの文法を削った書き方じゃん
変数宣言も一々めんどいだろうけど
その削ってない書き方をまず覚えてから便利な書き方覚える方が良いと思うよ
C++のほうが機能多いんだし、全くの初心者だったら才能あっても迷子になる

日本語でおｋ

最初はC++のベターC相当分でいいと思う

もしC→Java or C#という流れなら
そのCの部分をベターCとしてのC++に置き換えるみたいな感じで

>>159
>C++ってそもそもCの文法を削った書き方じゃん
え？

プログラミングの才能があるやつはどの言語から初めてもおｋ
たとえば俺とかな

COBOLのソース眺めてJavaカタカタ打つとか出来ないとこの業界は生きてゆけない。

こんな本あってワロス

http://www.amazon.co.jp/Java-Cobol-Programmers-Programming-Byrne/dp/toc/1584502282

>>164
それなんて拷問？

ドトネト言語同士の翻訳なら楽勝だけどな

皆が才能あるわけじゃないから困る

Cからやった方がいいと思ってる人は、おそらくCからC++に至る過程で
出版されたCの知識を前提とするC++の教本を読んで挫折した人じゃないかな？

当時はC++ををやる人の90％ぐらいがCユーザーな訳で、本の著者もCユーザー、
Cが使えるのは当たり前とされていたのだろう。
実際にプログラミング入門レベルから解説してるC++教本ってのは無かったと思う。

しかし、時代は変わって現在はCをやっていないのは普通であり、C++すらも陳腐化している。
JAVA、C#から始めてる人間も多い、というかそれが普通だ。
C++の教本もほとんどC++でプログラミングに初めてさわる事を前提として書かれている。
Ｃのコアなユーザーに向けてかかれた教本などほぼ皆無と言っていい。

この状況では、C++と完全な互換性が無いＣから始めるメリットは、C++習得その物を
目的とするなら無いと言っていい、逆に混乱するだけ。
本質を理解したいとか、多くのアルゴリズム、ネットワークの古典を読みたい、とかなら別だが。

実務でＣでなければどうしてもいけない、という事はほぼ無いだろう。
趣味でどうしてもＣ特有のプログラム手法を知りたい、とかでなければC++から初めた方が
時間的にも費用的にもメリットが大きいと思うがなー。

>>167

文法変えるだけじゃんw

いやべつにC++からやりたきゃやっても良いけどさ、

>>169
＞C++と完全な互換性が無いＣ
gotoの飛び先制限と、プロトタイプ必須以外に
Cがコンパイルできない部分ってあったっけ？

そういやC99は知らん…

重箱の隅をつつけばいくらでも出てくる。

void*からその他のオブジェクトへのポインタ型への暗黙的変換が無いこと。
（Cのコードをコンパイルするならmallocなどが痛い）

構造体がスコープを作ること。
sturct foo
{
  struct bar {};
};
よそから中のbar型を参照するにはCだとstruct barだが、C++だとstruct foo::bar（もちろんstructは省略可）。

constで定数を宣言できるようになったことと、
それに伴って関数外のconstが基本的に内部リンケージを持つようになったこと。

整数型から列挙型への暗黙の変換がなくなったこと。
enum hoge x;
x = 1;

ほかにもコンパイルができる、できないに関わらず非互換となった事柄はJIS X3014:2003 附属Cに色々載っている。

みなさん、基本情報技術者はもってます？

基本情報技術者はもってないですけど
一種には合格してます

俺は二種とソフ開だな。
ちょうど二種の最後の年かその前かぐらいに受かったから。

私も一種です。
ちょうど一種の最後の年かその前かぐらいに受かりました。

ちょうど二種の最後の年かその前かぐらいに落ちた。

char型のcharってcharacterの略で%nのnはnewlineの略ですよね？
こういう略してある語の元の単語が載ってるサイトってないですかね？
探してもこの２つしかわからなくて

\nならともかく%nはnewlineではないだろ

そうでしたすいません

>>178
マルチするならマルチするでせめてC用とjava用に文面を分けろよ

僕もいろんなdllを使えるようになりたいなぁ。

javaやれとかいわれるけどお前らがC++の話してるからjavaやってもツマンネ
よって俺はC++やる

>>179
可能です。
以上。
はい、次。

>>184
あんた馬鹿?

>>183
ゲーム作るとかハードウェアの突っ込んだ操作しないんだったらJavaの方がいいんじゃ？
携帯で動くし

Cプログラマ必須テキストです！

http://mori.eco.to/

おすすめはC++とJava。一方を覚えると他方も理解しやすい
今の流行はEclipseでJava
Javaで処理速度が遅いときはC++を使う

>>188
お前がマじゃないことはよくわかった

処理速度よりも、環境で決めるべきじゃないか？

>>190
やめとけ
今は環境問題に対していろいろうるさくなってきてるから国際的にも問題ありだぞう
パオーン

やっぱC++wakarannsi

ロベールのC++入門講座っていう、分厚いけどプログラミング未経験者向けっぽい本があった。
ざっと眺めただけだけど、おそらくC++をいきなりやる人でも大丈夫だと思う。
だれか読んだ人いる？

>>193
同じく立ち読みしてきた。
評価は高いようだね。但し入門者用だな。
中級者以上は同じような本が本棚に並ぶ事になる。

アマゾンにレビューが無いとこういう時悩むね。

>>193
今日買ってきたよ。今読んでる。
サンプルプログラムが多いので実際に打ち込んで走らせて
理解するにはいいと思う。

しかしテンプレートなどのディープな内容にはあまり深く
突っ込んでないので、そういうのを極めたい人はC++ Primer 4/E
の方がいいと思う。

どのくらいのことを「ディープ」と指してるのだろう

>>197
クラステンプレートの作り方しか書いてない。
メンバテンプレートについては一切触れてない。

なるほど。

しかしC++ Primer第三版持っているので4/Eを買うと
内容的に被るんだよなあ。

>>195
そういや、都内の23区の図書館にも無かった。
明日、近所の図書館に注文してこようかと思ってるが、
あの分厚さだときついかもしれん。

コンソールで「はい、動いたでしょ？」って言われても全然覚えられねーよ。
でも、ゲーム作ってメリットを把握しつつ勉強すると一回で覚えられる不思議。

もしかして、漫画だと分かった気になるけど小説だと理解できないタイプ?

>>203
単に暗号解読の勉強するよりも、
エロ動画入りの暗号ZIPファイルを解読するために勉強する方が
モチベーションが保ちやすいってことじゃないか？

キモイ上司の説明を聞くより、シャキッとした上司の説明の方が分りやすい。とかｗ

つまりお腹いっぱいでも甘いものは別バラってことじゃん。

>>203
そのタイプではないけど、そんな感じ。
ゲームだと実際に目でわかるから概念的に理解しやすいし、様々な状況があるから
それに合った処理ということでメリットや使い時が分かりやすい。

クラスは例えば、ゲームだとキャラクターそのものってことで非常に分かりやすいし、
リスト構造も何体出るか分からない敵等に使えば、
forで最大数回すより効率良いってことでメリットが分かってモチベーションが上がる。

その昔ゲームで覚えるC言語だかマシン語だったかってのがあったな。

その昔萌えるC言語だかってのがあったな。

そこで昔音楽で覚えるＣ言語ってのがあｔｔ(ｒｙ

自分はド素人だからＣ++がＣの発展型だと勝手に解釈しており、だったら最初からＣ++
覚えたっていいじゃんと思って、かまわずＣ++からはじめてる。

本当は機械語直といいたい所だけど
ゆとりにはアセンブリからだろ。

問題山積み

まずはCの基礎から

>>207
for -> list -> for に戻る
virtual execute() -> 汎用タスクシステム -> switch 分岐 に戻る

Ｃから先にやるべきと思います。
たとえJava、C#を知っていてもやはりＣをＣ++の前にやっておくべき。

215
理由を追加するなら、ポインタを理解する必要がある。上述の二言語の持つ参照型との違い類似点、知ってなきゃとてもＣ++で使えない。

>>216
CやってるとかえってC++のポインタとの違いに悩みそうだが…

それでもあえて言おう
歩けない人間に走り方を教えることは出来ない

プログラマは「わけのわからない例え」が多くて困りますぅ。。

まぁ、、みんなほとんどの人はC++よりもCから入る。
もし、茨の道を自ら歩みたいなら、あえて人が選ばないC++から入るのも、
また変わった事になりそうで良いんじゃないかと。
プログラムをやり続けるんなら、どんな言語から入ろうと関係ないし
C++よりもC言語やっとけ、とか言うのは、
教えやすさの問題だと思う

残念ながらCを知らないことを前提としたC++の入門書や、入門サイトは少ない。
大抵はCを知ってることが前提となっている。
Cの知識がC++本来の使い方の邪魔をするという意見があるが、それはない。
C++本来の使い方の邪魔をする知識など存在しない。
それらは知識が悪いのではなく、その人間の性癖が原因。

C++ PrimerはC知らない人用に書かれた名著だよ


C++からでいいよ。
Cの知識のいくらかはC++を覚える上で邪魔になる。

>>216
「Cで」ポインタ覚えなきゃいけない理由ないだろ。
C++ PrimerのほうがへたなCの解説書よりポインタの説明は親切。

むしろそれよりCASL2だな

聞くところによると某国立大学法人S大学の情報科でも
CよりC++を先に教えるそうで


邪道でもなんでもないです

ttp://www.amazon.co.jp/Primer-ASCII-Addison-Wesley-Programming/dp/4756140068

散々な書評なんだが。。もしここで指摘されてる事が本当ならＣ学習者相手を前提にしているとしか思えない。

C++はCのほとんどを含んでいるから、普通にC++を勉強すればよい。
…のだが、C++の解説書のほとんどは、C言語が知っていることを
前提として書かれているのが問題。

＞C++はCのほとんどを含んでいるから、普通にC++を勉強すればよい。
文法だけならそうだろう。

しかしCを先にやってC++の前にCでソフトを一本でも二本でも
何かしら完成させていたら、その後のC++学習で必ず生きてくる。

C++をいきなりやるとCの文法とC++の巨大な仕様の学習の間に
インターバルが取れないから、自分がなぜclassというのを勉強
しなきゃいけないかの意義も分からずに盲目的にやることになる
だろう。

そうするとC++なのにJavaと同じ感覚のプログラマーが誕生して
しまうことになる。

CにないC++の仕様は、現代プログラムの有用なセオリーを
自動化してくれることであって、自動化されないCでの経験は
あるとないでは大違い。

昔から急がば回れというが、C/C++学習において、この言葉は
生きている。

つまり高性能なABS（アンチロック・ブレーキ・システム）にいきなり
頼ったのでは、本当のブレーキングは身につかない。自分の足の感覚で
ABSを再現できるようになってこそ、ABSの本当の使い方もわかるという
頭文字D的な話なわけか？

車にたとえるやつは出てくるだろうと思ったけど、車はオートマ免許でも
ＯＫだと思うｗ

Cを文法の上っ面だけで済ましてC++に行ったときの典型
http://pc11.2ch.net/test/read.cgi/tech/1216215558/737-
動作の中身がまるで分かってないから、自分が何をしてるのか
自覚出来ていない。

学問に王道無し

いきなり東大の問題解いても天才以外は意味が無い

てことは、アセンブリからやれってこと？

ハッカーになろう (How To Become A Hacker）　2004/10/28 Revision 1.27 http://cruel.org/freeware/hacker.html
同上の最新版　2008/01/08 Revision 1.38 http://www.catb.org/~esr/faqs/hacker-howto.html
もうすこし詳しい言語比較　　http://www.stsc.hill.af.mil/CrossTalk/2008/01/0801DewarSchonberg.html

>>231
いまどきそれが妥当ともいえないが、アセンブラ知っていれば
Cの学習、開発で一歩抜きん出られるのも事実。

ただ、Cが可搬性のあるアセンブラだという側面もあるので、
その辺は各自の事情で選択すればいいんじゃないか。

Cをしっかりやる＝＝ターゲットのアセンブラにも多少触れる
＝＝マシンの裸の挙動を垣間見るだろうしね。

>>229
それはC++の中でCから引き継いだ部分をちゃんとやってないって話だろう。
CよりC++を先にやるっていっても、ポインタよりクラスを先にやるって意味ではなく、
C++の機能として取り込まれたポインタとかは当然習得しつつも、
mallocとかそういうのは最初からnewでいいでしょって話じゃないの？

若い人の多くが「Cはできます」と言い切って入社してくるが、安心して開発を任せられる人を見ることはほとんどない。
Cは開発コストを犠牲にして速度を稼ぐ言語であり、開発された1970年代においては価値が高かったのだが、
CPUが速くなり、ライブラリを扱うことの方が重要になった今となっては危険なだけの言語になってしまっている。
Cが本当に役に立っていた時代は、SQLもGUIも、もちろんwwwも無かった。CPUとメモリとディスクがあっただけだ。

今は皆がCを学ぶ必要はない時代だと思う。ラテン語のように、必要な人や興味がある人だけが学べば充分だろう。

>>234
＞それはC++の中でCから引き継いだ部分をちゃんとやってないって話だろう。
C++いきなり入るとこういうふうになるという話。だってCの部分をやったあと
その理解が問題ないと分かるまで次のカリキュラムは待ってくれまい？

練習問題２、３解いたからって済む話じゃないよ。

＞C++の機能として取り込まれたポインタとかは当然習得しつつも
これするためには先にclassやらないとダメでしょ。ポインタの上書きと
中身の転送の区別もあやふやな段階で（初心者が納得するのは
相当たいへんだよ）さらに頭が混乱するだけだと思う。

＞mallocとかそういうのは最初からnewでいいでしょって話じゃないの？
newするからにはclassでしょ。mallocの代わりにnew char[???]を使う
ってだけの話なら、べつにnewを教えてることにはならないと思う。

おまけに確保できなかった場合は近代処理系では例外が飛ぶし、
そうじゃなければゼロ戻しの現役環境もある。
try , catch , new , ポインタ , メモリの実体 , classが絡んだポインタ
の拡張…目が回る。

そういう君はいきなりC++族かい？だったらたいへんセンスあります。

>>235
＞ライブラリを扱うことの方が重要

いやあの、C++使いというからには、こっちを作る側じゃないですか？

＞今は皆がCを学ぶ必要はない時代だと思う。ラテン語のように、必要な人や興味がある人だけが学べば充分だろう。
ここまでいうなら、今の時代、「皆がC/C++を学ぶ必要はない時代だと思う」が正解だよ。

ライブラリを乗りこなすのが重要な分野は他の言語使ったほうがいいんじゃないかい

言い過ぎたかな
＞こっちを作る側じゃないですか？
↓
＞こっち『も』
C++でアプリ作ってるしね

>>236
いきなりC++な俺は練習問題2、3解いて済ませたけどな。

>mallocの代わりにnew char[???]を使う
>ってだけの話なら、べつにnewを教えてることにはならないと思う。
別にnew独自の概念教える必要なくていいんじゃないの？
俺がいきなりC++がよいとするのは、mallocとかの古い知識を初心者に教える必要ないからであって、
ポインタの概念とかを回避できるからC++っていってるわけでは必ずしもない。

最初に教える段階では、メモリは確保できるものとして教えればいいと思うし、
（確保できない可能性もあって、そのときは強制終了すると付け加えるとベター）
それで問題あれば「おまじない」としてtry-catch教えればいい。

iostreamでoperator<<とかオーバーロードしてる時点で、順番に教えてくのは無理なんだから、
適当に「おまじない」を駆使して先進めばいいと思うんだけどな。

あー確かに。malloc()とqsort()とキャストを教えなくて済むだけでもC++の方がいいわ。
仕事だとその一方でiostreamではなくてprintf()系を教える必要があるのが難だけど。

>>239
＞いきなりC++な俺は練習問題2、3解いて済ませたけどな。
すげーな。
ポインタを（C的にでも）モノにするまで、何か下積みの経験あった？

理解できないやつの気持ちは俺も分からないんだが、俺の場合は既に
マシン語で遊んでいたからな…。

>>241
特に、強いて言えばBASICやってたくらい。
マシン語とかアセンブリは無理だｗ

BASICやってたんなら制御文ところはおそらく楽勝だったろうから
ポインタあたりに集中できたんじゃね？　POKEとかPEEKだったら
噴出すが。

ポインタわかりますと言ってる奴でも

int (*(*func)(int))[5];

こういうのが何の宣言かわからない奴、たまにいるんだよな。
わかったと思って実際わかってないのがポインタよ。

>>244
そんな分かりにくいコードを読めることよりも、書かないことが重要なんだよ。

>>244
funcはポインタ、指す先は関数、関数の引数はint、帰り値はポインタ、そのポインタの指す先はint型5個の配列。
現実にこんなコードを書くことは避けるけれど、読めないというのは信頼できなくなるから困るな。

>>245
書くべき・書かないべき、の話をしてるんじゃないよ

これは配列で、配列の要素はポインタで、ポインタが指すのは関数で、その関数の引数はintで、その関数の返戻値もintである。
演算子の優先順位を暗記して、右柄から解きほぐしていくとわかる。
CでOOPやるとき関数テーブルが必要になることがある。

>>248
おまえが言ってるのはこんなんか？（要素数は勝手に5を補ったが）
int (*func[5])(int);

>>248

>>244のことを説明してるなら、ぜんぜんあってないじゃん

#include <stdio.h>
int p[5];
int *fucn1(int _arg)
{
int i;
for(i=0; i<5; i++)
{
p[i] = i + _arg;
}
return (int *)p;
}
int (*(*func)(int))[5];
int main()
{
int *ptr;
int i;
func = (int (*(*)(int))[])fucn1;
ptr = (int *)(*func)(100);
for(i=0; i<5; i++)
{
printf("%d\t%d\n", i, ptr[i]);
}
return 0;
}
なるほどこういうことか。ひとつ利口になったような気がするｗ

typedefしろよw

C言語でOOPするくらいなら、始めからC++使えよって思うけど、
C++が使えない環境が無いわけでも無いので、仕方ないのかなあ。

>>251
キャストなしで書けるよ。
#include <stdio.h>
int p[5];

int (*fucn1(int _arg))[5]
{
int i;
for(i=0; i<5; i++)
{
p[i] = i + _arg;
}
return &p;
}
int (*(*func)(int))[5];
int main()
{
int (*ptr)[5];
int i;
func = fucn1;
ptr = func(100);
for(i=0; i<5; i++)
{
printf("%d\t%d\n", i, (*ptr)[i]);
}
return 0;
}

gcc -Wallでコンパイル可能。

配列はポインタだから
配列へのポインタは、ポインタへのポインタだと。
return &p; はポインタへのポインタ、つまり、配列へのポインタを返している。
int (*func1(int _arg))[5]; の中の　func1(int _arg)　を ptr で置き換えると　int (*ptr)[5] になる。
だから、この関数は、配列へのポインタを返しす関数であり、型が一致している。

一方、int (*func1(int _arg))[5]; の中の　func1(int _arg)　を (*func)(int) で置き換えると
int (*(*func)(int))[5] という関数ポインタになる。

g++でもコンパイル可能だった。

関数に[5]を付ける書き方には依然として抵抗があるが、main()の中の可読性はそれ程悪くないか．．．
うーーーん

func(3)などの関数コールは、何かの戻り値に置き換えられるだろ？
つまり関数名とそれに続く仮引数リストが戻り値にすり変わる。
戻り値をAとする。
int func(int);
というプロトタイプがあったら、func(int)をAに置き換えると
int A;
となりあたかも、int型のAを定義してるよう！これはfunc()の戻り値型が
intだと言っている。同じ理屈で
int (*(*func)(int))[5];
だと関数コールに当たる部分は(*func)(int)だからこれをAに置き換えると
int (*A)[5];
となり、あたかも配列へのポインタを定義しているかのよう！だから
(*func)(int)の戻り値型は配列へのポインタになる。[5]が後ろへくるのは
必然なのだ。
関数の宣言・定義で関数の戻り値型を書くとき、関数名の左側にすべての
情報を書くというわけではなく、関数コールが戻り値に置き換わったとき
その戻り値はどんな型として定義されているか、それを考える。これが
関数の戻り値の型を見る方法。

それと何の宣言・定義かを判断するとき外側からとか右側から見ていくというのは
間違い。あくまで識別子を中心に先に作用する演算子から考える。
int (*(*func)(int))[5];
で識別子funcに最初に作用するのは内側の*だから、funcはまずポインタで
あることが確定。次に(int)が作用する（関数演算子()は*よりも優先順位が
上）から、funcはint型を仮引数に持つ関数へのポインタであることがわかる。
次に外側の*が作用するから、その関数の戻り値はポインタ型。次に[5]が
作用するからその関数の戻り値は要素数5の配列へのポインタ。
最後にintが作用してその配列はint型の要素を5つ持つ配列だとわかる。
というように、演算子の結合順位を追っていくと、より具体的な情報が後から
後からついてくる。
ポインタである→何のポインタ？→関数へのポインタである…

あとね、配列はポインタじゃないよ。あくまで配列。
int array[10];
とあったらarrayはポインタではなく配列。配列名のarrayが、何かにつけて
配列の先頭アドレスとして使えるから誤解が生じる。
sizeof arryaとやれば、配列全体のサイズが返る(intが4バイトなら40)。
arrayがポインタだったならポインタ型のサイズが返る（たいていの
処理系では4バイト）。配列へのポインタというのは、int型へのポインタと
同じ参照レベルであり、ポインタへのポインタではない。
たまたま配列名から配列の先頭アドレスが取り出せると考えたほうが良い。

#include "stdio.h"
#define N 20
int a[N];
#ifdef __CPLUSPLUS__
typedef int (*PTR)[N]; /*　>>252 */
#else
typedef int (*PTR)[]; /*　>>252 */
#endif
PTR func1(int _arg)
{
long i;
for(i=0L; i<N; i++)
{
a[i] = _arg + (int)i;
}
return &a;
}
PTR (*func)(int _arg);
int main()
{
PTR ptr;
func = func1;
ptr = (*func)(100);
long i;
for(i=0L; i<N; i++)
{
printf("%ld\t%d\n", i, (*ptr)[i]);
}
return 0;
}

この方がすこし、可読性があがるか

また自分基準の可読性か、当てにならないんだよ、お前のは

#include <stdio.h>
#include <stdlib.h>
#define N 20
typedef int (*PTR)[];
PTR func1(int _n)
{
PTR p = (PTR)malloc(sizeof(int) * _n);
long i;
for(i=0; i<_n; i++)
{
(*p)[i] = (int)(i * i);
}
return p;
}
int main()
{
PTR (*func)(int _arg);
PTR ptr;
func = func1;
ptr = (*func)(N);
long i;
for(i=0; i<N; i++)
{
printf("%ld\t%d\n", i, (*ptr)[i]);
}
free(ptr);
return 0;
}

そろそろスレ違い

けっきょくこういう頑固な奴は、いつまでたっても理解しないもの

(*func) /* funcはポインタである。*/
(*func)(int _arg) /* funcはポインタで、そのポインタは関数を指す。*/
(*(*func)(int _arg)) /* funcは関数ポインタで、その関数の返戻値はポインタである。*/
(*(*func)(int _arg))[N] /* funcは関数ポインタで、その関数の返戻値は配列へのポインタである。*/
int (*(*func)(int _arg))[N] /* funcは関数ポインタで、その関数の返戻値は配列へのポインタであり、配列の要素はintである。*/

typedef int (*PTR)[]; /* PTRは配列へのポインタで、その要素はintである。*/
(*func) /* funcはポインタである。*/
(*func)(int _arg) /* funcはポインタで、そのポインタは関数を指す。*/
PTR (*func)(int _arg) /* funcは関数ポインタで、その関数の返戻値はPTRであり、PTRはintを要素とする配列へのポインタである。*/

そろそろスレ違い

スレ違いです

ヘタなコードの書き方 http://pc11.2ch.net/test/read.cgi/tech/1208010023/
【動くんか？】摩訶不思議なコード【何語？】 http://pc11.2ch.net/test/read.cgi/tech/1187527909/
一度は読んだほうがいい、ソースコード http://pc11.2ch.net/test/read.cgi/tech/1201966827/
今までに見たソースコードで一番感動したのは http://pc11.2ch.net/test/read.cgi/tech/1037458703/

必ずしもC++を先にやったからこうなったとはいえないが…
http://pc11.2ch.net/test/read.cgi/tech/1218023777/82-89

なんかこの手のC++初心者多い気がする。C部分の学習時点で
EXEのアーキテクチャに直結してる部分（上の例ではスタックと
ヒープの概要）などクリアしておけば、C++を学ぶ時こんなアホな
ところで回り道なんかしないよ。

>>266
大丈夫、どうせCを先にやっても理解できないから。

JAVAやCでC++をやるのが結局１番？

JavaやCでC++とはどういう意味だ？

>>268
そのまえに日本語を

個人的には、ちゃんと教えてくれる人か、良い教材があるならC++からやった方がいいとすら思えるけどね。
ただ、自分はそんな良い教材をしらないけど。
で、そういう現状としては、自分はpython当たりのスクリプト言語から入るのもいいと思う。
HSPも仕様がまともになれば、以外と初心者向けとしていいかなぁ。と思うけど、まぁ紙に書いたモチなんで却下だろうし、
Rubyはやや高度すぎる部分があるから、下手に初心者が行くと混乱してそのまま退場しそう。
で、perlをやらせるぐらいなら、やっぱしPythonかな。と思う。


用途的に案外Cでなければならない所なんて、こんな事を聞く初心者は当分やらんだろうし、
Cを経由する必要性はそれこそ無いと思うんだよね。
それに加えて、これからの流れとして、C++の守備範囲が広がることはあれど、狭まることは考えにくいしね。
（どうしても、スクリプト言語から一歩先を目指すとCかC++になるし、その辺もだんだんC++の環境が整ってきてるし。）

あと、C++がマルチパラダイム言語であるから、良いコードを読んでそれを理解できるなら、
自分の使いやすいように使うのがいいと思う。
Better　C　ぐらいのプログラムでもいいと思うし。

それを言うなら絵に描いたモチだろ。

ちゃんと教えてくれる人に良い教材でCからやれ。
プログラムとメモリの対応関係が肌で理解できるまでは
Cから卒業しちゃいかん。

>>273
みたいなのをみるとどうしても、時代錯誤の老害としか思えない。
アセンブリを叩いてみろ。ってのなら多少は理解できるけど、Cっつうのが中途半端すぎるし
なんか、自分がそこで苦労して身につけたから、おまえらもそこは通れ！みたいな老害感。

アセンブラもＣも仕事で使ってた者だが>>273には賛成できないな。

おれは>>273に賛成

Cが中途半端って感覚がそもそもおかしい。

アセンブラはほとんど知らないけど>>273には賛成できないな

リリースビルドでデバッグ情報切った時しかおかしくならないんで
どうしようもありません…って言うのは勘弁して欲しいぞ。

そういう状況が発生したら、>>278はどう対処する？
最適化切ったりデバッグビルドでリリースっていうのは不可
ってことで。

>>279
そういう状況は、大抵バッファがオーバーしてるときに起こるもんだ。
ログの挟み撃ちをバイナリサーチ見たく半々に狭くしていって見つける。
てか、割り込みルーチンみたく、デバッガ使えない状況のデバッグって結構あるし、
いちいちその度にアセンブラコード眺めたりしないよ。
デバッグ情報か、逆アセを眺めることしかデバッグ手段が無い奴と一緒に仕事したくないぞｗ

>>280
ログ出しルーチンを有効にしたとたん症状が潜伏したりしてなｗ

mallocは好かん。sizeofでバイト数を取得しなければならないし、
のっけからポインタの型キャストがあるし。

あんなもの初心者にはわからん。

まだ、C++のnew、delete、delete []の方がまし

>>279
ろくにアサーションやってないからそうなる

>>282
お前と一緒にC++開発したくないわ。
Javaでもやってくれ。

Cは文法簡単だろ？（記述の手間は多少かかるが）
手間ひまかけて『コンピュータ』を学ぶにはかなりいい選択
なんだよ。

C++やるまえに悪いこと言わんから『コンピュータ』の学習は
終わらせておけ。

プログラム一筋ならＣもＣ＋＋もやらずにＪＡＶＡかＲＵＢＹをやればいい。
でもハードウェアのことも学びたいなら、Ｃとアセンブラをしっかり。

ハードウェアのことも学びたいなら、じゃなくて
ハードウェアのことを学んだら、だろ
本末転倒だ

とりあえずは目の前にある環境に既に入ってる言語使えばそれでじゅうぶん。

アセンブラは全く使えないけど、やっておくとハードウェアの仕組みが理解できると思うよ。

ハードウェアというか、正確にはコンピュータアーキテクチャ
ようするに、ハードウェアとアセンブラプログラマの接点の部分だ
ハードウェアはまた別

うーんどっちが先とかあるものではないだろう。

ハード叩くのなんて必要性が無けりゃ勉強なんてできんよ
俺はC2DのEISTで電圧と周波数(というか倍率)を任意に設定できる
汎用性の無いカーネルモジュールとか自作のAVRファンコン、モニタをPCから制御するドライバを書いたぐらい
実際カーネル自作するぐらいの目標が無いと何馬鹿な事してるんだ俺はってなる

人の自慢話ほど聞かされて馬鹿らしいものはない

Dr.Bjarne曰く「C++をやる予定なら最初からC++やったほうがいいよ」
らしい。

問題ない。

第一、mallocよりもnewの方がはるかに良い。deleteとdelete []の区別に
気をつけなければならないけど。

mallocは最初からsizeof演算子が必要で、それよりも気に入らないのはvoid
ポインタを型キャストしなければならない点。

でも、組み込み系ではC++が十分に使える環境にないからCしか使えないのが
つらい。

Embedded C++があるじゃないか。
まあテンプレートや例外処理はカットされているけど。

STLをマスターするより先にboost触った方がいいよ
こうですね

VC9 SP1のtr1で当面は十分では

だいたいCを軽視してる奴にまともなPGはいない

と、C++が理解できない頭の硬いオッサンが申しております

言語が理解できないって言っちゃう時点でもうね・・・

言語を一つ理解するのに数年かかるというのに、無闇に修得対象を広げたくない。
マニュアル斜め読みしただけで理解したって言っていいんなら話は別だけど。

本一冊読んでマスターしたと勘違いしちゃうやつ多いからなぁ。
バグ出したり可読性下げててもそれが理解不足であることも理解できない。

言語のベンダー試験あたりに合格するレベルでいいなら何年もいらない。

でも若い人でＣのポインタと配列の概念をきちんと理解している人って結構少ないよ
分割コンパイルの環境で、動的に確保できるグローバルな２次元配列の変数を宣言する方法とか
やらせてみると結構できない。
試しにやってみるか？
○幅WIDTH, 高さHEIGHTのchar型２次元配列をグローバルに定義および宣言せよ。
ただし分割コンパイル環境で使えるようにすること。またこの変数は定義時はNULLを与えておき、
初期化関数内で動的に確保すること。

便利なものなら使いたいじゃんスマポとかrangeとか

言語をひとつしか知らないやつは、その言語に深く精通してるかっていうと、そういうことはまず無いな。
複数知ってるから優秀ってわけでもないけど。

沢山知っててもいいんじゃね？
プログラマなら一年に一つは新しい言語を触れって格言もあるし
いいじゃんLisp系もやってML系もやってLL系もやってbrain fuckみたいな類の変なのもやればいいんだよ
boostの中のもLispやHaskellにインスパイアされてるし

>>305
.c/cppに
char Hoge[HEIGHT][WIDTH] = {NULL};

void fugafuga()
{
　　for (int i = 0; i < HEIGHT; ++i)
　　　　for (int j = 0; j < WIDTH; ++j)
　　　　　　Hoge[i][j] = うんたら;
}

.h/hppに
extern char Hoge[];　　// こんなことやる機会あんまないのでちょっと自信ない

こう？
偉そうには言えんけど、実務でミスっても調べりゃすぐわかりそうな気はするがｗ

305じゃないけど、まんまと引っ掛かったって感じだな。

スタックじゃなくてヒープを使えと
そういう引っ掛けだったの？

動的っていうからにはそうだろう。
仮にchar Hoge[HEIGHT][WIDTH]でやるとしても、
= {NULL}はおかしいし、extern char Hoge[][WIDTH];でないといけない。

＞動的に確保できるグローバルな２次元配列
＞またこの変数は定義時はNULLを与えておき
char **Hoge = NULL;でやれってこと？
「動的いいながら定義時にNULLとか意味わからん」思って無視してたｗ

char(*hoge)[WIDTH] = NULL;
hoge = malloc(sizeof(char[HEIGHT][WIDTH]));
こうだろ

ほーほー。
自分のポインタの理解が浅いことは認めるんだけど
普通こういう用途ってWIDTH * HEIGHTで確保するほうが賢いような・・・
あと{NULL}じゃなくて{{NULL}}か。Cでも通るのかは知らないｗ

まぁ知ってても実際に使う機会はないな
トリビアみたいなもんだ

＞{{NULL}}
実際にやってみたら全部NULLにはならなかった・・・（{NULL}でも）
（VC限定？グローバル変数は0で初期化されるので1で試したけど）
うーむ。

それは、初期化子の数が足りなければ、残りの要素は0で初期化されるという性質を使ったテクニック。
{{1}}で最初の要素以外が0になるというのであれば、それは期待どおりの結果。

ただし、そもそもchar型の要素をNULLで初期化しようってのが大間違い。
http://www.kouno.jp/home/c_faq/c5.html#9

そもそもchar型の要素をNULLで初期化しろなんて>>305は言ってないしね。

>>309はアドレスとメモリ内容の概念からやり直したほうがいい。

つまりは>>273ってこった。

>>314
その部分は正解だが、さらに「複数ソースで使用し、ちゃんとリンクエラーが出ないようにする」
ように記述しないと１００点はやれない（ここが出来ない人も結構いる）。
>>315
hoge[x + y * WIDTH]ってアクセスするの？
それがhoge[y][x]より賢いって？
３次元になっても１次元配列を自分でオフセット計算するかい？
>>316
どれだけ経験して「ない」って言い切ってるんだか知らんが、現実にこういうことあったよ。
MAX枚のHEIGHT*WIDTHサイズのマップデータをメモリに保持するソフトで、複数機種で
同時開発しているのだが、ある機種はメモリが足りなくて動的に確保しなくてはならない。
途中までできてたソースを大きく書き換えたくないから（複数人で作ってる）、#ifdefで
int map[MAX][HEIGHT][WIDTH];の部分を動的に確保するように書き換えた。

>>320
>>314は分かってるだろ。その上に突っ込んでるだけだしｗ

できた
reallocの落し穴とMakefileの書き方を覚えられたのが収穫だった

/* in foo.h */
extern char** ary;

/* in foo.c */
char** ary = NULL;
void* tmp = NULL;

int init(void) {
size_t i;
tmp = malloc(sizeof(char*)*WIDTH + sizeof(char)*HEIGHT*WIDTH);
ary = tmp;
for (i = 0; i < WIDTH; ++i) {
ary[i] = tmp+ sizeof(char*)*WIDTH + sizeof(char)*HEIGHT*i; }
return 0;
}

これはひどい

>>319
バカにしすぎかと。そういう前提で書いただけだっつーの・・・
普段ポインタ以外にNULL入れることなんか無いわ。
>>314みたいなのは確かに初めて知ったけど（´・ω:;.:...
＞hoge[x + y * WIDTH]ってアクセスするの？
＞それがhoge[y][x]より賢いって？
char **でバラバラに確保するのか・・？と思ってたので。
314のは連続した領域に確保してるんだからいいんだろうけど。
一つ勉強になりますた。

酷いですか御免なしあ

>>324
あんたは>>309だろｗ
それはそうと。
プライドが傷つくのは気の毒だが、動的に確保しろと言ってるのによくわからないから無視したり
してるところを見ると、もうちょっと勉強したほうがいいのは確かですね。

あとchar**でバラバラに確保しても、まあいいよ。効率はほんの少し落ちるけど、初期化と解放時だけの
効率だから目をつぶろう。>>322はその方法だが、ちょっとコードが良くないね。機械にやらせるべき計算を
自分でやってる。名誉挽回に、>>322を綺麗に書き直してみるかい？（と、煽ってみるｗ）

>>326
失礼ｗ
＞>>322はその方法だが
322って、バラバラじゃないような・・？
１箇所に確保した（連続した）領域に対して、HEIGHT分ごとに区切った
アドレス配列を作ろうとして何かミスってるように見えるんだけど・・・・(；´Д｀)

私なら、三次元配列でも一次元で確保してオフセット計算を関数でやらせる。
幅や高さが固定な用途ばかりじゃないんでね。

確かにnewがあればmalloc要らないとか、Cは既に陳腐化したツールも少なくないし、
その辺は適当にスキップしてC++を優先して学ぶのもよいと思う。

でもCを飛ばしてC++だけやるくらいなら、VBAとかJavaとかやったほうがいいと思う。
CもC++もややこしくて一筋縄にはいかない。
プログラマーに徹したいのなら、もっと楽に学べる言語はいくらでもある。

むしろプログラマーに徹したいのならC/C++制覇しろよ。
VBAとかJavaに徹してるプログラマってｗ

私大文系ならVBAに徹するしかないだろｗ

言っとくけど、アセンブリ言語勉強したらコンピュータの構造が分かるとか、
C++/Javaやっとけばオブジェクト指向がわかるみたいな伝説に惑わされたらだめよ。
結局は言語とは別に勉強しなければ使えないんだから。

沢山勉強することがあることは素晴らしいことだよ

>>332
言っとくけどと言いつつ何も言ってないゆとりに乾杯

始めての言語、C++買ってきた
夏休みの2週間でものにする

構造化が判ってない人間にオブジェクト指向が判るわけ無いと思う

ソースを整理整頓するという達観した視点で眺めれば
オブ指信仰なんて馬鹿らしい。

一つの言語しか知らない奴はそれが判らない。

（C++で？）オブジェクト指向を徹底すれば良い設計になると考える馬鹿も
居るということだろうけど、総合的な視点で良いコードを書くための
選択肢の一つに過ぎないだろ。
>>336
個人的には、構造化がわかるのにオブジェクト指向が理解できない人間が
理解できないｗ
そういう人は感覚じゃなく理屈でしか構造化を考えられないんだろうけど。

構造化ってなんですか

>>334
え？言ってるじゃん。

>>338
構造化 ＝ 手続きをモジュールにまとめること
と考えている俺にとって、
構造化とオブジェクト指向の間の溝が深かったよ。
スーパークラス、サブクラス、メッセージ受け渡しの概念を理解するの何年もかかった。

昔のオブジェクト指向の解説でよくあった、動物クラスを定義して、そこから犬クラスや猫クラスを派生させて、
「鳴け」とメッセージを送ると、「わん」とか「にゃー」とか鳴くとかってのを読んで、なるほどとは思ったけど、
じっさいのプログラミングでどう使っていいのかよくわからなかったな。

今はコードの実例がいっぱいあるから、JavaやらC#を使っていて、それでデザパタの本とか読んだら、すぐぴんと
くるんじゃないかと思うけど。

>>341
構造化が手続きによって処理をまとめる手法なのに対し
オブジェクト指向は集合の概念によって処理をまとめるだけのこと

名前空間の概念は最高だ…
emacs lispを弄る度にそう思うよ
これを使うだけでもC++を使う理由になる

CもC++も、ややこしすぎてわけわかんない。こんなのやる人間はヒマ人。

Visial Basicこそ最優秀プログラム言語だ。

>>345
ある意味正解。暴論すれば、
VBはアプリケーションを作るための言語。
C/C++はプログラミングするための言語。

>>345
同意だな、CもC++も低級言語（アセンブリ言語）に片足突っ込んでるような
もんだからややこしいよね（俺はアセンブリ言語好きだけど・・・）
Visial Basicこそ真の高級言語だな
Ｃ言語は使ってみたいけどヒマがないんだよね（インストールはしてあるのに･･･）

C/C++はOSやデバイスドライバを作るための言語

C++は好きだけど嫌い。でも、この言語ほど可能性がある言語はない。
ほとんど破たんしているけど、悪女に騙されているよう

どんな言語にでも言える事だけど、結局使う人次第。
つまり、その程度の定義しか出来ないって事だけど……
自分一人で完結出来る程度の物なら、楽しく使えるんだがな。

>>348
あとゲームも
>>349
本当に可能性あるよね、>>347が指摘してる通りアセンブリ言語に片足
突っ込んでるからね、それがややこしくしてる原因でもあるだよなー

俺C++0xでEmacsのクローンを作ったら彼女と結婚するんだ…

>>352
つまり、独身を貫くということですね、判ります。

ｌ

>>347
>Ｃ言語は使ってみたいけどヒマがないんだよね（インストールはしてあるのに･･･）


使った事ないのに語るなよｗ

ゲーム系や、速度が重要なPC上のアプリケーションとかでは
C/C++以外の選択肢は無いと思うよ。
Java使ったことないんだけど、JITだっけ？
特定の状況（最適化のかかった部分コード、つまり短い同じ処理を繰り返すような状況？）で
C/C++を超える速度を出すのは素晴らしいとは思うんだけど、
いかんせん「規模がでかくてしかも速度を要求する」ようなソフトは
低レベル処理に首つっこみつつ高レベルな設計が出来る言語を使うしかない。
コンシューマやPC上の３Dゲーは、やってる人間に言わせればまだまだ全然全く
CPU・GPUのパワー足りてないからな。

訂正。PC上のアプリケーションでも速度が重要なものとかは。

exeを吐けるJavaコンパイラが有償で売られてたりするけど、
そういうのじゃダメなの？

あー、そういうのもあるのか。詳しくなくてｽﾏｿヽ( ´･ω･)ﾉ
けど言語仕様上、Javaは安全性重視・オブジェクト指向重視なんじゃないのかな。
やっぱゲームには、CやC++みたいなキ○ガイじみた速度重視の言語が必要だと思う。
他の分野だとJavaがかなり市民権得てきてるなと思うけど。

C++でもConceptとかあれば安全なコード書けるよ
記述の冗長性はコードスニペットとか、エディタ側でどうにかできるし

そういうふうに何かツールに頼る奴って決まってなんちゃってプログラマなんだよな

楽出来る物があるのに楽しないのはプログラマー的にどうなの？とは思う

検索したり仕様を合わせたりマニュアル読んだりするより書いた方が早いときはそうするよ
よそのツール使って重くされちゃかなわんからな

そうだよね既存の機能に満足できないで
Emacsやvim、VSのVBAで新たにツールを作ってそれに頼る人はなんちゃってだよね
真のプログラマは脳内でコードが出きあがってるからあとはそれをシーケンシャルに打つスタイルの人だよね

Boostの中心人物の一人であるDave AbrahamsさんはEmacs派
昔C++のテンプレートを多用したコードに対し正確に見易く自動インデントする設定を晒してた
こういうのもツールに頼るなんちゃってプログラマなんだよね
真のプログラマは登大遊みたいに補完も使わず高速タイピングでベタ打ちする人達

核心をつかれたからってそんなにファビョるなよｗ

結局環境を変える手間があるなら、自分の適応能力を上げた方がいい
これを誰かオレポータビリティって言ってたな
自作だろうがツールに頼るやつは軟弱者
趣味のコーディングすら止めた方がいい

パソコンというツールに使われる男の人ってステキですね。

真剣に推移を注視しています
６２歳タイプ苦手
>>345-346
visualなんとかの評価話題は別ですね

VBはもはや言語と言ってもいいと思うけど。
元祖BASICを統合開発環境にした、とは到底言えない。
あんなもん既にWinアプリ開発用の独自言語だ

もはやっていうか、最初から言語だろ。

VCのような「Visual C++という名称がC++言語の統合開発環境」
な例とは違ってVBはもう独自言語の域だろ、という意味なんだがｗ
それともVisualC++っていう言語があるとか思ってんの？バカなの？

>>372
独自拡張までを含めて言うならVisualC++と呼ぶべきかもしれんな

行番号BASIC
↓
構造化BASIC
↓
イベントドリブンのVB　(ハイパーカードの影響の指摘もある)

ふつーにつながってる。

BCCの独自拡張もすごかったな。

virtual void hoge() = 0;

みたいな純粋仮想関数の書き方を勝手に拡張して、

virtual void hoge() = WM_HOGE;

みたいにして、イベントハンドラにできるとか。
これはちょっと一線を超えてる気がした。

ありゃObjectPascalと互換性持たせるためじゃないの？
アクセサメソッドのプロパティ化、とか芸当もできたし。

いいわけねーだろ
Cでのメモリの取り扱いをマスターするまでは、C++に手出すべきではない

>>10
つまりC言語ってC++があるなら使う意味無いの？

馬鹿が使うならCでもC++でも変わらない

うむ。かなりオブジェクト指向の日本語から学んでいるのに
（手続き型の）英語を先にまなんでいる奴らのほうが研究能力（そふとの世界で）
が高いのはそういうことだ。

そういう俗流文化論みたいのはいいから。

490 名前：名無し検定１級さん 投稿日：2008/10/26(日) 01:59:26
高度な３Dゲームといえば
グランツーリスモのプログラマは（最低年収８００だか１０００だか）
C/C++/ASMでの募集だったな。


491 名前：名無し検定１級さん 投稿日：2008/10/26(日) 02:00:51
グランツー
http://www.polyphony.co.jp/

俺様がポインタを8年かけて習得したというのに、
その概念がなければC++も真に習得できないのに、
2週間ほどでC++をものにできるわけがない！
俺は中学卒業時愛知県で上位200番だった男だぞ！

愛知県ｗ　m9(^д^)ﾌﾟｷﾞｬｰ

>本一冊読んでマスターしたと勘違いしちゃうやつ多いからなぁ。

ねこでもわかるＣ言語プログラミング読んだだけじゃだめなの？
みなさんいつも何を作ろうとプログラミングしてるの？

俺の場合はC言語のポインタの習得の方が難しかったな
最初は全然わからなくて、ある日突然頭の中で何かが閃いて
ポインタを理解した感じ。

C++の方はそういう閃きはなく、地道に少しずつ学んできたが
Cのポインタに比べるとまだ学びやすかった。

VBは響きが良くない
もっとかっこいい名前にするべきだ

Virtual Boy でどうか。

個人的には、よく言われるポインタが理解できない。ってのが良く分からないが……
たしかに、他のものよりも若干扱いにくい部分かもしれないし、
利用に際しては十分注意が必要だけど、べつに、意味が分からないことはないだろ？

あと、Ｃ＋＋の方がなにかと簡単にできる事も多いから、
別にＣから入る必要性はないと思う。
正直にいってさ。
こんな過疎スレだけどｗｗｗ

ポインタを理解できない人をポインタに置き換えれば理解できるかも

最初にCASL2の問題集でも一冊やらせたら後々迷わなくて済むと思う。

ニコ動にポインタの解説動画があったが、あれは分かりやすかったな
タイトルは忘れたが

初心者にとってprinf 一つ覚えるのに、数ページに及ぶ理屈や概念なんざどうでもいい
「printf は文字を表示出来ますよ〜。文法はこうです〜。」
「他にも色々あるけど、そゆ事は大人になってから覚えようね（はぁと 」
その程度で良い。
理屈や概念なんて物は初心者にとって学習の妨げになる
そんな物は後から覚えれば良いわけで今ではない。
大体、言語を覚えるのにインターネットや本で完結する奴なんて趣味でしか使わないだろ？
なーんてHSPしか使えない俺が言ってみる

printfを覚えるよりも先に、and回路、or回路、not回路を覚えるのが先だな
その後、CASL2やって、Cに移ればポインタで苦労する事は無い
ポインタに悩まされなければ、C++なんて屁みたいなもんだ

C++の嫌なところはポインタだけなのだろうか・・・

JAVA好きはポインタ毛嫌いする人多いけど、
ポインタこそC言語の便利なところで、
これがあったからこそ今でもC言語がよく使われてるように思う。

Java はむしろポインタばっかだろ・・・。

だな。ポインタ演算がないだけで。

javaってオブジェクトの無いところをポイントすると怒るんじゃなかったっけ？
c風に書くと
char buffer[100];
char *ptr = buffer - 1;
とか。
ポインタが問題なんじゃなくて、cとC++では「オブジェクトの無いところをポイントしても怒らない」ことが問題なんだよね。

そう、無効なところを表す手段がnullしかない。

まあガベコレがあるからこそだな。
無効なオブジェクトを null 以外指しようが無い。

ポインタの指している位置にオブジェクトがあるかどうかをコンパイラに判断させるのは無理だろう

むか〜し、どっかで翻訳されたC言語だったか、アセンブラ言語の
チュートリアルの記事を読んだ時に、禅がどうのこうのとか
宗教じみた内容だった気がするんだけど、
今でも、そのような宗教的なプログラマはいるんですか？

また、何で宗教が絡むんですか？仏教とか特に・・・

プログラマは宗教論争が結構好き

×アセンブラ言語
○アセンブリ言語

>>404
あらら；
信念が強いんですかね・・・

>>405
あぅｗトンです

PDAのPalmには「Zen of Palm」という思想があったな。

ポインタ理解するならアセンブリやった方が早いだろ。