JavaのL番号(ロング)仕様


95

Javaで数値を入力すると、コンパイラーはそれを整数として自動的に読み取るようです。そのため、(longの)6000000000(整数の範囲で6000000000はなく)入力すると、整数ではないと不平を言うでしょう。これを修正するには、を指定する必要がありました6000000000L。この仕様について学んだところです。

short、byte、float、doubleなどの他の数値指定はありますか?あなたが入力している数を指定できれば短いので、Javaはそれをキャストする必要がないため、これらは良いように思われます-それは仮定です、私が間違っていれば修正してください。私は通常、この質問を自分で検索しますが、この種の数値指定が何と呼ばれているかさえわかりません。

回答:


174

long(eg 39832L)、float(eg 2.4f)、double(eg -7.832d)には特定のサフィックスがあります。

接尾辞がなく、整数型(例:)の場合は、5623と見なされますint。整数型ではない場合(例3.14159)、それはであると見なされますdouble

他のすべてのケースでは(byteshortchar具体的なサフィックスがないので)、あなたはキャストが必要です。

Javaの仕様では、上部および下部の両方のケースサフィックスを可能にするが、ための大文字バージョンlongアッパーケースとしてSは、好ましいL符号と混同しにくくなる1低い場合に比べl

詳細はJLSセクション3.10を参照してください(の定義を参照IntegerTypeSuffix)。


9
レイトエントリー:曖昧さの潜在的な原因を除去することは常に良いです、と私は同意しません ...しかし、あなた自身が混乱する見つける場合、私は信じている1lして0O(など)、あなたの優先順位は(フォント権を設定することで、あなたができれば)、Shiftキーを忘れないよう注意してください。
davidcsb

私は宣言した場合、私は...サフィックスについて質問がある@SimonNickerson 長いまたはダブル:のような変数long _lo = 30;ではなく30L、これは私の変数が変換されます意味がフロートを?またはの場合の_lo = _lo + 2.77よう_loにキャストされますフロート、それは次のように宣言されましたが、長い
luigi7up

いいえ、フロートはここでは関与していません。最初のケースで30は、はintへの拡大変換によって自動的に変換されlongます。2番目のケースでは、ステートメントは不正です。右側を明示的にlongにキャストする必要があります。例:_lo = (long) (_lo + 2.77)
Simon Nickerson

4
@DavidCesarinoがフォントを変更すると、あいまいさが修正されます-正しく設定した特定のエディターで。lをLに変更すると、別のエディター、IDE、Web上のソース(レビューツール、リポジトリなど)でコードを読んでいるときに、自分を含めてコードを読む可能性があるすべての人のあいまいさが修正されます。私見優先度はシフトキーを見逃すことではありません。ところで あなたはどのフォントをお勧めしますか?私はモノスペースが好きです。これは、私が見たほとんどすべてのエディター、CLIなどのデフォルトであり、このフォントl10およびそれぞれO)はかなり似ています。
dingalapadum 2017

1
@dingalapadum言ったように、あなたは正しい。あいまいさの原因を取り除くことは間違いなく正しいことです。簡単に間違える可能性のあるエディターは使用しないようにしてください。言い換えれば、防御的なコーディングの古い提案ですが、それに依存していません。フォントについては非常に個人的なものですが、1)等幅であるため、私はいつでもできる限りいつでもDeja Vu Sans Monoを使用します。2)キャラクター間のあいまいさはありません。3)私はその形が美しく、優雅で、読みやすく、読みやすいサンセリフフォントに似ています(他の優れたプログラミングフォントは「メタリック」なIMHOを感じすぎます)。
davidcsb 2017年

13

少し接しても構わないと思いますがFD(floatの場合)、(doubleの場合)、L(longの場合)に加えて、andと- にそれぞれサフィックスを追加する提案がなされていることを知りたいとお考えかもしれません。。これにより、バイト(または短い)配列にリテラル構文を使用するときにバイトにキャストする必要がなくなります。提案の例を引用すると:byteshortYS

