Лингвофорум

Я всё равно не понял.

2 сценария:

• Используем Java. Запускаем javac, компилируем текст в байткод JVM. У пользователя байткод JVM компилируется при запуске.
  
• Используем IKVM. Запускаем javac, компилируем текст в байткод JVM. Используем ikvmc, компилируем код JVM в CIL (причём два действия объединяем в одно с помощью Makefile или Ant'а). У пользователя байткод на CIL компилируется при запуске.
  

В чём разница?..

В таком варианте для пользователя действительно нет разницы.
Но если

Цитата: http://en.wikipedia.org/wiki/IKVMWith //ikvm.net you can run compiled Java code (bytecode) directly on Microsoft .NET or Mono. The bytecode is converted on the fly to CIL and executed.

компиляция осуществляется на лету, потери времени достаются пользователю.

Ключевое слово — can.

Как бы да, если запустить ikvm, а не ikvmc, то затраты действительно достанутся пользователю. Но при чём тут это вообще?

Цитировать//ikvm.net includes ikvmc, a Java bytecode to .NET IL translator. If you have a Java library that you would like to use in a .NET application, run ikvmc -target:library mylib.jar to create mylib.dll.

http://www.ikvm.net/uses.html

Цитата: Demetrius от ноября  2, 2010, 21:18

Цитата: Python от ноября  2, 2010, 20:33

Цитата: Demetrius от ноября  2, 2010, 19:23
лучше взять IKVM и не мучаться

Теоретически, верно. Но меня немного ужасает одна виртуальная машина поверх другой — можно ли получить высокую производительность с ее помощью?

Так она же вроде бы переводит в .NET'овый код, разве нет?

А то, что можно написать с помощью макросов, ужасает ещё сильнее. Впрочем, вызывает сомнения, что с помощью макросов вообще можно что-то дельное и достаточно большое написать.

Consider CL

Цитата: Python от ноября  2, 2010, 20:48
Куда уж сильнее? И так убил пару суток на бессмысленные споры непонятно ради чего.

Если это заставит Вас познать тёмную сторону макросов, которая несоизмеримо больше светлой; значит эти споры не были бессмысленными.

Цитата: Python от ноября  2, 2010, 20:48
Что я могу сделать? Джавовские средства ввода-вывода — один большой ужас, и макросы сами по себе не смогут их исправить — скорее, наоборот.

Не вижу ничего особо ужасного.

Цитата: Python от ноября  3, 2010, 00:50
Макросы есть смысл использовать ограниченно. Естественно, так сильно понравившийся публике макрос, созданный мной непосредственно из не менее ужасного стандартного фрагмента кода на джаве, в библиотеке макросов появляться не должен.

Скажите, а какую вообще проблему Вы пытались решить тем макросом?

Цитата: Demetrius от ноября  3, 2010, 00:57
По сути, макросы — это язык в языке, причём с разным синтаксисом. Оккам негодуэ.

Дело не только в этом, но в том, что препроцессор тупо делает подстановку текста со всеми вытекающими. Буквально вчера вечером он мне засрал два литерала в перечислениях. Ошибки компилятора на проделки препроцессора никак не указывают. Программист должен быть хорошо знаком с подлянками препроцессора и постоянно помнить об этой сволочи. В противном случае он обречён на длительное созерцание казалось бы правильного кода, который тем не менее не компилируется (и это в лучшем случае).

Цитата: Python от ноября  3, 2010, 01:06
goto они тоже не добавили специально. Что сделало адаптацию сишного кода для джавы нетривиальной задачей.

Я что-то не заметил засилья goto в сишном коде.

Цитата: addewyd от ноября  3, 2010, 04:44
Consider CL

Мы здесь другие макросы обсуждаем. Хотя лисповыми тоже можно оторвать себе голову.

Цитата: myst от ноября  3, 2010, 09:35
Я что-то не заметил засилья goto в сишном коде.

Ну тк это же не BASIC
Переход к метке — действие, используемое достаточно редко, но все же иногда используемое. Кроме того, иногда C используется в качестве промежуточного языка компилятора — там goto может оказаться несоизмеримо больше.

Цитата: myst от ноября  3, 2010, 09:21
Скажите, а какую вообще проблему Вы пытались решить тем макросом?

Не надоело еще? )
Проблема — слишком большой объем стандартного джава-кода при стандартных манипуляциях с файлом. Вообще, хороший макрос в этом случае мог бы выглядеь примерно так:

