blocks|key|312867|text|因为他们没有在字节码中实现必要的指令，而且你真的不想写那么多情况，无论你的代码有多“生产就绪”……|type|unstyled|depth|inlineStyleRanges|entityRanges|data|312868|编辑:摘自对此答案的评论，并在背景上添加了一些内容|312869|准确地说，2³²是一个lot的案例和任何程序的方法足够长，以容纳更多将是完全可怕的！任何一种语言。(据我所知，在任何语言的代码中，最长的函数是略高于6k的SLOC+-是的，它是一个很大的switch+-而且它真的很难管理。)如果您真的坚持只有一个int或更少的long，那么您有两个真正的选择。|offset|length|style|BOLD|CODE|312870|312871|使用散列函数主题的一些变体来将long压缩为int。最简单的方法就是强制转换，只有在类型错误的时候才会使用！更有用的做法是：|ordered-list-item|312872|312873|(int)+((x+&0xFFFFFFFFF)%5E((x+>>>+32)+&0xFFFFFFFFF))|312874|在打开结果之前。您还必须弄清楚如何转换您正在测试的用例。但实际上，这仍然很可怕，因为它没有解决很多情况下的真正问题。|312875|如果你处理大量的情况，一个更好的解决方案是将你的设计更改为使用Map<Long,Runnable>或类似的东西，这样你就可以查找如何分派一个特定值。这允许您将案例分离到多个文件中，当案例数量变大时，这将更容易管理，尽管组织所涉及的实现类主机的注册会变得更加复杂(注释可能会通过允许您自动构建注册代码来帮助您)。|unordered-list-item|312876|312877|顺便说一下，我在很多年前就这样做了(我们在项目中途切换到了新发布的JVM1.2)，当时我构建了一个用于模拟大规模并行硬件的自定义字节码引擎(不，重用J2SE并不适合，因为涉及的值和执行模型完全不同)，并且相对于C版本代码使用的大switch，它极大地简化了代码。|312878|为了重申这一要点，想要在long上执行switch，这表明您要么在程序中搞错了类型，要么您正在构建的系统中包含了如此多的变体，因此您应该使用类。无论是哪种情况，都是时候重新考虑了。|312879|entityMap^0|0|0|B|3|2L|6|3F|3|3M|4|0|0|F|4|M|3|0|0|0|0|V|I|0|0|36|6|0|C|4|J|6|0^^$0|@$1|2|3|4|5|6|7|13|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|14|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|15|8|@$F|16|G|17|H|I]|$F|18|G|19|H|J]|$F|1A|G|1B|H|J]|$F|1C|G|1D|H|J]]|9|@]|A|$]]|$1|K|3|-4|5|6|7|1E|8|@]|9|@]|A|$]]|$1|L|3|M|5|N|7|1F|8|@$F|1G|G|1H|H|J]|$F|1I|G|1J|H|J]]|9|@]|A|$]]|$1|O|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1L|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1M|8|@]|9|@]|A|$]]|$1|T|3|U|5|V|7|1N|8|@$F|1O|G|1P|H|J]]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1R|8|@$F|1S|G|1T|H|J]]|9|@]|A|$]]|$1|Z|3|10|5|6|7|1U|8|@$F|1V|G|1W|H|J]|$F|1X|G|1Y|H|J]]|9|@]|A|$]]|$1|11|3|-4|5|6|7|1Z|8|@]|9|@]|A|$]]]|12|$]]

Because they didn't implement the necessary instructions in the bytecode and you really don't want to write that many cases, no matter how "production ready" your code is...

[EDIT: Extracted from comments on this answer, with some additions on background]

To be exact, 2³² is a lot of cases and any program with a method long enough to hold more than that is going to be utterly horrendous! In any language. (The longest function I know of in any code in any language is a little over 6k SLOC – yes, it's a big <code>switch</code> – and it's really unmanageable.) If you're really stuck with having a <code>long</code> where you should have only an <code>int</code> or less, then you've got two real alternatives.

<ol>
<li>Use some variant on the theme of hash functions to compress the <code>long</code> into an <code>int</code>. The simplest one, only for use when you've got the type wrong, is to just cast! More useful would be to do this:

<pre><code>(int) ((x&amp;0xFFFFFFFF) ^ ((x &gt;&gt;&gt; 32) &amp; 0xFFFFFFFF))
</code></pre>

before switching on the result. You'll have to work out how to transform the cases that you're testing against too. But really, that's still horrible since it doesn't address the real problem of lots of cases.</li>
<li>A much better solution if you're working with very large numbers of cases is to change your design to using a <code>Map&lt;Long,Runnable&gt;</code> or something similar so that you're looking up how to dispatch a particular value. This allows you to separate the cases into multiple files, which is much easier to manage when the case-count gets large, though it does get more complex to organize the registration of the host of implementation classes involved (annotations might help by allowing you to build the registration code automatically).

FWIW, I did this many years ago (we switched to the newly-released J2SE 1.2 part way through the project) when building a custom bytecode engine for simulating massively parallel hardware (no, reusing the JVM would not have been suitable due to the radically different value and execution models involved) and it enormously simplified the code relative to the big <code>switch</code> that the C version of the code was using.</li>
</ol>

