トップページ⇒tech
408コメント120KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2005/10/27(木) 21:34:44
教えてください。
0232参考の名無しさん2008/08/04(月) 07:17:56
ハッカーになろう (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

0233デフォルトの名無しさん2008/08/04(月) 12:03:39
>>231
いまどきそれが妥当ともいえないが、アセンブラ知っていれば
Cの学習、開発で一歩抜きん出られるのも事実。

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

Cをしっかりやる＝＝ターゲットのアセンブラにも多少触れる
＝＝マシンの裸の挙動を垣間見るだろうしね。
0234デフォルトの名無しさん2008/08/04(月) 16:33:22
>>229
それはC++の中でCから引き継いだ部分をちゃんとやってないって話だろう。
CよりC++を先にやるっていっても、ポインタよりクラスを先にやるって意味ではなく、
C++の機能として取り込まれたポインタとかは当然習得しつつも、
mallocとかそういうのは最初からnewでいいでしょって話じゃないの？
0235デフォルトの名無しさん2008/08/04(月) 16:38:55
若い人の多くが「Cはできます」と言い切って入社してくるが、安心して開発を任せられる人を見ることはほとんどない。
Cは開発コストを犠牲にして速度を稼ぐ言語であり、開発された1970年代においては価値が高かったのだが、
CPUが速くなり、ライブラリを扱うことの方が重要になった今となっては危険なだけの言語になってしまっている。
Cが本当に役に立っていた時代は、SQLもGUIも、もちろんwwwも無かった。CPUとメモリとディスクがあっただけだ。

今は皆がCを学ぶ必要はない時代だと思う。ラテン語のように、必要な人や興味がある人だけが学べば充分だろう。
0236デフォルトの名無しさん2008/08/04(月) 17:18:27
>>234
＞それはC++の中でCから引き継いだ部分をちゃんとやってないって話だろう。
C++いきなり入るとこういうふうになるという話。だってCの部分をやったあと
その理解が問題ないと分かるまで次のカリキュラムは待ってくれまい？

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

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

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

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

そういう君はいきなりC++族かい？だったらたいへんセンスあります。
0237デフォルトの名無しさん2008/08/04(月) 17:24:24
>>235
＞ライブラリを扱うことの方が重要

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

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

ライブラリを乗りこなすのが重要な分野は他の言語使ったほうがいいんじゃないかい
0238デフォルトの名無しさん2008/08/04(月) 17:44:38
言い過ぎたかな
＞こっちを作る側じゃないですか？
↓
＞こっち『も』
C++でアプリ作ってるしね
0239デフォルトの名無しさん2008/08/04(月) 17:48:52
>>236
いきなりC++な俺は練習問題2、3解いて済ませたけどな。

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

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

iostreamでoperator<<とかオーバーロードしてる時点で、順番に教えてくのは無理なんだから、
適当に「おまじない」を駆使して先進めばいいと思うんだけどな。
0240デフォルトの名無しさん2008/08/04(月) 17:57:06
あー確かに。malloc()とqsort()とキャストを教えなくて済むだけでもC++の方がいいわ。
仕事だとその一方でiostreamではなくてprintf()系を教える必要があるのが難だけど。
0241デフォルトの名無しさん2008/08/04(月) 18:05:40
>>239
＞いきなりC++な俺は練習問題2、3解いて済ませたけどな。
すげーな。
ポインタを（C的にでも）モノにするまで、何か下積みの経験あった？

理解できないやつの気持ちは俺も分からないんだが、俺の場合は既に
マシン語で遊んでいたからな…。
0242デフォルトの名無しさん2008/08/04(月) 18:59:20
>>241
特に、強いて言えばBASICやってたくらい。
マシン語とかアセンブリは無理だｗ
0243デフォルトの名無しさん2008/08/04(月) 19:19:31
BASICやってたんなら制御文ところはおそらく楽勝だったろうから
ポインタあたりに集中できたんじゃね？　POKEとかPEEKだったら
噴出すが。
0244デフォルトの名無しさん2008/08/05(火) 09:38:09
ポインタわかりますと言ってる奴でも

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

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

0245デフォルトの名無しさん2008/08/05(火) 09:48:35
>>244
そんな分かりにくいコードを読めることよりも、書かないことが重要なんだよ。
0246デフォルトの名無しさん2008/08/05(火) 10:21:08
>>244
funcはポインタ、指す先は関数、関数の引数はint、帰り値はポインタ、そのポインタの指す先はint型5個の配列。
現実にこんなコードを書くことは避けるけれど、読めないというのは信頼できなくなるから困るな。
0247デフォルトの名無しさん2008/08/05(火) 10:28:05
>>245
書くべき・書かないべき、の話をしてるんじゃないよ
0248名無しさん2008/08/05(火) 14:57:36
これは配列で、配列の要素はポインタで、ポインタが指すのは関数で、その関数の引数はintで、その関数の返戻値もintである。
演算子の優先順位を暗記して、右柄から解きほぐしていくとわかる。
CでOOPやるとき関数テーブルが必要になることがある。
0249デフォルトの名無しさん2008/08/05(火) 15:22:47
>>248
おまえが言ってるのはこんなんか？（要素数は勝手に5を補ったが）
int (*func[5])(int);
0250デフォルトの名無しさん2008/08/05(火) 16:13:12
>>248

>>244のことを説明してるなら、ぜんぜんあってないじゃん
0251名無しさん2008/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;
}
なるほどこういうことか。ひとつ利口になったような気がするｗ
0252デフォルトの名無しさん2008/08/05(火) 16:35:07
typedefしろよw
0253デフォルトの名無しさん2008/08/05(火) 16:38:00
C言語でOOPするくらいなら、始めからC++使えよって思うけど、
C++が使えない環境が無いわけでも無いので、仕方ないのかなあ。
0254デフォルトの名無しさん2008/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でコンパイル可能。
0255名無しさん2008/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()の中の可読性はそれ程悪くないか．．．
うーーーん


