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

C言語よりC++を先に習 ..

245:デフォルトの名無しさん
08/08/05 09:48:35
>>244
そんな分かりにくいコードを読めることよりも、書かないことが重要なんだよ。

246:デフォルトの名無しさん
08/08/05 10:21:08
>>244
funcはポインタ、指す先は関数、関数の引数はint、帰り値はポインタ、そのポインタの指す先はint型5個の配列。
現実にこんなコードを書くことは避けるけれど、読めないというのは信頼できなくなるから困るな。

247:デフォルトの名無しさん
08/08/05 10:28:05
>>245
書くべき・書かないべき、の話をしてるんじゃないよ

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

249:デフォルトの名無しさん
08/08/05 15:22:47
>>248
おまえが言ってるのはこんなんか？（要素数は勝手に5を補ったが）
int (*func[5])(int);

250:デフォルトの名無しさん
08/08/05 16:13:12
>>248

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

251:名無しさん
08/08/05 16:31:44
#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;
}
なるほどこういうことか。ひとつ利口になったような気がするｗ

252:デフォルトの名無しさん
08/08/05 16:35:07
typedefしろよw

253:デフォルトの名無しさん
08/08/05 16:38:00
C言語でOOPするくらいなら、始めからC++使えよって思うけど、
C++が使えない環境が無いわけでも無いので、仕方ないのかなあ。

254:デフォルトの名無しさん
08/08/05 17:19:11
>>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でコンパイル可能。

255:名無しさん
08/08/05 20:51:14
配列はポインタだから
配列へのポインタは、ポインタへのポインタだと。
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()の中の可読性はそれ程悪くないか．．．
うーーーん

256:デフォルトの名無しさん
08/08/06 05:41:49
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つ持つ配列だとわかる。
というように、演算子の結合順位を追っていくと、より具体的な情報が後から
後からついてくる。
ポインタである→何のポインタ？→関数へのポインタである…

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

258:名無しさん
08/08/06 12:38:13
#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;
}

259:名無しさん
08/08/06 12:46:22
この方がすこし、可読性があがるか

260:デフォルトの名無しさん
08/08/06 18:17:41
また自分基準の可読性か、当てにならないんだよ、お前のは

261:名無しさん
08/08/06 22:07:18
#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;
}

262:デフォルトの名無しさん
08/08/07 00:06:18
そろそろスレ違い

263:デフォルトの名無しさん
08/08/07 05:23:21
けっきょくこういう頑固な奴は、いつまでたっても理解しないもの

