Здравствуйте, Философ, Вы писали:

I>>И потому глючат даже сишные проги и проги на дельфях всяких ?

Ф>И потому же глючат шарповые проги и проги на VBNet'ах всяких

Глючат. Но таких проблем с указателями и близко нет.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Философ, Вы писали:

I>>>И потому глючат даже сишные проги и проги на дельфях всяких ?

Ф>>И потому же глючат шарповые проги и проги на VBNet'ах всяких

I>Глючат. Но таких проблем с указателями и близко нет.

О!
Таки дошли/добрались до корня зла.
Ну и при чём здесь нативный/не нативный?

Здравствуйте, sysenter, Вы писали:

S>Что-то очень на враньё похоже, щедулер при 1000Hz даст время переключения 1 мл.сек. + нужно ещё посчитать квант процесса + нужно добавить погрешность переключения (в среднем от 0.5 до 1 тика) т.е. до 1 мл.сек. + время задержки в TCP/IP стеке (алгоритм Нагла может задержать пакеты, установка соединения и т.п.). Итого, не может быть внутренняя задержка меньше 2 мл.сек.

Сорри, не специалист в этом.
Опять же — тут неясно точно что они имели в виду под этим параметром — тут есть варианты.

Здравствуйте, azzx, Вы писали:

A>Опять же — тут неясно точно что они имели в виду под этим параметром — тут есть варианты.

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

Здравствуйте, Философ, Вы писали:

Ф>cpp — мутант переходного периода, и должен умереть

Тестовое задание C++ win

Здравствуйте, amberovsky, Вы писали:

	Скрытый текст
	A>Здравствуйте. A>При попытке устроится в одну фирму прислали "удалённое" тестовое задание. A> A>Какие проблемы Вы видите в этих фрагментах кода и как предлагаете их решать? A>1. A>void g( char *, char *, size_t ); A>void f( size_t n ) A>{ A> char *a = new char[n]; A> char *b = new char[n]; A> g( a, b, n ); A> delete [] b; A> delete [] a; A>} A>2. A>int main(int argc, char* argv[]) A>{ A> if( argc > 1 ) A> printf( argv[1] ); A> return 0; A>} A>

Здравствуйте, Философ, Вы писали:


I>>Глючат. Но таких проблем с указателями и близко нет.

Ф>О!
Ф>Таки дошли/добрались до корня зла.

Я с этого и начинал. "Нативный код дискредетировал себя проблемами со стабильностью и безопасностью. Единственное на чем он сейчас держится это низкоуровневый контроль ресурсов.
"

Ф>Ну и при чём здесь нативный/не нативный?

При том, что менеджет как правило не использует указатели. У многиъ программистов хронически не получается использовать указатели, софт тупо не взлетает или глючит. Эти же программисты худо бедно но рожают менеджет решения

Здравствуйте, Ikemefula, Вы писали:

I>При том, что менеджет как правило не использует указатели. У многиъ программистов хронически не получается использовать указатели, софт тупо не взлетает или глючит.
Не волнуйся ты так, этих криворучкек выпинывают с работы и они идут говнокодить на managed.

I>Эти же программисты худо бедно но рожают менеджет решения
Да да. Наши говнокодеры уже все у вас. Что изрядно улучшило стабльность native софта.

Здравствуйте, Философ, Вы писали:

Ф>Здравствуйте, Ikemefula, Вы писали:

I>>Нативный код дискредетировал себя проблемами со стабильностью и безопасностью. Единственное на чем он сейчас держится это низкоуровневый контроль ресурсов.

Ф>дискредитировал себя не нативный код, а С'стайл в C++
+1

Ф>cpp — мутант переходного периода, и должен умереть
А это к чему?
Ты таки считаешь, что должен умереть С'стайл в C++ (с чем я полностью согласен), или весь С++ (с чем я не согласен)?

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Banned by IT, Вы писали:

I>>При том, что менеджет как правило не использует указатели. У многиъ программистов хронически не получается использовать указатели, софт тупо не взлетает или глючит.
BBI>Не волнуйся ты так, этих криворучкек выпинывают с работы и они идут говнокодить на managed.