0256デフォルトの名無しさん2008/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つ持つ配列だとわかる。
というように、演算子の結合順位を追っていくと、より具体的な情報が後から
後からついてくる。
ポインタである→何のポインタ？→関数へのポインタである…
0257デフォルトの名無しさん2008/08/06(水) 05:43:34
あとね、配列はポインタじゃないよ。あくまで配列。
int array[10];
とあったらarrayはポインタではなく配列。配列名のarrayが、何かにつけて
配列の先頭アドレスとして使えるから誤解が生じる。
sizeof arryaとやれば、配列全体のサイズが返る(intが4バイトなら40)。
arrayがポインタだったならポインタ型のサイズが返る（たいていの
処理系では4バイト）。配列へのポインタというのは、int型へのポインタと
同じ参照レベルであり、ポインタへのポインタではない。
たまたま配列名から配列の先頭アドレスが取り出せると考えたほうが良い。
0258名無しさん2008/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;
}
0259名無しさん2008/08/06(水) 12:46:22
この方がすこし、可読性があがるか
0260デフォルトの名無しさん2008/08/06(水) 18:17:41
また自分基準の可読性か、当てにならないんだよ、お前のは
0261名無しさん2008/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;
}
0262デフォルトの名無しさん2008/08/07(木) 00:06:18
そろそろスレ違い
0263デフォルトの名無しさん2008/08/07(木) 05:23:21
けっきょくこういう頑固な奴は、いつまでたっても理解しないもの
0264名無しさん2008/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を要素とする配列へのポインタである。*/

そろそろスレ違い
0265デフォルトの名無しさん2008/08/08(金) 16:39:13
スレ違いです

ヘタなコードの書き方 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/
0266デフォルトの名無しさん2008/08/10(日) 04:57:23
必ずしもC++を先にやったからこうなったとはいえないが…
http://pc11.2ch.net/test/read.cgi/tech/1218023777/82-89

