F>Например то, что байт-код перед исполнением компилируется в машинные коды, в отличии от интерпретируемых языков.
здрасть и вы туда же, все не можете смириться что результат вашей работы
суррогат?,
НА ВЫХОДЕ НЕТ ИСПОЛНЯЕМОГО ФАЙЛА,
ТЫ МОЖЕШЬ СКОЛЬКО УГОДНО ГОВОРИТЬ ... ПРО МАШИННЫЕ КОДЫ.
короче вы для меня лично теперь тоже входите в кагорту тех самых
которые так и не уловили смысл сказанного...
... что же там их явка делает на самом то деле ? ась
This is achieved by most Java compilers by compiling the Java language code halfway (to Java bytecode) – simplified machine instructions specific to the Java platform. The code is then run on a virtual machine (VM), a program written in native code on the host hardware that interprets and executes generic Java bytecode. (In some JVM versions, bytecode can also be compiled to native code, either before or during program execution, resulting in faster execution.)
Сообщение отредактировано модератором. ДХ
Re[15]: Зачем нужен сборщик мусора? Как жить без деструкторо
Здравствуйте, infusion, Вы писали:
I>здрасть и вы туда же, все не можете смириться что результат вашей работы I>суррогат?, I>ДЛЯ ОСОБО "ОДАРЕННЫХ", НА ВЫХОДЕ НЕТ ИСПОЛНЯЕМОГО ФАЙЛА, I>ТЫ МОЖЕШЬ СКОЛЬКО УГОДНО ГОВОРИТЬ ЧУШЬ ПРО МАШИННЫЕ КОДЫ.
Тебе выхлоп JIT в виде нативного кода показать? Самый настоящий нативный код, который выплёвывает JIT при запуске Java программы.
I>короче вы для меня лично теперь тоже входите в кагорту тех самых I>которые так и не уловили смысл сказанного, и пытаются дро#ить на I>тему, что же там их явка делает на самом то деле ? ась
I>http://en.wikipedia.org/wiki/Java_(programming_language) I>
I>This is achieved by most Java compilers by compiling the Java language code halfway (to Java bytecode) – simplified machine instructions specific to the Java platform. The code is then run on a virtual machine (VM), a program written in native code on the host hardware that interprets and executes generic Java bytecode. (In some JVM versions, bytecode can also be compiled to native code, either before or during program execution, resulting in faster execution.)
Ну. А в скобках парой слов позже прочитать не судьба? Чтоб ты знал, в Sun-овская Java по умолчанию работае в mixed-режиме, когда байткод исполняеться N-раз, а после этого транслируется в нативный код и последующие разы уже выполняется нативный код.
Re[14]: Зачем нужен сборщик мусора? Как жить без деструкторо
Здравствуйте, fmiracle, Вы писали: F>Ух ты, какой замечательный ребенок. Еще ничего не знает, но энергия самомнение просто бьют через край. F>Ознакомься с материалом, узнаешь много чего интересного.
F>Например то, что байт-код перед исполнением компилируется в машинные коды, в отличии от интерпретируемых языков.
надо бы выделить для тебя особенно
(In some JVM versions, bytecode can also be compiled to native code, either before or during program execution, resulting in faster execution.)
но подзреваю ты все равно ничего не понял
Re[15]: Зачем нужен сборщик мусора? Как жить без деструкторо
I>здрасть и вы туда же, все не можете смириться что результат вашей работы I>суррогат?, I>ДЛЯ ОСОБО "ОДАРЕННЫХ", НА ВЫХОДЕ НЕТ ИСПОЛНЯЕМОГО ФАЙЛА, I>ТЫ МОЖЕШЬ СКОЛЬКО УГОДНО ГОВОРИТЬ ЧУШЬ ПРО МАШИННЫЕ КОДЫ.
.NET может генерировать .exe файлы, которые вполне исполняемые.
Re[17]: Зачем нужен сборщик мусора? Как жить без деструкторо
L>На которые компилятор кричит-кричит, аж надрывается, бедный.
А что тут такого? Совершенно нормальный код. Ты ведь, я надеюсь, в конструкторе myMember методы myClass не дергаешь? А сохранить указатель на обертывающую структуру — вполне нормально для определенного круга задач.
Да здравствует мыло душистое и веревка пушистая.
Re[15]: Зачем нужен сборщик мусора? Как жить без деструкторо
Здравствуйте, infusion, Вы писали:
I>здрасть и вы туда же, все не можете смириться что результат вашей работы I>суррогат?, I>ДЛЯ ОСОБО "ОДАРЕННЫХ", НА ВЫХОДЕ НЕТ ИСПОЛНЯЕМОГО ФАЙЛА, I>ТЫ МОЖЕШЬ СКОЛЬКО УГОДНО ГОВОРИТЬ ЧУШЬ ПРО МАШИННЫЕ КОДЫ.
Что-то я не понял — это codelord размножился или в школе клонированных детей сегодня интернет подключили?
Само по себе наличие "исполняемого файла" именно на постоянном носителе может заинтересовать разве что фетишистов.
Обычно интересует работа программы, а не то, как и когда строится исполняемый файл.
Опять же — то что JVM может интерпретировать код, не значит, что она не может его компилировать. Промышленные JVM умеют компилировать код.
Re[13]: Зачем нужен сборщик мусора? Как жить без деструкторо
Здравствуйте, PaulMinelly, Вы писали:
N>>.NET не использует подсчет ссылок. Он строит граф достижимых объектов, остальные автоматически умирают при дефрагментации.
PM>Ну и что это не подсчет ссылок, если ссылок 1 (одна) то объект оставить — если 0, то finalize. Формально, очень даже подсчет ссылок.
На счет простого подсчета ссылок. Если два объекта ссылается друг на друга, то сколько тут ссылок? Правильно, две. А если три объекта ссылаются друг на друга по кругу? Правильно, три.
Но дотнет такие ситуации разруливает очень даже просто. Именно с помошью построения графа достижимых объектов.
Re[11]: Зачем нужен сборщик мусора? Как жить без деструкторо
Здравствуйте, landerhigh, Вы писали:
D>>Неэквивалентно, бо terminate() после исключений из деструкторов, тогда как в C# никаких проблем.
L>Исключения из деструкторов бывают только в случае кривого драйвера ruki.sys,
Про то и речь. А вот Dispose() в C# может их кидать без каких-либо проблем. И поэтому Ваш C++ код не является эквивалентом моего на C#. Ваш код гораздо "глупее".
Здравствуйте, drol, Вы писали:
L>>Исключения из деструкторов бывают только в случае кривого драйвера ruki.sys, D>Про то и речь. А вот Dispose() в C# может их кидать без каких-либо проблем. И поэтому Ваш C++ код не является эквивалентом моего на C#. Ваш код гораздо "глупее".
Ну кинешь ты исключение из финализатора. И что дальше-то? Какой в этом смысл?
Sapienti sat!
Re[13]: Зачем нужен сборщик мусора? Как жить без деструкторо
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, drol, Вы писали:
L>>>Исключения из деструкторов бывают только в случае кривого драйвера ruki.sys, D>>Про то и речь. А вот Dispose() в C# может их кидать без каких-либо проблем. И поэтому Ваш C++ код не является эквивалентом моего на C#. Ваш код гораздо "глупее". C>Ну кинешь ты исключение из финализатора. И что дальше-то? Какой в этом смысл?
Не подменяйте понятия.
Dispose() и Finalize() очень даже разные методы. В общем случае они даже выполняются в разных потоках: Dispose в том потоке, где собственно ресурсы захватывались, а Finalize в потоке GC.
В кидании исключения из финализатора действительно смысла не много. А вот в кидании исключения из Dispose очень даже смысл есть.
Re[13]: Зачем нужен сборщик мусора? Как жить без деструкторо
Здравствуйте, Cyberax, Вы писали:
L>>>Исключения из деструкторов бывают только в случае кривого драйвера ruki.sys, D>>Про то и речь. А вот Dispose() в C# может их кидать без каких-либо проблем. И поэтому Ваш C++ код не является эквивалентом моего на C#. Ваш код гораздо "глупее". C>Ну кинешь ты исключение из финализатора.
Причём здесь finalizer-то ??? Dispose() это обычный метод, и вызывается в обычном контексте исполнения.
C>И что дальше-то? Какой в этом смысл?
Здравствуйте, drol, Вы писали:
C>>Ну кинешь ты исключение из финализатора. D>Причём здесь finalizer-то ??? Dispose() это обычный метод, и вызывается в обычном контексте исполнения.
Ну ладно. Кинешь исключение из Dispose(). Какой в этом смысл?
C>>И что дальше-то? Какой в этом смысл? D>См. http://www.rsdn.ru/forum/message/3047423.aspx
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, drol, Вы писали:
C>>>Ну кинешь ты исключение из финализатора. D>>Причём здесь finalizer-то ??? Dispose() это обычный метод, и вызывается в обычном контексте исполнения. C>Ну ладно. Кинешь исключение из Dispose(). Какой в этом смысл?
Да такой же как в выбрасывании любого другого исключения с любом другом месте. Сообщить вызывающему коду об исключительной ситуации.
C>И? Что мне мешает сделать то же самое из деструктора С++? C>Просто единственное ограничение — это не выбрасывать другое исключение за пределы дестркуктора.
Т.е. внятно сообщить вызывающему коду о невозможности/ощибке освобождения ресурса не получится? Или я неверно понял?
Re[10]: Зачем нужен сборщик мусора? Как жить без деструкторо
Здравствуйте, Vamp, Вы писали:
L>>На которые компилятор кричит-кричит, аж надрывается, бедный. V>А что тут такого? Совершенно нормальный код. Ты ведь, я надеюсь, в конструкторе myMember методы myClass не дергаешь? А сохранить указатель на обертывающую структуру — вполне нормально для определенного круга задач.
В том-то и дело, что ничего такого нет. Только компилятор норовит ворнинг кинуть. Что усугубляется, когда warnings are threated as errors
Re[11]: Зачем нужен сборщик мусора? Как жить без деструкторо
А>{
А> r1.open();
А> r2.open();
А> r3.open();
А> //делаем то, что хотим!!!
А> ............
А> //метод close автоматически вызовется в деструкторах
А>}
А>
А>В с++ в случаях удовлетворяющих идиоме RAII можно использовать деструкторы, в более сложных случах обработчики завершения, блоки try catch
Вообще-то, насколько я понимаю, приведенный выше код RAII как раз не соответствует, т.к. вызов open() происходит явно, а не в конструкторе. А значит (сюрпрайз!) если, например, r2.open() вызван не был, а исключение вылетело где-то на этапе r1.open(), то при выходе из блока в деструкторе r2 все равно будет произведена попытка освобождение никогда не занимавшегося им ресурса. Такая вот "красота" и "читабельность".
Но сейчас даже немного не об этом, а вот о чем: уверен ли ты, что в случае, если r1, r2, r3 станут указателями на кучу этот код будет выглядеть так же красиво, как в случае автоматических переменных? В частности ведь в точке "делаем то, что хотим" они могут, например, тупо передаваться ожидающему какого-то события объекту с более широкой областью видимости, которых должен с ними сделать что-то полезное уже сильно опосля того, как завершится данная функция. И как в этом случае будет выглядеть вся эта автоматика с деструкторами?
