コーディングスタイルにこだわるスレ

**デフォルトの名無しさん** · 2007/10/28(日) 15:59:01

コーディングスタイルについて熱く語れ

**デフォルトの名無しさん** · 2010/04/18(日) 18:17:17

通常の意味でのcontinueはdo while文の中でbreakすればいいか
ややこしい…

**デフォルトの名無しさん** · 2010/04/18(日) 18:32:55

お前らおかしいぞ
普通に goto 使え

**デフォルトの名無しさん** · 2010/04/18(日) 19:51:37

飛び先を制御するためだけに
ループしない while を用意するのは邪悪

**デフォルトの名無しさん** · 2010/04/18(日) 21:16:50

普段gotoを使わないから>>514のようなケースのとき
gotoを使うってとこまで頭が働かないな

**デフォルトの名無しさん** · 2010/04/19(月) 08:13:33

無限ループは for (;;) {} で、ループしないループは do {} while (0) で、
というのはイディオム。

**デフォルトの名無しさん** · 2010/04/19(月) 19:25:34

do {} while (0); は continue しようが何しようが必ず抜けるから
continue した時はループする >>541 とは全く別の話だな

**デフォルトの名無しさん** · 2010/06/12(土) 22:46:29

>>514のコードを書き換えるという前提では、結局gotoを使うのが一番簡潔に
なるんだろうけど、実際のコーディングではケースバイケースで全然違う書き方を
すると思う。
いったん普通にループを抜けてからREWINDやREDOに相当する処理を別にするとか。

**デフォルトの名無しさん** · 2010/06/18(金) 01:39:17

最近言語に関係なくインデントにスペース2つを使うプロジェクトを
よく見る気がするんですが、これって元々どの辺の文化で使われていたんでしょうか？

**デフォルトの名無しさん** · 2010/06/18(金) 19:27:50

スクリプト言語じゃないかね

**デフォルトの名無しさん** · 2010/06/18(金) 19:50:49

GNU?

**デフォルトの名無しさん** · 2010/06/18(金) 23:54:30

ぐにゅ？

**デフォルトの名無しさん** · 2010/06/28(月) 10:51:33

>>549-552
2桁インデントはGNUスタイルだろ。
indentがインストールされている環境なら、indent -gnu <ソースファイル> でGNUスタイルに整形される。

**デフォルトの名無しさん** · 2010/06/28(月) 10:59:34

GNU indent 2.2.3で試してみた。
::::::::::::::foo.c // オリジナル
#include <stdio.h>
int main()
{
for (int ic = 0; ic < 10; ++ic) {
if (ic % 2 == 0) printf("%d\n", ic);
}
return 0;
}
::::::::::::::foo.kr.c // K&Rスタイル
#include <stdio.h>
int main()
{
for (int ic = 0; ic < 10; ++ic) {
if (ic % 2 == 0)
printf("%d\n", ic);
}
return 0;
}
::::::::::::::foo.gnu.c // GNUスタイル
#include <stdio.h>
int
main ()
{
for (int ic = 0; ic < 10; ++ic)
{
if (ic % 2 == 0)
printf ("%d\n", ic);
}
return 0;
}

**デフォルトの名無しさん** · 2010/06/28(月) 15:41:41

>>554
navi2chとかchalice使いでないと違いわからんだろ、これ

**デフォルトの名無しさん** · 2010/06/28(月) 16:30:35

>554を変換してみた
::::::::::::::foo.c // オリジナル
#include <stdio.h>
int main()
{
    for (int ic = 0; ic < 10; ++ic) {
        if (ic % 2 == 0) printf("%d\n", ic);
    }
    return 0;
}
::::::::::::::foo.kr.c // K&Rスタイル
#include <stdio.h>
int main()
{
    for (int ic = 0; ic < 10; ++ic) {
        if (ic % 2 == 0)
            printf("%d\n", ic);
    }
    return 0;
}
::::::::::::::foo.gnu.c // GNUスタイル
#include <stdio.h>
int
main ()
{
  for (int ic = 0; ic < 10; ++ic)
    {
      if (ic % 2 == 0)
        printf ("%d\n", ic);
    }
  return 0;
}