I>>Эти же программисты худо бедно но рожают менеджет решения
BBI>Да да. Наши говнокодеры уже все у вас. Что изрядно улучшило стабльность native софта.

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

Здравствуйте, Ikemefula, Вы писали:

I>Глючат. Но таких проблем с указателями и близко нет.

Проблем с указателями не бывает. Бывают проблемы с программистами, их ниасилившими и их кодом.

Здравствуйте, Privalov, Вы писали:

P>А ты запускал VC6 на Pentium-100 с 16M оперативы?
запускал на 486dx 100MHz с 24М, работало дововольно шустро, но сравнивать с 2010й студией не стоит

Здравствуйте, Pavel Dvorkin, Вы писали:


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

PD>Python — интерпретатор, плагин к эклипсу для Python 2.7. Для Явы — эклпипс.

Я имел ввиду, жаба с ключиком -server или нет? Это в числодробилках очень важно.

E__>>А еще есть управление памятью. Которое очень сложный вопрос. В приложениях типа веба — шах и мат нативе.

PD>Вот тут согласен, но частично. Шах и мат не нативе, а нативе с указателями. Натива может вполне быть без указателей и со сборкой мусора, а тогда никакого шаха и мата не будет. Дело не в нативе vs. управляемый код, а в наличии или отсутствии сборки мусора.

Ну да, как-то так.

