Java

> Просто надо писать на Джава, а не на всяких Ц/Ц++, она сама не даст ошибок наделать

Не дать наделать ошибок может только блокировка клавиатуры. ;-)

Re[3]: Как писать ПО лучше

Есть ещё одна еще чудесная книга:

Ален И. Голуб "Правила программирования на C/C++"

http://www.holub.com/

Ну и гуглить, "Ален И. Голуб" тягает на нужную страницу.

http://prog.dax.ru/docs/cpprules/

Классная книга. Особенно про то, что гуманитарии лучше пишут проги, чем технари, а особенно физики (и особенно из ИФВЭ-IHEP http://ontil.ihep.su/~vsl/:)))

>> Обоснуй необходимость поддержки ошибок выделения памяти в современных языках программирования. Мне очень интересно.

> Причем тут поддержка ошибок? =) Я говорю о том что не вижу ничего плохого в том что программист управляет памятью- размещением и высвобождением это вполне удобно, не всегда конечно, согласен что для написания всякой мелочи можно обойтись скриптовыми языками, но все же зачем полностью полагаться на сборщиков мусора?

> Ошибки все равно будут - хотя бы в самом сборщике мустора - его то надо как то писать тоже =))

При чём тут сборка мусора и скриптовые языки? Под поддержкой ошибок я имел в виду:

1. Наличие адресной арифметики.

2. Наличие нетипизированных указателей.

3. Свободное приведение типов указателей.

4. Отсутствие контроля выхода за границу массива.

Между прочим первые 3 пункта ещё и мешают реализовать дефрагментацию хипа.

А сборщик мусора всего лишь уменьшает возможности создания утечек памяти.

Касательно ошибок в сборщике мусора - попробуй использовать готовый оттестированный :)

>KAK HET?!?

>baklan (*) (11.10.2004 3:32:15)

Urly v studiyu pliz daby vyglyadelo vse argumentirovano...

-d

Лики на яве тоже создаются, просто чуть-чуть по-другому. Я вспомнил про один, правда в Qt его нашли, но именно другого типа. Допустим, есть дерево объектов, часть из них безымянные. Попользовали и забыли. Например, Label на диалоге. На него одна ссылка - с родителя. Когда родитель грохается, этот Label, понятно, подохнет.

А вот если такого плана объект прилеплен к Application, да про него забыли, он вполне себе легально висит у него в детях, и помрёт только при выходе. Теперь картина маслом: при создании какого-то объекта делается такой вот узелок, который по каким-то причинам должен быть прикручен к корню. А потом его пришибить забыли :-( И никаким Memory debugger'ом ты не найдёшь эту дрянь. Только "метод пристального взляда" или дамп этого самого дерева объектов, чтобы этих расплодившихся найти.

PS. Для вещей а-ля GC в C++ есть всякие Smart pointers (www.boost.org), только, говорю, не панацея это.

PPS. Не рассказывайте про различия GC и SP. Я их и сам знаю. Для рассматриваемого типа утечек памяти это несущественно.

2 pitekantrop:

>PPS. Не рассказывайте про различия GC и SP. Я их и сам знаю. Для р ассматриваемого типа утечек памяти это несущественно.

Это я не вам. Просто щас куча анонимусов накинется :-)

>Только "метод пристального взляда" или дамп этого самого дерева объектов, чтобы этих расплодившихся найти

Сейчас Вам посоветуют для создать метод ReleaseTree, который проходит по всем узлам дерева, обнуляя все ссылки, и вызывать его явно перед тем как дерево становится ненужно. Или использовать паттерн "делегат" :)
Проверено

> и вызывать его явно перед тем как дерево становится ненужно.

Если тут появится какой-нить vtVitus, то он будет рекомендовать трижды вручную вызывать ReleaseTree "там, где захочешь".

Я не говорил, что сборщик мусора исключает memory leaks =)

>АЛУ в процессоре должен сложить числа. Проверили - складывает.