**デフォルトの名無しさん** · 2010/06/29(火) 22:32:49

>>555
ニョロカッコの位置と改行位置で分かるだろ?

**デフォルトの名無しさん** · 2010/12/12(日) 19:10:07

以下のような理由をあげて、「構造体の typedef 禁止！！！」つったのに
平気で typedef srruct foo { ... } foo_t; をやってくるおまえらは
なにものですか > 今度使ってる害虫
Avoid using typedefs for structure types. Typedefs are problematic
because they do not properly hide their underlying type; for example you
need to know if the typedef is the structure itself or a pointer to the
structure. In addition they must be declared exactly once, whereas an
incomplete structure type can be mentioned as many times as necessary.
Typedefs are difficult to use in stand-alone header files: the header
that defines the typedef must be included before the header that uses it,
or by the header that uses it (which causes namespace pollution), or
there must be a back-door mechanism for obtaining the typedef.

**デフォルトの名無しさん** · 2010/12/12(日) 20:19:08

>>558
それを挙げて禁止とか言ったんなら、英語の読めない中途半端な経験者だったんだろう。
一般的な解説と、具体的なデメリットとを繋いで説明できればよかったのにね。

**デフォルトの名無しさん** · 2010/12/13(月) 02:21:42

キャッチボールで相手のレベルに合わせて投げるのと同じように、
コミュニケーションでも相手のレベルに合わせて伝えるべき。
子供相手に変化球投げたりしないだろ?

と、昔上司から言われた台詞を貴方にも。

**デフォルトの名無しさん** · 2010/12/13(月) 03:09:28

>>559, 560
そのほかに指示したのは、「名前の長さは長くても20文字程度に押さえてね」だけで、
こっちは守られてるのに、「構造体の typedef 禁止」は無視するってのはおかしくないか？

一部の地域には構造体を typedef しなきゃいけない宗教的理由でもあるのか？

**デフォルトの名無しさん** · 2010/12/13(月) 03:53:23

>>561
少なくとも、妄信的にtypedefする奴はいる。

**デフォルトの名無しさん** · 2010/12/13(月) 07:30:35

>>561
http://www.google.co.jp/search?q=%E5%85%A5%E9%96%80+typedef+struct

名前20文字以内が守れてるってのは、普通にやってればなかなかそこまで
長くならないってだけかもしれない。

**デフォルトの名無しさん** · 2010/12/13(月) 22:03:37

妄信的に単語を短縮する奴もいる。
酷いのだと何でもかんでもアルファベット3文字とか。
特にCOBOLer上がり。

**デフォルトの名無しさん** · 2010/12/14(火) 00:18:34

H8環境でC++使ってないとtypedefだらけになる。

**デフォルトの名無しさん** · 2010/12/23(木) 22:21:26

>>558
そういうトラブルは typedef を禁止したところで
なくならないし未然防止にもならない。

そもそも言語に対するスキルというか
リテラシーが低いことが問題。

名前の長さも同じこと。不思議な省略単語濫用で
20文字以内になっても意味がない。

**デフォルトの名無しさん** · 2010/12/23(木) 23:58:54

>>566
んなことは分かてる、なんでルールを無視するんだ？と言ってる
実際にあった話だが、顧客指定でLaTeXでドキュメント寄越せと言われたらどうするよ

**デフォルトの名無しさん** · 2010/12/24(金) 01:23:48

タグ名と typedef 名が同一ならよいのだから、そのくらいはヴァリデータツールを書いて、通らなければコミットできないようにしてしまえばよいのではないか。

**デフォルトの名無しさん** · 2010/12/24(金) 13:17:29

>>568
同一ならいいってわけじゃないだろう。 >>558 は読んだか？

**デフォルトの名無しさん** · 2010/12/26(日) 10:09:36

まぁ、下請けになめられてるんだろうな。

**デフォルトの名無しさん** · 2010/12/28(火) 19:29:32

