【初心者歓迎】C/C++室 Ver.44【環境依存OK】

【初心者歓迎】C/C++� ..

300:デフォルトの名無しさん
07/11/14 15:07:54
>>298　そんなことより、さっさとエラーメッセージ貼れよ。

301:デフォルトの名無しさん
07/11/14 15:18:14
>>299
g++ でコンパイルできました。
どうもすみませんでした。
ｇ＋＋というのを知りませんでした。

302:デフォルトの名無しさん
07/11/14 16:12:07
>>297
質問です。
コンパイルは出来たんですが、実行が出来ません。
g++ aMain.cpp -o aMain
では何も起こらないんですがどうやって実行したんですか？

303:デフォルトの名無しさん
07/11/14 16:14:59
gccはコンパイラコレクションだからC++特化のライブラリを探してくれない。
g++はC++コンパイラだからC++特化のライブラリも探してくれる。

304:デフォルトの名無しさん
07/11/14 16:16:51
明示しなかった場合、実行モジュールはカレントディレクトリにa.outという名でできる。
実行するには、./a.outでいい。

つーか、その程度の基礎知識もなしにコンパイルなんてするなよw

305:デフォルトの名無しさん
07/11/14 16:18:11
>>302
何したいの？それで aMain というファイルができてるの？
できていえれば、 ./aMain とすれば走るはずだけど。

306:デフォルトの名無しさん
07/11/14 16:26:34
これはスルーしたほうがいいな

307:デフォルトの名無しさん
07/11/14 16:40:07
a.outができません。aMain.oだけできます。
./aMainだとpermission denied となってしまいます。

308:デフォルトの名無しさん
07/11/14 16:45:08
問題解決しました。./aMainでは実行できなくても
g++ aMain.cpp -o aMain && ./aMain
で実行できました。
お騒がせしてすみませんでした。

309:デフォルトの名無しさん
07/11/14 17:40:55
なんじゃそりゃ。
ただのタイプミスな気がする

310:デフォルトの名無しさん
07/11/14 18:06:04
>>308
そんなにあせらずに、Unix 系の CUI 使いかたの本薄いので
良いから一冊読むと大分時間の節約になると思うよぉ。

311:デフォルトの名無しさん
07/11/14 20:33:43
基本的なポインタの質問で申し訳ないんですが。
mallocなどで確保されてない領域を知る方法はありませんか？

char *str;
str=(char *)malloc(sizeof(char)*2);

for(int i=0; i<5; i++){
if( (str+i) == NULL)
//未確保
}
みたいな形でわかればいいんですが、必ずしもNULLが入ってるとは限らないので…。

よろしくお願いします。

312:デフォルトの名無しさん
07/11/14 20:40:37
確保したサイズを覚えておく。

313:311
07/11/14 20:41:58
>>312
なるほど・・・。
やっぱり、そういう方法しかないんですか・・・
せめてtry catchがあれば、強引に出来そうなんですけどね。

どうもありがとうございました。

314:デフォルトの名無しさん
07/11/14 20:46:31
ていうかそのソース突っ込みどころ満載だから勉強頑張ろうな。

315:デフォルトの名無しさん
07/11/14 20:47:44
自分が確保したメモリのアドレスとサイズを持つ構造体でも定義すれば？

316:311
07/11/14 21:14:02
>>314
具体的にどのあたりでしょうか？
よろしくお願いします。

>>315
なるほど。
その方法も検討してみます。

317:デフォルトの名無しさん
07/11/14 21:18:32
DLLで確保されたメモリはそのDLLで解放しないといけないと聞きました。

そこでお聞きしたいのですが、例えば以下のような場合
　・アプリケーションAがDLL_BとDLL_Cを参照
　・DLL_B自身もDLL_Cを参照
DLL_BがDLL_Cで確保したメモリを
アプリケーションAからリンクされたDLL_Cで解放するのは大丈夫なのでしょうか？
よろしくお願いします。

318:デフォルトの名無しさん
07/11/14 21:33:27
>>317
OKだけど、LocalAllocにすればそんなこと気にしなくてもいいんじゃね？

319:デフォルトの名無しさん
07/11/14 21:42:20
いや、Win32ならLocal系よりHeap系だろ

320:デフォルトの名無しさん
07/11/14 21:55:12
>>316
>if ( ( str + i ) == NULL )
この行で、iに2以上の値が入った時点でアウト。
確保されていない領域を参照することになる。
NULLとの比較も無意味。
初期化されていない領域はゴミが入っているのでNULLかどうかなんてわからない。

321:デフォルトの名無しさん
07/11/14 22:06:29
そもそも参照できてない、それ。

322:デフォルトの名無しさん
07/11/14 22:07:09
>>318
LocalAlloc, HeapAlloc, GlobalAlloc
って名前が違うだけでは無いんですね。
知りませんでした。

>>319
Heap系はよけいなオブジェクトが必要になるのであまり使いたくないです・・・
そこが肝という気もしますが