Для 64-битного процессора: 2^64 * 2^64 = 2 ^ 128. Допустим, проверить можно 2 ^ 38 вариантов в секунду. Получаем 2 ^ 90 секунд. Для сравнения - в сутках 86400 секунд, в году - ~31557600. В общем, 2 ^ 60 лет будете проверять. Это если операция вне контекста. А если ещё зависим от флагов, от кэша, от электномагнитного фона, от излучения из космоса ( это, кстати, тоже учитывается, если не знали ).

Если под тестированием понимать всякие unit test-ы (в том же экстриме) - то таких фреймворков - ДО ЖОПЫ. Точно так же, полно языков, которые поддерживают design by contract.

Да проверять никто и не призывает - железо легко доказывается формально. Это гораздо проще, чем с программами - ведь железка может всегда быть представлена в виде автомата (state machine), а для доказательства соответствия автомата спецификации мат.аппарат уже давном давны разработан.

> Всяческие Rational Robot'ы мало помогают.

Потому что они говно полнейшее....

А с кем это вы тут разговариваете?

>Если под тестированием понимать всякие unit test-ы (в том же экстриме) - то таких фреймворков - ДО ЖОПЫ.

Unit testing ne otobrazhaet real'nyh zaprosov k prilozheniyu so srorony end-usera. Pod testirovaniem ponimaetsya, naprimer, GUI testing s vozmozhnost'yu scriptinga. Lider zhanra - soft ot "Mercury Interactive" s nepomernoy cenoy - gde frishnye analogi ?!

>The basic idea is, generate random input, feed it to the application, keep doing this until the application breaks. It's surprisingly effective. In a recent study they did this with Windows application software, feeding random Windows events to it, so effectively it simply sat there at full computer speed continuously clicking randomly, closing and opening dialog boxes, picking menu items, and typing. And about half the Windows software they subjected to this particular torture, crashed.

Re[4]: Как писать ПО лучше

Если позволят модераторы, еще поспамлю (эту книгу я уже поминал):

Фредерик Брукс "Мифический человеко-месяц".

Книга, скорее, для руководящих лиц, но и программеру есть что почерпнуть.

Алан Кокс - старый пердун, свихнувшийся от проганья. Не слушайте его дети, ему даже 2.6 порулить не дали. И вообще он МВА.

Гон. Я сижу в дойч банке, пишу на яве

>Для 64-битного процессора: 2^64 * 2^64 = 2 ^ 128. Допустим, проверить можно 2 ^ 38 вариантов в секунду. Получаем 2 ^ 90 секунд. Для сравнения - в сутках 86400 секунд, в году - ~31557600. В общем, 2 ^ 60 лет будете проверять. Это если операция вне контекста. А если ещё зависим от флагов, от кэша, от электномагнитного фона, от излучения из космоса ( это, кстати, тоже учитывается, если не знали ).

Да я вижду, ты большой специалист! Ну проверяй так, если тебе хочется :)... А я уже не первый раз делаю сложные проекты на FPGA и смею тебя уверить - искать багу в логическом описании сумматора вообще никогда не требуется. А еще есть, знаешь ли, конечные автоматы, таблицы истинности и пр. надежные способы проверки и проектирования. Разнообразие микросхем поистине велико, а ошибок, как видишь - практически нет. Чаще просто технологический брак. А баги встречаются вообще очень редко. Еще раз повторяю, как человек, имеющий неплохой практический навык проектирования в цифровой электронике: допустить ошибку в железке гораздо и гораздо сложнее, чем в софте!

Самое главное - code reusing решает гораздо больше проблем, чем создает в плане багов хотя бы потому, что то, что уже работает - как правило хотя бы работает, в отличие от того, что надо еще написать до стадии, чтобы оно заработало.

Второе, у языка Си, упомянутого в статье, реально сейчас нет разумной альтернативы, кроме, разве что, языка Ада. Для задач, которые решаются на языке Си, разумеется, а это - ядра ОС, драйвера, приложения для встроенных систем, софт для железа одним словом. Между прочим, не думаю, что сильно погрешу против истины, если скажу, что Linux написан на языке Си не частично, а полностью, поскольку является ядром по определению :)