>>569
読んだ上で問題ないと判断したんだが、具体的にどういう場合に不具合があるんだ？
そこにある三つの問題全てクリアになると思うよ。

**デフォルトの名無しさん** · 2010/12/28(火) 22:13:38

>>571
"they must be declared exactly once"
"the header that defines the typedef must be included before the header that uses it"

A.h で struct A だけが宣言されていて、使う側で毎度 struct A と書く場合、
使う側で A.h をインクルードせずに struct A の前方宣言で済ませることができる。

A.h で struct A の宣言に加えて typedef struct A A があり、関連する関数の宣言に
struct A* ではなく A* が現れる場合、 A* を使うためには必ず A.h のインクルードが
必要になる。

問題が３つだとしたら２つは残ってるように見える。
何か誤解されてるんじゃなかろうか？

**デフォルトの名無しさん** · 2010/12/29(水) 18:29:41

>>572
コーディング規約にすることで未然に防ぎたい不具合の具体的な例をお願い。

> A.h で struct A の宣言に加えて typedef struct A A があり、関連する関数の宣言に
> struct A* ではなく A* が現れる場合、 A* を使うためには必ず A.h のインクルードが
> 必要になる。

根拠が分からない。
手元の三つのコンパイラでコンパイルでき、警告さえ出さない。
俺が失念している規格があるのかもしれないから、具体的に示してもらえるとありがたい。

> A.h で struct A だけが宣言されていて、使う側で毎度 struct A と書く場合、
> 使う側で A.h をインクルードせずに struct A の前方宣言で済ませることができる。

というわけで、こちらも前方宣言で済ませることができる。
ただし typedef struct A A; の一行が余分に必要になる。
ちなみに C++ なら余分の typedef も不要。

と、ここまで書いてようやく気づいたが、同じ typedef 名の typedef がいけないということか。
typedef struct A A;
typedef struct A { int a; } A;
とあると、後者でエラーになるということか。

ちなみにこれは gcc ではエラーだが、cl と bcc32 ではスルーだった。
もちろん C++ ならどれも ok。

その理由で禁止なら、支持できるが、本当にこんなことを言ってたの？

**デフォルトの名無しさん** · 2010/12/29(水) 18:34:40

>>573
> 手元の三つのコンパイラでコンパイルでき、警告さえ出さない。

どんなコードでテストしてるの？

> というわけで、こちらも前方宣言で済ませることができる。
> ただし typedef struct A A; の一行が余分に必要になる。
...
> typedef struct A A;
> typedef struct A { int a; } A;
> とあると、後者でエラーになるということか。

前方宣言のつもりで複数のヘッダに typedef struct A A; と書いたとしたら、
それらのヘッダをひとつの翻訳単位にインクルードすればやっぱりエラーになるだろ。

**デフォルトの名無しさん** · 2010/12/30(木) 02:33:59

C禁止にしてC++に統合しようぜ。

**デフォルトの名無しさん** · 2010/12/30(木) 07:16:23

そんな事したらリーナスおじさんが黙っていない

**デフォルトの名無しさん** · 2010/12/30(木) 11:06:58

俺もOOPは大好きだが、
OOPLとしてのC++にも感謝してるが、
どっちか無くせといわれたら、C++がイランなｗ
Cは必要だな。

**デフォルトの名無しさん** · 2010/12/30(木) 15:26:15

>>573
> もちろん C++ ならどれも ok。

C++ でも微妙だったりする。
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#407

**デフォルトの名無しさん** · 2010/12/30(木) 23:31:39

揚げ足取りならC++ならC的な書き方もできるがね。

とはいえ組み込み系だと環境構築してる間に開発期間がなくなる勢いだから
トップダウンでCを減らして欲しい。ボトムアップじゃムリポ。

**デフォルトの名無しさん** · 2010/12/31(金) 09:26:49

>>579
組み込み系だとC++が使えない程度に貧弱なハードの場合も多々あるんだが
つか、テンプレートとか使うとC++ってコードサイズが見積もれなくないか？

**デフォルトの名無しさん** · 2011/01/01(土) 01:27:35