To reiterate the take-home message, wanting to <code>switch</code> on a <code>long</code> is an indication that either you've got the types wrong in your program or that you're building a system with that much variation involved that you should be using classes. Time for a rethink in either case.

blocks|key|307793|text|因为查找表索引必须是32位。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|307794|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Because the lookup table index must be 32 bits.

blocks|key|310829|text|我认为在某种程度上，这可能是基于switch的典型用法而做出的武断决定。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|310830|开关基本上可以通过两种方式(或原则上，一种组合)来实现:对于少数情况，或者值广泛分散的情况，开关本质上等同于临时变量上的一系列if(打开的值只能计算一次)。对于值或多或少连续的中等数量的情况，使用切换表(Java中的TABLESWITCH指令)，从而在表中有效地查找要跳转到的位置。|310831|原则上，这两种方法都可以使用长值而不是整数。但我认为这可能只是为了平衡指令集和编译器的复杂性与实际需要的实际决定:您确实需要切换到长值的情况非常罕见，因此可以接受将其重写为一系列IF语句，或者以其他方式变通(如果所讨论的长值很接近，则可以在Java代码中切换为减去最低值后的int结果)。|310832|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I think to some extent it was probably an arbitrary decision based on typical use of switch.

A switch can essentially be implemented in two ways (or in principle, a combination): for a small number of cases, or ones whose values are widely dispersed, a switch essentially becomes the equivalent of a series of ifs on a temporary variable (the value being switched on must only be evaluated once). For a moderate number of cases that are more or less consecutive in value, a switch table is used (the TABLESWITCH instruction in Java), whereby the location to jump to is effectively looked up in a table.

Either of these methods could in principle use a long value rather than an integer. But I think it was probably just a practical decision to balance up the complexity of the instruction set and compiler with actual need: the cases where you really need to switch over a long are rare enough that it's acceptable to have to re-write as a series of IF statements, or work round in some other way (if the long values in question are close together, you can in your Java code switch over the int result of subtracting the lowest value).

blocks|key|3048686|text|在32位体系结构中，由两个字表示。现在，想象一下，如果由于同步不足，switch语句的执行观察到来自一次写入的高位32位的长整型，以及来自另一次写入的32低位的长整型，会发生什么！它可以尝试去....who+knows！基本上是随机的。即使这两种写操作都表示switch语句的有效情况，但它们有趣的组合可能既不会导致第一种情况，也不会导致第二种情况--或者更糟糕的是，它可能导致另一种有效但无关的情况！|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|3048687|至少对于int+(或更小的类型)，不管你搞得有多糟糕，switch语句至少会读取某个人实际写入的值，而不是“凭空”读取的值。|3048688|当然，我不知道真正的原因(这已经超过15年了，我没有注意那么长时间！)，但是如果你意识到这样的构造可能是多么不安全和不可预测，你会同意这绝对是一个很好的理由永远不会有开关的长整型(只要-pun的意图-将有32位机器，这个理由将仍然有效)。|3048689|entityMap^0|A|4|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|P|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|Q|8|@]|D|@]|E|$]]]|K|$]]

A long, in 32bit architectures, is represented by two words. Now, imagine what could happen if due to insufficient synchronization, the execution of the switch statement observes a long with its high 32 bits from one write, and the 32 low ones from another! It could try to go to ....who knows where! Basically somewhere at random. Even if both writes represented valid cases for the switch statement, their funny combination would probably lead neither to the first nor to the second -- or extremely worse, it could lead to another valid, but unrelated case!

At least with an int (or lesser types), no matter how badly you mess up, the switch statement will at least read a value that someone actually wrote, instead of a value "out of thin air".

Of course, I don't know the actual reason (it's been more than 15 years, I haven't been paying attention that long!), but if you realize how unsafe and unpredictable such a construct could be, you'll agree that this is a definitely very good reason not to ever have a switch on longs (and as long -pun intended- there will be 32bit machines, this reason will remain valid).

Here's an excerpt from <a href="https://docs.oracle.com/javase/tutorial/java/nutsandbolts/switch.html" rel="noreferrer">Sun's Java tutorials</a>:

<blockquote>
 A switch works with the <code>byte</code>, <code>short</code>, <code>char</code>, and <code>int</code> primitive data types. It also works with enumerated types (discussed in Classes and Inheritance) and a few special classes that "wrap" certain primitive types: <code>Character</code>, <code>Byte</code>, <code>Short</code>, and <code>Integer</code> (discussed in Simple Data Objects).
</blockquote>

There must be a good reason why the <code>long</code> primitive data type is not allowed. Anyone know what it is?

Why can't your switch statement data type be long, Java?

编译器

Java

以下是的摘录开关用于byte、short、char和int基元数据类型。它还适用于枚举类型(在类和继承中讨论)和一些“包装”某些原语类型的特殊类：Character、Byte、Short和Integer (在简单数据对象中讨论)。一定有一个很好的理由来解释为什么不允许使用long原语数据类型。有人知道这是什么吗？

问为什么您的switch语句数据类型不能是long，Java？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么您的switch语句数据类型不能是long，Java？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么您的switch语句数据类型不能是long，Java？
EN