Что касается языка С++, то, во первых, GC вполне возможен и реализуем на С++ (если кого это удивляет - есть литература по данному вопросу, практически в любой книжке, посвященной smart-указателям). Во вторых, GC как таковой не является необходимым, так как есть стандартные контейнеры (и нестандартные тоже, если программист на С++ достаточно квалифицирован :) Прямая работа с выделением памяти, если она реально необходима (а если она необходима - поверьте на слово, лучше, чтобы она была ;), может быть инкапсулирована и спрятана куда подальше.

В общем идея в том, что смешивать понятия Си и С++, либо утверждать, что Java лучше по определению - означает нежелание серьезно разобраться в вопросе и повышать свою квалификацию.

PS: вообще я замечаю тенденцию последнее время клепания новых языков и фреймворков - порипать С++, приделать к остаткам былого величия GC, организовать исполнение байт-кода, и обозвать всё это новым языком или платформой, по типу Java или .NET :)

> Ошибки все равно будут - хотя бы в самом сборщике мустора - его то надо как то писать тоже =))

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

И это должно стать базовым принципом ;)

netch: еще раз говорю, GC - это не кубок грааля, не может он являться самоцелью. Сборщик мусора сразу ограничивает область использования языка автоматически. Java - хорошо, но всё на ней не напишешь, как уже было отмечено ранее насчет KDE и других подобных монстров :) А самое главное, не дает он той степени безопасности, которая бы стоила его применения, поскольку те же проблемы можно решать эффективнее использованием других средств языка, например контейнеров и умных указателей. :) Только мозги нужны в голове, но без этого лучше в программирование не лезть.

Про reusing очень согласен. А принцип уже давно заложен (AKA Unix way). Маленькие и функционально конкретные кусочки гораздо проще отслеживать и отлаживать, проще сопровождать. Но не все внимают этому принципу.

GC и в C можно сделать легко и непринужденно. Совсем недавно для ознакомления скачал один такой коллектор. Очевидный и простой код.

А еще есть проект BetterC. Человек воодушевился идеями Design By Contract в Eiffel и сделал библиотеку с макросами (m4? не помню просто) для C. В действии BetterC не пробовал.

Тут ещё стоит тогда Cyclone помянуть. Тоже мегарулез...

> netch: еще раз говорю, GC - это не кубок грааля, не может он являться самоцелью.

Я его и не предлагал самоцелью.

Это одно из свойств исполняющей среды. Исполняющую среду надо рассматривать во всей её совокупности, но если она обеспечивает собственное управление памятью - это серьёзно помогает.

> А самое главное, не дает он той степени безопасности, которая бы стоила его применения, поскольку те же проблемы можно решать эффективнее использованием других средств языка, например контейнеров и умных указателей. :)

Понимаешь в чём дело... ты напишешь _свою_ часть с контейнерами, smart pointers и прочими радостями. А потом тебе надо будет использовать какую-то другую библиотеку, в которой в каких-то непонятных случаях затирается часть совершенно чужой памяти (приводя к разносу всего вокруг твоими же "умными" указателями, не рассчитанными, естественно, на столь грубое вмешательство). А потом окажется, что из твоих 100,000,000 строк примерно 100,000 используют классические, "глупые" указатели, и тебе ещё надо будет их найти все. В борьбе с глюками этого потратится ещё часть времени...

У меня нет никаких возражений против того, что C++ со smart pointers и прочими удобствами даёт тебе возможность писать значительно бОльшие объёмы кода без ошибок и с минимумом отладки по сравнению с тем, что даёт C++ в голом виде, а он в свою очередь - по сравнению с C. Но рантайм с полностью взятым на себя распределением памяти может ещё больше сдвинуть границу возможностей вверх, за счёт того, что все грабельные поля у него собраны в один маленький сто тысяч раз проверенный кусок кода.

"_Может_", конечно. Ему что-то ещё может помешать. Но если не помешает... И, наконец, это просто удобно. Писать даже что-то мелкое на языке, в котором все эти грабли уже аккуратно разломаны и засунуты в механизм, и не будут вылазить. И где не нужно даже просто учить, что такое smart pointers и чем они лучше простых указателей, не нужно знать все сверхтонкие особенности инстанциации шаблонов...

