UUIDでは,16進数の13
桁目および17
桁目にそれぞれアルゴリズムとバリアント(変種)のコードが出力される場合があります。たとえばバージョン4のバリアント1であれば,13
桁目が常に4
,17
桁目が8
からb
の値になります。
Windows版の4Dでは,UUIDのバージョンコードが13
桁目ではなく15
桁目に出現します。Mac版は慣例どおり13
桁目です。言い換えるならば,値は確かにUUIDですが,フォーマットはMicrosoftのGUIDやCLSIDのものを踏襲しており,Macと比較すると,HHHHHHHH-HHHH-HHHH
グループがそれぞれバイトスワップされたような格好になっています。これはプラットフォームの設計に由来する仕様です。
128.1-128.08
という数式を4Dで評価すると0.01999999999998
という値が返されます。127.1-127.08
であれば0.02
が返されるのとは対照的です。
プログラミングで小数を扱う場合,実数は近似値を表現したものであることを憶えておきましょう。小学校で習った算数とは違うことをしている,ということです。計算の結果がぴったり割り切れるかどうかは,実数の内部的なデジタル値に左右されます。上述した例では,どちらも「およそ0.02
」という近似値が返されているのであり,これを「およそ等しい」と判定するために SET REAL COMPARISON LEVELのような仕組みが存在します。これは計算間違いではなく仕様です。
通常,実数値の「丸め」処理をするにはRound
を使用します。しかし,Round
を使用していないのに数値が四捨五入されることがあります。整数型のフィールドや変数に実数値を代入した場合,暗黙的に小数値が四捨五入されるためです。小数値を四捨五入するのではなく,切り捨てるのであれば,明示的にInt
関数を使用して整数部を取り出してください。
コンパイラーは定数のMAXLONG
を整数としてコンパイルします。リテラル数値とは違い,定義済み定数は値だけでなく型も決まっているからです。たとえばMAXLONG+1
という数式はインタープリターモードで実数値の2147483648
を返しますが,コンパイルモードでは整数値の-1
を返します。これは仕様です。符号付き32ビット整数値の範囲をオーバーフローするような数値をコンパイルモードで扱うのであれば,整数型の定義済み定数は使用しないでください。
SQL LOGIN
, Begin SQL
~End SQL
のODBC接続は,外部データプロバイダーとの接続を想定しています。4DのODBC Driverを使用して4Dから4Dに接続することは想定されていません。標準SQLで4D同士のODBC接続を試みた場合,SQLコマンドは正しい結果を返さないかもしれません。これは仕様です。どうしても4D同士でODBC接続をするのであれば,標準コマンドではなく,ODBC Proプラグインを使用してください。
19r2以降,テキストファイルを作成するコマンド(TEXT TO DOCUMENT
)File.setText()
でエンコーティングを明示的に指定しなかった場合,デフォルトでバイト・オーダー・マーク(BOM)なしのUTF-8が使用されるようになりました。UTF-8
などのエンコーティングを明示的に指定すれば,これまでどおりBOMが出力されます。これは仕様です。
エンコーティングを指定せずにUTF-8(デフォルト)でテキストファイルを作成した場合,ファイルの冒頭に0xEF
0xBB
0xBF
の3
バイトが追加されることがありません。これは,テキストエディターがBOMに基づいてファイルのエンコーディングを判定することができないことを意味します。
過去のバージョンで作成されたプロジェクトであれば,互換性オプションで動作を切り替えることができますが,19r2以降で作成されたプロジェクトにはオプションが表示されず,以前の動作に切り替えることはできません。
どちらのモードであってもUTF-8-no-bom
のようにBOMなしのエンコーティング名を指定することができます。
https://doc.4d.com/4Dv19R4/4D/19-R4/Compatibility-page.300-5737012.ja.html