逆に、constなんかはCよりC++の仕様のほうが組込にも向いているように思う。

自分の知り合いは、テンプレートは使う（もちろんコードサイズ増加は織り込み済み）が、
それよりも動的メモリ確保(malloc/new等)禁止のほうを気にかけている感じだった。
これももちろん分野によるのだろうけど。

**デフォルトの名無しさん** · 2011/01/01(土) 04:27:25

if文の中に長い関数式を書くのはあまり好みではないので分けて書くことが多いけどどうよ
何をあほな書き方してんだと思うかいな。

if (MessageBox("保存しますか?", "内容が変更されています", MB_YESNO | MB_ICONQUESTION) == IDYES)
文;
----------------------------------------------------
const char * const pc1 = "保存しますか?";
const char * const pc2 = "内容が変更されています";
int num1 = MessageBox(pc1, pc2, utype);
// もしくは
// const LPCTSTR lpctstr1 = "保存しますか?";
// const LPCTSTR lpctstr2 = "内容が変更されています";
// uint utype = MB_YESNO | MB_ICONQUESTION;
// int num1 = MessageBox(lpctstr1, lpctstr2, utype);
int num2 = num1 == IDYES;
if (num2)
文;

**デフォルトの名無しさん** · 2011/01/01(土) 11:57:47

え？　折角変数使うのにnum2みたいな糞名前？

そんなんつけるくらいなら
int ret = MessageBox(pc1, pc2, utype);
if (ret == IDYES)

こうするほうがまだマシでは？
else if (ret == IDCANCEL)などと続けられることも考えて。

**デフォルトの名無しさん** · 2011/01/03(月) 13:24:29

>>580
ハード性能の貧弱さで C++ が使えなくなるなんてことはないよ。

例外、 RTTI 、テンプレートとか、機能や具体的な使い方に応じて
費用対効果が見合わないことはあるだろうけどね。
でもそれは組み込みにかかわらずあたりまえの話。

マイナーすぎてコンパイラが無いっていう方向の貧弱さを言ってるんだったら別。

**デフォルトの名無しさん** · 2011/01/03(月) 14:07:45

>>584 主記憶64kでやってみろよ

**デフォルトの名無しさん** · 2011/01/03(月) 14:46:28

>>585 別に問題ありませんが何か？

**デフォルトの名無しさん** · 2011/01/03(月) 22:32:32

>>585
むしろその環境に対して C++ の何が問題を起こすと思っているのか聞きたい。

**デフォルトの名無しさん** · 2011/01/11(火) 01:09:09

C++ が問題というよりは、組み込みでテンプレとか
ガンガン使っておいて ROM/RAM 足りませんみたいな
こと言ってくる奴が多すぎて困る。

バグったらバグったで自分じゃ解析できないから
ヘルプミーだと。 C++禁止にしようぜ。

**デフォルトの名無しさん** · 2011/01/11(火) 23:44:50

テンプレ禁止しろよ

**デフォルトの名無しさん** · 2011/01/12(水) 10:53:19

テンプレってリソース喰うん？

**デフォルトの名無しさん** · 2011/01/12(水) 11:49:57

>>590 いいえ

**デフォルトの名無しさん** · 2011/01/12(水) 12:12:04

リソースを食うコードを書いてしまいやすいと言うべきかな

**デフォルトの名無しさん** · 2011/01/12(水) 12:22:45

なにこのほほえましいスレ。

**デフォルトの名無しさん** · 2011/01/12(水) 18:43:10

>>588
禁止というか免許制にすればいいのにとは思う

**デフォルトの名無しさん** · 2011/01/12(水) 20:08:48

http://sky.geocities.jp/tcshacina/hash.c
これは？

**デフォルトの名無しさん** · 2011/01/24(月) 02:34:22

Javaで使い終わった変数にnullセットとか意味あんの？
ゴスリングも、今のGCは賢いからそんなことせんでええと言っているし、
そもそもスタイルとして美しくないので嫌いなんだが。
あと、宣言時のnullセットも同じく。
ここの先輩諸氏はどう思われますか。

