Java двойная инициализация
Текущий выбранный ответ НЕ обрабатывает строки без пробелов, таких как «jjjjjjjjjjjjjjjjjjj» x1000 (подумайте, что произойдет, если кто-то вставил URL-адрес)
Этот код решает эту проблему:
private void txtBody_TextChanged(object sender, EventArgs e)
{
// amount of padding to add
const int padding = 3;
// get number of lines (first line is 0, so add 1)
int numLines = this.txtBody.GetLineFromCharIndex(this.txtBody.TextLength) + 1;
// get border thickness
int border = this.txtBody.Height - this.txtBody.ClientSize.Height;
// set height (height of one line * number of lines + spacing)
this.txtBody.Height = this.txtBody.Font.Height * numLines + padding + border;
}
4 ответа
Попробовав простую программу (с использованием как 0, так и 100) , чтобы показать разницу между "специальными" константами и общими) компилятор Sun Java 6 будет выводить один и тот же байт-код для 1 и 2 (случаи 3 и 4 идентичны 2 для компилятора).
Так, например:
double x = 100;
double y = 100.0;
компилируется в:
0: ldc2_w #2; //double 100.0d
3: dstore_1
4: ldc2_w #2; //double 100.0d
7: dstore_3
Однако я не вижу ничего в Спецификации языка Java , гарантирующего это расширение константных выражений во время компиляции. Существует сужение времени компиляции для таких случаев, как:
byte b = 100;
, как указано в разделе 5.2 , но это не совсем то же самое.
Может быть, кто-то с более острым взглядом, чем я, сможет найти гарантия там где-то ...
Для первого:
double dummy = 0;
целочисленный литерал 0 преобразуется в двойной с расширяющимся примитивным преобразованием, см. 5.1.2 Расширяющее примитивное преобразование в Java Спецификация языка. Обратите внимание, что это делается полностью компилятором, это никак не влияет на создаваемый байт-код.
Для остальных:
double dummy = 0.0;
double dummy = 0.0d;
double dummy = 0.0D;
Эти три абсолютно одинаковы - 0.0, 0.0d и 0.0D - это всего лишь три разных способа написания литерала double. См. 3.10.2 Литералы с плавающей точкой в JLS.
для Java я точно не знаю, в C это может быть очень опасно, если вы опустите этот D в конце, так как он не изменит старшие байты, что может иметь эффект, что в вашей переменной лежит число, которое вы на самом деле не поместили в!
В Java у меня была действительно большая проблема с созданием экземпляра BigDecimal - новый BigDecimal (0) и новый bigDecimal (0L) - это НЕ одно и то же, вы можете почувствовать это, если переносите код с Java 1.4 на Java 1.5 , Не знаю, почему они были неаккуратны по этому поводу, может быть, они должны были сделать это таким образом.
Последние 3 должны быть идентичными. Буквальный справа уже двойник. 'D' или 'D' неявно используются, когда у вас есть десятичный литерал.
Первый немного отличается тем, что 0 - это литерал int, который будет расширен до двойного. Я не знаю, дает ли это вообще другой байт-код в этом случае или нет; в любом случае результат должен быть идентичным.