Что именно будет из комплекта Perl/Tcl/Ruby/Python/Lisp/Scheme/Haskell/etc. - тут уже вторично. Собственно, C никогда не задумывался как язык, на котором надо писать всё. Керниган с компанией думали, что верхним уровнем будут sh, awk и прочие. Они просчитались в том, что не заполнили нишу полноценного скриптового языка (Perl и Tcl - пришли значительно позже, и показали пример того, как должен был бы выглядеть шелл, если бы не был сделан через то, где темно у негра); ну и скорость тогдашнего железа привела к тому, что на PC пошёл именно Си в основные средства разработки. История появления C++ - это в значительной части история того, что пришлось заполнять огромную зияющую дыру в средствах, и ситуация потребовала заполнения её со стороны низкого уровня. Но кто говорит, что так надо делать сейчас? Пропагандируемый сейчас "бутербродный" метод (C внизу для наиболее критичных по скорости/памяти подзадач, общий скриптовый язык в середине, специализированные скрипты-конфиги сверху) может дать результат не хуже, и даёт во многих случаях.

Фу-ух, расписался. В общем, "пусть цветут сто цветов" ;)))

> А потом тебе надо будет использовать какую-то другую библиотеку, в которой в каких-то непонятных случаях затирается часть совершенно чужой памяти

Библиотека - она и есть библиотека. То, что происходит внутри библиотеки - относится на совести её автора. Современный подход к программированию (например, технология COM) позволяет писать и использовать библиотеки, пригодными к использованию в любых языках. Короче, суть в том, что библиотеки к выделению памяти не имеют никакого отношения. Выделение памяти на уровне библиотеки _обязано_ быть инкапсулировано, что собственно успешно и делается независимо от языковых средств.

> (приводя к разносу всего вокруг твоими же "умными" указателями, не рассчитанными, естественно, на столь грубое вмешательство).

Это нонсенс. Какое такое грубое вмешательство? :) Литературно конечно фраза звучит красиво, но по сути. Чтобы библиотека фигачила данные в чужую память... Это надо блин постараться сделать. Сначала надо обнаружить эту чужую область памяти, чтобы в неё что-то зафигачить. Потом обмануть операционную систему, которая не должна давать что-либо фигачить по чужим адресам. В особенности, если библиотека построена на COM, CORBA (или вообще на обобщенном RPC) и находится на внепроцессном сервере - тогда такое просто невообразимо!

> А потом окажется, что из твоих 100,000,000 строк примерно 100,000 используют классические, "глупые" указатели, и тебе ещё надо будет их найти все. В борьбе с глюками этого потратится ещё часть времени...

Глюками чего? :) Выделения памяти - я уже всё объяснил. Глюками поиска "глупых указателей? :) А если их нет, что делать, как искать глюки? :) Или даже если есть (глубоко инкапсулированы и приносят реальный выигрыш по эффективности), почему они обязаны вызывать какие либо глюки? Я, извините, не понимаю :) Вас похоже научили, что если есть выделение памяти - то оно обязано быть ошибочным. Так вот, сообщаю, к счастью это не так :) Большинство сервисов для ОС Linux написаны на языках Си и С++ и работают годами, не вызывая значительных memory leaks. А вот одна программулина на Java может сожрать на раз всю доступную системе память ;) Потом, конечно, она её освободит (когда-нибудь, когда это соблаговолит сделать GC :), но системе то от этого не легче, потеря производительности будет серьезная. :)

> История появления C++ - это в значительной части история того, что пришлось заполнять огромную зияющую дыру в средствах, и ситуация потребовала заполнения её со стороны низкого уровня.

С точки зрения ООП, более мощным языком _высокого_ уровня, чем С++, является разве что SmallTalk :)

PS: прошу заметить, что я не собираюсь спорить, что обобщенно GC может быть полезен. Он конечно может быть полезен, за счет того, что область применения софта, написанного с его помощью, будет серьезно ограничена.

Да, вот еще что, использование GC действительно позволяет снизить требования к квалификации программиста. Однако, что-то я пока что не замечал, чтобы программистам на Java или С# платили меньше, чем программистам на С++ :) Парадокс, не правда ли? :)