#define OPENW(S)  new BufferedWriter(new FileWriter(new File(S)))

Но необходимое удаление существующего файла не вписывается в одно выражение и требует либо объявления переменной, либо создания функции, выполняющей это действие. Тот пример действительно лучше было запихнуть в метод, а не создавать макрос, либо создать функцию для услвного удаления файла, которую можно использовать в выражениях, в том числе и в макросе, аналгичном приведенному в этом сообщении:

#define OPENW(S)  new BufferedWriter(new FileWriter(delFile(new File(S))))
....
public static File delFile(File F)
   {
   if (F.exists()) F.delete();
   return F;
   }
.....
Writer W=OPENW("file.txt");
.....

(естественно, при вызове delFile следует указать точное положение сей процедуры в иерархии пакетов, например, com.example.MyFileUtils.delFile).


Жду следующего вопроса о том же макросе. Может, обсуждение его вообще вынести в отдельную тему, поскольку вопрос исключительно важный?

Цитата: Python от ноября  3, 2010, 13:06
Переход к метке — действие, используемое достаточно редко, но все же иногда используемое.

Значит и нет никакой проблемы.

Цитата: Python от ноября  3, 2010, 13:06
Кроме того, иногда C используется в качестве промежуточного языка компилятора — там goto может оказаться несоизмеримо больше.

Это не для человеков.

Цитата: Python от ноября  3, 2010, 13:06
Жду следующего вопроса о том же макросе.

И зачем пытаться имитировать подпрограмму макросом, если можно написать нормальную подпрограмму, жажда острых ощущений?

(А что, Жаба не умеет перезапись файлов?)

Цитата: myst от ноября  3, 2010, 09:15
Не вижу ничего особо ужасного.

Но лично я бы предпочел писать Writer W=OPENW("file.txt"); вместо Writer W=new BufferedWriter(new FileWriter(com.example.MyFileUtils.delFile(new File(S))))

Цитата: myst от ноября  3, 2010, 13:56
Значит и нет никакой проблемы.

Проблема есть. Например, вот такой фрагмент кода можно адаптировать для джавы, лишь используя switch и дополнительную переменную:

{
XXXX x = new XXXX(args);
l1:  if(x.a()) goto l2;
      if(x.b()) goto l3;
      goto end;
l2:  if(x.c()) goto l1;
      if(x.d()) goto l3;
      goto end;
l3:  if(x.e()) goto l1;
      if(x.f()) goto l2;
end:
}


Цитата: myst от ноября  3, 2010, 13:56
И зачем пытаться имитировать подпрограмму макросом, если можно написать нормальную подпрограмму, жажда острых ощущений?

(А что, Жаба не умеет перезапись файлов?)

Конечно, можно, все можно. Но не уверен, идут ли на пользу и без того малопроизводительной джаве функции-обертки. Кроме того, мы так и не решили проблемы с длинными путями к классам и методам, импорт которых средствами чистой джавы невозможно собрать в один инклуд.

А с другой стороны, какие ошибки может вызвать последняя версия OPENW или PRINTLN? Разве что совпадение с идентификатором, набранным большими буквами.

Цитата: myst от ноября  3, 2010, 13:56
Это не для человеков.

Это для человеков. Платформа с единственным компилятором — не платформа, а язык. Компиляторы, использующие промежуточный С-код — довольно распространенное явление. Невозможность скомпилировать С для JVM порождает невозможность использовать и эти компиляторы на этой платформе.

Цитата: Python от ноября  3, 2010, 14:00
Но лично я бы предпочел писать Writer W=OPENW("file.txt"); вместо Writer W=new BufferedWriter(new FileWriter(com.example.MyFileUtils.delFile(new File(S))))

В Жабе нет подпрограмм, поэтому их приходится имитировать макросами, да?

Цитата: Python от ноября  3, 2010, 14:03
Например, вот такой фрагмент кода можно адаптировать для джавы, лишь используя switch и дополнительную переменную:

