LINUX.ORG.RU

Зачем нужны GC, Java, .NET?


0

0

Имеем для каждого объекта счетчик ссылок на него. Исчезает последняя ссылка --> объект удаляется. Запрещаем при этом ручную работу с указателями. Получаем то же самое, что и в Java или .NET, но без огромного оверхеда. Те же Genie или Vala работают по такому принципу, хотя там и есть возможность рулить памятью руками (но чисто опционально). При этом они не таскают за собой большую дуру под названием JVM и работают куда быстрее.

Так в чем прикол «безопасного программирования» по Сану или Микрософту в таком случае?

Ответ на: комментарий от jtootf

> может потому, что оно им является?

Т.е. если это такое осязаемое «преимущество», то на него, наверное, можно реально полагаться в разработке? Простите великодушно, но я бы за такое по е**лу бил, не стесняясь.

ты его [Кармака] исходники видел? от C и C++ там мало чего осталось


Что здесь имеется ввиду? QuakeC из первой части что ли?

mannaz
()
Ответ на: комментарий от Legioner

>Поэтому выражение «программист java на x86» почти бессмысленно. В отличие от С, естественно.

А ну-ка по-подробнее, чем си на x86 отличается от си на других архитектурах? Проблемы кретинов, приводящих указатели к int не в счёт.

legolegs ★★★★★
()
Ответ на: комментарий от anonymous

>Почему же тогда C является самым переносимым языком? потому, что C рулит. Особенно, когда написано и спроектировано всё грамотно, но чудеса бывают редко.

Например, для SQL-injection в веб-приложении.

Ничего общего с багами и недокуменнтированными функциями либ или JVM тут нет.

А если программисты такие «мудрые» что от них защищаться надо, лучше их разогнать. Пусть будут обычными дворниками - больше пользы будет.

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

Так что выбирать технологию нужно в зависимости от задачи.

qnikst ★★★★★
()
Ответ на: комментарий от mannaz

Т.е. если это такое осязаемое «преимущество», то на него, наверное, можно реально полагаться в разработке? Простите великодушно, но я бы за такое по е**лу бил, не стесняясь.

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

jtootf ★★★★★
()
Ответ на: комментарий от anonymous

Присваивать ссылке новое значение не принято

«нельзя». правильно это называется «нельзя». тот факт, что в C++ любое правило можно поломать cast'ами, как аргумент использовать несколько невыгодно

Арифметика по ссылкам выполняется еще как. Например, при вызове функций-членов класса

ты вот это сейчас серьёзно написал? ты правда считаешь, что разницы никакой, и вызов функции-члена можно считать случаем использования «ссылочной арифметики»?

Единственное исключение - это указатели как частный случай итераторов

ну так я тебя обрадую - любой указатель является итератором. а ссылка - не является. о чём, собственно, и речь

jtootf ★★★★★
()
Ответ на: комментарий от jtootf

> извини, но ни хрена не понял, что ты тут хотел сказать

Ты пьян?

jtootf> ...использование GC при избытке хип-памяти может повысить производительность приложения...

mannaz> Забавно, ты озвучил следствие из основного недостатка GC, а преподнес его как преимущество.

jtootf> может потому, что оно им является?

mannaz> Т.е. если это такое осязаемое «преимущество», то на него, наверное, можно реально полагаться в разработке?

P.S. Так что с исходниками Кармака, в которых «от C и C++ там мало чего осталось»?

mannaz
()
Ответ на: комментарий от mannaz

Ты пьян?

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

что ты понимаешь под словом «полагаться», и кому ты собрался бить, гм, морду - это уже твоё личное дело. если технологии разработки вызывают в тебе такую реакцию - что ж, возможно валерианка тебе поможет

P.S. Так что с исходниками Кармака, в которых «от C и C++ там мало чего осталось»?

не так давно здесь же обсуждали выход первого #fprog, и пришли к выводу, что на практике ФП используется исключительно для построения DSL'ей. так вот в кваках - чистой воды DSL, что вынесенный отдельно как QuakeC в первой части, что оставленный внутри в остальных. чтобы работать в комманде программистов Quake, надо уже учить не C или C++ - надо учить Quake

jtootf ★★★★★
()
Ответ на: комментарий от jtootf

Ладно, забей. Демагогия в ответ на конкретные вопросы меня мало интересует.

чтобы работать в комманде программистов Quake, надо уже учить не C или C++ - надо учить Quake