Использование GC позволяет сосредоточится на непосредственном решении задачи, не создавая новой задачи управления распределением памяти. Вообще назначение языков высокого уровня дать программисту возможность мыслить в терминах решаемой задачи, не вводя дополнительных категорий.

Стандартный прикол местных недоучек. Если GC - то сразу Жаба. Про тот же Лисп все забыли, да? GC не ограничивает область применения - даже для жёсткой ембедщины.

Да, с точки зрения правильности ОО - почти все ОО-языки лучше, чем C++, не только Smalltalk (хотя таки он - среди лучших). И Eiffel, и даже Питон - существенно кошернее, чем C++. Да и Жаба с точки зрения ОО почище будет.

НИЧТО не позволяет снизить допустимый предел квалификации программиста. Просто языки с GC позволяют программисту заниматься более важными вещами, чем отлов утечек памяти.

Предотвращение race conditions

> Это нонсенс. Какое такое грубое вмешательство? :) Литературно конечно фраза звучит красиво, но по сути. Чтобы библиотека фигачила данные в чужую память... Это надо блин постараться сделать.

Ничего не надо стараться. Достаточно случайно перекрыть указатель чем-то другим. Да, надо писать не очень хорошо (мягко говоря) чтобы такое получить, но методы есть ;))

И чем больше у Вас кода на языке, который _потенциально_ допускает такую возможность, тем больше вероятность такой позы. У Вас же нет, наверно, _автоматического_ чекера кода на C++ на предмет отсутствия dumb pointers? А сканировать всё глазами - операция 100% невыполнимая.

> Я, извините, не понимаю :) Вас похоже научили, что если есть выделение памяти - то оно обязано быть ошибочным. Так вот, сообщаю, к счастью это не так :)

Нет, меня не учили, но опыт показывает: если ошибки могут быть сделаны - они будут сделаны. Потому что errare humanum est.

И единственный путь обеспечить отсутствие ошибок - автоматизированное средство, которое не допускает таких ошибок. Например, в каком-то году началось распространение языков, в которых нет возможности использовать неописанную ранее переменную. И ошибки соответствующего класса (просто описки кодера) исчезли.

Точно так же и с выделением памяти: пока есть _возможность_ делать ошибку - они будут. Повторю вопрос: у Вас есть автоматический чекер кода на отсутствие использования dumb pointers? Если нет - этого IMO достаточно, чтобы считать средство ненадёжным в плане защиты от ошибок кодирования в области работы с указателями.

> Большинство сервисов для ОС Linux написаны на языках Си и С++ и работают годами, не вызывая значительных memory leaks.

"Значительных"? Да вообще никаких не должно быть, если средство действительно защищает от них.

А сколько лет могут вычищаться малозаметные ошибки, Вы не замечали? Я слежу за этим, сам нашёл десяток плюх (во freebsd) и добился починки большинства найденных. Да, это немного. Но я и не старался искать. А на самом деле их ещё в десятки раз больше. И Linux тут, FreeBSD или Windows - разницы нет: если к коду не было жесточайшего контроля и аудита - их будут тысячи, если были - сотни, ну десятки. Но отсутствия ошибок не будет.

А когда среда исполнения своим конструктивом просто не допускает ситуации вроде записи по указателю, который затёрт чужими данными - этой вероятности просто ноль. Извините, что повторяю в третий раз тот же тезис.

> С точки зрения ООП, более мощным языком _высокого_ уровня, чем С++, является разве что SmallTalk :)

А я не про голую мощь. C++ с ассемблерными вставками будет ещё мощнее, но будет ли безопаснее и надёжнее? Ой вряд ли.

> PS: прошу заметить, что я не собираюсь спорить, что обобщенно GC может быть полезен. Он конечно может быть полезен, за счет того, что область применения софта, написанного с его помощью, будет серьезно ограничена.

Вы тут немножко путаете грешное с праведным. Как минимум, следовало бы говорить про среды исполнения с GC на её объекты. А не про чистый GC сам по себе, который просто обязателен в случае сложных запутанных сетей объектов и который не может быть заменён никакими другими методами.

