Фичи Java-ы и .Net-а (указатели, шаблоны и т.д.) [Re: А какие]
> Указатели - это просто ненужный гемор.
Если захочется написать эффективную свою hash-таблицу, или эффективый на твоих данных сборщик мусора, то это уже не так.
Если захочется написать эффективную свою hash-таблицу, или эффективый на твоих данных сборщик мусора, то это уже не так.
может, ты и прав, хехе. Но мне и в голову не придет писать подобные вещи. Меня решения от сана вполне устраивают 
да, кстати, может, не совсем точно выражусь, но в джаве все по ссылке передается.
Расскажи, плиз, зачем вообще нужны голые переменные (а не указатели на них)?
Расскажи, плиз, зачем вообще нужны голые переменные (а не указатели на них)?
Допустим тебе необходимо работать с матрицей чисел, посчитай затраты по памяти и по быстродействию для случая, когда эти числа хранятся по ссылке (а так приходится делать в Java) или когда эти числа напрямую хранятся в памяти (т.е. хранится массив чисел, а не массив ссылок на числа).
в этом ты прав. О таких задачах я уже позабыл 
.
Но надо отметить, что в основной области применения Java она со своими задачами отлично справляется (потому что применяется в области веб-решений) и гораздо удобней, чем С++ (который в своей области десктопных решений тоже справляется).
Т.е. если микроскопом не забивать гвоздей, а использовать все по назначению, то джава удобней.
.Но надо отметить, что в основной области применения Java она со своими задачами отлично справляется (потому что применяется в области веб-решений) и гораздо удобней, чем С++ (который в своей области десктопных решений тоже справляется).
Т.е. если микроскопом не забивать гвоздей, а использовать все по назначению, то джава удобней.
Недавно пришлось вернуться к С++. Указатели - это просто ненужный гемор.
Можно подумать, что в Java нет указателей!.. Смешно...
Допустим тебе необходимо работать с матрицей чисел, посчитай затраты по памяти и по быстродействию для случая, когда эти числа хранятся по ссылке (а так приходится делать в Java)
А почему собственно на хранить в Яве массив чисел? int[] matrix; ... matrix[x*size+y]...
1) гон, в джаве параметры по значению передаются
2) ссылки могут ссылаться только на объекты в куче, а в стеке можно хранить только примитивные типы
редко, но случается так, что 1) и 2) сильно ограничивают
думаю лучше всего сделала майкрософт: если нужны указатели, темплейты (сила!) и проч., то пиши на с++ (если тебе все равно, что код не fully trusted а где имеет смысл на с# (gui, ...). при этом на с# пишется прекрасно >90% кода
2) ссылки могут ссылаться только на объекты в куче, а в стеке можно хранить только примитивные типы
редко, но случается так, что 1) и 2) сильно ограничивают
думаю лучше всего сделала майкрософт: если нужны указатели, темплейты (сила!) и проч., то пиши на с++ (если тебе все равно, что код не fully trusted а где имеет смысл на с# (gui, ...). при этом на с# пишется прекрасно >90% кода
нет в джаве указателей (есть ссылки, думаю, можно сказать, что они частный случай указателей)
темплейты (сила!)
, установишь и увидишь, что теперь и в C# сила есть
если нужны указатели ... пиши на с++
на C# в unsafe есть указатели, правда, урезенные, сам с ними не работал.....
гон, темплейты и дженерики совсем разные вещи
поэтому нужен vc++2005 для полного счастья (там есть и то и другое)
поэтому нужен vc++2005 для полного счастья (там есть и то и другое)
в чем принципиальная разниза то? (сам еще не разбирался )
)template-ы не очень хорошо дружат с .Net-классами
> template-ы не очень хорошо дружат с .Net-классами
Беру свои слова обратно.
Vc2005 съел даже такую конструкцию:
Беру свои слова обратно.
Vc2005 съел даже такую конструкцию:
ref class A
{
public:
void G
{
Console::WriteLine("A");
}
};
template<typename T>
ref class B:T
{
public:
void F
{
G;
Console::WriteLine("B");
}
};
int _tmain
{
(gcnew B<A>->F;
}
если коротко, то
1) разная реализация (если так можно сказать)
2) темплейт - это шаблон типа (на синтаксическом уровне)
по темплейту тип создается только когда в темплейт подстанавливаются параметры:
так vector<int> дает класс, который получается если взять исходный код темплейта vector и заменить вхождения параметра темплейта на int
дженерик класс - это отдельный самостоятельный тип, поэтому если ты можешь работать с объектами типа параметра дженерика только как с объектами Object + то что ты укажешь в where
1) разная реализация (если так можно сказать)
2) темплейт - это шаблон типа (на синтаксическом уровне)
по темплейту тип создается только когда в темплейт подстанавливаются параметры:
так vector<int> дает класс, который получается если взять исходный код темплейта vector и заменить вхождения параметра темплейта на int
дженерик класс - это отдельный самостоятельный тип, поэтому если ты можешь работать с объектами типа параметра дженерика только как с объектами Object + то что ты укажешь в where
просто темплейты - это чисто синтаксическая примочка VC++ компилятора, поэтому в il будут все используемые варианты темплейта отдельными классами
здорово, что теперь компиятор поддерживает эту фичу
здорово, что теперь компиятор поддерживает эту фичу
кстати пример darkgrey нельзя сделать с помощью дженериков, нужно будет делать методы виртуальными -- так уж эти дженерики реализованы (STL, ATL и тд на них тоже сделать не получиться)
упс, ты даже наследуешься от T, такое реализовать в этой версии CLR вообще нельзя
в одном из блогов один девелопер из CLR team обещался, что в будущих версиях CLR можно будет наследоваться от парамента дженерика
в одном из блогов один девелопер из CLR team обещался, что в будущих версиях CLR можно будет наследоваться от парамента дженерика
> А почему собственно на хранить в Яве массив чисел? int[] matrix; ... matrix[x*size+y]...
Так обычно и делают, но проблемы начинаются, когда мы хотим написать матрицу для произвольных типов (int-ы, double-ы, вектор-а, complex-ы и т.д.)
generics-и как раз направлены на решение вот этой проблемы.
Так обычно и делают, но проблемы начинаются, когда мы хотим написать матрицу для произвольных типов (int-ы, double-ы, вектор-а, complex-ы и т.д.)
generics-и как раз направлены на решение вот этой проблемы.
ха, только пока они так реализованы в джаве, что
ArrayList l = new ArrayList; ... A a = (A) l.get(0);
и
ArrayList<A> l = new ArrayList<A> ... A a = l.get(0);
одно и тоже
ArrayList l = new ArrayList; ... A a = (A) l.get(0);
и
ArrayList<A> l = new ArrayList<A> ... A a = l.get(0);
одно и тоже
Даже после Jit-а?
там вроде на уровне байткода нет разницы, поэтому джитеру довольно сложно сообразить, что кастить не нужно
Но информация о '<A>' должна же быть и на уровне bytecode-а, соответственно этой информацией может воспользоваться JIT.
теоретически да
но для этого нужно новая команда байткода new, в которой будет указан тип A
вроде в sun не хотели вводить новые команды и они реализуют так, что дженерик класс - это класс, где все параметры на самом деле Object, просто к классу храниться дополнительная информация (может как специальные annotations где описаны параметры
поэтому байт код для
new ArrayList<A> и new ArrayList<B> одинаков и для джитера это ArrayList<Object>
одним словом дженерик в Джава - это фича компилятора
вроде в sun не хотели вводить новые команды и они реализуют так, что дженерик класс - это класс, где все параметры на самом деле Object, просто к классу храниться дополнительная информация (может как специальные annotations где описаны параметры
поэтому байт код для
new ArrayList<A> и new ArrayList<B> одинаков и для джитера это ArrayList<Object>
одним словом дженерик в Джава - это фича компилятора
> и для джитера это ArrayList<Object>
Да, но кто мешает JIT-еру смотреть annotations?
зы
Идея JAVA-истов понятна - они хотят, чтобы с новыми примочками работали нормально и старые java-машины, но никто не мешает новым Java-машинам пользоваться дополнительной информацией о шаблонах на полную катушку.
Да, но кто мешает JIT-еру смотреть annotations?
зы
Идея JAVA-истов понятна - они хотят, чтобы с новыми примочками работали нормально и старые java-машины, но никто не мешает новым Java-машинам пользоваться дополнительной информацией о шаблонах на полную катушку.
annotation может воспользоваться компилятор
джитер конечно тоже с помощью их может понять что
там где new ArrayList<A> создается объект джинерика, но
в байткоде соотв new ArrayList<A> нет данных на A
максимум что он может - это использовать информацию о ограничении extends параметра дженерика:
class <T extends I> A { T get; }
A<S> a = new A<S>
I i = a.get; // здесь джитер знает что тип I и кастить не надо
джитер конечно тоже с помощью их может понять что
там где new ArrayList<A> создается объект джинерика, но
в байткоде соотв new ArrayList<A> нет данных на A
максимум что он может - это использовать информацию о ограничении extends параметра дженерика:
class <T extends I> A { T get; }
A<S> a = new A<S>
I i = a.get; // здесь джитер знает что тип I и кастить не надо
как ни крути нужно вводить новую команду new в байткод, которая хранит значения аргументов параметров дженерика
Первое в джаве легко обходится
учитывая, что в джаве нельзя ссылаться на стек, то не всегда можно обойти отсутствие возможности передавать по ссылке без оверхеда
Оставить комментарий
irina-sokolov
не согласен. Java, например, не предоставляет всех возможностей С++ по работе с памятью, но это и не требуется.
Недавно пришлось вернуться к С++. Указатели - это просто ненужный гемор.