Java中的对象声明语句不允许使用单行循环.为什么? [英] Object declaration statement in Java doesn't allow to use a single-line loop. Why?

问题描述

以下程序本身没有意义.它仅使用类Counter中的静态字段，通过使用for循环来计算创建的对象数，如下所示.

The following program has no significance of its own. It just counts the number of objects created through the use of a for loop using a static field inside the class Counter as shown below.

package temp;

final class Counter
{
    private static int cnt;

    public Counter()
    {
        cnt++;
    }

    public static int show()
    {
        return(cnt);
    }
}

final public class Main
{
    public static void main(String[] args)
    {
        for (int i=0;i<50;i++)
        {
            Counter counter=new Counter();
        }

        /*for (int i=0;i<50;i++)
            Counter counter=new Counter();*/

        System.out.print("\nNumber of objects created:->"+Counter.show()+"\n\n");
    }
}

这里唯一的问题是，注释的for循环与前面的for循环完全相同，因此导致编译时错误，该错误指示"不是语句"意味着在这种特殊情况下，即使for循环仅包含一个语句，也必须使用一对大括号！为什么?

The only question here is that the commented for loop means the same as the preceding for loop doesn''t work at all causing a compile-time error that indicates that "not a statement" means that in this particular situation, the pair of braces are mandatory even though the for loop contains only one statement! Why?

推荐答案

在这种情况下，编译器为您提供了很好的服务.

该循环代码毫无意义-在注释和未注释的变体中都是如此.在每个循环迭代中，您都将创建一个新的Counter对象，并将其分配给循环中本地定义的变量，随后，您将在每个迭代中松散此值，因为您将在每个迭代中创建一个新对象和一个新变量，并获得老物件丢了.从原则上讲，对未分配赋值的编译器的调用可能具有某种意义，因为仅出于副作用而调用它.这将是一个糟糕的阶梯，但在形式上是有效的.因此，问题在于存在未使用的本地声明和无用的赋值.

现在，为什么编译器在一种情况下而不是另一种情况下都发现问题，而两种情况都不对?那么，编译器不是那么聪明.我将尝试解释它的思考"，这很简单.

编译器仅在没有块的情况下才能够检测到这种病理情况，这比较容易.编译器可以看到"循环下唯一的语句(称为 embedded语句)是变量声明，而从不可能没有任何意义，不管是否要分配作业.在{/*.../}块的情况下，编译器将停止进行更深入的分析；因此，这里的编译器逻辑是谁知道接下来会发生什么?".确实，您在块中添加了另一行，并且第二行使用了counter的值，因此可以完美证明声明的合理性.如果是嵌入式语句语法，则原则上不可能进行这种添加.

如果考虑考虑，编译器旨在将代码分析到合​​理的深度，这很有意义.抛开性能，技术问题和可支持性问题，如果编译器太笨拙"，那么高级错误消息将太复杂且更易混淆，可能会有所帮助.看我目前的答案.它已经足够长了，几乎是一篇简短的文章.现在想象一下编译器，该编译器会不时地为您提供一些与整篇文章一样大小的错误消息. :-)因此，对问题代码的分析应该更简单，更容易伪造并且严格地形式化，可以直接引用语言的定义.

错误消息并不完美，但总比没有好. :-)

—SA

In this case, the compiler serves you quite well.

This loop code makes no sense — in both commented and uncommented variants. In each of the loop iterations you create a new Counter object and assign it to the variable locally defined in the loop, and later you loose this value in each iteration as you create a new object and a new variable in each iteration and get the old object lost. The call to the compiler without assignment could have some sense in principle, because it could be called just for side effect. It would be a bad stile, but formally valid. So the problem is having the unused local declaration and useless assignment.

Now, why the compiler detects the problem in one case and not in another case while both cases are wrong? Well, the compiler is not so intellectual. I''ll try to explain its "thinking" which is pretty straightforward.

The compiler is able to detect this pathological case only without the block, which is kind of easier. The compiler can "see" that the the only statement under the loop (it is called embedded statement) is a variable declaration, which never can make any sense, no matter if is it followed by assignment or not. In case of the block {/*.../} compiler just stops to analyze the situation deeper; so the compiler logic here is "who knows what comes next?". Indeed, it you added another line in the block, and it that second line used the value of counter, it would perfectly justify the declaration. In case of embedded statement syntax, such addition is impossible in principle.

The compiler is designed to analyze the code to some reasonable depth which makes perfect sense, if you think about it. Set aside performance, technical problem and the problem of supportability, if a compiler is too "intellectual", the advanced error messages would be too complex and more confusing then helping. Look at my present answer. It is already long enough, almost a short article. Now imagine the compiler which gives out you some error messages of the size of the whole article, now and then. :-) So, the analysis of the problem code should be simpler, easier to falsify and strictly formal, directly referencing the definition of the language.

The error message is less than perfect, but it''s still better then nothing. :-)

—SA

这篇关于Java中的对象声明语句不允许使用单行循环.为什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！