264:名無しさん
08/08/07 08:35:36
(*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を要素とする配列へのポインタである。*/

そろそろスレ違い

265:デフォルトの名無しさん
08/08/08 16:39:13
スレ違いです

ヘタなコードの書き方ｽﾚﾘﾝｸ(tech板)
【動くんか？】摩訶不思議なコード【何語？】ｽﾚﾘﾝｸ(tech板)
一度は読んだほうがいい、ソースコードｽﾚﾘﾝｸ(tech板)
今までに見たソースコードで一番感動したのはｽﾚﾘﾝｸ(tech板)

266:デフォルトの名無しさん
08/08/10 04:57:23
必ずしもC++を先にやったからこうなったとはいえないが…
ｽﾚﾘﾝｸ(tech板:82-89番)

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

267:デフォルトの名無しさん
08/08/10 08:39:09
>>266
大丈夫、どうせCを先にやっても理解できないから。

268:デフォルトの名無しさん
08/08/11 09:34:22
JAVAやCでC++をやるのが結局１番？

269:デフォルトの名無しさん
08/08/11 14:05:57
JavaやCでC++とはどういう意味だ？

270:デフォルトの名無しさん
08/08/11 18:26:07
>>268
そのまえに日本語を

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

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

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

272:デフォルトの名無しさん
08/08/11 20:43:53
それを言うなら絵に描いたモチだろ。

273:デフォルトの名無しさん
08/08/11 20:59:46
ちゃんと教えてくれる人に良い教材でCからやれ。
プログラムとメモリの対応関係が肌で理解できるまでは
Cから卒業しちゃいかん。

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

275:デフォルトの名無しさん
08/08/11 22:44:54
アセンブラもＣも仕事で使ってた者だが>>273には賛成できないな。

276:デフォルトの名無しさん
08/08/11 23:55:44
おれは>>273に賛成

277:デフォルトの名無しさん
08/08/12 00:02:38
Cが中途半端って感覚がそもそもおかしい。

278:デフォルトの名無しさん
08/08/12 10:55:14
アセンブラはほとんど知らないけど>>273には賛成できないな

279:デフォルトの名無しさん
08/08/12 14:12:06
リリースビルドでデバッグ情報切った時しかおかしくならないんで
どうしようもありません…って言うのは勘弁して欲しいぞ。

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

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

281:デフォルトの名無しさん
08/08/12 15:44:21
>>280
ログ出しルーチンを有効にしたとたん症状が潜伏したりしてなｗ

282:デフォルトの名無しさん
08/08/12 20:49:53
mallocは好かん。sizeofでバイト数を取得しなければならないし、
のっけからポインタの型キャストがあるし。

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

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

283:デフォルトの名無しさん
08/08/12 21:18:27
>>279
ろくにアサーションやってないからそうなる

284:デフォルトの名無しさん
08/08/12 22:12:09
>>282
お前と一緒にC++開発したくないわ。
Javaでもやってくれ。

285:デフォルトの名無しさん
08/08/12 22:35:37
Cは文法簡単だろ？（記述の手間は多少かかるが）
手間ひまかけて『コンピュータ』を学ぶにはかなりいい選択
なんだよ。

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

286:デフォルトの名無しさん
08/08/13 18:22:21
プログラム一筋ならＣもＣ＋＋もやらずにＪＡＶＡかＲＵＢＹをやればいい。
でもハードウェアのことも学びたいなら、Ｃとアセンブラをしっかり。

287:デフォルトの名無しさん
08/08/13 19:05:46
ハードウェアのことも学びたいなら、じゃなくて
ハードウェアのことを学んだら、だろ
本末転倒だ

288:デフォルトの名無しさん
08/08/13 20:36:51
とりあえずは目の前にある環境に既に入ってる言語使えばそれでじゅうぶん。

289:デフォルトの名無しさん
08/08/13 22:11:33
アセンブラは全く使えないけど、やっておくとハードウェアの仕組みが理解できると思うよ。

290:デフォルトの名無しさん
08/08/13 22:14:13
ハードウェアというか、正確にはコンピュータアーキテクチャ
ようするに、ハードウェアとアセンブラプログラマの接点の部分だ
ハードウェアはまた別

291:デフォルトの名無しさん
08/08/13 23:34:48
うーんどっちが先とかあるものではないだろう。

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

293:デフォルトの名無しさん
08/08/14 16:00:33
人の自慢話ほど聞かされて馬鹿らしいものはない

294:デフォルトの名無しさん
08/08/14 19:10:10
Dr.Bjarne曰く「C++をやる予定なら最初からC++やったほうがいいよ」
らしい。

295:デフォルトの名無しさん
08/08/14 23:58:04
問題ない。

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

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

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

296:デフォルトの名無しさん
08/08/15 00:04:33
Embedded C++があるじゃないか。
まあテンプレートや例外処理はカットされているけど。

297:デフォルトの名無しさん
08/08/15 00:04:49
STLをマスターするより先にboost触った方がいいよ
こうですね

298:デフォルトの名無しさん
08/08/15 00:06:29
VC9 SP1のtr1で当面は十分では

299:デフォルトの名無しさん
08/08/15 00:09:38
だいたいCを軽視してる奴にまともなPGはいない

300:デフォルトの名無しさん
08/08/15 00:10:16
と、C++が理解できない頭の硬いオッサンが申しております

301:デフォルトの名無しさん
08/08/15 00:11:47
言語が理解できないって言っちゃう時点でもうね・・・

302:デフォルトの名無しさん
08/08/15 00:19:20
言語を一つ理解するのに数年かかるというのに、無闇に修得対象を広げたくない。
マニュアル斜め読みしただけで理解したって言っていいんなら話は別だけど。

303:デフォルトの名無しさん
08/08/15 00:21:49
本一冊読んでマスターしたと勘違いしちゃうやつ多いからなぁ。
バグ出したり可読性下げててもそれが理解不足であることも理解できない。

304:デフォルトの名無しさん
08/08/15 00:24:48
言語のベンダー試験あたりに合格するレベルでいいなら何年もいらない。

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

306:デフォルトの名無しさん
08/08/15 00:27:42
便利なものなら使いたいじゃんスマポとかrangeとか

307:デフォルトの名無しさん
08/08/15 00:30:20
言語をひとつしか知らないやつは、その言語に深く精通してるかっていうと、そういうことはまず無いな。
複数知ってるから優秀ってわけでもないけど。

308:デフォルトの名無しさん
08/08/15 00:47:52
沢山知っててもいいんじゃね？
プログラマなら一年に一つは新しい言語を触れって格言もあるし
いいじゃんLisp系もやってML系もやってLL系もやってbrain fuckみたいな類の変なのもやればいいんだよ
boostの中のもLispやHaskellにインスパイアされてるし

309:デフォルトの名無しさん
08/08/15 00:48:53
>>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[];　　// こんなことやる機会あんまないのでちょっと自信ない

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

310:デフォルトの名無しさん
08/08/15 00:50:56
305じゃないけど、まんまと引っ掛かったって感じだな。

311:デフォルトの名無しさん
08/08/15 00:53:12
スタックじゃなくてヒープを使えと
そういう引っ掛けだったの？

312:デフォルトの名無しさん
08/08/15 01:03:22
動的っていうからにはそうだろう。
仮にchar Hoge[HEIGHT][WIDTH]でやるとしても、
= {NULL}はおかしいし、extern char Hoge[][WIDTH];でないといけない。

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

314:デフォルトの名無しさん
08/08/15 01:11:59
char(*hoge)[WIDTH] = NULL;
hoge = malloc(sizeof(char[HEIGHT][WIDTH]));
こうだろ

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

316:デフォルトの名無しさん
08/08/15 01:35:49
まぁ知ってても実際に使う機会はないな
トリビアみたいなもんだ

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

318:デフォルトの名無しさん
08/08/15 01:55:28
それは、初期化子の数が足りなければ、残りの要素は0で初期化されるという性質を使ったテクニック。
{{1}}で最初の要素以外が0になるというのであれば、それは期待どおりの結果。

ただし、そもそもchar型の要素をNULLで初期化しようってのが大間違い。
URLﾘﾝｸ(www.kouno.jp)

319:デフォルトの名無しさん
08/08/15 07:31:29
そもそもchar型の要素をNULLで初期化しろなんて>>305は言ってないしね。

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

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

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

321:デフォルトの名無しさん
08/08/15 09:15:10
>>320
>>314は分かってるだろ。その上に突っ込んでるだけだしｗ

322:デフォルトの名無しさん
08/08/15 09:48:00
できた
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;
}