**デフォルトの名無しさん** · 2011/01/24(月) 03:50:41

宣言時のnullセットは意味が無いな

**デフォルトの名無しさん** · 2011/01/24(月) 09:14:31

インスタンス変数で、null代入しないとオブジェクトリークになる、
というのでもない限りいらんだろ。

**デフォルトの名無しさん** · 2011/01/24(月) 09:17:46

GC目的のつもりの代入に限って言えば、
それを強いるなど狂気の沙汰だ。

**デフォルトの名無しさん** · 2011/01/24(月) 10:34:58

生存時間の長いローカル変数に対して、時間がかかる処理の前にnull代入するのは意味がないこともないよ
GCの世代昇格を防いだり

**デフォルトの名無しさん** · 2011/01/24(月) 11:02:17

>そもそもスタイルとして美しくないので嫌いなんだが。

なぜそう思う？

**デフォルトの名無しさん** · 2011/01/24(月) 22:59:59

>>596
VB出身者が必要だと思ってるんだろ。それ。

**デフォルトの名無しさん** · 2011/01/24(月) 23:02:00

使い終わった変数にnullを入れると安全になるって思い込んでるヤツは
よくみるな。
それで安全になるようなコードの書き方をしてるなら、そっちを見直すべき
なんだけど。

**デフォルトの名無しさん** · 2011/01/29(土) 15:50:46

C++なら新人に多重deleteされないようにdeleteし終わったらNULL入れておくかな。
C++はNULLのdeleteは「何もしない」のが仕様として決まっているから。
無条件deleteでも問題ない話になる。

**デフォルトの名無しさん** · 2011/01/29(土) 17:09:13

コーディングルールの話をしてて、それはダメだってことになると、
「これはヘタクソには有効だ」って反論がでてくるけど、ヘタクソ向けの
コーディングルールなんていらないよな。
だいたいヘタクソに対しても別に有効じゃねえだろって感じだし。

**デフォルトの名無しさん** · 2011/01/29(土) 19:15:53

よう俺。
デメリットを指摘しても「でも僕はこっちの方がいいです。慣れですよ」とか言われるし。

**デフォルトの名無しさん** · 2011/01/29(土) 20:13:55

個人でプログラムしてるのなら、
周りの人間がそいつのコーディングスタイルをどうのこうの言っても意味が無い
好みの問題に他人が口出しするものではない

が、チームを組んでプログラムしてたり、
そいつのソースを将来別の誰かがメンテしたりするのなら、
コーディングスタイルを合わせるよう「命令」しないといけない

デメリットやメリットは無意味で、問答無用で「命令」だ

**デフォルトの名無しさん** · 2011/01/29(土) 20:37:06

もしかして:スレ違い

**デフォルトの名無しさん** · 2011/01/29(土) 20:38:07

ヘタクソにコーディングルールを強いると、生産性が落ちてバグが増えそうで怖い。
なのでヘタクソのコーディングルールに合わせるのです。

**デフォルトの名無しさん** · 2011/01/29(土) 20:54:06

>>609
> 生産性が落ちてバグが増えそうで怖い

見えないものを怖がるな

どのようなヘタクソに、どのようなコーディングルールを強いた場合、
生産性がどれくらい落ちて、バグがどれくらい増えるのか、ちゃんと検証すればいい

検証の結果、本当は逆に生産性が上がってバグが減るのかも知れない

**デフォルトの名無しさん** · 2011/01/29(土) 21:51:55

>>604
スマートポインタ、最低でも auto_ptr で自分で delete 書かないほうがいいだろ。
確実だし、デストラクタでヌル詰めるとか無駄だし。

**デフォルトの名無しさん** · 2011/01/30(日) 01:19:42

>611
>最低でもauto_ptr
そしてコンテナでハマると。

>609,610
バカをフォローする手間を省くためだと思う。
ルールを決めるに当たって
・バカでも憶えやすい・理解しやすい
・特定の条件下では最も無難
・機械的にチェックしやすい
に傾きがちなのもきっとそのせい。

