アカウント名:
パスワード:
そんな持てはやされるものかねnull 参照の不具合なんて結局パラメータか戻り値のチェックミスなんだからそこに null が入ってようが不正な値が入ってようがプログラムが正しく動かないというのは変わらないし、ぬるぽで落ちるほうがバグが見つけやすいんじゃなかろうか
時代は関数型プログラミングですよ。中でif文あれこれ書くのはスマートじゃないんですよ。エラーだったら”なんかエラーです”とメッセージ出すだけなんだからそれでいいんですよ。
バグが見つからない？そんなのユーザーが文句いってから処理をつければいいんですよ。
NULLを禁止している言語は、C++等がNULLで表現しているエラーや異常値を表すための機構（Option型など）を持っています。NULLの代わりにこれらを使うと、異常値検査を省略したコードが書けないため、
パラメータか戻り値のチェックミス
が起きない仕組みになっています。
それでも、0除算はできるという、この中途半端さよ。
Rustだと、NonZero型 [rust-lang.org]もありますね。除数として使うことを意図しているのかどうかは分からないけど。
double f(double x) => 1 / (x - 1) - 1;
あんまり意味がないよね。
null参照エラーだと何が起きたのか分かりにくいというのはあると思う。でもnullがなければ変わりのエラーになるだけで意味ない感じはするな。# NoneとかNothingとか、何故nullにしなかったんだ、あの言語どもは。Cで書けてしまう不正なアドレス参照とはまた違う話だからなぁ。nullな状態を表せない分使い勝手が悪いとしか思えん。
表現力のなかった過去の言語のいわばバッドノウハウに固執しすぎでは。新しい言語でも表現する方法はありますし、むしろ使い勝手もいいですよ。
例えばC#は長らくnull安全ではなかったけど、最近ようやくオプションでnull安全機能を有効にも出来るようになった。なので、設定を有効にしたり無効にしたりしてコーディングをしてみる事で実体験をもってnull安全がコードの安全性にどう寄与するかを学習できる。マジおすすめ。
nullが使えなくなったのはいいんだけど、オブジェクトが破棄されているか分からないのがなあ。
それ null が使用できたとしてもオブジェクトが破棄されていることは分からないのでは。
破棄が必要なオブジェクトは IDisposable使うし、プログラマが制御するのも .NETの基本中の基本だけど、、、
というかdispose()の実装こそが、nullが使えなくなることで面倒になるの典型例の一つだよ。dispose済みかどうかのフラグを追加するしかないことも多いと思う。
それは null の使用可否は関係なくて単に dispose() の存在を前提にした設計や実装ができてないだけでは。
親子コメはDispose()を実装するときの話をしていると思うの。
もちろん dispose() を実装するときの話です。
1bit分のフラグをnullかどうかで表してるのよねそういうちまちました最適化はコンパイラ任せに出来る流れ
クソSIerで働いてそう
ぬるぽで落ちるまでバグが見つからないのと、nullチェックをコンパイラに強制されるかの違いです「チェック済みポインタだけ渡してね」って仕様書やコメントに書いてお願いするより型検査で弾ける方が確実じゃないかと
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
最近の流行りだけど (スコア:0)
そんな持てはやされるものかね
null 参照の不具合なんて結局パラメータか戻り値のチェックミスなんだからそこに null が入ってようが不正な値が入ってようがプログラムが正しく動かないというのは変わらないし、ぬるぽで落ちるほうがバグが見つけやすいんじゃなかろうか
Re:最近の流行りだけど (スコア:1)
時代は関数型プログラミングですよ。
中でif文あれこれ書くのはスマートじゃないんですよ。
エラーだったら”なんかエラーです”とメッセージ出すだけなんだからそれでいいんですよ。
バグが見つからない？そんなのユーザーが文句いってから処理をつければいいんですよ。
Re:最近の流行りだけど (スコア:1)
NULLを禁止している言語は、C++等がNULLで表現しているエラーや異常値を表すための機構（Option型など）を持っています。NULLの代わりにこれらを使うと、異常値検査を省略したコードが書けないため、
パラメータか戻り値のチェックミス
が起きない仕組みになっています。
Re: (スコア:0)
それでも、0除算はできるという、この中途半端さよ。
Re: (スコア:0)
Rustだと、NonZero型 [rust-lang.org]もありますね。
除数として使うことを意図しているのかどうかは分からないけど。
Re: (スコア:0)
あんまり意味がないよね。
Re:最近の流行りだけど (スコア:1)
null参照エラーだと何が起きたのか分かりにくいというのはあると思う。
でもnullがなければ変わりのエラーになるだけで意味ない感じはするな。
# NoneとかNothingとか、何故nullにしなかったんだ、あの言語どもは。
Cで書けてしまう不正なアドレス参照とはまた違う話だからなぁ。
nullな状態を表せない分使い勝手が悪いとしか思えん。
Re: (スコア:0)
表現力のなかった過去の言語のいわばバッドノウハウに固執しすぎでは。
新しい言語でも表現する方法はありますし、むしろ使い勝手もいいですよ。
Re: (スコア:0)
例えばC#は長らくnull安全ではなかったけど、最近ようやくオプションで
null安全機能を有効にも出来るようになった。
なので、設定を有効にしたり無効にしたりしてコーディングをしてみる事で
実体験をもってnull安全がコードの安全性にどう寄与するかを学習できる。
マジおすすめ。
Re:最近の流行りだけど (スコア:1)
nullが使えなくなったのはいいんだけど、オブジェクトが破棄されているか分からないのがなあ。
Re: (スコア:0)
それ null が使用できたとしてもオブジェクトが破棄されていることは分からないのでは。
Re: (スコア:0)
破棄が必要なオブジェクトは IDisposable使うし、プログラマが制御するのも .NETの基本中の基本だけど、、、
Re:最近の流行りだけど (スコア:1)
というかdispose()の実装こそが、nullが使えなくなることで面倒になるの典型例の一つだよ。
dispose済みかどうかのフラグを追加するしかないことも多いと思う。
Re: (スコア:0)
それは null の使用可否は関係なくて
単に dispose() の存在を前提にした設計や実装ができてないだけでは。
Re: (スコア:0)
親子コメはDispose()を実装するときの話をしていると思うの。
Re: (スコア:0)
もちろん dispose() を実装するときの話です。
Re: (スコア:0)
1bit分のフラグをnullかどうかで表してるのよね
そういうちまちました最適化はコンパイラ任せに出来る流れ
Re: (スコア:0)
クソSIerで働いてそう
Re: (スコア:0)
ぬるぽで落ちるまでバグが見つからないのと、nullチェックをコンパイラに強制されるかの違いです
「チェック済みポインタだけ渡してね」って仕様書やコメントに書いてお願いするより型検査で弾ける方が確実じゃないかと