トップ «前の日記(2022-10-11) 最新 次の日記(2022-11-23)» 編集

Cocoa練習帳

iOS/iPhone/iPad/watchOS/tvOS/MacOSX/Android プログラミング, Objective-C, Cocoa, Swiftなど

2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|04|05|06|

2022-11-20 [Swift][Kotlin]UInt

プログラミング言語の制限を付与する機能は誰に対してなのか?例えばプライベートに対して隠すというのは、ソースが読める時点で丸見えなような。これについて、相手に対して不必要な情報を見せないという上手い表現をする人もいて、自分の気に入って使わせてもらっている。

これらの制限はなんなのか?注釈で説明する手間を省くためのものなのか?

例えば、C++にはconst地獄という言葉があって、せっかくconstが付けられていても、仕様が変わって、constを外すために多くのファイルで修正が発生しまったり、const値をライブラリに渡そうとすると、受け取り側がconstでないのでキャストすることになってしまったり。

ファイル内でしか使われない変数にconstがついていると、これを書いた人は自分自身が信用できなかったのかなと想像してしまったりする。

また、unsignedはどう考えればいいのか?負の値があり得ない変数はunsignedを選択すべきなのか?0より小さな値にならない制限だとすると上限値の制限はどうするの?下限値にないしてはコンパイラに任せ、上限値はプログラマがif文でチェックするのか?例えば、上限値は100、下限値は10で、どちらもif文でチェックしている場合、コンパイラの0以上チェックななんなのか?

iBooksとWebで公開されているThe Swift Programming Languageを読んでいて、興味深い説明を見つけた。

NOTE
Use UInt only when you specifically need an unsigned integer type with the same size as the platform’s native word size. If this isn’t the case, Int is preferred, even when the values to be stored are known to be nonnegative. A consistent use of Int for integer values aids code interoperability, avoids the need to convert between different number types, and matches integer type inference, as described in Type Safety and Type Inference.>/td>

大雑把に訳すと、特別な理由がない限りUIntを使わずIntを使え。理由はキャストを発生させないため。

厳密は型を気にする人が、構造体のメンバーでInt32やUIntなどを細かく指定するのを見たことがあるが、ライブラリの関数に値を渡す場合は、演算の際にIntにキャストすることになってしまい、それが本当に安全か?というのモヤモヤしてましたが、基本的にIntとすればキャストが発生しないので、ある程、こちらの方が安全ですね。

公式のドキュメントに書いてくれると、周りに説明しやすいので助かる。ありがとう。


トップ «前の日記(2022-10-11) 最新 次の日記(2022-11-23)» 編集