Надеюсь, этот код Ваша фантазия?

Цитата: Python от ноября  3, 2010, 14:11
Но не уверен, идут ли на пользу и без того малопроизводительной джаве функции-обертки.

Преждевременная пессимизация — один из смертных грехов программирования.
И да, тесты, доказывающие малую производительность Жабы,— в студию.

Цитата: Python от ноября  3, 2010, 14:11
Кроме того, мы так и не решили проблемы с длинными путями к классам и методам, импорт которых средствами чистой джавы невозможно собрать в один инклуд.

Чо?

Цитата: Python от ноября  3, 2010, 14:11
А с другой стороны, какие ошибки может вызвать последняя версия OPENW или PRINTLN?

Это к специалисту по Жабе, я в ней не разбираюсь.

Но для любого языка препроцессор тупо заменит имя макроса на тело везде, куда дотянется без учёта лексических контекстов и т. п. Ему без разницы имя переменной то будет, константы, типа или подпрограммы — всё пойдёт под нож. Препроцессор понятия не имеет о типах и охотно примет белиберду в качестве параметров; компилятор укажет на ошибку, но не на сам макрос, так как для него никаких макросов не существует, в итоге диагностика компилятора превращается в бред сумасшедшего.

И снова спрашиваю нахрена имитировать подпрограммы, когда в языке они есть?

Цитата: Python от ноября  3, 2010, 14:14
Это для человеков. Платформа с единственным компилятором — не платформа, а язык. Компиляторы, использующие промежуточный С-код — довольно распространенное явление. Невозможность скомпилировать С для JVM порождает невозможность использовать и эти компиляторы на этой платформе.

Я имел в виду психически здоровых человеков, которые не транслируют язык A в язык B компилятором, а потом руками переписывают с языка B на язык C.

Цитата: myst от ноября  3, 2010, 15:57
Я имел в виду психически здоровых человеков, которые не транслируют язык A в язык B компилятором, а потом руками переписывают с языка B на язык C.

Зачем руками? В идеале, все должно работать автоматически.

Цитата: myst от ноября  3, 2010, 15:57
Но для любого языка препроцессор тупо заменит имя макроса на тело везде, куда дотянется без учёта лексических контекстов и т. п. Ему без разницы имя переменной то будет, константы, типа или подпрограммы — всё пойдёт под нож. Препроцессор понятия не имеет о типах и охотно примет белиберду в качестве параметров; компилятор укажет на ошибку, но не на сам макрос, так как для него никаких макросов не существует, в итоге диагностика компилятора превращается в бред сумасшедшего.

На то и существует соглашение, предписывающее использовать капс-лок в макроопределениях и строчные буквы в переменных и функциях. Правда, джависты используют немного другие соглашения.

Цитата: myst от ноября  3, 2010, 15:57
В Жабе нет подпрограмм, поэтому их приходится имитировать макросами, да?

В принципе, можно было бы обойтись и одними подпрограммами. Вместо инклуда, содержащего макроопределения, вполне можно создать класс с кучей оберточных функций, а потом импортировать его везде, где требуются функции из этого набора. Впрочем, это не решает проблему импорта имен классов, которые приходится импортировать либо индивидуально для каждого класса, либо целым пакетом. Иными словами, если в разных программах мне одновременно требуется класс A из пакета aaa.a, класс B из пакета //bbbbb.bb, ..., класс X из пакета x, то единственный способ импортировать этот джентльменский набор — полностью его перечислить в каждом файле, использующем этот набор классов.

Цитата: Python от ноября  3, 2010, 17:11
Зачем руками? В идеале, все должно работать автоматически.

Тогда какое Вам дело до goto? Но такая трансляция в любом случае извращение.

Цитата: Python от ноября  3, 2010, 17:11
На то и существует соглашение, предписывающее использовать капс-лок в макроопределениях и строчные буквы в переменных и функциях.

Которое не соблюдается.

Цитата: Python от ноября  3, 2010, 17:11
Впрочем, это не решает проблему импорта имен классов, которые приходится импортировать либо индивидуально для каждого класса, либо целым пакетом. Иными словами, если в разных программах мне одновременно требуется класс A из пакета aaa.a, класс B из пакета //bbbbb.bb, ..., класс X из пакета x, то единственный способ импортировать этот джентльменский набор — полностью его перечислить в каждом файле, использующем этот набор классов.

