Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
g>> Открою тайну. В.NET нету VM. Весь .NET код компилируется в native перед исполнением.
H>CLR является виртуальной машиной .NET
Где такой бред прочитал? Runtime != VM. Ты еще скажи что CRT — виртуальная машина C.
g>>> Открою тайну. В.NET нету VM. Весь .NET код компилируется в native перед исполнением.
H>>CLR является виртуальной машиной .NET
G>Где такой бред прочитал? Runtime != VM. Ты еще скажи что CRT — виртуальная машина C.
The Common Language Runtime (CLR) is the virtual machine component of Microsoft's .NET framework and is responsible for managing the execution of .NET programs. In a process known as just-in-time (JIT) compilation, the CLR compiles the intermediate language code known as CIL into the machine instructions that in turn are executed by the computer's CPU.
Здравствуйте, Mamut, Вы писали:
g>>>> Открою тайну. В.NET нету VM. Весь .NET код компилируется в native перед исполнением.
H>>>CLR является виртуальной машиной .NET
G>>Где такой бред прочитал? Runtime != VM. Ты еще скажи что CRT — виртуальная машина C.
M>
M>The Common Language Runtime (CLR) is the virtual machine component of Microsoft's .NET framework and is responsible for managing the execution of .NET programs. In a process known as just-in-time (JIT) compilation, the CLR compiles the intermediate language code known as CIL into the machine instructions that in turn are executed by the computer's CPU.
g>>>>> Открою тайну. В.NET нету VM. Весь .NET код компилируется в native перед исполнением.
H>>>>CLR является виртуальной машиной .NET
G>>>Где такой бред прочитал? Runtime != VM. Ты еще скажи что CRT — виртуальная машина C.
M>>
M>>The Common Language Runtime (CLR) is the virtual machine component of Microsoft's .NET framework and is responsible for managing the execution of .NET programs. In a process known as just-in-time (JIT) compilation, the CLR compiles the intermediate language code known as CIL into the machine instructions that in turn are executed by the computer's CPU.
M>>Не?
G>Это где написано? Не в википедии случайно?
Здравствуйте, alexey_ma, Вы писали:
I>>Хватает. Сколько времени было затрачено на фиксы багов с указателями ? _>Ну слава богу хоть удалось разглядеть серьезные нативные стабильные проекты "Сколько времени" это важно? Полагаю что это время не определялось только фиксом багов именно с указателями.
"на фиксы багов с указателями " время определялось не токльо фиксом таких багов ? Ну и дела
>Тот кто оные программы делал мог себе позволить столько времени сколько нужно, и пока не видно особой тенденции на менеджет переписывать(разве что VS2010).
Это не из за того, что С++ такой крутой, а потому что большие проекты переписывать слишком дорого с любого языка на любой.
Здравствуйте, Mamut, Вы писали:
g>>>>>> Открою тайну. В.NET нету VM. Весь .NET код компилируется в native перед исполнением.
H>>>>>CLR является виртуальной машиной .NET
G>>>>Где такой бред прочитал? Runtime != VM. Ты еще скажи что CRT — виртуальная машина C.
M>>>
M>>>The Common Language Runtime (CLR) is the virtual machine component of Microsoft's .NET framework and is responsible for managing the execution of .NET programs. In a process known as just-in-time (JIT) compilation, the CLR compiles the intermediate language code known as CIL into the machine instructions that in turn are executed by the computer's CPU.
M>>>Не?
G>>Это где написано? Не в википедии случайно?
M>В ней, родимой
M>С другой стороны, что там неправильно? То же самое, только другими словами и старательно избегая слова виртуальная машина написано и тут: http://msdn.microsoft.com/en-us/library/8bs2ecf4.aspx
И ведь не зря "старательно избегая". Ведь CLR описан как спецификация для VM, хотя физически VM отсуствует. Все компилируется в нативный код JIT, который полностью удовлетворяет спецификации.
g>>>>>>> Открою тайну. В.NET нету VM. Весь .NET код компилируется в native перед исполнением.
H>>>>>>CLR является виртуальной машиной .NET
G>>>>>Где такой бред прочитал? Runtime != VM. Ты еще скажи что CRT — виртуальная машина C.
M>>>>
M>>>>The Common Language Runtime (CLR) is the virtual machine component of Microsoft's .NET framework and is responsible for managing the execution of .NET programs. In a process known as just-in-time (JIT) compilation, the CLR compiles the intermediate language code known as CIL into the machine instructions that in turn are executed by the computer's CPU.
M>>>>Не?
G>>>Это где написано? Не в википедии случайно?
M>>В ней, родимой
M>>С другой стороны, что там неправильно? То же самое, только другими словами и старательно избегая слова виртуальная машина написано и тут: http://msdn.microsoft.com/en-us/library/8bs2ecf4.aspx
G>И ведь не зря "старательно избегая". Ведь CLR описан как спецификация для VM, хотя физически VM отсуствует. Все компилируется в нативный код JIT, который полностью удовлетворяет спецификации.
Ну тут уже начинаются философские споры, на самом деле
Здравствуйте, Ikemefula, Вы писали:
I>>>Хватает. Сколько времени было затрачено на фиксы багов с указателями ? _>>Ну слава богу хоть удалось разглядеть серьезные нативные стабильные проекты "Сколько времени" это важно? Полагаю что это время не определялось только фиксом багов именно с указателями.
I>"на фиксы багов с указателями " время определялось не токльо фиксом таких багов ? Ну и дела
Ну да, дела. Есть какая-то статистика о количестве времени потраченном на фиксы багов связанных именно с памятью хотя-бы по какому либо продукту? Ваш вопрос "Сколько времени было затрачено на фиксы багов с указателями ?" смысла не имеет, и даже сами производители вряд-ли на него точно ответят. Можете считать что вся команда VS или хрома от релиза к релизу только и занималась тем что боролась с указателями.
>>Тот кто оные программы делал мог себе позволить столько времени сколько нужно, и пока не видно особой тенденции на менеджет переписывать(разве что VS2010).
I>Это не из за того, что С++ такой крутой, а потому что большие проекты переписывать слишком дорого с любого языка на любой.
Естественно, это тоже вполне себе причина, как и то что менеджет недостаточно крут что бы использовать его универсальное лекарство от всех проблем.
Здравствуйте, gandjustas, Вы писали: g> g>> Открою тайну. В.NET нету VM. Весь .NET код компилируется в native перед исполнением. g> H>CLR является виртуальной машиной .NET g> Где такой бред прочитал? Runtime != VM.
Одно уже наличие байткода говорит об этом. Попробуй подумать. Наличие виртуальной машины ни коим образом не указывает на интерпретацию байткода (если ты, вдруг, об этом), это, вообще говоря, сугубо личное дело самой ВМ, как его исполнять. CLR джитит, и Java тоже джитит. Хоть википедию почитай, что ли g> Ты еще скажи что CRT — виртуальная машина C.
Ты не отличаешь исполняющую среду (CLR) от библиотеки времени исполнения (CRT)?
Здравствуйте, Ikemefula, Вы писали:
>>А баги они везде бывают, и нетовые программы тоже вылетают по ексцепшинам и бывает что память и них течет, это просто менее заметно ввиду малого распостранения подобных программ на десктопе.
I>В с++ коде есть такой класс багов, как баги с указателями. В менеджет его нет. В остальном все одинаково.
Нет такого класса багов. В принципе. Указатель — это просто число, накосячить с ним не просто.
Зато бывают баги, вызванные кривыми руками и мозгами, ниасилившими ручное управление ресурсами и продуманную архитектуру. Ну и, в качестве привета из каменного века, так всеми любимое переполнение буфера, которое в нынешнем С++ нужно еще постараться устроить.
Здравствуйте, gandjustas, Вы писали:
G>И ведь не зря "старательно избегая". Ведь CLR описан как спецификация для VM, хотя физически VM отсуствует. Все компилируется в нативный код JIT, который полностью удовлетворяет спецификации.
В mono же и интерпретатор есть, так что зависит от реализации.
L>Зато бывают баги, вызванные кривыми руками и мозгами, ниасилившими ручное управление ресурсами и продуманную архитектуру. Ну и, в качестве привета из каменного века, так всеми любимое переполнение буфера, которое в нынешнем С++ нужно еще постараться устроить.
Ну дык. Указатели старательно упаковывают в GC для бедных — auto_ptr, shared_ptr и прочая *_ptr, чтобы не дай бог кто-то не использовал голые указатели. Можно поискать по форумам. Как только кто-то заикается про указатели, его всем форумом начинают бить канделябром за неиспользование *_ptr. Но при этом продолжают всем рассказывать сказки про то, что от указателей проблем нет
Здравствуйте, landerhigh, Вы писали:
I>>В с++ коде есть такой класс багов, как баги с указателями. В менеджет его нет. В остальном все одинаково.
L>Нет такого класса багов. В принципе. Указатель — это просто число, накосячить с ним не просто.
Очень просто, чисто для демонстрации:
char *p;
strcpy(p,src);
L>Зато бывают баги, вызванные кривыми руками и мозгами, ниасилившими ручное управление ресурсами и продуманную архитектуру. Ну и, в качестве привета из каменного века, так всеми любимое переполнение буфера, которое в нынешнем С++ нужно еще постараться устроить.
Не надо там пытаться. Пример не сложнее предыдущего.
во.
L>>Нет такого класса багов. В принципе. Указатель — это просто число, накосячить с ним не просто.
I>Очень просто, чисто для демонстрации: I>
I>char *p;
I>strcpy(p,src);
I>
Хороший пример Ну и за какое время сия хрень обнаруживается и фиксится?
Кстати если ms компилятором пользуетесь то нужно warning-и читать научиться. Есть там С4700 : "You used the local variable name without first assigning it a value, which could lead to unpredictable results."
Здравствуйте, alexey_ma, Вы писали:
I>>Очень просто, чисто для демонстрации: I>>
I>>char *p;
I>>strcpy(p,src);
I>>
_> Хороший пример Ну и за какое время сия хрень обнаруживается и фиксится?
Цитирую : "чисто для демонстрации"
_>Кстати если ms компилятором пользуетесь то нужно warning-и читать научиться. Есть там С4700 : "You used the local variable name without first assigning it a value, which could lead to unpredictable results."
Здравствуйте, Ikemefula, Вы писали:
I>>>Очень просто, чисто для демонстрации: I>>>
I>>>char *p;
I>>>strcpy(p,src);
I>>>
_>> Хороший пример Ну и за какое время сия хрень обнаруживается и фиксится?
I>Цитирую : "чисто для демонстрации"
Хиленькая такая демонстрация, совсем не показывающая всей сложности использования чистых указателей. Ошибка-то легко обнаруживается еще на этапе компиляции.
_>>Кстати если ms компилятором пользуетесь то нужно warning-и читать научиться. Есть там С4700 : "You used the local variable name without first assigning it a value, which could lead to unpredictable results."
I>Спасибо, капитан.
Пожайлуста.
Здравствуйте, alexey_ma, Вы писали:
I>>>>Очень просто, чисто для демонстрации: I>>>>
I>>>>char *p;
I>>>>strcpy(p,src);
I>>>>
_>>> Хороший пример Ну и за какое время сия хрень обнаруживается и фиксится?
I>>Цитирую : "чисто для демонстрации" _>Хиленькая такая демонстрация, совсем не показывающая всей сложности использования чистых указателей. Ошибка-то легко обнаруживается еще на этапе компиляции.
Очень даже показывает проезд по памяти. Представь, что p инициализируется неправильно.
Здравствуйте, Ikemefula, Вы писали:
I>>>Цитирую : "чисто для демонстрации" _>>Хиленькая такая демонстрация, совсем не показывающая всей сложности использования чистых указателей. Ошибка-то легко обнаруживается еще на этапе компиляции.
I>Очень даже показывает проезд по памяти. Представь, что p инициализируется неправильно.
Вот что мне нравится в подобного рода дискуссиях так это предложения представить какой-то там гипотетический случай.
Мне-то зачем что-то представлять? Это Вы тут пытаетесь напугать сообщество ужасными голыми указателями. Вот и подгоняйте достоверные примеры неуловимых багов на указателях. Лично меня убеждать не нужно, я и так знаю с какими реальными багами приходится сталкиваться, и неправильная инициализация указателя вообще не входит в список часто встречающихся и трудно уловимых. Вы ж упорно пытаетесь убедить меня в обратном тупым примером. Думаете получится? Коллеги реально пишушие на плюсах вам уже неоднократно говорили что указатели не более чем жупел, и проблемы с ними сильно преувеличены. Никто не говорит что проблемы польностью отсутствуют. Но это далеко не самый тормозящий фактор в плюсных проектах. Прямой доступ к памяти это преимущество с/c++, причем иногда абсолютно необходимое. Опасно? Конечно, но есть опробованные лекарства. Не нужен прямой доступ к памяти — пишите на менеджет.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, landerhigh, Вы писали:
I>>>В с++ коде есть такой класс багов, как баги с указателями. В менеджет его нет. В остальном все одинаково.
L>>Нет такого класса багов. В принципе. Указатель — это просто число, накосячить с ним не просто.
I>Очень просто, чисто для демонстрации: I>
I>char *p;
I>strcpy(p,src);
I>
Бага с указателем не видно. Видно баг в /dev/brain и отовсюду торчат кривые hands.sys
Не говоря уже о том, что сейчас делают так
std::string dst(pSrc);
L>>Зато бывают баги, вызванные кривыми руками и мозгами, ниасилившими ручное управление ресурсами и продуманную архитектуру. Ну и, в качестве привета из каменного века, так всеми любимое переполнение буфера, которое в нынешнем С++ нужно еще постараться устроить.
I>Не надо там пытаться. Пример не сложнее предыдущего.
В моей команде тебе придется на уши встать и гопака на потолке станцевать, чтобы что-то отдаленно напоминающее приведенный выше прикол прошел код ревью.
Есть какая-то статистика о количестве времени потраченном на фиксы багов связанных именно с памятью хотя-бы по какому либо продукту? Ваш вопрос "Сколько времени было затрачено на фиксы багов с указателями ?" смысла не имеет, и даже сами производители вряд-ли на него точно ответят. Можете считать что вся команда VS или хрома от релиза к релизу только и занималась тем что боролась с указателями.