Далее, если про среды с собственным управлением памятью, недоступным программисту. Да, у них возможности меньше, кто бы спорил, я не буду. Но зато для подавляющего большинства применений эти возможности, которые там не даются, не нужны или просто вредны (тем, что провоцируют ошибки в их использовании). И на их средствах тем, кто не имеет длительного опыта писания на том же C++, кодировать просто легче.

Я так понимаю, что различие наших точек зрения вытекает из различия задач и из них - средств построения. У меня сейчас это в основном unix и "бутербродное" построение средств (C внизу, Perl/Tcl/etc. посредине, спецконфиги/скрипты сверху). У Вас - в основном Windows (да?) и монолитный конструктив. Я с этим подходом работал, но могу сравнивать два варианта видев каждый из них и снаружи, и изнутри;) - и вижу, что большинству народа писать на чём-то перло-тикле-питоно-образном _значительно_ легче (а значит, вероятность ошибок значительно меньше), чем осваивать C++ + все тонкости шаблонов + boost...

Кстати, посмотрите Joel'а про то, что некоторой части людей работа с указателями не даётся принципиально из-за врождённых особенностей их мышления. Я не склонен безоговорочно принимать на веру его утверждение, но если это так, то язык без указателей имеет значительно бОльшую потенциальную базу...

>Кстати, посмотрите Joel'а про то, что некоторой части людей работа с указателями не даётся принципиально из-за врождённых особенностей их мышления.

А части людей не дается игра на музыкальных инструментах в силу врожденного отсутствия музыкального слуха, давайте для таких людей на скрипках лады приделаем (как на гитаре) - чтобы они хоть как-то играть могли. Не беда, что нормально они (в силу врожденных особенностей) все-равно играть не смогут - зато будет политкорректно :)

Ну и аналогию можно дальше развивать, на самом деле. В общем, не можешь с... - не мужай ж... :)

Я вижу Вы долго думали, прежде чем написать ответ, чтож, похвально.

> Ничего не надо стараться. Достаточно случайно перекрыть указатель чем-то другим. Да, надо писать не очень хорошо (мягко говоря) чтобы такое получить, но методы есть ;))

При внепроцессном сервере ситуация невозможна, еще раз повторяю. Защита на уровне операционной системы.

> У Вас же нет, наверно, _автоматического_ чекера кода на C++ на предмет отсутствия dumb pointers?

Есть, система предупреждений и ошибок при компиляции.

> ет, меня не учили, но опыт показывает: если ошибки могут быть сделаны - они будут сделаны. Потому что errare humanum est.

Разумеется. Больше того, ошибки будут сделаны в любом случае, могут быть они сделаны или нет (как показывает опыт). Поэтому писать программы по этой логике вообще нельзя, заранее известно, что какие-либо баги всё равно будут :) Я говорю о том, что такое языковое средство, как управление памятью, создает гораздо больше возможностей, чем создает проблем, только и всего.

> А я не про голую мощь. C++ с ассемблерными вставками будет ещё мощнее, но будет ли безопаснее и надёжнее? Ой вряд ли.

Я специально сказал, Объектно Ориентированное Программирование. И тем не менее всплывает ассемблер. Опять литературный приём. Если я говорю об ООП, то имею ввиду именно ООП, а не тупую ассемблерную мощь. Я вижу, спорить Вы умеете, но старайтесь всё же по сути общаться.

> Нечто по поводу опыта написания программ на С++

У меня есть стойкое мнение, что ошибки в гораздо большей степени связаны с недостаточной квалификацией программиста, нежели чем с разницей в языковых средствах. Человек, который не умеет писать программы, наделает ошибок и на Java и на С# с таким же успехом, как и на С++ и на любом другом языке. Разница в этом случае, есть GC, нет GC уже непринципиальна :) Собственно поэтому и платят деньги за квалификацию и опыт, умение решать задачи и находить так или иначе возникающие ошибки, а не за твердую уверенность, что GC решит все возможные проблемы :)

> так понимаю, что различие наших точек зрения вытекает из различия задач и из них - средств построения. У меня сейчас это в основном unix и "бутербродное" построение средств (C внизу, Perl/Tcl/etc. посредине, спецконфиги/скрипты сверху). У Вас - в основном Windows (да?) и монолитный конструктив. Я с этим подходом работал, но могу сравнивать два варианта видев каждый из них и снаружи, и изнутри;) - и вижу, что большинству народа писать на чём-то перло-тикле-питоно-образном _значительно_ легче (а значит, вероятность ошибок значительно меньше), чем осваивать C++ + все тонкости шаблонов + boost...

