После двух лет разработки доступен (http://sourceforge.net/mailarchive/forum.php?thread_name=201...) релиз инструмента Valgrind 3.8.0 (http://valgrind.org/), предназначенного для отладки работы с памятью, обнаружения утечек памяти и профилирования потребления памяти. В новой версии добавлена полная поддержка платформ MIPS32/Linux и X86/Android, а также частичная поддержка Mac OS X 10.8 (Mountain Lion). Обеспечена поддержка наборов инструкций POWER DFP, Intel AVX и AES. Добавлена поддержка новых дистрибутивов и системных инструментариев (glibc 2.16, gcc 4.7). Внесена большая порция оптимизаций производительности и сокращено потребление памяти. Добавлена поддержка реализаций malloc, не из состава libc, что позволяет отлаживать программы, статически слинкованные с такими библиотеками, как TCMalloc и JEMalloc.URL: http://sourceforge.net/mailarchive/forum.php?thread_name=201...
Новость: http://www.opennet.me/opennews/art.shtml?num=34569
Языки без автоматического управления памятью должны остаться в прошлом веке
Пока процессор и остальная обвязка не научится обрабатывать непосредственно высокоуровневые конструкции языков и реализовывать автоматическое управление памятью все уровни программирования от предметно ориентированного до машинного кода будут иметь свою нишу. И да, Вы полный неадекват.
> Пока процессор и остальная обвязка не научится обрабатывать непосредственно высокоуровневые конструкции языков и реализовывать автоматическое управление памятью все уровни программирования от предметно ориентированного до машинного кода будут иметь свою нишу.А после того, как они это научатся, мы получим аппаратно реализованные тормоза и глюки.
Именно так. Хотел дописать, но подумал, что догадаются.Можно скорректировать:
> ...не научится обрабатывать...на
> ...не научится эффективно обрабатывать...
Эльбрус-1, -2, барроузовские машины - на аппартное управление веделением ОП как то народ не жаловался. Особенно после GETMAIN/FREEMAIN :)
Не вдаваясь в тонкости управления памятью в Эльбрус-1, -2, изначальный вопрос состоял в автоматической сборке мусора, что ИМХО более высокоуровнево, но может и ошибаюсь. В любом случае распространенность остальных систем и распространенность Эльбрус снижают полезность продолжения этой беседы до 0.
> Не вдаваясь в тонкости управления памятью в Эльбрус-1, -2, изначальный вопрос состоял
> в автоматической сборке мусора, что ИМХО более высокоуровнево, но может и
> ошибаюсь.Сборка мусора там как раз была. Эльбрусы да, не выжили. А барроузовская платформа вполне себе существует. Только сменила владельца.
> В любом случае распространенность остальных систем и распространенность Эльбрус
> снижают полезность продолжения этой беседы до 0.Ну почему же. ВМ последние годы активно плодятся. Так что проблема в полный рост.
>Эльбрусы да, не выжили.Ну почему же? В оборонке они используются. Да и вот, например - http://sdelanounas.ru/blogs/20202/
> Ну почему же? В оборонке они используются. Да и вот, например -
> http://sdelanounas.ru/blogs/20202/Интересно, почему США или там китай не занимаются созданием таких сайтов? Может, секрет в том что дела за себя говорят лучше слов?
Как это не занимаются? Они просто делают это на гораздо более мощном уровне www.cnn.com например.
> Как это не занимаются? Они просто делают это на гораздо более мощном
> уровне www.cnn.com например.cnn.com не занимается коллекцией всего булшита мира по принципу "сделано в сша".
Вместе с вменяемыми требованиями к оперативной памяти. Со всякими явами и питонами уже сейчас 4х гиг не хватает...
> Вместе с вменяемыми требованиями к оперативной памяти. Со всякими явами и питонами
> уже сейчас 4х гиг не хватает...Ну не надо говно брать. Тот же OCaml жрёт очень мало, компилирует значительно быстрее С++, а скорость выполнения примерно такая же.
> Ну не надо гoвно брать.Кто ж виноват что громче всего орущие скриптокиды обычно про него вещают?
> Тот же OCaml жрёт очень мало, компилирует
> значительно быстрее С++, а скорость выполнения примерно такая же.Ну и как, рискнули бы вы прокатиться на авто где памятью будет автоматически рулить в критичных системах (отказ которых ведет к ДТП) это нечто? На си можно и полностью статиное распределение памяти отбабахать там где это надо. Так что память ни течь ни кончаться не сможет. А вот на "современных" ЯП - фиг с маслом. Такой уровень предсказуемости и надежности там попросту невозможен как класс.
> Ну и как, рискнули бы вы прокатиться на авто где памятью будет
> автоматически рулить в критичных системах (отказ которых ведет к ДТП) это
> нечто?Эээ, я, знаете, авто никогда не программировал. И большая часть программистов на С - тоже.
Кроме того, на авто, где отказ ПО ведёт к ДТП, я бы предпочёл вообще не ездить. Вне зависимости от того, на чём это ПО написано. (внезапная остановка двигателя к ДТП не приводит)
> Эээ, я, знаете, авто никогда не программировал. И большая часть программистов на С - тоже.А уж жаба-скриптеры и подавно. И вот поди ж ты - люди делают вполне себе надежные вещи. Которые ездят, плавают, летают и прочая. В том числе и с критичными функциями возложенными на софт. Просто потому что во многих случаях жесткой логикой это сделать не выйдет вообще и/или схема получится настолько сложной что ее надежность и бажность будет еще хуже.
> Кроме того, на авто, где отказ ПО ведёт к ДТП, я бы предпочёл вообще не ездить.
Тогда вам придется ходить пешком. Дело в том что современные нормы выхлопов типа евро-4 вообще нереально осилить без микроконтроллерного управления. ABS? АКПП? Опять же - без uC нереал. А в случае синхронных BLDC (электроскутеры/электровелосипеды, ...) - микроконтроллер вообще напрямую обмотки двигателя коммутирует, в реальном времени щелкая ключами. Вот так вот прсото и брутально. Просто потому что 3-фазную последовательность с переменной частотой и разным заполнением периода да еще анализом ряда условий на лету - как-то иначе не очень то и сделаешь. Такая штука обычно получает по цифровому интерфейсу команды типа "а сделай ка нам вот столько". Ну и может ошибки детектировать и рапортовать сразу. При том временами - до того как все разнесет к чертям. Благо у uC скорость реакция превосходит человека в тысячи раз.
> Вне зависимости от того, на чём это ПО написано. (внезапная остановка двигателя
> к ДТП не приводит)Ну если водитель среагирует - то может и не приведет. Но это весьма зависит от. Вот только если что - у микроконтроллеров скорость реакции получше будут. Например, для вас 0.1 секунды - очень быстро. Для микроконтроллера это вечность. Что и позволяет uC например выкинуть подушки безопасности на основе анализа показаний датчиков задолго до того как владелец расшибется. А будь управление отстрелом подушек в виде кнопки нажимаемой юзером (казалось бы надежнее) - юзер бы просто в 99% случаев не успевал бы нажать на кнопку или растерялся бы. А когда из юзера бифштекс - уже как-то немного поздновато кнопку жать.
На самом деле - оно вполне себе работает. При соблюдении специфичных правил и ответственном подходе. Более того - бортовые компьютеры нынче рулят большинством подсистем самолетов АФАЙК. И как бы еще не факт что это хуже чем человек надрывающийся в тщетных попытках осознать показания 100500 механических приборов.
> В том числе и с критичными функциями возложенными на софтКритичные функции _никогда_ нельзя полностью возлагать на софт. За подробностями гуглите Therac-25 (спойлер: медицинский прибор, у которого отключили аппаратную блокировку слишком мощного излучения, что (вместе с кривой прошивкой) привело к смерти нескольких человек)
а в железе багов не бывает, ага. какая разница, на что там возлагается? тестировать надо. и не «абы как», а всё и вся, и fuzz'ом тоже. не зря у нормальных контор бюджет и время на тестирование чуть ли не больше (а иногда и весьма больше), нежели бюджет и время на разработку.
Пишите аккуратно и не надо автоматически управлять памятью.А с помощью valgrind'а отладка производится быстро и удобно.
Да пускай пишет на говно-языках "будущего". Ему больше ниначём другом писать нельзя. Криворукость головного мозга.
> Пишите аккуратно и не надо автоматически управлять памятью.Это совет никогда не делать ошибок. :-)
> Это совет никогда не делать ошибок. :-)На си можно вообще не оперировать выделением памяти. При этом ошибки выделения памяти исключены чисто технически. Если у вас нет malloc то и юзать его вы не сможете. В фирмварях где нужна железобетонная предсказуемость и совершенно неприемлим отказ в невнятных условиях через полгода работы - так и делается.
> На си можно вообще не оперировать выделением памяти.Все на константные массивы!!! :)
И кстати, массивы переменной длины уже давно в стандарте.
> Все на константные массивы!!! :)В критичных применениях есть и такое. Вплоть до запрета в ответственных применениях адресной арифметики вообще. А как раз чтоб не нарваться на факап лишний раз. Вплоть до того что программа просто не собирается если такое в ней есть.
> И кстати, массивы переменной длины уже давно в стандарте.
Так это... стандарты разные бывают. Под разные нужды. Погугли и подивись: для высоконадежной эмбеддовки от факапа в которой что-то всерьез зависит (типа падения самолета или отвала бошки у опасной промышленной установки) - существует ряд своих требований и стандартов. Некоторые из них налагают по истине драконовские требования. Ради надежности и предсказуемости. Статичное распределение памяти и запрет арифметики с указателями - наиболее очевидное, что первым делом делается.
> На си можно вообще не оперировать выделением памяти.Это вы так тонко советуете вообще программы на С не писать? Разумно, конечно. Всё-таки, глупо писать программы, не выжимающие что-то специфическое из железа, на портабельном ассемблере, когда есть множество других языков.
>> На си можно вообще не оперировать выделением памяти.
> Это вы так тонко советуете вообще программы на С не писать?Почему же. На нем вполне можно писать. И даже очень ответственные штуки, которые на чем-то еще пожалуй фиг напишешь так же предсказуемо.
> Разумно, конечно.
Я как бы пытался намекнуть что в сях, стань оно реально надо, можно и вот так. А вот в этих автоматических ж@повытиралках для скрипткидисов - рукоятка отобрана. Система лучше знает. А то что это может к факапу вести и потере предсказуемости - так оно ж для скрипткидей на поиграться.
> Всё-таки, глупо писать программы, не выжимающие что-то специфическое из железа,
> на портабельном ассемблере, когда есть множество других языков.Ну да, все дураки, пишут уже столько лет системный софт на этом, просто потому что ничего лучше как-то и не появилось. А вот вы тут один умный. Правда на uC давно уже делают довольно критичные штуки, отказ которых вполне может иметь последствия. И программят или на голом асме или на сях. А на чем-то еще как-то и не получается особо, да и предсказуемость совсем не та уже.
Расскажи это Apple, пусть заменят ObjC на жабку, сынку
> Расскажи это Apple, пусть заменят ObjC на жабку, сынкуИх Oracle затроллит, так что ObjC так и будут строгать )))
>Расскажи это Apple, пусть заменят ObjC на жабку, сынкуObjC более продвинутый и современный язык чем Java, к тому же в нём тоже есть автомитическая сборка мусора (опционально)
Уже выпилили, зато запилили ARC
> Языки без автоматического управления памятью должны остаться в прошлом векеДовольно лицемерная заява в свете того что недавно был представлен инструмент для борьбы с утечками памяти в ... JS.
p.s. но я искренне желаю вам чтобы у таракашки управляющего "электронным газом" или ABS невовремя кончилась память. Это было бы заслуженным наказанием за общую идиотию и неспособность смотреть вокруг и видеть что-то кроме себя и своих задач.
мнение похаписта очень ценно для нас, пожалуйста продолжайте
весьма толсто, в стиле iZen
C#-compatible programmer detected.
В OpenWRT и производных появился в нативном виде и прекрасно работает на крохотныъ embedded системах. Трижды рулез!
В D сборка мусора реализована без всяких ВМ.
Так что можно спокойно писать на машинозависимых языках не задумываясь об утечках памяти. Скорее бы ...
> Так что можно спокойно писать на машинозависимых языках не задумываясь об утечках
> памяти. Скорее бы ...А зачем?
Машино-зависимые хороши только когда используемых платформ/железок довольно мало. Как только видов железа становится много, так сразу абстракции/VM/машино-независимость.
PS C# - машино-зависимый язык. Оно работает только на x86 и x86 64 bit ;)))
> PS C# - машино-зависимый язык. Оно работает только на x86 и x86 64 bit ;)))И только в виндовсе, по большому счету. Даже кроссплатформенного набора виджетов нету.
http://www.mono-project.com/Supported_Platforms - мужики-то не знали.
> http://www.mono-project.com/Supported_Platforms - мужики-то не знали.Мужики читать не научились. В какоме месте непонимание того что стандартного кроссплатформенного набора виджетов - нет? По поводу чего начинаются извращения, когда вместо paint.net появляется наполовину переписанная pinta. Такой вот хреновый written once, runs everywhere, что даже гтк или куть какой-нибудь более кроссплатформенный. По крайней мере, программы на GTK или Qt не требуется переписывать наполовину при переносе на иную ОС. Как максимум - перекомпилить.
1. Мой комментарий относился к "x86 и x86 64" предыдущего оратора.
2. Язык программирования никоим образом не связан с "стандартный кроссплатформенный набор виджетов". Gtk# - "стандартный кроссплатформенный набор виджетов" для _платформы_ mono. Windows.Forms - стандартный _не_ кроссплатформенный набор виджетов для _платформы_ .NET.
4. paint.net - столько раз обсуждалось почему так, чтоповоторять это сдесь - просто бессмысленно.
5. Покажите-ка мне программу на Qt или Gtk которая будет кроссплатформенно двигать курсом мыши, работу с окнами (взять дескриптор текущего выделенного окна чужого приложения, у найти у него 3-й дочерний виджет и установить ему какие-либо свойства), установить тему курсоров/окон. Не реализуя нескольких различных вариантов для Windows и Linux. Правда, очень интересно было-бы взглянуть.
пятый пункт сразу за слив считать?
или одумаетесь?зыж
винапи выносит моск напрочь.
не имеет права одна программа менять что-либо в окне другой программы.
точка.
нужно взаимодействие? используйте ipc. дбас наконец (который в кутэ есть).
дескриптор окана? а нету его. в некоторых платформах и окон нету.
курсор? в своём окне хоть сто порций. тема? тоже самое. а в системе - да вы рехнулись.от подобных манипуляций уже даже мс отказывается (зарывая винапи в вин8рт)
Пятый пункт был приведен для того, чтобы показать что утверждение "По крайней мере, программы на GTK или Qt не требуется переписывать наполовину при переносе на иную ОС." - верно не для всех программ. Я не утверждал, что дескриптор окна должен быть на каждой системе, просто есть гора и маленькая тележка решений которые не переносимы на другие системы. Реализация того-же D-Bus для Windows появился не так давно, и его использование под Windows не является распространенным явлением.
Сборка мусора либо автоматическая либо ручная.То, что приложение можно запустить без VM - ни о чем не говорит. Ту же java можно собирать в нативные бинари. А сборка мусора как была автоматической, так и остается ;)))
> Сборка мусора либо автоматическая либо ручная.Вообще, бывали адекватные потуги - разрешить и так и сяк.
>> Сборка мусора либо автоматическая либо ручная.
> Вообще, бывали адекватные потуги - разрешить и так и сяк.потуги были, а вот результат в мэйнстриме не виден. увы.