Как технарю из России стать программером в США за 150К

[ddv]

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

Нет нельзя их выбрасывать, потому что любой может их вызвать через reflection

И почему RTTI/metadata и машинный код - вещи совершенно параллельные и слабо друг от друга зависимые.

Это в С++ они паралелльные, а для .NET это основная информация.

[Zombie416]

Нет нельзя их выбрасывать, потому что любой может их вызвать через reflection

reflection на private методы может и не работать.

Это в С++ они паралелльные, а для .NET это основная информация.

В нативно откомпилированном C++ просто metadata победнее.

И опять-таки не надо противопоставлять C++ и .NET, это апельсины и яблоки. C++/CLR - вполне себе нормальный компилятор, настолько же стандартный насколько это вообще возможно у майкрософтовских компиляторов. Только что код не x86 выплевывает, а более нечто более portable и с более развитыми средствами динамической компоновки.

[ddv]

Нет нельзя их выбрасывать, потому что любой может их вызвать через reflection

reflection на private методы может и не работать.

Работает - я пробовал.

[Zombie416]

Работает - я пробовал.

Рантаймов может быть великое множество, оптимизировать они могут совершенно по-разному, и что reflection над private частями работает никто не обещал. В Silverlight, например, не будет работать.

[crypto5]

Я не знаю..

Давайте докажем такую возможность от противного. Предположим что его нельзя написать на С++. Но ведь java VM написана на asm/C/C++...из этого следует что и этот memory manager тоже написан на смеси этих языков...из чего следует что его можно было бы применить и в С++, а это противоречит изначальному условию что его нельзя написать на С++.
Значит его можно написать на С++.

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

Теперь по поводу полезности такого memory manager в С++. Предположим что он ооочень полезен для С++...тогда наверняка его уже кто нибудь написал бы за столько лет. Значит он уже или есть и мы просто незнаем,т.к. мы у нас нет документации на описание такого memory manager....или он просто бесполезен и поэтому его никто не пишет. Тут конечно не точное логическое доказательтво, но , по моему, более вероятное чем предположение о том, что все такие тупые и ленивые что не могут реализовать такой полезный memory manager для С++.

Я читал где то про такие реализации, но они были интегрированы с конкретной библиотекой тредов, видимо не соответствовали каким то стандартам, и обычному С++ программисту юзающему glibc видимо бесполезны.

Что в моих словах вам кажется не логичным?

Нет!

[ddv]

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

Менеджер памяти жестко завязан на операционную систему и архитектуру процессора, поэтому реализация нитей ему тоже известна.

[crypto5]

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

Менеджер памяти жестко завязан на операционную систему и архитектуру процессора, поэтому реализация нитей ему тоже известна.

Мой профанский взгляд заключается в том что вы счас нафантазировали.
Но и кроме того я привел еще две причины из-за которых в С++ могут возникнуть трудности с таким менеджером памяти.

[crypto5]

А, вот нашел, фейсбук таким занимался:

[ddv]

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

Менеджер памяти жестко завязан на операционную систему и архитектуру процессора, поэтому реализация нитей ему тоже известна.

Мой профанский взгляд заключается в том что вы счас нафантазировали.

Т.е. вы считаете что необходимые ЛЮБОМУ memory manager выделения памяти у операционной системы, mutexes, events, atomic operations и т.п. не зависят от операционной системы и архитектуры процессора? А если зависят - значит он жестко привязывается к архитектуре. Можно написать кроссплатформенный, но в любом случае он должен будет в каждом конкретном случае использовать специфические вызовы системы.

[crypto5]

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

Менеджер памяти жестко завязан на операционную систему и архитектуру процессора, поэтому реализация нитей ему тоже известна.

Мой профанский взгляд заключается в том что вы счас нафантазировали.

Т.е. вы считаете что необходимые ЛЮБОМУ memory manager выделения памяти у операционной системы, mutexes, events, atomic operations и т.п. не зависят от операционной системы и архитектуры процессора? А если зависят - значит он жестко привязывается к архитектуре. Можно написать кроссплатформенный, но в любом случае он должен будет в каждом конкретном случае использовать специфические вызовы системы.

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

[zzhou]

И по вашему его невозможно реализовать на С++?

На С++ всё можно реализовать. Но только в Яве оно уже есть. Уже работает. Во всех приложениях.

Т.е. написать библиотеку умных указателей на С++ можно. Я уверен что многие сишники за неё радостно возьмутся - в рамках разработки рабочего места кассира. И угробят на доводку этого менеджера памяти времени больше чем на само рабочее место кассира.

И их реализация всё равно будет глючить и тормозить по сравнению с реализации в JVM. Которая работает в любой программе на Яве.

[ddv]

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

А как же POSIX thread APIs?

А, вот нашел, фейсбук таким занимался: http://www.facebook.com/notes/facebook- ... 0222803919.

Только похоже что даже они сами после их исследований так до конца не поняли помогает это или нет.

[crypto5]

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

А как же POSIX thread APIs?

Вы осчусчаете разницу между словами АПИ и детали реализации?

А, вот нашел, фейсбук таким занимался: http://www.facebook.com/notes/facebook- ... 0222803919.
Только похоже что даже они сами после их исследований так до конца не поняли помогает это или нет.

Ну вам виднее конечно, как всегда впрочем,как я вижу.

[ddv]

На С++ всё можно реализовать. Но только в Яве оно уже есть. Уже работает. Во всех приложениях.

Так в С++ тоже все работает...а то что другой memory manager может существенно повысить производительность это еще надо доказать.
Такой memory manager в JVM просто сглаживает падение производительности вызванное GC, и ни каких приимуществ по сравнению с С++ не дает.

[crypto5]

На С++ всё можно реализовать. Но только в Яве оно уже есть. Уже работает. Во всех приложениях.

Так в С++ тоже все работает...а то что другой memory manager может существенно повысить производительность это еще надо доказать.
Такой memory manager в JVM просто сглаживает падение производительности вызванное GC, и ни каких приимуществ по сравнению с С++ не дает.

Ну у вас опять я вижу информация из первых рук