なんかこの手のC++初心者多い気がする。C部分の学習時点で
EXEのアーキテクチャに直結してる部分（上の例ではスタックと
ヒープの概要）などクリアしておけば、C++を学ぶ時こんなアホな
ところで回り道なんかしないよ。
0267デフォルトの名無しさん2008/08/10(日) 08:39:09
>>266
大丈夫、どうせCを先にやっても理解できないから。
0268デフォルトの名無しさん2008/08/11(月) 09:34:22
JAVAやCでC++をやるのが結局１番？
0269デフォルトの名無しさん2008/08/11(月) 14:05:57
JavaやCでC++とはどういう意味だ？
0270デフォルトの名無しさん2008/08/11(月) 18:26:07
>>268
そのまえに日本語を
027120代のプログラマー2008/08/11(月) 20:42:37
個人的には、ちゃんと教えてくれる人か、良い教材があるならC++からやった方がいいとすら思えるけどね。
ただ、自分はそんな良い教材をしらないけど。
で、そういう現状としては、自分はpython当たりのスクリプト言語から入るのもいいと思う。
HSPも仕様がまともになれば、以外と初心者向けとしていいかなぁ。と思うけど、まぁ紙に書いたモチなんで却下だろうし、
Rubyはやや高度すぎる部分があるから、下手に初心者が行くと混乱してそのまま退場しそう。
で、perlをやらせるぐらいなら、やっぱしPythonかな。と思う。


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

あと、C++がマルチパラダイム言語であるから、良いコードを読んでそれを理解できるなら、
自分の使いやすいように使うのがいいと思う。
Better　C　ぐらいのプログラムでもいいと思うし。
0272デフォルトの名無しさん2008/08/11(月) 20:43:53
それを言うなら絵に描いたモチだろ。
0273デフォルトの名無しさん2008/08/11(月) 20:59:46
ちゃんと教えてくれる人に良い教材でCからやれ。
プログラムとメモリの対応関係が肌で理解できるまでは
Cから卒業しちゃいかん。
0274デフォルトの名無しさん2008/08/11(月) 21:43:22
>>273
みたいなのをみるとどうしても、時代錯誤の老害としか思えない。
アセンブリを叩いてみろ。ってのなら多少は理解できるけど、Cっつうのが中途半端すぎるし
なんか、自分がそこで苦労して身につけたから、おまえらもそこは通れ！みたいな老害感。
0275デフォルトの名無しさん2008/08/11(月) 22:44:54
アセンブラもＣも仕事で使ってた者だが>>273には賛成できないな。
0276デフォルトの名無しさん2008/08/11(月) 23:55:44
おれは>>273に賛成
0277デフォルトの名無しさん2008/08/12(火) 00:02:38
Cが中途半端って感覚がそもそもおかしい。
0278デフォルトの名無しさん2008/08/12(火) 10:55:14
アセンブラはほとんど知らないけど>>273には賛成できないな
0279デフォルトの名無しさん2008/08/12(火) 14:12:06
リリースビルドでデバッグ情報切った時しかおかしくならないんで
どうしようもありません…って言うのは勘弁して欲しいぞ。

そういう状況が発生したら、>>278はどう対処する？
最適化切ったりデバッグビルドでリリースっていうのは不可
ってことで。
0280デフォルトの名無しさん2008/08/12(火) 15:40:30
>>279
そういう状況は、大抵バッファがオーバーしてるときに起こるもんだ。
ログの挟み撃ちをバイナリサーチ見たく半々に狭くしていって見つける。
てか、割り込みルーチンみたく、デバッガ使えない状況のデバッグって結構あるし、
いちいちその度にアセンブラコード眺めたりしないよ。
デバッグ情報か、逆アセを眺めることしかデバッグ手段が無い奴と一緒に仕事したくないぞｗ
0281デフォルトの名無しさん2008/08/12(火) 15:44:21
>>280
ログ出しルーチンを有効にしたとたん症状が潜伏したりしてなｗ
0282デフォルトの名無しさん2008/08/12(火) 20:49:53
mallocは好かん。sizeofでバイト数を取得しなければならないし、
のっけからポインタの型キャストがあるし。

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