>>(непойманное исключение в жабошарпах ложит текущий поток обработки с записью в логи, в плюсах — весь сервер;

PD>Ну это совсем не обязательно, можно на С++ ловить необработанные исключения.

Можно. Но в общем случае у жабы поведение по умолчанию при непойманном исключении — сваливается проблемный поток, остальные ничего про это не знают. У плюсов — ну ты в курсе. То есть, даже если код одной странички на жабе писал студент, это не повлияет на код рядом, написанный профи.

Здравствуйте, Ikemefula, Вы писали:

Ф>>Ну и при чём здесь нативный/не нативный?
I>При том, что менеджет как правило не использует указатели. У многиъ программистов хронически не получается использовать указатели, софт тупо не взлетает или глючит. Эти же программисты худо бедно но рожают менеджет решения
Ты считаешь это хорошо? Ты считаешь, что непонимание одной из базовых концепций не то что программирования, а вообще — функцинирования компьютеров — это нормально для разработчика? Это отстой. Такие программисты и в managed нафиг не нужны, потому что на выходе все-равно получается хрень. Реальная отдача от подобных "разработчиков" — головная боль для вменяемых программеров, которым рано или поздно, но приходится переделывать глюкалово, написанное без подключения головы.

Здравствуйте, MxMsk, Вы писали:

Ф>>>Ну и при чём здесь нативный/не нативный?
I>>При том, что менеджет как правило не использует указатели. У многиъ программистов хронически не получается использовать указатели, софт тупо не взлетает или глючит. Эти же программисты худо бедно но рожают менеджет решения
MM>Ты считаешь это хорошо?

Я считаю, что бизнес в состоянии запустить столько проектов, сколько ему, бизнесу, требуется.

>Ты считаешь, что непонимание одной из базовых концепций не то что программирования, а вообще — функцинирования компьютеров — это нормально для разработчика? Это отстой.

См. выше. Сколько будет проектов в разработке, решают вообще не разработчики, а люди из бизнеса.

>Такие программисты и в managed нафиг не нужны, потому что на выходе все-равно получается хрень. Реальная отдача от подобных "разработчиков" — головная боль для вменяемых программеров, которым рано или поздно, но приходится переделывать глюкалово, написанное без подключения головы.

Бизнес всё равно запустит проекты

Здравствуйте, landerhigh, Вы писали:

I>>Глючат. Но таких проблем с указателями и близко нет.

L>Проблем с указателями не бывает. Бывают проблемы с программистами, их ниасилившими и их кодом.

Это абсолютно несущественная разница. Если прогарммист не осилил указатели, то эта особенность указателей проявится во всех фрагментах его кода.

Здравствуйте, Banned by IT, Вы писали:

I>>При том, что менеджет как правило не использует указатели. У многиъ программистов хронически не получается использовать указатели, софт тупо не взлетает или глючит.
BBI>Не волнуйся ты так, этих криворучкек выпинывают с работы и они идут говнокодить на managed.

Да не выпинывают

I>>Эти же программисты худо бедно но рожают менеджет решения
BBI>Да да. Наши говнокодеры уже все у вас. Что изрядно улучшило стабльность native софта.

Ваших говнокодеров у нас нет

Здравствуйте, Ikemefula, Вы писали:


I>Я с этого и начинал. "Нативный код дискредетировал себя проблемами со стабильностью и безопасностью. Единственное на чем он сейчас держится это низкоуровневый контроль ресурсов.
I>"

Еще в случаях, когда ресурсы ограничены. Если у тебя девайс с 64К оперативы(а таковых еще дочерта, на наш век хватит), то ни о каких жабошарпах речи нет. Только чистый С. Но там и сложность не та. Никто не требует от портативного автомата по печати билетов, например(для кондуктора) 3Д интерфейса и всяких плюшек. Там хватит обычного текста. И в таких девайсах не будет еще долго гигабайт памяти и супер-пупер проца. Потому что батарейка. Ну и цена.

Здравствуйте, Eugeny__, Вы писали:

I>>Я с этого и начинал. "Нативный код дискредетировал себя проблемами со стабильностью и безопасностью. Единственное на чем он сейчас держится это низкоуровневый контроль ресурсов.
I>>"

E__>Еще в случаях, когда ресурсы ограничены. Если у тебя девайс с 64К оперативы(а таковых еще дочерта, на наш век хватит), то ни о каких жабошарпах речи нет.

Это как раз вписывается в "низкоуровневый контроль ресурсов". Низкий контроль нужен когда много всяких ограничений, объемы, скорость и тд и тд и тд при чем под эти ограничений нет готовых инструментов и все нужно делать руками.

Здравствуйте, alzt, Вы писали:

A>Вот представь, что ты хочешь написать что-то для ARMа, а твой SuperNativeCSharp умеет генерировать код только для x86, причём у него даже есть некие проблемы с 64 разрядными приложениями. Те, кто развивают этот язык говорят, что лет через 7 может добавят поддержку ещё какой-нибудь платформы.
Вот что мне нравится в подобного рода дискуссиях так это предложения представить какой-то там гипотетический случай. А нафига? Не сомневаюсь что есть случаи когда управляемый код рулит. Однако у меня есть в наличии реальнейшие задачи где в обозримом будущем нейтив непобедим как чак норрис. В основном это работа со сторонними аппликациями в целях интеграции и автоматизации, хуки, перехваты api (причем не только системных) и т.п. Есть клиент с программой на QT, написаной и поддерживаемой какими-то там индусами. Нужно пошерудить в ее гуе на предмет получения информации и автоматизации. Мне хук на джаве писать что-ли?

Здравствуйте, Ikemefula, Вы писали:


I>>>Я с этого и начинал. "Нативный код дискредетировал себя проблемами со стабильностью и безопасностью. Единственное на чем он сейчас держится это низкоуровневый контроль ресурсов.
I>>>"

E__>>Еще в случаях, когда ресурсы ограничены. Если у тебя девайс с 64К оперативы(а таковых еще дочерта, на наш век хватит), то ни о каких жабошарпах речи нет.

I>Это как раз вписывается в "низкоуровневый контроль ресурсов". Низкий контроль нужен когда много всяких ограничений, объемы, скорость и тд и тд и тд при чем под эти ограничений нет готовых инструментов и все нужно делать руками.

Да нету там никакого контроля ресурсов(ну, кроме контроля модема через АТ команды, и принтера через POS), просто аккуратное написание кода на С, чтобы не вылезти за предел памяти. Учитывая, что графики нет, 64К хватает с головой.
А заказчики — люди, умеющие считать. Они лучше закажут девайс с 64К, слабым арм процом, но который прослужит годы, и не будет требовать зарядки каждые пару часов, чем.. Ну ты понял. А написать прогу я могу как под нативу, так и под Ведроид какой-нибудь, но это один раз. А девайсов нужно много, и желательно, чтобы они были долгоживущими во всех смыслах этого слова.