Здравствуйте, Eugeny__, Вы писали:
E__>Здравствуйте, Ikemefula, Вы писали:
I>>Я с этого и начинал. "Нативный код дискредетировал себя проблемами со стабильностью и безопасностью. Единственное на чем он сейчас держится это низкоуровневый контроль ресурсов. I>>"
E__>Еще в случаях, когда ресурсы ограничены. Если у тебя девайс с 64К оперативы(а таковых еще дочерта, на наш век хватит), то ни о каких жабошарпах речи нет.
Это очень маленький процент проектов в наше время. Думаю менее 0,001%. Так что абсолютно нет смысла его тут рассматривать.
Здравствуйте, alexey_ma, Вы писали:
_>Здравствуйте, alzt, Вы писали:
A>>Вот представь, что ты хочешь написать что-то для ARMа, а твой SuperNativeCSharp умеет генерировать код только для x86, причём у него даже есть некие проблемы с 64 разрядными приложениями. Те, кто развивают этот язык говорят, что лет через 7 может добавят поддержку ещё какой-нибудь платформы. _>Вот что мне нравится в подобного рода дискуссиях так это предложения представить какой-то там гипотетический случай. А нафига? Не сомневаюсь что есть случаи когда управляемый код рулит. Однако у меня есть в наличии реальнейшие задачи где в обозримом будущем нейтив непобедим как чак норрис. В основном это работа со сторонними аппликациями в целях интеграции и автоматизации, хуки, перехваты api (причем не только системных) и т.п. Есть клиент с программой на QT, написаной и поддерживаемой какими-то там индусами. Нужно пошерудить в ее гуе на предмет получения информации и автоматизации. Мне хук на джаве писать что-ли?
Хук можно написать на .NET. Вернее создать либу на C++\CLI, сделать в ней хук (или взять готовую), а из нее вызывать C#.
Кстати может лучше не гуй ковырять, а хранимые данные?
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, Mamut, Вы писали:
MM>>>Ты считаешь это хорошо? Ты считаешь, что непонимание одной из базовых концепций не то что программирования, M>>Каким боком указатели относятся к базовым концепциям программирования? MM>Послушай, ты же прекрасно понимаешь, что я имею ввиду. Давай возьмем хотя-бы C# — уж самый что ни на есть managed язык. Ну и? Даже в нем требуется понимание указателей. Ну, или ссылок, в этой терминологии я всегда плаваю. Человек должен уметь отличать Value type от Reference type, а это уже требует понимание сути указателя: есть адрес, а есть значение по этому адресу.
Ссылка, и значение по ссылке. В отличие от указателей не может быть ссылок на ссылки, арифметики ссылок итп. То что ссылка == адрес в документации ничего не фигурирует. Это оставляет возможность проводить многие оптимизации, например размещение объектов в стеке. Если понимать ссылку как адрес в управляемой куче, то это во многом ограничивает CLR.
Видишь, ты зная указатели не понимаешь ссылки в .NET.
Здравствуйте, Banned by IT, Вы писали:
M>>Понимание работы VM .NET'а может много в плане понимания работы компьютера и его оперативной памяти BBI>Аха. Сколько дотнетчиков понимают как реально внутри устроена VM и как она работает? 1% или ещё меньше?
M>>Ну или с указателями, но без участия С++ и его понимания указателей. BBI>Расскажи нам лучше на чём написана VM дотнета.
Открою тайну. В.NET нету VM. Весь .NET код компилируется в native перед исполнением.
Здравствуйте, gandjustas, Вы писали:
G>Видишь, ты зная указатели не понимаешь ссылки в .NET.
Ой спасибо. Мне недавно еще посоветовали почитать книгу по WPF, мол, я в нем мало что понимаю. Посоветуй и ты мне книжку, которая учит приемам демагогии.
MM>>> Давай возьмем хотя-бы C# — уж самый что ни на есть managed язык. Ну и? Даже в нем требуется понимание указателей. Ну, или ссылок, в этой терминологии я всегда плаваю. Человек должен уметь отличать Value type от Reference type, а это уже требует понимание сути указателя: есть адрес, а есть значение по этому адресу. M>>Эти понятия немного отличаются от указателей/ссылок в С++, не находишь? Настолько, что ты сам плаваешь в понятиях указатель/ссылка MM>Ikemefula написал
про указатели в общем смысле, никакого уточнения о специфике С++ сказано не было Если он имеет ввиду какие-то особенности, то стоит уточнить
ТОгда забываем слово указатели и говорим об архитектуре компьютера.
M>>>>Отстой получается из программистов, которые не знают реально базовых концепций программирования. MM>>>Вот это как раз не столь критично, потому что для большинства алгоритмов код давно уже написан. M>>Угу. Вот и получим в итоге говнопрограммистов, которые только и умеют делать, что копипастить/дергать чужой код без понимания, как он работает. Не говоря уже о том, что любая программа — это набор алгоритмов. Скажешь, для всех программ уже есть готовый код? Тогда чем мы занимаемся? MM>Скажу, что это не отменяет проблему непонимания указателей.
M>>Оперативная память — да. Работа с ней — нет. BBI>Драсте.
Здрасте
M>>Понимание работы VM .NET'а может много в плане понимания работы компьютера и его оперативной памяти BBI>Аха. Сколько дотнетчиков понимают как реально внутри устроена VM и как она работает? 1% или ещё меньше?
Столько же, сколько и С++'ников действительно понимающих, как работает CRT и указатели в С++
M>> безо всяких указателей вообще. BBI>Да ты шо. Т.е. в .NET runtime нет ни единой переменной, в которой бы хранился адрес чего либо? BBI>Просто фантастика. Пешы ищё!
Ну, если ты собираешься додумывать до меня то, что я не говорил, то, пожалуй, можно разговор прекращать.
M>>Ну или с указателями, но без участия С++ и его понимания указателей. BBI>Расскажи нам лучше на чём написана VM дотнета.
Какое отношение этот вопрос имеет к необходимости знать указатели? Никакого.
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, gandjustas, Вы писали:
G>>Видишь, ты зная указатели не понимаешь ссылки в .NET. MM>Ой спасибо. Мне недавно еще посоветовали почитать книгу по WPF, мол, я в нем мало что понимаю. Посоветуй и ты мне книжку, которая учит приемам демагогии.
Здравствуйте, gandjustas, Вы писали:
A>>>Вот представь, что ты хочешь написать что-то для ARMа, а твой SuperNativeCSharp умеет генерировать код только для x86, причём у него даже есть некие проблемы с 64 разрядными приложениями. Те, кто развивают этот язык говорят, что лет через 7 может добавят поддержку ещё какой-нибудь платформы. _>>Вот что мне нравится в подобного рода дискуссиях так это предложения представить какой-то там гипотетический случай. А нафига? Не сомневаюсь что есть случаи когда управляемый код рулит. Однако у меня есть в наличии реальнейшие задачи где в обозримом будущем нейтив непобедим как чак норрис. В основном это работа со сторонними аппликациями в целях интеграции и автоматизации, хуки, перехваты api (причем не только системных) и т.п. Есть клиент с программой на QT, написаной и поддерживаемой какими-то там индусами. Нужно пошерудить в ее гуе на предмет получения информации и автоматизации. Мне хук на джаве писать что-ли?
G>Хук можно написать на .NET. Вернее создать либу на C++\CLI, сделать в ней хук (или взять готовую), а из нее вызывать C#.
Можно конечно, но зачем? Нафига тянуть с собой все дллки нета если сама таргет-аппликация их не использует? Тем более в случае с QT, тут хук должен быть qt-длл. Есть у нас нетовые хуки и джавовые, они используються там где это необходимо. G>Кстати может лучше не гуй ковырять, а хранимые данные?
Конечно лучше, но во первых практически никогда этого не разрешают, а в вторых иногда бывает нужно автоматизировать гуй или вмешаться во взаимодействие ползователя с гуем, контролировать ввод до того как он сохранился и т.п. Кроме того есть чисто политические моменты, опыт показывает что любой доступ к данным помимо гуя требует согласования с отделом IT клиента на слишком ранних стадиях проекта. Для IT лишний гемор не нужен у них и так все работает и новые приблуды им не нужны, поэтому часто бывает что преждевременный контакт с IT губит проект на корню. Проще через бизнес все сделать, показать бизнес-менеджерам возможность добавить необходимую им бизнес функциональность всего-лишь установив на десктопе маленькую программу.
Здравствуйте, landerhigh, Вы писали:
L>>>А я знаю. Зато я не знаю ни одного серьезного проекта на .NET, который бы по срокам не пролетел минимум в два раза. На нем же так просто и быстро разрабатывать!
I>>Думаешь на С++ лучше ?
L>Думаешь? Я знаю. У нас сроки всегда выдерживаются.
У нас тоже
L>>>P.S. А эа выделенное в приличном обществе можно и канделябром огрести. I>>Это ж ты решил записать в профнепригодных людей, которые ошибки с указателями делают. Канделябр найдёшь или выслать ? L>Много чести. Ниасилившие указатели прекрасно справляются со стрельбой по собственным ногам даже в управлямых языках.
Здравствуйте, Eugeny__, Вы писали:
E__>Здравствуйте, maykie, Вы писали:
M>>В нативных Segmentation fault получить. Заметно проще, учитывая наличие почти во всех них Null Pointer'а. Есть исключения вроде Eiffel если не ошибаюсь, но они нафиг никому не нужны. В явах NPE получить тоже не проблема, но там хотя бы красивая трассировка стека будет вместо всяких "память не может быть read"
E__>В явах/шарпах еще, что очень важно, при почти любой ошибке максимум свалится текущий поток, а не все приложение. Если потоки практически независимы(а это именно так в подавляющем большинстве веб-приложений), то другие треды просто не заметят падения собрата. В тех же плюсах непойманное исключение в любом потоке ложит весь сервер.
Поэтому элементарное try-catch(...) в главной функции потока нормальные программеры ставят, не задумываясь, и горя не знают
А уж если нормальный С++ использовать (типа буста или C++11), то там вообще проблем нет, так как функция потока передается в виде boost/std::function, и ее вызов можно автоматом обернуть в try-catch(...) прозрачно для программера.
Это даже не говоря о том, что в С++11 предусмотрен механизм корректной передачи исключения из дочернего потока в родительский поток.
Причем обрати внимание, в С++ благодаря RAII рухнувший по исключению поток сразу же автоматически освободит все захваченные ресурсы (включая, например, локи мьютексов, открытые файлы/сокеты/соединения и т.п.).
Здравствуйте, Ikemefula, Вы писали:
I>Эдак все С++ программисты станут профнепригодными. Не знаю ни одного серьезного проекта где бы не было ошибок с указателями.
Вы мягко говоря преувеличиваете. Широко известные, нативные и довольно обьемные программы, как то известные браузеры, оффис и т.п уже давным давно не валяться из за "ошибок с указателями". А баги они везде бывают, и нетовые программы тоже вылетают по ексцепшинам и бывает что память и них течет, это просто менее заметно ввиду малого распостранения подобных программ на десктопе.
Здравствуйте, monax, Вы писали:
M>Здравствуйте, landerhigh, Вы писали:
L>>Много чести. Ниасилившие указатели прекрасно справляются со стрельбой по собственным ногам даже в управлямых языках.
M>Указатели, вроде как, осилил, проблем никогда не было. Но вот за несколько лет программирования на скриптовых языках под веб мне ни разу указатели не помогли.
Скриптовые языки и веб, где скоп живет считанные миллисекунды есть весьма отдельный случай. Но и там стрельба по ногам встречается чаще, чем хотелось бы.
I>>>Думаешь на С++ лучше ?
L>>Думаешь? Я знаю. У нас сроки всегда выдерживаются.
I>У нас тоже
Поздравляю.
L>>Много чести. Ниасилившие указатели прекрасно справляются со стрельбой по собственным ногам даже в управлямых языках.
I>Это мягко говоря далеко от истины.
Здравствуйте, alexey_ma, Вы писали:
_>Здравствуйте, Ikemefula, Вы писали:
I>>Эдак все С++ программисты станут профнепригодными. Не знаю ни одного серьезного проекта где бы не было ошибок с указателями. _>Вы мягко говоря преувеличиваете. Широко известные, нативные и довольно обьемные программы, как то известные браузеры, оффис и т.п уже давным давно не валяться из за "ошибок с указателями".
Понадобились многие годы что бы пофиксить Но вообще — валятся. Смотри дыры в безопасности где всякие срывы стека.
>А баги они везде бывают, и нетовые программы тоже вылетают по ексцепшинам и бывает что память и них течет, это просто менее заметно ввиду малого распостранения подобных программ на десктопе.
В с++ коде есть такой класс багов, как баги с указателями. В менеджет его нет. В остальном все одинаково.
Здравствуйте, Ikemefula, Вы писали:
I>Понадобились многие годы что бы пофиксить Но вообще — валятся. Смотри дыры в безопасности где всякие срывы стека.
Ну так а говорите "не видел". И не только про браузеры речь, на десктопе хватает нативного достаточно стабильного софта. >>А баги они везде бывают, и нетовые программы тоже вылетают по ексцепшинам и бывает что память и них течет, это просто менее заметно ввиду малого распостранения подобных программ на десктопе.
I>В с++ коде есть такой класс багов, как баги с указателями. В менеджет его нет. В остальном все одинаково.
Дык про то и речь. У плюсов свои проблемы, у менеджа свои. Менеджет программ на десктопах пока очень мало.
Здравствуйте, alexey_ma, Вы писали:
I>>Понадобились многие годы что бы пофиксить Но вообще — валятся. Смотри дыры в безопасности где всякие срывы стека. _>Ну так а говорите "не видел". И не только про браузеры речь, на десктопе хватает нативного достаточно стабильного софта.
Хватает. Сколько времени было затрачено на фиксы багов с указателями ?
Здравствуйте, landerhigh, Вы писали:
L>>>Много чести. Ниасилившие указатели прекрасно справляются со стрельбой по собственным ногам даже в управлямых языках. M>>Указатели, вроде как, осилил, проблем никогда не было. Но вот за несколько лет программирования на скриптовых языках под веб мне ни разу указатели не помогли. L>Скриптовые языки и веб, где скоп живет считанные миллисекунды есть весьма отдельный случай. Но и там стрельба по ногам встречается чаще, чем хотелось бы.
Такая стрельба это норма у свежемигрировавших сиплюсников
Здравствуйте, Ikemefula, Вы писали:
I>Хватает. Сколько времени было затрачено на фиксы багов с указателями ?
Ну слава богу хоть удалось разглядеть серьезные нативные стабильные проекты "Сколько времени" это важно? Полагаю что это время не определялось только фиксом багов именно с указателями. Тот кто оные программы делал мог себе позволить столько времени сколько нужно, и пока не видно особой тенденции на менеджет переписывать(разве что VS2010).
Здравствуйте, gandjustas, Вы писали:
G>Открою тайну. В.NET нету VM. Весь .NET код компилируется в native перед исполнением.
Это ты Мамуту тайны открывай.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Если он имеет ввиду какие-то особенности, то стоит уточнить 