まだ、C++のnew、delete、delete []の方がまし
0283デフォルトの名無しさん2008/08/12(火) 21:18:27
>>279
ろくにアサーションやってないからそうなる
0284デフォルトの名無しさん2008/08/12(火) 22:12:09
>>282
お前と一緒にC++開発したくないわ。
Javaでもやってくれ。
0285デフォルトの名無しさん2008/08/12(火) 22:35:37
Cは文法簡単だろ？（記述の手間は多少かかるが）
手間ひまかけて『コンピュータ』を学ぶにはかなりいい選択
なんだよ。

C++やるまえに悪いこと言わんから『コンピュータ』の学習は
終わらせておけ。
0286デフォルトの名無しさん2008/08/13(水) 18:22:21
プログラム一筋ならＣもＣ＋＋もやらずにＪＡＶＡかＲＵＢＹをやればいい。
でもハードウェアのことも学びたいなら、Ｃとアセンブラをしっかり。
0287デフォルトの名無しさん2008/08/13(水) 19:05:46
ハードウェアのことも学びたいなら、じゃなくて
ハードウェアのことを学んだら、だろ
本末転倒だ
0288デフォルトの名無しさん2008/08/13(水) 20:36:51
とりあえずは目の前にある環境に既に入ってる言語使えばそれでじゅうぶん。
0289デフォルトの名無しさん2008/08/13(水) 22:11:33
アセンブラは全く使えないけど、やっておくとハードウェアの仕組みが理解できると思うよ。
0290デフォルトの名無しさん2008/08/13(水) 22:14:13
ハードウェアというか、正確にはコンピュータアーキテクチャ
ようするに、ハードウェアとアセンブラプログラマの接点の部分だ
ハードウェアはまた別
0291デフォルトの名無しさん2008/08/13(水) 23:34:48
うーんどっちが先とかあるものではないだろう。
0292デフォルトの名無しさん2008/08/14(木) 15:06:45
ハード叩くのなんて必要性が無けりゃ勉強なんてできんよ
俺はC2DのEISTで電圧と周波数(というか倍率)を任意に設定できる
汎用性の無いカーネルモジュールとか自作のAVRファンコン、モニタをPCから制御するドライバを書いたぐらい
実際カーネル自作するぐらいの目標が無いと何馬鹿な事してるんだ俺はってなる
0293デフォルトの名無しさん2008/08/14(木) 16:00:33
人の自慢話ほど聞かされて馬鹿らしいものはない
0294デフォルトの名無しさん2008/08/14(木) 19:10:10
Dr.Bjarne曰く「C++をやる予定なら最初からC++やったほうがいいよ」
らしい。
0295デフォルトの名無しさん2008/08/14(木) 23:58:04
問題ない。

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

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