**デフォルトの名無しさん** · 2011/01/30(日) 02:32:19

昔は馬鹿を育てたんだけどな
俺も育てられたし

**デフォルトの名無しさん** · 2011/01/30(日) 15:27:32

ポインタをnullクリアより、変数のスコープを小さくしましょうとか、
使い回しをやめろとか教えたほうがいいだろ。

ポインタをnullクリアって、バグがおきないとかバグを発見しやすくする
工夫じゃなくて、バグってもなんとなく動いちゃう工夫だし。

あと上から目線で馬鹿向けって言ってるけど、使い終わったポインタを
NULLクリアするって言ってるやつって、馬鹿向けじゃなくて本気でそれ
がいいって思ってるっぽいし。

**デフォルトの名無しさん** · 2011/01/30(日) 15:38:08

スタイルというより教育だな。

**デフォルトの名無しさん** · 2011/01/30(日) 15:49:28

ある程度熟達すればコーディングスタイルにほとんどばらつきが出ない Lisp 系は、
コーディングスタイルという点ではけっこういい言語かも知れない

**デフォルトの名無しさん** · 2011/01/30(日) 15:51:29

馬鹿の度合いにもよるけどな。
とにかくいじらせるコード量を減らすこと。
今はそれで対処できるのでそうしてる。
教育できそうな馬鹿っていいよね。
うらやましいよ。
こっちの馬鹿は英単語すら読めねえんだぜ。
だから当然エラーメッセージもw

**デフォルトの名無しさん** · 2011/01/30(日) 15:54:38

>>616
ループを回すのに、dolist や loop を使うか、map 系を使うかというのでちょっ
と悩む。

**デフォルトの名無しさん** · 2011/01/30(日) 15:57:54

>>614
> 本気でそれがいいって思ってるっぽい
一概にそうとは言いきれない

無限ループ
入力 -> フィルター -> 出力 ==> 別プロセス

をやると, 世代別 GC しか持ってない言語だと, フィルターの出力段近くで使っ
てる変数とか出力バッファがらみの動的オブジェクトは明示的に null 代入し
ないとメモリー足りなくなる

**デフォルトの名無しさん** · 2011/01/30(日) 16:15:53

deleteしたポインタにnull入れても無意味だし、GCある言語でも
スコープはずれたり使いまわししてる変数にnull入れても無意味。

**デフォルトの名無しさん** · 2011/01/30(日) 17:20:47

GC目的以外ならnullは有効だろう。
シングルトンパターンでの生成を遅延させたりするとき、
bool isinitedみたいなよけいないもんを使うより単に、
Foo foo = null;
getInstance() {
if (foo == null) foo = new FooBig();
return foo;
}
とすれば満足では。

あと、Foo::delete(Foo **foo)みたいにして
中でdelete *foo; *foo = null;とかさせておいて、
呼び出し元で、それ以降の望まないfoo->bar()を失敗させるのもやった。
当時はこれでうまくいったと思ってたが、今見るとなんかアホっぽいけど。

**デフォルトの名無しさん** · 2011/01/30(日) 17:35:24

ポインタのnullクリアは、GC関連なら特殊なパターン以外は意味ないし、
バグを防ぐって意味なら、変数のスコープを狭くしなさいとか、使いまわしは
やめなさいとかってルールのほうがいいよね。

**デフォルトの名無しさん** · 2011/01/30(日) 21:49:58

不正アクセス防止になるじゃねーの？　JAVAなんか使わないから知らんけど。

**デフォルトの名無しさん** · 2011/01/30(日) 22:16:04

いやならないんじゃないの?

**デフォルトの名無しさん** · 2011/01/31(月) 00:20:16

ぬるぽが出るんじゃないの？

**デフォルトの名無しさん** · 2011/02/05(土) 00:36:57

nullクリアが真価を発揮するのは、デバッガでソース追う時。
スパゲティなソースでも、きちんとnullクリアしてるかどうかで
デバッグのしやすさが格段に違う。