323:デフォルトの名無しさん
08/08/15 09:55:14
これはひどい

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

325:デフォルトの名無しさん
08/08/15 11:46:57
酷いですか御免なしあ

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

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

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

328:デフォルトの名無しさん
08/08/15 13:37:13
私なら、三次元配列でも一次元で確保してオフセット計算を関数でやらせる。
幅や高さが固定な用途ばかりじゃないんでね。

329:デフォルトの名無しさん
08/08/15 16:46:35
確かにnewがあればmalloc要らないとか、Cは既に陳腐化したツールも少なくないし、
その辺は適当にスキップしてC++を優先して学ぶのもよいと思う。

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

330:デフォルトの名無しさん
08/08/15 16:55:28
むしろプログラマーに徹したいのならC/C++制覇しろよ。
VBAとかJavaに徹してるプログラマってｗ

331:デフォルトの名無しさん
08/08/15 17:59:40
私大文系ならVBAに徹するしかないだろｗ

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

333:デフォルトの名無しさん
08/08/15 20:55:49
沢山勉強することがあることは素晴らしいことだよ

334:デフォルトの名無しさん
08/08/16 00:42:53
>>332
言っとくけどと言いつつ何も言ってないゆとりに乾杯

335:デフォルトの名無しさん
08/08/16 08:17:42
始めての言語、C++買ってきた
夏休みの2週間でものにする

336:デフォルトの名無しさん
08/08/16 08:31:44
構造化が判ってない人間にオブジェクト指向が判るわけ無いと思う

337:デフォルトの名無しさん
08/08/16 08:33:05
ソースを整理整頓するという達観した視点で眺めれば
オブ指信仰なんて馬鹿らしい。

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

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

339:デフォルトの名無しさん
08/08/16 10:03:15
構造化ってなんですか

340:デフォルトの名無しさん
08/08/16 10:04:50
>>334
え？言ってるじゃん。

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

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

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

343:デフォルトの名無しさん
08/08/16 10:35:00
>>341
構造化が手続きによって処理をまとめる手法なのに対し
オブジェクト指向は集合の概念によって処理をまとめるだけのこと

344:デフォルトの名無しさん
08/08/16 12:32:25
名前空間の概念は最高だ…
emacs lispを弄る度にそう思うよ
これを使うだけでもC++を使う理由になる

345:デフォルトの名無しさん
08/08/16 20:58:42
CもC++も、ややこしすぎてわけわかんない。こんなのやる人間はヒマ人。

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

346:デフォルトの名無しさん
08/08/16 22:28:30
>>345
ある意味正解。暴論すれば、
VBはアプリケーションを作るための言語。
C/C++はプログラミングするための言語。

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