323:デフォルトの名無しさん
07/11/14 22:09:06
>>320
それが出来ないから質問きたんだろ
出来るなら、既に解決してるじゃんｗ

そもそも
＞この行で、iに2以上の値が入った時点でアウト。
これを判定したいって言う質問なのに、そのレスはナンセンス過ぎる

324:デフォルトの名無しさん
07/11/14 23:06:43
>>320
＞この行で、iに2以上の値が入った時点でアウト。
単なるポインタに数字を足した値を見ただけで何でアウトなんだ？
*つけて参照してるならともかく・・・

325:デフォルトの名無しさん
07/11/14 23:14:37
>>322
ヒープハンドルは常にGetProcessHeap()で得たものを使うことにすれば、
Local/Globalと比べ、新たな面倒さが生まれることはないと思うぞ。

326:デフォルトの名無しさん
07/11/14 23:39:43
そもそもLocalとGlobalってかなり前にMSが使うのやめてっていってなかった？

327:デフォルトの名無しさん
07/11/15 01:27:02
もうCoTaskMemAllocでいいよ

328:デフォルトの名無しさん
07/11/15 01:59:11
>>324
配列要素数を超えたところを指すようにポインタに足し算すると未定義動作になる。

C99 6.5.6 p8 より（ C++ では 5.7 p5 に同じ文面がある）
> If both the pointer operand and the result point to elements of the same array object, or one past the last element
> of the array object, the evaluation shall not produce an overflow; otherwise, the behavior is undefined.

この場合だと要素数 2 の char 配列とみなせるから、 2 までは大丈夫で 3 以上でアウトね。

329:デフォルトの名無しさん
07/11/15 02:05:54
ポインタは*つけて参照しなければ、単なる数字だよ。
しかも、ポインタ変数に代入したわけでもなく、単に+3をやってifで比較しただけでしょ？

その文面は
*(str+i)のように参照した場合や、str+=iのように加算を行った場合であって
str+iでは、何の意味もないかと。

試してみれば分かると思うけど
char *str;
に
if( (str+5000)!=NULL)
ってやろうと
if( (str+50000000)!=NULL)
ってやろうと、エラーは出るはず無いよ。

330:デフォルトの名無しさん
07/11/15 02:23:13
>>329
> *(str+i)のように参照した場合や、str+=iのように加算を行った場合であって

そんなことどこにも書いてない。 p + n という式自体について述べた部分だよ。
* で参照したり = で代入したりする前の話。

331:デフォルトの名無しさん
07/11/15 02:43:49
なんで「一つ後ろ」みたいな表現するんだろう
一瞬、「じゃあふたつ後ろならいいのかよ」とか思ってしまったよ

332:デフォルトの名無しさん
07/11/15 10:42:18
>>330
仕様の読み方わかってないだろ。
プログラムの勉強からはじめたほうがいいね。

333:デフォルトの名無しさん
07/11/15 10:57:22
>>332
どこをどう読んだら >329 みたいな解釈になるのか教えてください。

334:デフォルトの名無しさん
07/11/15 11:24:57
>>328

加減演算子

ポインタオペランド及びその結果の両方が同じ配列オブジェクトの要素、又は
配列オブジェクトの最後の要素を一つ越えたところを指している場合、演算に
よって、オーバーフローを生じてはならない。それ以外の場合、動作は未定義
とする。

あくまで未定義といっているのだから、規格上は何でもあり得る、つまり
実装依存ということになるね。>>329の言っている、エラーが出ない
とか参照しなければ単なる数字になるということは、多くの実装がそう
なっているだけであって、str+5000の加算演算で仮にクラッシュする実装が
あっても、それは規格には従っていることになる。結局、この場合、
動作は未定義だから実装まかせ。

なので、厳密には>>328の意見が正しいと思われる。

335:デフォルトの名無しさん
07/11/15 13:04:40
実際、タイトなメモリ空間モデルを持っている実装では、割と容易に起こり得る。
例えばint array[2]に対してarrayが0xfff0にアサインされているかもしれない。
ポインタもintも16bitなら、array + 4が0になってしまい、NULLと区別できなくなってしまう。
# 流石に即クラッシュはしないだろうけどね。

336:デフォルトの名無しさん
07/11/15 14:02:36
境界の問題はポインタ特有の話じゃありませんね

337:デフォルトの名無しさん
07/11/15 17:44:01
それがどうかしましたか?

338:デフォルトの名無しさん
07/11/15 17:57:27
つまり見当違い

339:デフォルトの名無しさん
07/11/15 18:16:43
どこが?
そもそも誰か、境界の話なんてしているんですか?

340:デフォルトの名無しさん
07/11/15 18:31:33
>>336が場違いな件について

341:wolf ◆8VH3XAqjlU
07/11/15 22:09:24
>>311
*** For your reference ***

Windows. _heapwalk (CRT)
URLﾘﾝｸ(msdn2.microsoft.com)(VS.80).aspx

Linux 2.4x
src\drivers\char\drm\sis_ds.c "void mmDumpMemInfo( memHeap_t *mmInit )"