Вот это откровение. Что-то аргументация вбросов у тебя страдает последнее время :(

mannaz
()
Ответ на: комментарий от legolegs

А ну-ка по-подробнее, чем си на x86 отличается от си на других архитектурах?

Знанием особенностей аппаратной платформы (размеры и прочее, intptr_t тоже не так просто придумали), компилятора (не gcc единым живёт этот мир), особенностей реализации посикса (если он вообще есть), особенностей реализации того, что в посикс не вошло.

Legioner ★★★★★
()
Ответ на: комментарий от mannaz

Ладно, забей. Демагогия в ответ на конкретные вопросы меня мало интересует.

а, так это были конкретные вопросы? извини, не узнал в гриме

Что-то аргументация вбросов у тебя страдает последнее время :(

старею :(

jtootf ★★★★★
()
Ответ на: комментарий от jtootf

>так вот в кваках - чистой воды DSL

Это ты о т.н. idScript? В игровом коде ETQW (tech4), его всего 18% относительно остального кода. А в самом tech4, он вообще не используется.

надо уже учить не C или C++ - надо учить Quake


То что ты называешь «Quake», изучается очень быстро, в сравнении с C++, просто мгновенно.

чтобы работать в комманде программистов Quake


Strong math & Expert C++. Это из вакансии. Знание «Quake», там - необязательное требование.

summatus
()
Ответ на: комментарий от summatus

>Strong math & Expert C++. Это из вакансии. Знание «Quake», там - необязательное требование.

Какое это отношение вообще имеет к топику? Что касательно Quake*, то там потребностей в динамической памяти нет совсем. Ну то есть уровень загружается целиком в память, и после этого рендерится с разных позиций X раз в секунду. К типичным задачам это отношения не имеет. Вот к написанию редактора уровней и всего тулчейна побочных утилит - да, имеет.

Absurd ★★★
()
Ответ на: комментарий от legolegs

>Я прямо вижу, как ты записываешь себе в блокнотик: «похожесть на java: 3+»

Да я не фан жавы. Конечно, С++ порождает много фана вокруг себя, но другие языки этого не требуют и это наверно трудно понять. Жаба - надежная рабочая лошадка, не более того.

Absurd ★★★
()
Ответ на: комментарий от jtootf

> «нельзя». правильно это называется «нельзя». тот факт, что в C++ любое правило можно поломать cast'ами, как аргумент использовать несколько невыгодно

Не нравится - не пользуйся. Нет таких правил, которые нельзя нарушить, если очень надо.

ты вот это сейчас серьёзно написал? ты правда считаешь, что разницы никакой, и вызов функции-члена можно считать случаем использования «ссылочной арифметики»?

А что ты вообще считаешь «арифметикой»? Я имел ввиду ситуацию, когда к адресу прибавляется смещение. При вызове функции-члена по ссылке это происходит. Тебя не устраивает, что в синтаксисе нет «+ чтонибудь»?

ну так я тебя обрадую - любой указатель является итератором. а ссылка - не является. о чём, собственно, и речь

То есть ты назвал доступ к элементам последовательности с помощью итератора «адресной арифметикой»? Это же очевидный бред.

И не любой указатель является итератором. Например, указатель на базовый класс, указывающий на производный большего размера. Как раз тот случай, когда сходство T& и T* очевидно. Прибавлять к нему что-то нет смысла - он будет указывать хрен знает куда в любом случае.

Или ты назовешь итератором любую сущность с перегруженным набором операций? Тогда вот это тоже итератор:

struct fail_iterator : public std::vector<int>::iterator { operator -> () { throw; } operator * () { throw; } };

Согласен с этим?

anonymous
()
Ответ на: комментарий от Legioner

> Чистый Java код не зависит от архитектуры вообще никак. Поэтому выражение «программист java на x86» почти бессмысленно. В отличие от С, естественно.

«Чистого» Java кода не бывает. Он в любом случае использует библиотеки и оказывается завязан на платформу, под которой они есть.

На днях попалась на глаза книга про Java Card - это такие карточки с 5МГц процессорами и предельно обрезанной JVM. Так там даже GC может не быть. А библиотек нет тем более. Код должен писаться так, чтобы быть готовым к отключению питания в любой момент. Какой смысл называть это Java? Там от нее только байткод.

От того, что есть зоопарк JVM на разных платформах, Java программы кроссплатформенными не становятся.

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

Я раньше несколько лет пользовался КПК на WinMobile. Софта для нее было море, устанавливай чего хочешь. А вот Java машины не было. Ходили слухи, что есть какая-то от noname производителя и платная. Но мне найти так и не удалось.

Если не ограничиваться телефонами, открытых устройств полно. Например, роутеры и сетевые диски вроде WD World Edition. Java на них не видел ни разу.

anonymous
()
Ответ на: комментарий от Legioner

> > В таком варианте определения GC среды текут всегда, пока хватает памяти.

Почему? Освобождение - по сути переиспользование. GC будет переиспользовать память, которая больше не нужна. Т.е. можно считать, что память освобождается тут же, как только теряется последняя ссылка на неё.

Это видно только самому GC. Если он считает, что свободной памяти еще много, а программа успевает отработать до конца - то вся выделенная ей память по твоему определению «утекла».

Тут не так просто подобрать подходящее определение.

anonymous
()
Ответ на: комментарий от Legioner

> Тут тоже чудес не бывает, угадывать, что программисту больше этот объект не нужен, компьютер не умеет. К платформе, это всё-таки отношения не имеет, это проблемы конкретной программы.

Поэтому люди и спрашивают, в чем выгода от «безопасного программирования по XXX». Какие проблемы оно решает, если программисту все равно надо думать самому?

anonymous
()
Ответ на: комментарий от anonymous

>Полноценные реализации JVM доступны только для x86

интересно, как к этому утверждению отнесутся парни из IBM, продающие мейнфреймы и AIX-ы

maloi ★★★★★
()
Ответ на: комментарий от anonymous

Поэтому люди и спрашивают, в чем выгода от «безопасного программирования по XXX».

Буду сравнивать конкретно Java SE (а не Java ME, чудо на микрокартах или что там ещё придумали) и С (компилируемый gcc).

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

2. Программа на джаве содержит эффективный GC. На С можно использовать консервативный GC, но он хуже GC явы (потому что С не даёт и не может давать сборщику мусора тех гарантий, которые даёт Java). И вообще в GC явы (конкретно сановский) вбухано достаточно много миллионов, диссертаций и времени, чтобы считать его хорошим.

3. Для программы можно строить песочницу - разрешая или запрещая практически любые взаимодействия с внешним миром. Для С аналог делается только с поддержкой ядра ОС - виртуализации, неймспейсов и прочего. Это позволяет, например, выполнять апплеты в браузере, не опасаясь того что они сделают «rm -rf /», или что угодно за пределами того прямоугольника, где им разрешили рисовать.

4. Java программа кроссплатформенна, если в ней не используются native библиотеки. Если Java-машина на целевой платформе существует, значит Java-программа там будет работать. Это один из основных принципов джавы (write once, run everywhere).

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

>Знанием особенностей аппаратной платформы (размеры и прочее, intptr_t тоже не так просто придумали)

И что-же тебе надо знать из особенностей платформы (если ты пишешь не ОС и не драйвер)? Размеры? А зачем? есть sizeof() и что бы он ни вернул программа должна компилироваться и работать. Если тебе нужно 32хбитное целое - ты обязан использовать int32_t, а не городить лестницу из #ifdef x86 #define myint long #elif x86_64 #define myint int #elif x86_128 #define myint short #endif

А проблемы с компилятором и средой исполнения на практике у java те-же самые.

legolegs ★★★★★
()
Ответ на: комментарий от Legioner

>Программа на джаве всегда работает корректно. Она не может упасть

В стране эльфов - может быть. В реальном мире хорошее приближение к явовской надёжности даётся скриптом while ! ./program ; do echo Unhandled exception ; done

Если Java-машина на целевой платформе правильной версии и от правильного вендора, значит Java-программа там скорее всего будет работать без бубна.

legolegs ★★★★★
()
Ответ на: комментарий от legolegs

>И что-же тебе надо знать из особенностей платформы (если ты пишешь не ОС и не драйвер)? Размеры? А зачем? есть sizeof() и что бы он ни вернул программа должна компилироваться и работать.

Ага. Это в сферическом вакууме. А на практике, переносишь программу на другую платформу и опа!

Waterlaz ★★★★★
()
Ответ на: комментарий от anonymous

А что ты вообще считаешь «арифметикой»?

то же, что и все остальные люди. у этого слова определение есть, вообще говоря

То есть ты назвал доступ к элементам последовательности с помощью итератора «адресной арифметикой»

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

Или ты назовешь итератором любую сущность с перегруженным набором операций?

я называю итератором любую сущность, удовлетворяющую концепту итератора. ты, судя по всему, не понимаешь, что это такое: в приведённом тобой примере std::vector<int>::iterator никоим образом не обязан быть типом, от которого можно отнаследоваться

jtootf ★★★★★
()
Ответ на: комментарий от summatus

То что ты называешь «Quake», изучается очень быстро, в сравнении с C++, просто мгновенно.

значит хорошо написали :) этого я никоим образом не отрицаю

jtootf ★★★★★
()
Ответ на: комментарий от maloi

> интересно, как к этому утверждению отнесутся парни из IBM, продающие мейнфреймы и AIX-ы

Подскажите где можно скачать мейнфреймы и AIX, желательно с исходниками (я параноик). Если платно - то не дороже 10 рублей с оплатой по СМС :3

Иначе это называется «недоступны».

А где-то выше уже давали ссылки на embedded сборки для разных архитектур. Хотя на месте embedded разработчика я бы пожадничал 60-80 мегабайт на JVM. Нету под нее столько софта, чтобы это имело смысл.

anonymous
()
Ответ на: комментарий от jtootf

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

Ты можешь сложить 2 указателя и получить новый указатель? Надо же, я старался, но так и не смог. Кстати, зачем это тебе нужно?

я называю итератором любую сущность, удовлетворяющую концепту итератора. ты, судя по всему, не понимаешь, что это такое: в приведённом тобой примере std::vector<int>::iterator никоим образом не обязан быть типом, от которого можно отнаследоваться

Ну не писать же мне полный интерфейс random-access. Если так хочется скомпилировать - замени vector на map. На вопрос ты так и не ответил - считаешь ли ты итератором сущность с интерфейсом итератора, но с ГАРАНТИРОВАННО бессмысленным поведением?

Заодно расскажи, какой смысл ты вкладываешь в использование указателя на полиморфный класс как итератора. Если ты еще не забыл, речь о эквивалентности T* и T& шла в этом контексте.

anonymous
()
Ответ на: комментарий от anonymous

Ты можешь сложить 2 указателя и получить новый указатель?

вычесть могу, и сложить с числом могу. кончай шланговать, ну:

http://serc.iisc.ernet.in/ComputingFacilities/systems/cluster/vac-7.0/html/language/ref/clrc03ptarith.htm

Ну не писать же мне полный интерфейс random-access

это-то тут при чём? да и не интерфейс это, во всяком случае - не ООП-шный интерфейс

Если так хочется скомпилировать - замени vector на map

это ничего не меняет

считаешь ли ты итератором сущность с интерфейсом итератора, но с ГАРАНТИРОВАННО бессмысленным поведением?

на этот вопрос ответил не я, а Александр Степанов, активно используя обобщённое программирование в STL. да, любая сущность, удовлетворяющая концепту итератора, будет итератором; что входит в описание этого концепта (в частности, какие требования накладываются на семантику) у того же Степанова можно почитать

более сложные концепты, построенные по тому же принципу, используются в BGL

Заодно расскажи, какой смысл ты вкладываешь в использование указателя на полиморфный класс как итератора

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

jtootf ★★★★★
()
Ответ на: комментарий от Legioner

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

Что-то это мне напоминает. Кажется, это была основная причина разделения user/kernel и появления виртуальной памяти в современных ОС. Одно неясно - зачем еще один промежуточный слой в виде JVM?

2. Программа на джаве содержит эффективный GC. На С можно использовать консервативный GC, но он хуже GC явы (потому что С не даёт и не может давать сборщику мусора тех гарантий, которые даёт Java). И вообще в GC явы (конкретно сановский) вбухано достаточно много миллионов, диссертаций и времени, чтобы считать его хорошим.

«Программы с GC быстрее программ без GC». Не убедительно.

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

3. Для программы можно строить песочницу - разрешая или запрещая практически любые взаимодействия с внешним миром. Для С аналог делается только с поддержкой ядра ОС - виртуализации, неймспейсов и прочего. Это позволяет, например, выполнять апплеты в браузере, не опасаясь того что они сделают «rm -rf /», или что угодно за пределами того прямоугольника, где им разрешили рисовать.

Некорректно сравнивать с С в этом смысле. Java тоже нужна поддержка JVM, которая по сути «виртуальная ОС». Sandbox - это дело ядра ОС в любом случае.

А Java-апплеты как-то не прижились - менее идеологичный flash сожрал их вместе с ActiveX. А других очевидных применений sandbox в Java в голову не приходит.

4. Java программа кроссплатформенна, если в ней не используются native библиотеки. Если Java-машина на целевой платформе существует, значит Java-программа там будет работать. Это один из основных принципов джавы (write once, run everywhere).

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

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

Так что преимущества скорее теоретические. А есть ли у Java практические, специфичные именно для managed - сред преимущества? Например, легкость построения компиляторов в байткод?

anonymous
()
Ответ на: комментарий от jtootf

>> Ты можешь сложить 2 указателя и получить новый указатель?

вычесть могу, и сложить с числом могу. кончай шланговать

Вычесть и получить новый указатель? Какая у тебя нетрадиционная арифметика.

А итератор random access я тоже могу сложить с числом. Но указателем он от этого не станет. Как и указатель на полиморфный класс - итератором, не смотря на «соответствие концептам». Ты вообще видишь разницу между синтаксисом выражения и его смыслом?

на этот вопрос ответил не я, а Александр Степанов, активно используя обобщённое программирование в STL. да, любая сущность, удовлетворяющая концепту итератора, будет итератором

Надо же, С++ в больших количествах действительно вреден. Или ты перебрал с веществами, как Степанов при разработке STL?

Программисты на других языках определяют итератор иначе. В Design Patterns итератор показан на классе с методами next() и get(), а в Higher Order Perl - это функция. И что, они перестали быть итераторами?

Читай больше, и не только про С++. Вредно не знать основ и лезть в STL - из-за таких программистов любители Java и C# считают что С++ используют только дебилы.

anonymous
()
Ответ на: комментарий от anonymous

Вычесть и получить новый указатель? Какая у тебя нетрадиционная арифметика.

talking to yourself is a bad habit for a dungeoneer. не надоело?

А итератор random access я тоже могу сложить с числом. Но указателем он от этого не станет

и что? тот факт, что у ссылок и указателей в C++ принципиально разная семантика, от этого как-то меняется?

Как и указатель на полиморфный класс - итератором, не смотря на «соответствие концептам»

то есть про концепт ты ни хрена не понял? ну попробуй почитать, что ли, это совсем не больно. я подожду

Вредно не знать основ и лезть в STL - из-за таких программистов любители Java и C# считают что С++ используют только дебилы.

что точно вредно - так это пытаться спорить о вещах, в которых ты не разбираешься. STL написан не на Java и не на C# - и то, что ты не понимаешь принципов, лежащих в его основе, выставлет в не очень хорошем свете только тебя самого. хотя пассаж в сторону «программистов на других языках» зачётен и очень уместен, да. офигенно уместен. я тоже так всегда буду говорить - а вот в %languagename% они всё делают по-другому, значит и тут так надо

вообще круто, конечно, затеять спор об «эквивалентности укзателей и ссылок», и походу слить не только эту тему, но ещё пару штук за компанию. высокое искусство, я так не умею :(

jtootf ★★★★★
()
Ответ на: комментарий от anonymous

и да, я всё-таки хочу увидеть примеров заявленной эквивалентности - кода, корректно обрабатывающего «нулевую ссылку», и использования «ссылочной арифметики» (с любыми приведениями типов, оставляющих ссылку ссылкой). может я и правда не знаю C++, а ты мне откроешь глаза

jtootf ★★★★★
()
Ответ на: комментарий от jtootf
struct A {};

void f(unsigned char * p)
{
    *(p + 1);
}

void g(void * p)
{
    if(p == 0)
    {
        std::cout << "null pointer" << std::endl;
    }
}

...


A * obj = new A;
A * obj2 = 0;

f(reinterpret_cast<unsigned char *>(&obj));
g(obj2);

демонстрировать эквивалентность можно на примере этого кода. если ты, конечно, не против

jtootf ★★★★★
()
Ответ на: комментарий от anonymous

Что-то это мне напоминает. Кажется, это была основная причина разделения user/kernel и появления виртуальной памяти в современных ОС. Одно неясно - зачем еще один промежуточный слой в виде JVM?

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

Разные программы (вообще разные) и разные модули одной программы - сильно разные вещи.

«Программы с GC быстрее программ без GC». Не убедительно.

Не нужно мне приписывать не мои слова. Быстрее или медленнее - зависит в каждом конкретном случае. Я говорю конкретно про gc, когда он есть, и про то, что сановский GC лучше сишного (Boehm GC например).

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

Не знаю, может такой оригинальный способ продвижения своей виртуальной машины (если это IBM или Weblogic какой).

Некорректно сравнивать с С в этом смысле. Java тоже нужна поддержка JVM, которая по сути «виртуальная ОС». Sandbox - это дело ядра ОС в любом случае.

Какая разница - виртуальная ОС или нет. Важен результат и то, что можно это делать.

А Java-апплеты как-то не прижились - менее идеологичный flash сожрал их вместе с ActiveX. А других очевидных применений sandbox в Java в голову не приходит.

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

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

У меня в линуксе работают без глюков Squirrel SQL, Eclipse, Azureus, некоторый проприетарный софт для разработки. Внешний вид устраивает (кроме может Swing-овского Squirrel-а, но использовать можно).

А если любая программа не из под рута рушит X сервер, это баг X сервера, а не программы, вам не кажется?

Так что преимущества скорее теоретические. А есть ли у Java практические, специфичные именно для managed - сред преимущества? Например, легкость построения компиляторов в байткод?

Ну байткод у джавы простой, может даже чересчур простой. Наверное компилировать в его байткод проще чем в машинный код, хотя есть LVM, gcc backend, mono, и я не буду утверждать что лучше а что хуже.

Legioner ★★★★★
()
Ответ на: комментарий от jtootf

> talking to yourself is a bad habit for a dungeoneer. не надоело?

Что, уже пора тыкать в твои же посты на прошлой странице? Не надолго же тебя хватило.

и что? тот факт, что у ссылок и указателей в C++ принципиально разная семантика, от этого как-то меняется?

Я тебе уже три раза объяснял, что в контексте выбора между T*, T& и кучей смартпоинтеров семантика одна и та же, синтаксис разный.

то есть про концепт ты ни хрена не понял? ну попробуй почитать, что ли, это совсем не больно. я подожду

При чем тут концепт? Опять путаешь семантику с синтаксисом?

ОК, объясняю еще раз. Итератор - сущность для доступа к элементам последовательности. Интерфейс при этом может быть любой.

Концепты - вещь специфичная для C++. Итераторы есть везде. В С++ тоже есть итераторы, не соответствующие концепту. Например, Java-style итераторы в контейнерах QT.

что точно вредно - так это пытаться спорить о вещах, в которых ты не разбираешься.

Ты - отличный тому пример. Не делай так больше.

вообще круто, конечно, затеять спор об «эквивалентности укзателей и ссылок», и походу слить не только эту тему, но ещё пару штук за компанию. высокое искусство, я так не умею :(

Да-да, аутотренинг это наше все. Усердно тренируйся, и ты сможешь поверить в десяток невозможностей еще до завтрака :3

anonymous
()
Ответ на: комментарий от jtootf

Будет код, куда же он денется. Легким движением скрываем разницу в синтаксисе указателей и ссылок - и они работают совершенно одинаково.

#include <iostream>

struct A {};

void f(unsigned char * p) { *(p + 1); }

void g(void * p) {
  if(p == 0) {
    std::cout << "null pointer" << std::endl;
  }
}

template<class T> T * syntax_adapter (T * t) { return  t; }
template<class T> T * syntax_adapter (T & t) { return &t; }

int main() {
  A * obj = new A;
  A * obj2 = 0;

  f(reinterpret_cast<unsigned char *>(&obj));
  g(obj2);

  // -------------------------------
  A & ref  = *obj;
  A & ref2 = *obj2;

  f(reinterpret_cast<unsigned char *>( syntax_adapter(ref) ));
  g(syntax_adapter(ref2));

  // -------------------------------
  A * ptr  = new A;
  A * ptr2 = obj2;

  f(reinterpret_cast<unsigned char *>( syntax_adapter(ptr) ));
  g(syntax_adapter(ptr2));
}
anonymous
()
Ответ на: комментарий от anonymous

facepalm.mpeg...

анон, это все равно что утвержать, что семантически «+» и "-" это одно и то же. Потому, что видите ли, можно вместо a - b записать a + (-b).

Waterlaz ★★★★★
()
Ответ на: комментарий от Legioner

> Какая разница - виртуальная ОС или нет. Важен результат и то, что можно это делать.

Ну тогда получается, что сравнивать Java и C/С++ вообще некорректно.

Можно сравнивать синтаксис языка Java и инструменты разработки для него с C/C++ аналогами. Можно сравнивать JVM с другими ОС, виртуальными или «железными». И GC тогда аналог не «ручного выделения/освобождения», а всей подсистемы памяти в обычных ОС.

Однозначно сказать, что одно хуже другого нельзя - это зависит от задачи, навыков программиста и других неявных факторов. И выбор платформы, если он вообще есть, делается не из технических соображений. А из любви/ненависти к M$/Sun/Adobe или расчете на аутсорсинг в ИндоКитай.

Вроде логично.

anonymous
()
Ответ на: комментарий от Waterlaz

> анон, это все равно что утвержать, что семантически «+» и "-" это одно и то же. Потому, что видите ли, можно вместо a - b записать a + (-b).

Ты можешь определить «+» в терминах "-" и наоборот. Используя это, ты спрятал "-" в скобки и выбросил 0. Но не значит что «+» и "-" одно и то же.

А T* и T& одно и то же - это две разных формы синтаксиса для косвенного обращения. Но синтаксис T& соответствует типу T, а T* заставляет пользоваться оператором "->".

anonymous
()
Ответ на: комментарий от anonymous

Легким движением скрываем разницу в синтаксисе указателей и ссылок

ничего ты не скрыл, чудо. операция получения адреса что угодно превратит в указатель. ТЗ читать не умеем, да?

с любыми приведениями типов, оставляющих ссылку ссылкой

ты доказал тот факт, что указатель ведёт себя как указатель - это очень ценно, но не имеет отношения к делу. если у нас будет вот такой код:

void g(SomeType & p) { 
  if(check(p)) { 
    std::cout << "null reference" << std::endl; 
  } 
} 

как ты напишешь функцию check, пользуясь только семантикой ссылки (т.е. без привязки к SomeType), и как ты будешь пользоваться этим механизмом?

jtootf ★★★★★
()
Ответ на: комментарий от anonymous

Ты можешь определить «+» в терминах "-" и наоборот

определи мне ссылочный аналог для void *

jtootf ★★★★★
()
Ответ на: комментарий от Sectoid

Это не быдлокод, это диверсия. Почти как #define while if

legolegs ★★★★★
()
Ответ на: комментарий от Waterlaz

>А на практике, переносишь программу на другую платформу и опа!
Что опа?

Платформенно-независимые программы на С++ с винды на юникс переносятся элементарно простой перекомпиляцией без всяких «опа».
«Опа» происходит если альернативно-одарённые программисты пишут

int r = (int)&a;

anonymous
()
Ответ на: комментарий от anonymous

>Платформенно-независимые программы на С++ с винды на юникс переносятся элементарно простой перекомпиляцией без всяких «опа».

Знаешь чтор ты тут написал?

«Если программа переносится только лишь перекомпиляцией, то она переносится перекомпиляцией» Я очень рад и спорить не буду.

Ситуаций, когда происходит «Опа» достаточно много. Да они возникают от плохого стиля программирования. Но в Си они сплошь и рядом, а в Жабе их нет.

ЗЫ нет ну серьезно. Есть немало примеров, когда софт(опен сорс) появился на х64 не сразу и, например, генту собирала 32битные либы специально под них.

Waterlaz ★★★★★
()
Ответ на: комментарий от Waterlaz

>Есть немало примеров, когда софт(опен сорс) появился на х64 не сразу

Самое удивительное, что у жабософта тоже были такие проблемы.

legolegs ★★★★★
()

Я тоже не понимаю ценности GC. Конечно я заблуждаюсь, подкиньте инфы для просветления. Циклические ссылки? Действительно зачем ссылка на ссылку? Я конечно не скажу, что GC это вселенское зло, но если идёт интенсивное выделение памяти, и очень часто работает GC? И если таких программ сотни? Я понимаю, что прогресс не стоит на месте, и что машиное время дёшево, но всё-же.

Booster ★★
()

Кстати в GC тоже приколы и подводные камни. По сути это отложенное разрушение объекта, с возможностью утечек ресурсов отличных от памяти. Я однажды с такой хренью сталкнулся в .Net, где приходилось метод очистки вручную вызывать.

Booster ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.