でも、組み込み系ではC++が十分に使える環境にないからCしか使えないのが
つらい。
0296デフォルトの名無しさん2008/08/15(金) 00:04:33
Embedded C++があるじゃないか。
まあテンプレートや例外処理はカットされているけど。
0297デフォルトの名無しさん2008/08/15(金) 00:04:49
STLをマスターするより先にboost触った方がいいよ
こうですね
0298デフォルトの名無しさん2008/08/15(金) 00:06:29
VC9 SP1のtr1で当面は十分では
0299デフォルトの名無しさん2008/08/15(金) 00:09:38
だいたいCを軽視してる奴にまともなPGはいない
0300デフォルトの名無しさん2008/08/15(金) 00:10:16
と、C++が理解できない頭の硬いオッサンが申しております
0301デフォルトの名無しさん2008/08/15(金) 00:11:47
言語が理解できないって言っちゃう時点でもうね・・・
0302デフォルトの名無しさん2008/08/15(金) 00:19:20
言語を一つ理解するのに数年かかるというのに、無闇に修得対象を広げたくない。
マニュアル斜め読みしただけで理解したって言っていいんなら話は別だけど。
0303デフォルトの名無しさん2008/08/15(金) 00:21:49
本一冊読んでマスターしたと勘違いしちゃうやつ多いからなぁ。
バグ出したり可読性下げててもそれが理解不足であることも理解できない。
0304デフォルトの名無しさん2008/08/15(金) 00:24:48
言語のベンダー試験あたりに合格するレベルでいいなら何年もいらない。
0305デフォルトの名無しさん2008/08/15(金) 00:26:06
でも若い人でＣのポインタと配列の概念をきちんと理解している人って結構少ないよ
分割コンパイルの環境で、動的に確保できるグローバルな２次元配列の変数を宣言する方法とか
やらせてみると結構できない。
試しにやってみるか？
○幅WIDTH, 高さHEIGHTのchar型２次元配列をグローバルに定義および宣言せよ。
ただし分割コンパイル環境で使えるようにすること。またこの変数は定義時はNULLを与えておき、
初期化関数内で動的に確保すること。
0306デフォルトの名無しさん2008/08/15(金) 00:27:42
便利なものなら使いたいじゃんスマポとかrangeとか
0307デフォルトの名無しさん2008/08/15(金) 00:30:20
言語をひとつしか知らないやつは、その言語に深く精通してるかっていうと、そういうことはまず無いな。
複数知ってるから優秀ってわけでもないけど。
0308デフォルトの名無しさん2008/08/15(金) 00:47:52
沢山知っててもいいんじゃね？
プログラマなら一年に一つは新しい言語を触れって格言もあるし
いいじゃんLisp系もやってML系もやってLL系もやってbrain fuckみたいな類の変なのもやればいいんだよ
boostの中のもLispやHaskellにインスパイアされてるし
0309デフォルトの名無しさん2008/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[];　　// こんなことやる機会あんまないのでちょっと自信ない

こう？
偉そうには言えんけど、実務でミスっても調べりゃすぐわかりそうな気はするがｗ
0310デフォルトの名無しさん2008/08/15(金) 00:50:56
305じゃないけど、まんまと引っ掛かったって感じだな。
0311デフォルトの名無しさん2008/08/15(金) 00:53:12
スタックじゃなくてヒープを使えと
そういう引っ掛けだったの？
0312デフォルトの名無しさん2008/08/15(金) 01:03:22
動的っていうからにはそうだろう。
仮にchar Hoge[HEIGHT][WIDTH]でやるとしても、
= {NULL}はおかしいし、extern char Hoge[][WIDTH];でないといけない。
03133092008/08/15(金) 01:07:03
＞動的に確保できるグローバルな２次元配列
＞またこの変数は定義時はNULLを与えておき
char **Hoge = NULL;でやれってこと？
「動的いいながら定義時にNULLとか意味わからん」思って無視してたｗ
0314デフォルトの名無しさん2008/08/15(金) 01:11:59
char(*hoge)[WIDTH] = NULL;
hoge = malloc(sizeof(char[HEIGHT][WIDTH]));
こうだろ
03153092008/08/15(金) 01:19:36
ほーほー。
自分のポインタの理解が浅いことは認めるんだけど
普通こういう用途ってWIDTH * HEIGHTで確保するほうが賢いような・・・
あと{NULL}じゃなくて{{NULL}}か。Cでも通るのかは知らないｗ
0316デフォルトの名無しさん2008/08/15(金) 01:35:49
まぁ知ってても実際に使う機会はないな
トリビアみたいなもんだ
03173092008/08/15(金) 01:48:39
＞{{NULL}}
実際にやってみたら全部NULLにはならなかった・・・（{NULL}でも）
（VC限定？グローバル変数は0で初期化されるので1で試したけど）
うーむ。
0318デフォルトの名無しさん2008/08/15(金) 01:55:28
それは、初期化子の数が足りなければ、残りの要素は0で初期化されるという性質を使ったテクニック。
{{1}}で最初の要素以外が0になるというのであれば、それは期待どおりの結果。

ただし、そもそもchar型の要素をNULLで初期化しようってのが大間違い。
http://www.kouno.jp/home/c_faq/c5.html#9
0319デフォルトの名無しさん2008/08/15(金) 07:31:29
そもそもchar型の要素をNULLで初期化しろなんて>>305は言ってないしね。

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