Так и должно быть. За транзитивность отношения импорта убивать надо.

Цитата: myst от ноября  3, 2010, 17:28
Которое не соблюдается.

Чья-то криворукость — еще не повод считать, что так и должно быть.

Цитата: myst от ноября  3, 2010, 17:28
Тогда какое Вам дело до goto? Но такая трансляция в любом случае извращение.

Почему же, такую трансляцию легче реализовать, чем трансляцию непосрадственно в машинный код.

Цитата: myst от ноября  3, 2010, 17:28
Так и должно быть. За транзитивность отношения импорта убивать надо.

И чем же ручной ввод/копипаст кучи кода принципиально лучше, чем возможность создать некий пакет с привязанными к нему чужими классами? Если программист все вводит руками, у него меньше шансов ошибиться, что ли?

Цитата: Python от ноября  3, 2010, 18:13
Чья-то криворукость — еще не повод считать, что так и должно быть.

Вы стандарт C вообще в глаза видели?

Цитата: Python от ноября  3, 2010, 18:13
Почему же, такую трансляцию легче реализовать, чем трансляцию непосрадственно в машинный код.

Вы так говорите, будто извращение — это всегда сложно. Что же мешает ниасилившим нормальный компилятор велосипедистам сделать трансляцию прямо на целевой язык, то есть жабу? Извращенцы такие извращенцы.

Цитата: Python от ноября  3, 2010, 18:13
И чем же ручной ввод/копипаст кучи кода принципиально лучше, чем возможность создать некий пакет с привязанными к нему чужими классами? Если программист все вводит руками, у него меньше шансов ошибиться, что ли?

Вы меня с каждым разом удручаете всё больше и больше. Это же азбучные истины, 2x2. Вы не знаете элементарных вещей, азов, но уже вовсю критикуете. Это выглядит очень нелепо.

Цитата: Python от ноября  3, 2010, 18:13
Почему же, такую трансляцию легче реализовать, чем трансляцию непосрадственно в машинный код.

И да, какое Вам дело до goto, если этим будет заниматься транслятор?

Цитата: myst от ноября  3, 2010, 18:42
Вы меня с каждым разом удручаете всё больше и больше. Это же азбучные истины, 2x2. Вы не знаете элементарных вещей, азов, но уже вовсю критикуете. Это выглядит очень нелепо.

Любые азы подлежат перепроверке. Да, сейчас норма — писать флудозаголовки на пару страниц, а когда-то нормой был спутанный код с кучей переходов. Чем же так хороши гигантские шапки?

Цитата: myst от ноября  3, 2010, 18:42
Вы стандарт C вообще в глаза видели?

На что именно в том стандарте следует обратить особое внимание?

Цитата: myst от ноября  3, 2010, 18:42
Что же мешает ниасилившим нормальный компилятор велосипедистам сделать трансляцию прямо на целевой язык, то есть жабу?

Предположим, есть транслятор из исходного языка в ANSI C, поддерживаемый большинством платформ. Благодаря отсутствию качественных С-совместимых языков для JVM мы создаем дополнительную работу для программистов.

Цитата: Python от ноября  3, 2010, 18:54
Любые азы подлежат перепроверке.

Прежде чем перепроверять, их следует познать и понять.

Цитата: Python от ноября  3, 2010, 18:56
На что именно в том стандарте следует обратить особое внимание?

На регистр символов у макросов. Или Вы снова забыли, о чём идет речь?

Цитата: Python от ноября  3, 2010, 19:00
Предположим, есть транслятор из исходного языка в ANSI C, поддерживаемый большинством платформ. Благодаря отсутствию качественных С-совместимых языков для JVM мы создаем дополнительную работу для программистов.

Мне уже наскучили Ваши сферические кони, пол Африки можно было бы от голода спасти этим табуном. Проблемы создателей маргинальных недоязычков, которые осилили трансляцию на С, но никак не могут осилить трансляцию на жабу или в байт-код жаба-машины, совершенно неинтересны.