主要なメリット:提案が採用された場合、プラットフォームが優れているのはなぜですか?

のような無愛想なコード

 byte[] stuff = { 0x00, 0x7F, (byte)0x80,  (byte)0xFF};

として再コーディングできます

 byte[] ufum7 = { 0x00y, 0x7Fy, 0x80y, 0xFFy };

Joe DarcyはProject Coin for Java 7を監督しており、彼のブログはこれらの提案を追跡する簡単な方法です。


それはいいだろう...私はいつもすべてのキャストが本当に迷惑であることがわかりました
jbu

これはJava 7に組み込まれなかったと思います。それが将来のアップデートまたはJava 8に組み込まれるかどうかについてはどうですか?
2013

@crush数か月前に調べてみましたが、私の知る限り、提案は放棄されていました。数値リテラルと0bバイナリリテラルの接頭辞には_が含まれていました。おっと。
エリクソン2013

オラクルはコミュニティに作業方法を教えたくないので、この提案はおそらくJavaではなくkotlinに実装されています... 2018年であり、残念ながらこの提案については何もありません
JoelBonetR

11

デフォルトでは、すべての整数プリミティブデータ型(byte、short、int、long)は、Javaコンパイラーによってint型として扱われます。以下のためにバイト短く、限り、それらに割り当てられた値がその範囲内にあるように、何の問題や不要サフィックスはありません。byteshortに割り当てられた値が範囲を超える場合は、明示的な型キャストが必要です。

例:

byte b = 130; // CE: range is exceeding.

これを克服するには、型キャストを実行します。

byte b = (byte)130; //valid, but chances of losing data is there.

longデータ型の場合、手間をかけずに整数値を受け入れることができます。次のように割り当てたとします

Long l = 2147483647; //which is max value of int

この場合、L / lのようなサフィックスは必要ありません。デフォルトでは、2147483647はJavaコンパイラーによってint型と見なされます。内部型キャストはコンパイラによって行われ、intはLong型に自動昇格されます。

Long l = 2147483648; //CE: value is treated as int but out of range 

ここでは、Javaコンパイラーでリテラル2147483648をlong型として扱うために、接尾部をLとして置く必要があります。

最後に

Long l = 2147483648L;// works fine.


1

あなたが入力している数を指定できれば短いので、Javaがそれをキャストする必要がないため、これらは良いと思われます

リテラルの解析はコンパイル時に行われるため、これはパフォーマンスに関してはまったく関係ありません。shortおよびbyte接尾辞を付けるのが良い唯一の理由は、コードがよりコンパクトになることです。


0

intlongリテラルを区別する必要がある理由を理解するには、次のことを考慮してください。

long l = -1 >>> 1;

int a = -1;
long l = a >>> 1;

当然のことながら、どちらのコードフラグメントもvariableに同じ値を与えていますlintlongリテラルを区別することができなければ、どのように解釈され-1 >>> 1ますか?

-1L >>> 1 // ?

または

(int)-1 >>> 1 // ?

そのため、数値が共通の範囲内であっても、タイプを指定する必要があります。リテラルの大きさでデフォルトが変更された場合、数字を変更しただけで、式の解釈に奇妙な変化が生じます。

これがために発生していないbyteshortchar彼らは常に、算術やビット演算を実行する前に推進されているので。おそらく、それらは、たとえば配列初期化式で使用するための整数型の接尾辞でなければなりませんが、ありません。float接尾辞fとを使用しますdouble d。他のリテラルには明確な型があり、には特別な型がありnullます。


私はあなたが昔何を意味していたかに本当に興味があります。どちらの場合も、2147483647が返され、なぜ他のことを期待する必要があるのか​​理解できません。
驚くべき1

@TheincredibleJan当然のことですが、リテラルとリテラルInteger.MAX_VALUEを区別する方法がなければ、あいまいになります。/この質問の記憶はありませんが、とにかく私の答えを明確にしました。intlong
トム・ホーティン-タックライン
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.