348:デフォルトの名無しさん
08/08/16 22:55:20
C/C++はOSやデバイスドライバを作るための言語

349:デフォルトの名無しさん
08/08/16 23:47:14
C++は好きだけど嫌い。でも、この言語ほど可能性がある言語はない。
ほとんど破たんしているけど、悪女に騙されているよう

350:デフォルトの名無しさん
08/08/17 03:38:44
どんな言語にでも言える事だけど、結局使う人次第。
つまり、その程度の定義しか出来ないって事だけど……
自分一人で完結出来る程度の物なら、楽しく使えるんだがな。

351:デフォルトの名無しさん
08/08/17 22:24:38
>>348
あとゲームも
>>349
本当に可能性あるよね、>>347が指摘してる通りアセンブリ言語に片足
突っ込んでるからね、それがややこしくしてる原因でもあるだよなー

352:デフォルトの名無しさん
08/08/18 01:20:04
俺C++0xでEmacsのクローンを作ったら彼女と結婚するんだ…

353:デフォルトの名無しさん
08/08/18 10:49:27
>>352
つまり、独身を貫くということですね、判ります。

354:ｋ ◆zoHAGELM5Q
08/08/18 13:11:23
ｌ

355:デフォルトの名無しさん
08/08/18 13:21:51
>>347
>Ｃ言語は使ってみたいけどヒマがないんだよね（インストールはしてあるのに･･･）

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

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

357:デフォルトの名無しさん
08/08/18 14:19:32
訂正。PC上のアプリケーションでも速度が重要なものとかは。

358:デフォルトの名無しさん
08/08/18 14:24:25
exeを吐けるJavaコンパイラが有償で売られてたりするけど、
そういうのじゃダメなの？

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

360:デフォルトの名無しさん
08/08/18 14:34:59
C++でもConceptとかあれば安全なコード書けるよ
記述の冗長性はコードスニペットとか、エディタ側でどうにかできるし

361:デフォルトの名無しさん
08/08/18 14:42:40
そういうふうに何かツールに頼る奴って決まってなんちゃってプログラマなんだよな

362:デフォルトの名無しさん
08/08/18 14:45:31
楽出来る物があるのに楽しないのはプログラマー的にどうなの？とは思う

363:デフォルトの名無しさん
08/08/18 14:50:55
検索したり仕様を合わせたりマニュアル読んだりするより書いた方が早いときはそうするよ
よそのツール使って重くされちゃかなわんからな

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

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

366:デフォルトの名無しさん
08/08/18 15:20:01
核心をつかれたからってそんなにファビョるなよｗ

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

368:デフォルトの名無しさん
08/08/18 15:43:33
パソコンというツールに使われる男の人ってステキですね。

369:デフォルトの名無しさん
08/08/21 22:47:26
真剣に推移を注視しています
６２歳タイプ苦手
>>345-346
visualなんとかの評価話題は別ですね

370:デフォルトの名無しさん
08/08/22 19:23:15
VBはもはや言語と言ってもいいと思うけど。
元祖BASICを統合開発環境にした、とは到底言えない。
あんなもん既にWinアプリ開発用の独自言語だ

371:デフォルトの名無しさん
08/08/22 23:15:39
もはやっていうか、最初から言語だろ。

372:デフォルトの名無しさん
08/08/22 23:27:44
VCのような「Visual C++という名称がC++言語の統合開発環境」
な例とは違ってVBはもう独自言語の域だろ、という意味なんだがｗ
それともVisualC++っていう言語があるとか思ってんの？バカなの？

373:デフォルトの名無しさん
08/08/22 23:32:15
>>372
独自拡張までを含めて言うならVisualC++と呼ぶべきかもしれんな

374:デフォルトの名無しさん
08/08/23 00:04:50
行番号BASIC
↓
構造化BASIC
↓
イベントドリブンのVB　(ハイパーカードの影響の指摘もある)

ふつーにつながってる。

375:デフォルトの名無しさん
08/08/23 00:08:35
BCCの独自拡張もすごかったな。

virtual void hoge() = 0;

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

virtual void hoge() = WM_HOGE;

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

376:デフォルトの名無しさん
08/08/27 00:56:26
ありゃObjectPascalと互換性持たせるためじゃないの？
アクセサメソッドのプロパティ化、とか芸当もできたし。

377:デフォルトの名無しさん
08/10/10 09:29:05
いいわけねーだろ
Cでのメモリの取り扱いをマスターするまでは、C++に手出すべきではない

378:デフォルトの名無しさん
08/10/25 14:58:22
>>10
つまりC言語ってC++があるなら使う意味無いの？