「追いやすいコード」を目指すなら、多少手間でもnullクリアをしとくべき。
読みやすさを心がけてるなら、追いやすさも当然心がけるよな?

**デフォルトの名無しさん** · 2011/02/05(土) 01:19:09

free(p);
#if DEBUG
p = NULL;
#endif

ですねわかります

**デフォルトの名無しさん** · 2011/02/05(土) 02:04:04

>>626
null クリアでトレースしやすくなる理由がわかりません。

**デフォルトの名無しさん** · 2011/02/05(土) 16:34:51

>627
そしてリリース版/デバッグ版の挙動の違いに悩まされる訳ですね。分かります。

>628
一部のデバッガが、未初期化・delete後の領域に
0xccとか埋める理由を考えてみると良いかと。

とか書くとnullクリアしなくても、その機能だけでも十分とか言い出すんだろうな。

**デフォルトの名無しさん** · 2011/02/05(土) 16:42:32

>>629
0xcc とか埋めるのはデバッガじゃないよ。
VC++ でデバッグビルドの時のデフォルト動作だったはず。

で、その機能はトレースのしやすさとは関係ないと思うんだけど、どういうこと？

うっかり破棄後のポインタを触る可能性を考えるなら、スマートポインタを
使っておけばスコープアウトで解放するんだからほぼ根絶できるし、
スコープアウト前に解放する場合はスマートポインタが null クリア相当の
ことはするし。

手間をかけてでも null クリアしとけというのはやっぱりわからん。

**デフォルトの名無しさん** · 2011/02/05(土) 20:54:22

Javaの話じゃなかったのか

**デフォルトの名無しさん** · 2011/02/05(土) 21:35:50

Java で 0xcc 埋めとか、無いよな。

**デフォルトの名無しさん** · 2011/02/06(日) 18:13:55

そんなもん入ってたら大変なことになるだろうな

**デフォルトの名無しさん** · 2011/02/06(日) 21:32:52

>>633
なんで？

プログラマやデバッガが Java の意味として解釈できるアクセス対象は、
せいぜいバイトコードまでで、そりよりしたのレベルはランタイムに依るから、
実際のところ 0xcc で埋められていようといまいと、何も起こらないと思うんだが
（正確にはインターフェースのこちら側にとっては何も起こってないように見える）

**デフォルトの名無しさん** · 2011/02/06(日) 21:45:00

>>634
その 0xcc 埋めは Java では実装できないだろ。
JVM の実装として話すんなら C++ 以下の話だろう。

**デフォルトの名無しさん** · 2011/02/06(日) 22:13:55

>>635
> その 0xcc 埋めは Java では実装できないだろ

だから、プログラマやデバッガの立場では 0xcc 埋めできないんだから、
実際に 0xcc が入っていても大変なことになんてなるわけないと思うんだが

**デフォルトの名無しさん** · 2011/02/06(日) 22:22:39

>>636
そういうことか。
「Java の話ではない」って流れについて言ってるのかと思った。ごめん。

**デフォルトの名無しさん** · 2011/02/07(月) 00:29:09

>630
>うっかり破棄後のポインタを触る可能性を考えるなら、スマートポインタを
>使っておけばスコープアウトで解放するんだからほぼ根絶できるし

それはメモリ管理が楽になるだけであって、トレースしやすさとは別の話だと思うけど。
トレースし易いってのは、nullとか0xCCとか埋められれば、特定のアドレスの値を
見れば状態が分かるとかいう事だと思うが。

**デフォルトの名無しさん** · 2011/02/07(月) 00:32:55

0xccが無効なオブジェクト扱いになるんかいな。NULLは処理系として例外扱いだろ？

**デフォルトの名無しさん** · 2011/02/07(月) 00:36:36

>>638
0xcc の話なら確かに「特定のアドレスの値を見れば状態が分かる」けど、
破棄後のポインタにヌルを入れてもそんなことにはならないよ。

**デフォルトの名無しさん** · 2011/02/07(月) 00:47:22

>640
ポインタの値を見れば、そのポインタの状態は一目瞭然ですよね。