Если уж Вы так заинтересовались, в настоящее время я пишу ПО по большей части на pure C под операционные системы реального времени. POSIX, не Windows :) Linix тоже используется, как тестовая и отладочная платформа :) Скриптовые языки, как и администрирование в понятии системного адсинистратора ненавижу :) От одного слова Perl меня выворачивает, если при этом не ограничивается задача распарсить текст.

> А части людей не дается игра на музыкальных инструментах в силу врожденного отсутствия музыкального слуха, давайте для таких людей на скрипках лады приделаем (как на гитаре) - чтобы они хоть как-то играть могли. Не беда, что нормально они (в силу врожденных особенностей) все-равно играть не смогут - зато будет политкорректно :)

Не-а, для них сделаны проигрыватели/магнитофоны всех видов, драм-машины и прочие хитрые устройства. И работают, заметьте.

Кстати, такого отсутствия музыкального слуха, чтобы даже "блатной квадрат" нельзя было сыграть, я ещё не видел. Если речь не идёт про физическую глухоту.

В общем, Вы меня поняли. ;))

> Я вижу Вы долго думали, прежде чем написать ответ, чтож, похвально.

Спасибо, не за что. Я тут вообще почти случайно и скоро снова не буду заглядывать несколько месяцев ;))

>> Ничего не надо стараться. Достаточно случайно перекрыть указатель чем-то другим. Да, надо писать не очень хорошо (мягко говоря) чтобы такое получить, но методы есть ;))

> При внепроцессном сервере ситуация невозможна, еще раз повторяю. Защита на уровне операционной системы.

Защита от вылета при срабатывании? Или всё же ещё до использования такого указателя? Что-то мне во второе слабо верится.

>> У Вас же нет, наверно, _автоматического_ чекера кода на C++ на предмет отсутствия dumb pointers?

> Есть, система предупреждений и ошибок при компиляции.

И оно опознает одновременное описание тупого указателя и его использование в этой роли? Сомневаюсь...

>> А я не про голую мощь. C++ с ассемблерными вставками будет ещё мощнее, но будет ли безопаснее и надёжнее? Ой вряд ли.

> Я специально сказал, Объектно Ориентированное Программирование. И тем не менее всплывает ассемблер. Опять литературный приём. Если я говорю об ООП, то имею ввиду именно ООП, а не тупую ассемблерную мощь. Я вижу, спорить Вы умеете, но старайтесь всё же по сути общаться.

Просто у Вас было достаточно неконкретно расписано. А я в первую очередь ощупываю маргинальные случаи, чтобы определить границы понимания и интерпретации. Голый спор тут не планировался.

А теперь выведу рассмотрение опять же в предельно пограничный случай. Есть код с ассемблерной вставкой. Ну вот кто-то написал так из команды этак в сотню человек. Опознать автоматически сможете? Без чтения глазами всего кода? Если думаете, что сможете при текущих параметрах кода, то увеличим рассматриваемый объём сразу в 1000 раз.

А теперь всё это помножьте на фактор не квалификации Вашего уровня, а значительно более низкой.

> У меня есть стойкое мнение, что ошибки в гораздо большей степени связаны с недостаточной квалификацией программиста, нежели чем с разницей в языковых средствах. Человек, который не умеет писать программы, наделает ошибок и на Java и на С# с таким же успехом, как и на С++ и на любом другом языке. Разница в этом случае, есть GC, нет GC уже непринципиальна :) Собственно поэтому и платят деньги за квалификацию и опыт, умение решать задачи и находить так или иначе возникающие ошибки, а не за твердую уверенность, что GC решит все возможные проблемы :)

Так вот - нет у нас (в глобальном смысле, т.е. на планете Земля) достаточного количества программистов столь высокого уровня. И надо рассматривать средства, которые дают полноценно работать и совершать минимум ошибок остальным.