379:デフォルトの名無しさん
08/10/25 17:32:30
馬鹿が使うならCでもC++でも変わらない

380:デフォルトの名無しさん
08/10/25 17:43:41
うむ。かなりオブジェクト指向の日本語から学んでいるのに
（手続き型の）英語を先にまなんでいる奴らのほうが研究能力（そふとの世界で）
が高いのはそういうことだ。

381:デフォルトの名無しさん
08/10/25 18:15:54
そういう俗流文化論みたいのはいいから。

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

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

383:デフォルトの名無しさん
08/10/27 14:35:04
俺様がポインタを8年かけて習得したというのに、
その概念がなければC++も真に習得できないのに、
2週間ほどでC++をものにできるわけがない！
俺は中学卒業時愛知県で上位200番だった男だぞ！

384:デフォルトの名無しさん
08/10/27 15:08:22
愛知県ｗ　m9(^д^)ﾌﾟｷﾞｬｰ

385:デフォルトの名無しさん
08/10/27 15:44:53
>本一冊読んでマスターしたと勘違いしちゃうやつ多いからなぁ。

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

386:デフォルトの名無しさん
08/10/27 15:59:28
俺の場合はC言語のポインタの習得の方が難しかったな
最初は全然わからなくて、ある日突然頭の中で何かが閃いて
ポインタを理解した感じ。

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

387:デフォルトの名無しさん
08/10/27 23:26:56
VBは響きが良くない
もっとかっこいい名前にするべきだ

388:デフォルトの名無しさん
08/11/05 16:16:16
Virtual Boy でどうか。

389:デフォルトの名無しさん
08/11/10 11:43:28
個人的には、よく言われるポインタが理解できない。ってのが良く分からないが……
たしかに、他のものよりも若干扱いにくい部分かもしれないし、
利用に際しては十分注意が必要だけど、べつに、意味が分からないことはないだろ？

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

390:デフォルトの名無しさん
08/11/10 12:14:49
ポインタを理解できない人をポインタに置き換えれば理解できるかも

391:デフォルトの名無しさん
08/11/10 13:23:53
最初にCASL2の問題集でも一冊やらせたら後々迷わなくて済むと思う。

392:デフォルトの名無しさん
08/11/10 23:09:20
ニコ動にポインタの解説動画があったが、あれは分かりやすかったな
タイトルは忘れたが

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

394:デフォルトの名無しさん
08/11/19 08:09:36
printfを覚えるよりも先に、and回路、or回路、not回路を覚えるのが先だな
その後、CASL2やって、Cに移ればポインタで苦労する事は無い
ポインタに悩まされなければ、C++なんて屁みたいなもんだ

395:デフォルトの名無しさん
08/11/19 14:57:37
C++の嫌なところはポインタだけなのだろうか・・・

396:デフォルトの名無しさん
08/11/19 22:13:33
JAVA好きはポインタ毛嫌いする人多いけど、
ポインタこそC言語の便利なところで、
これがあったからこそ今でもC言語がよく使われてるように思う。

397:デフォルトの名無しさん
08/11/19 22:41:42
Java はむしろポインタばっかだろ・・・。

398:デフォルトの名無しさん
08/11/19 23:29:07
だな。ポインタ演算がないだけで。

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

400:デフォルトの名無しさん
08/11/20 12:55:20
そう、無効なところを表す手段がnullしかない。

401:デフォルトの名無しさん
08/11/20 20:26:27
まあガベコレがあるからこそだな。
無効なオブジェクトを null 以外指しようが無い。

402:デフォルトの名無しさん
08/11/22 12:35:10
ポインタの指している位置にオブジェクトがあるかどうかをコンパイラに判断させるのは無理だろう

403:デフォルトの名無しさん
08/11/23 03:52:04
むか～し、どっかで翻訳されたC言語だったか、アセンブラ言語の
チュートリアルの記事を読んだ時に、禅がどうのこうのとか
宗教じみた内容だった気がするんだけど、
今でも、そのような宗教的なプログラマはいるんですか？

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

404:デフォルトの名無しさん
08/11/23 04:38:53
プログラマは宗教論争が結構好き

405:デフォルトの名無しさん
08/11/23 13:48:10
×アセンブラ言語
○アセンブリ言語

406:デフォルトの名無しさん
08/11/24 21:19:13
>>404
あらら；
信念が強いんですかね・・・

>>405
あぅｗトンです

407:デフォルトの名無しさん
08/11/25 13:39:28
PDAのPalmには「Zen of Palm」という思想があったな。

408:デフォルトの名無しさん
08/11/27 23:46:24
ポインタ理解するならアセンブリやった方が早いだろ。