つまりは>>273ってこった。
03203052008/08/15(金) 08:03:12
>>314
その部分は正解だが、さらに「複数ソースで使用し、ちゃんとリンクエラーが出ないようにする」
ように記述しないと１００点はやれない（ここが出来ない人も結構いる）。
>>315
hoge[x + y * WIDTH]ってアクセスするの？
それがhoge[y][x]より賢いって？
３次元になっても１次元配列を自分でオフセット計算するかい？
>>316
どれだけ経験して「ない」って言い切ってるんだか知らんが、現実にこういうことあったよ。
MAX枚のHEIGHT*WIDTHサイズのマップデータをメモリに保持するソフトで、複数機種で
同時開発しているのだが、ある機種はメモリが足りなくて動的に確保しなくてはならない。
途中までできてたソースを大きく書き換えたくないから（複数人で作ってる）、#ifdefで
int map[MAX][HEIGHT][WIDTH];の部分を動的に確保するように書き換えた。
0321デフォルトの名無しさん2008/08/15(金) 09:15:10
>>320
>>314は分かってるだろ。その上に突っ込んでるだけだしｗ
0322デフォルトの名無しさん2008/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;
}
0323デフォルトの名無しさん2008/08/15(金) 09:55:14
これはひどい
03243052008/08/15(金) 10:56:25
>>319
バカにしすぎかと。そういう前提で書いただけだっつーの・・・
普段ポインタ以外にNULL入れることなんか無いわ。
>>314みたいなのは確かに初めて知ったけど（´・ω:;.:...
＞hoge[x + y * WIDTH]ってアクセスするの？
＞それがhoge[y][x]より賢いって？
char **でバラバラに確保するのか・・？と思ってたので。
314のは連続した領域に確保してるんだからいいんだろうけど。
一つ勉強になりますた。
0325デフォルトの名無しさん2008/08/15(金) 11:46:57
酷いですか御免なしあ
0326ほんとの3052008/08/15(金) 11:51:20
>>324
あんたは>>309だろｗ
それはそうと。
プライドが傷つくのは気の毒だが、動的に確保しろと言ってるのによくわからないから無視したり
してるところを見ると、もうちょっと勉強したほうがいいのは確かですね。

あとchar**でバラバラに確保しても、まあいいよ。効率はほんの少し落ちるけど、初期化と解放時だけの
効率だから目をつぶろう。>>322はその方法だが、ちょっとコードが良くないね。機械にやらせるべき計算を
自分でやってる。名誉挽回に、>>322を綺麗に書き直してみるかい？（と、煽ってみるｗ）
03273092008/08/15(金) 12:33:36
>>326
失礼ｗ
＞>>322はその方法だが
322って、バラバラじゃないような・・？
１箇所に確保した（連続した）領域に対して、HEIGHT分ごとに区切った
アドレス配列を作ろうとして何かミスってるように見えるんだけど・・・・(；´Д｀)
0328デフォルトの名無しさん2008/08/15(金) 13:37:13
私なら、三次元配列でも一次元で確保してオフセット計算を関数でやらせる。
幅や高さが固定な用途ばかりじゃないんでね。
0329デフォルトの名無しさん2008/08/15(金) 16:46:35
確かにnewがあればmalloc要らないとか、Cは既に陳腐化したツールも少なくないし、
その辺は適当にスキップしてC++を優先して学ぶのもよいと思う。

でもCを飛ばしてC++だけやるくらいなら、VBAとかJavaとかやったほうがいいと思う。
CもC++もややこしくて一筋縄にはいかない。
プログラマーに徹したいのなら、もっと楽に学べる言語はいくらでもある。
0330デフォルトの名無しさん2008/08/15(金) 16:55:28
むしろプログラマーに徹したいのならC/C++制覇しろよ。
VBAとかJavaに徹してるプログラマってｗ
0331デフォルトの名無しさん2008/08/15(金) 17:59:40
私大文系ならVBAに徹するしかないだろｗ
■ このスレッドは過去ログ倉庫に格納されています