А тут и оказывается, что GC в таких средствах практически всегда принципиально необходимый конструктивный элемент.

> Если уж Вы так заинтересовались, в настоящее время я пишу ПО по большей части на pure C под операционные системы реального времени. POSIX, не Windows :)

Ага. Ну там действительно бутербродный дизайн слишком часто не подходит.

> Linix тоже используется, как тестовая и отладочная платформа :) Скриптовые языки, как и администрирование в понятии системного адсинистратора ненавижу :) От одного слова Perl меня выворачивает, если при этом не ограничивается задача распарсить текст.

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

Я предлагаю на этом закончить обсуждение.;)) Просто задачи слишком разные. Если бы мне вот прямо сейчас оказалось нужно строить что-то в том же realtime, я бы тоже стал смотреть в сторону тех же методов. ;))

С++ для железяк между прочим не очень то используется. Это скорее для desctop'a хороший добротный язык, в котором есть всё что нужно для счасться. Язык общего назначения. Java - тоже хорошо. Там есть почти всё, что нужно для полного счастья :) Кое чего нет, но вроде не очень и нужно, если использовать Java для того, для чего оно предназначено.

PS: а насчет квалификации, её оценить в форуме довольно сложно, не стоит.

> Гон. Я сижу в дойч банке, пишу на яве
В такой?: http://www.galacentre.ru/photos/400/804/804090.jpg

> С++ для железяк между прочим не очень то используется. Это скорее для desctop'a хороший добротный язык,

Мнэээ... Вы говорили про realtime, а теперь про железяки.

Я оценивал с той стороны, что получить хороший реалтайм (неважно, железка будет мощностью в 8051 или в современный писюк) можно только детально зная тайминги всех потрохов. У того же GC простые реализации дают неравномерные длительные задержки, а сложные - сложно делать;)) Там действительно управление памятью самим кодером способно дать гарантированное время работы подложки.

Но это опять же весьма специальный случай.

> Java - тоже хорошо. Там есть почти всё, что нужно для полного счастья :) Кое чего нет, но вроде не очень и нужно, если использовать Java для того, для чего оно предназначено.

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

> PS: а насчет квалификации, её оценить в форуме довольно сложно, не стоит.

А я и не оценивал - так, прикидка на диапазон оценки. А надо было вместо лёгкой лести попинать в духе фидошного флейма? ;))

netch: ну, вообще, что касается лести, было высказано желание закончить флейм. При этом проявлено уважение к собеседнику (даже излишнее, что было мной мягко отмечено). Я бы мог и дальше жестко комментировать по сути, но, раз уж такое дело, решил что не стоит.

Да, а realtime нужен как раз в основном для работы с железом.

>Еще раз повторяю, как человек, имеющий неплохой практический навык проектирования в цифровой электронике: допустить ошибку в железке гораздо и гораздо сложнее, чем в софте! Ню-ню... Ты знаещь почему существует просто недетская куча design rules? Причём зачастую закладываются, где нужно и где нет. Да потому что ПРАКТИЧЕСКИ НЕВОЗМОЖНО оптимально layout рассчитать. Индуктивность, прыжки ёмкости, дефеткы техпроцесса, который позволяет делать только приблизительно нарисованные вещи! Я не знаю, может ты лично проектируешь под .50 техпроцесс и под 10кГц, а я говорю про процессоры, которые работают у тебя в компьютере. Там и частоты другие, и взаимодействие тоже. Как домашнее задание: как вы думаете, почему некоторые фирмы отменяли некоторые проекты, если всё так просто? И поверь мне, я знаю, о чём говорю, очень и очень хорошо. Для того, чтобы формальная верификация работала, нужно очень долго разрабатывать design rules. И знаешь, сколько времени проходит между tape-out'ом и продажей?

Мой пост был: не всё так просто, и проверить, что "всё работает", далеко не тривиальная задача.

>Как писать ПО лучше

А, может, его лучше вообще не писать? ;)

Это закнутый круг... Никто тебе твою ботву (отпускб квартира и т.п.) просто так не даст... так что придется потерпеть....однажды разоврать этот порочный замкнутый круг....и всем юудет хорошо :-)