Oberon space
General Category => Общий раздел => Тема начата: valexey от Февраль 06, 2012, 05:38:37 am
-
Во-вторых, там сборщик мусора всегда гарантированно работает линейное время (от размера кучи).
Кто бы мне пояснил... в чём радость от использования сборщиков мусора?..
К примеру, научили школяра/студента писать на oberon, где встроенный сборщик мусора. Устроился этот бывший школяр на работу программистом, а там на C++ пишут или на Delphi... И начались проблемы с протечками. Не лучше ли прививать культуру работы с памятью. Нет же в этом ничего заумного и трудного. Меня не напрягает для программ, где используется много объектов, расписывать карту памяти... это позволяет заблаговременно понять, что же и как, собственно, делается в программе... увидеть узкие места. Такие задачи никакой сборщик мусора за программиста не решит.
Другими словами, наличие сборщика мусора в среде разработки/языке я бы скорее оценил отрицательно... не говоря уже о тех проблемах (тормоза), которые поднял Сергей.
Ну, во-первых есть ситуации когда без сборщика мусора принципиально нельзя обойтись. Обычно они возникают в системах, где интенсивно используют динамическую подгрузку/выгрузку и горячую замену кода. В том же ерланге.
Во-вторых, без сборщика мусора очень печально становится с лямбдами. Просто очень-очень. Хотя, с лябдами вообще печально если есть мутабельные переменные, ибо получается лямбда-изврат.
В-третьих, предыдущие два это фигня на самом деле. Ну, то есть они объясняют зачем в ерланге сборщик мусора, но не объясняют зачем он скажем в XDS-Обероне. Так что вот главный довод - наличие в системе сборщика мусора позволяет массово использовать дешевых программистов, которые без сборщика мусора напишут ужас-ужас. А со сборщиком мусора будет вполне рабочий код.
-
А, ну забыл еще один пункт - система со сборщиком мусора В СРЕДНЕМ, работает быстрее чем программа со, скажем, подсчетом ссылок (shared_ptr и компания). Но это именно что в среднем. За скорость расплачиваемся отсутствием реалтайма (в случае императивного шарпа например, в ерланге, как я уже писал, все получше - софтреалтайм там имеется, впрочем софтреалтайм это таки не реалтайм ;-) ).
-
Хотя, с лябдами вообще печально если есть мутабельные переменные, ибо получается лямбда-изврат.
В F#, например, в лямбдах просто запрещено использовать мутабельные переменные.
В Хаскелле такие лямбды, использующие мутабельные переменные, автоматически причисляются к действиям ввода/вывода.
Иак что всё таки есть решения этой проблемы...
-
Ну, во-первых есть ситуации когда без сборщика мусора принципиально нельзя обойтись. Обычно они возникают в системах, где интенсивно используют динамическую подгрузку/выгрузку и горячую замену кода. В том же ерланге.
У меня довольно интенсивно используется перезагрузка данных, необходимости в сборщике мусора не возникало... Overlay в типовом программировании сейчас используется очень редко (уже и не припомню, когда в последний раз применял загрузку/выгрузку кода). То есть, это тоже сомнительный аргумент за использование сборщика мусора.
В программах я использую свой менеджер памяти (по сути, обёртка над функциями ОС)... С переходом к 64-разрядным вычислениям, проблем с нехваткой (виртуальной/адресуемой) памяти просто не должно быть.
Во-вторых, без сборщика мусора очень печально становится с лямбдами. Просто очень-очень. Хотя, с лябдами вообще печально если есть мутабельные переменные, ибо получается лямбда-изврат.
Лямбда - это отдельный разговор... для функциональщиков, а oberon императивный язык, насколько я понимаю.
В-третьих, предыдущие два это фигня на самом деле. Ну, то есть они объясняют зачем в ерланге сборщик мусора, но не объясняют зачем он скажем в XDS-Обероне. Так что вот главный довод - наличие в системе сборщика мусора позволяет массово использовать дешевых программистов, которые без сборщика мусора напишут ужас-ужас. А со сборщиком мусора будет вполне рабочий код.
Те, которые не умеют работать без сборщика мусора, рано или поздно, но всё равно породят "ужас-ужас", поскольку это не вопрос наличия мозгов, а вопрос культуры программирования. Некультурный программист нагадит, не в этом углу, так в другом. Опять же культуру надо прививать в самом начале... (я так думаю)
-
А, ну забыл еще один пункт - система со сборщиком мусора В СРЕДНЕМ, работает быстрее чем программа со, скажем, подсчетом ссылок (shared_ptr и компания). Но это именно что в среднем. За скорость расплачиваемся отсутствием реалтайма (в случае императивного шарпа например, в ерланге, как я уже писал, все получше - софтреалтайм там имеется, впрочем софтреалтайм это таки не реалтайм ;-) ).
Так я о том, что... проектирование программы - это одно, программирование/реализация - другое. Количество реализаций, которые могут быть хуже данной - неограниченно ничем, кроме фантазии.
Вопрос не в том, как определять объект подлежащий уборке, а в том нужно ли/полезно ли вообще применять GC.
-
Ну, а такие экстремальные ситуации, как у Сергея, требуют нестандартных подходов...
Это не экстремальные ситуации на самом деле. Как-то так сложилось, что все задачи с которыми я сталкиваюсь делятся на две категории:
1) Простенькие "скриптовые" задачки. Сюда же входят эксперименты с алгоритмами и структурами данных. В этих задачах можно либо вообще не освобождать память (программа отработает много раньше чем память кончится), либо все держать на стэке, либо пользоваться стандартными, скажем stl, контейнерами, которые за меня сами все сделают. То есть задачи где думать о памяти не нужно вообще и без сборщика мусора.
2) Задачи где проблем со сборщиком мусора больше чем без сборщика мусора. То есть идет большая прокачка данных, требуется реалтайм. Со сборщиком мусора приходится бороться (шаманить с настройками, с логикой программы, создавать некие пулы объектов которые засовываются и удаляются из пула естественно вручную (привет malloc/free) - в общем, изврат похлеще чем без него).
-
Те, которые не умеют работать без сборщика мусора, рано или поздно, но всё равно породят "ужас-ужас", поскольку это не вопрос наличия мозгов, а вопрос культуры программирования.
Есть ряд задач где программист просто не успевает пострадать от того ужаса который он наворотил - задача оказывается решена раньше, чем все это рухнет. Таким образом, с одной стороны имеем быстро и дешево решенную задачу (хорошо для бизнеса), с другой стороны программист не имеет шанса научиться хотя бы на своих ошибках, появляется некая самоуверенность что "могу все". При этом вырабатывается зависимость от конкретного языка, IDE и сборщика мусора ;-)
Если программисту встретится задачка более масштабная, то проект будет погребен под кучами написанного мусора.
Некультурный программист нагадит, не в этом углу, так в другом. Опять же культуру надо прививать в самом начале... (я так думаю)
Согласен. Самое смешное, что все (или почти все) учебные задачки входят как раз в то множество задач, где при небрежном программировании задача оказывается решена раньше, чем программист успевает пострадать от чудовищ им порожденных.
Поэтому первым языком должен быть какой-нибудь (возможно слегка упрощенный) ужас вроде чистого Си, где можно легко пострадать при отсутствии культуры программирования. Паскаль уже подходит хуже - он навязывает некую культуру программирования, при этом человек так и не поймет ЗАЧЕМ она вообще нужна, эта культура. Оберон подходит еще меньше, ибо там до кучи еще и сборщик мусора, который спасет обучающегося от злых утечек памяти (в учебных программах) и не спасет в реальных задачах.
-
Во-вторых, без сборщика мусора очень печально становится с лямбдами. Просто очень-очень. Хотя, с лябдами вообще печально если есть мутабельные переменные, ибо получается лямбда-изврат.
Скорее проблемы возникают с замыканиями (если они есть в языке) - точнее, с освобождением "захваченных" ресурсов - к ним же нет глобального доступа.
-
Кстати, примечательно, что ньюсгруппе языка D, в котором сборщик мусора есть, очень часто задают вопрос и обсуждают, как от него избавиться. То есть из рантайма и чтобы стандартная библиотека могла работать без него.
Видимо сборщик мусора таки мешается под ногами людям, ну и необходимости в нем народ не видит.
-
У меня довольно интенсивно используется перезагрузка данных, необходимости в сборщике мусора не возникало... Overlay в типовом программировании сейчас используется очень редко (уже и не припомню, когда в последний раз применял загрузку/выгрузку кода). То есть, это тоже сомнительный аргумент за использование сборщика мусора.
В программах я использую свой менеджер памяти (по сути, обёртка над функциями ОС)... С переходом к 64-разрядным вычислениям, проблем с нехваткой (виртуальной/адресуемой) памяти просто не должно быть.
Вообще говоря ДА - ПРИНЦИПИАЛЬНО без мусорозборки, работая в чисто императивной парадигме, обойтись ВОЗМОЖНО. Но давайте вспомним что состояние замкнутой системы в императивной парадигме ПОЛНОСТЬЮ описывается набором значений переменных на каждом шаге выполнения программы - т.е в общем случае -вы должны контролировать значения ВСЕХ переменных - по этому, чем их больше(и они структурно сложнее) и.или программа содержит большое число исполняемых инструкций - тем сложнее эта задача. По факту, эта способность зависит -от уровня программиста, ЯП, инструментария, сложности задачи. Исходя из этого, очевидно , что мусорозборник позволяет УСПЕШНО решать БОЛЕЕ сложные задачи конкретному программисту (либо простые но за меньшее время). Отдельная песня программирование СЛОЖНЫХ систем с использованием СТОРОННИХ компонентов, это тот случай , когда вы ПРИНЦИПИАЛЬНО не можете контролировать ВСЕ (компоненты идут в бинарном виде) - каждый из них может содержать до сотни тысяч строк кода (пример - современные GRIDы).
-
Самое смешное, что все (или почти все) учебные задачки входят как раз в то множество задач, где при небрежном программировании задача оказывается решена раньше, чем программист успевает пострадать от чудовищ им порожденных.
Увы... да.
Поэтому первым языком должен быть какой-нибудь (возможно слегка упрощенный) ужас вроде чистого Си, где можно легко пострадать при отсутствии культуры программирования.
Лучше уж сразу... ассемблер. :o Простые учебные задачки... позволяют. Опять же сформируется представление о памяти, вводе-выводе, принципах работы процессора... Вообще, мне всегда казалось, что для обучения лучше всего подходит именно тот путь, которым прошла цивилизация (ламповые вычислительные устройства и программирование перемычками в рассмотрение включать не будем... 8) ).
Паскаль уже подходит хуже - он навязывает некую культуру программирования, при этом человек так и не поймет ЗАЧЕМ она вообще нужна, эта культура. Оберон подходит еще меньше, ибо там до кучи еще и сборщик мусора, который спасет обучающегося от злых утечек памяти (в учебных программах) и не спасет в реальных задачах.
Паскаль надо давать на следующем этапе сразу после Фортрана/Си... Тогда он смотрится просто здорово!.. Вообще Паскаль - самый успешный проект Н. Вирта. Самым красивым, я бы назвал Модула2, а самым бесперспективным Оберон/Оберон2... IMHO, разумеется. И GC - это частный пример тотальной неудачи.
-
Кстати, примечательно, что ньюсгруппе языка D, в котором сборщик мусора есть, очень часто задают вопрос и обсуждают, как от него избавиться. То есть из рантайма и чтобы стандартная библиотека могла работать без него.
Видимо сборщик мусора таки мешается под ногами людям, ну и необходимости в нем народ не видит.
Тут опять идет речь об области эффективного и использования ЯП - задачи решаемые с помощью него СЕЙЧАС, вероятно, вполне могут обходиться без мусорозборника (и есть подозрение , что расширение области его эффективного использования не предвидится) -если это так , то в D мусорозборник можно будет считать ошибкой дизайна ЯП.
Кстати, господа, подспудно возникает мысля - что идея Вирта , о успешном совмещении в одном императивном ЯП качеств системного и высокоуровневого ЯП не очень успешна (получается ни рыба, ни мясо) - хотя Илья Ермаков, вроде говорил преимуществах такого подхода в своих системных задачах...
-
Паскаль надо давать на следующем этапе сразу после Фортрана/Си... Тогда он смотрится просто здорово!.. Вообще Паскаль - самый успешный проект Н. Вирта. Самым красивым, я бы назвал Модула2, а самым бесперспективным Оберон/Оберон2... IMHO, разумеется. И GC - это частный пример тотальной неудачи.
Чем Си с точки зрения низкоуровневого программирования принципиально лучше Модулы-2 и в чем безперспективность Оберон/Оберон2?
-
Сборщик мусора можно было бы заменить каким-нибудь анализатором кода, который бы облегчал программисту правильно организовать этот процесс.
-
Паскаль надо давать на следующем этапе сразу после Фортрана/Си... Тогда он смотрится просто здорово!.. Вообще Паскаль - самый успешный проект Н. Вирта. Самым красивым, я бы назвал Модула2, а самым бесперспективным Оберон/Оберон2... IMHO, разумеется. И GC - это частный пример тотальной неудачи.
Чем Си с точки зрения низкоуровневого программирования принципиально лучше Модулы-2 и в чем безперспективность Оберон/Оберон2?
В моём сообщении не говорилось о том, что Си лучше Modula-2, в том числе, не говорилось и с точки зрения низкоуровневого программирования.
Перспективность любого средства, и языка программирования, конечно, имеет несколько ключевых критериев:
- Важные, с точки зрения пользователей, преимущества перед аналогами, при успешном решении основной задачи/предназначения;
- Доступность (не только ценовая, но и понятность, документированность и пр.);
- Нацеленность на будущее (возможность развития, в частности, как сбережение инвестиций пользователей... опять же не только денежных, но и времени на изучение, создание собственных и чужих наработок и пр.)
С моей точки зрения ни по одной из перечисленных позиций Oberon не блещет.
-
Паскаль надо давать на следующем этапе сразу после Фортрана/Си... Тогда он смотрится просто здорово!.. Вообще Паскаль - самый успешный проект Н. Вирта. Самым красивым, я бы назвал Модула2, а самым бесперспективным Оберон/Оберон2... IMHO, разумеется. И GC - это частный пример тотальной неудачи.
Чем Си с точки зрения низкоуровневого программирования принципиально лучше Модулы-2 и в чем безперспективность Оберон/Оберон2?
Как минимум тем, что на нем написана система.... есть тонны литературы (в которых описываются нюансы программирования в терминах Си и сопутствующих моделей) и высококлассных специалистов.
-
Сборщик мусора можно было бы заменить каким-нибудь анализатором кода, который бы облегчал программисту правильно организовать этот процесс.
А что должен делать такой анализатор?
-
Как минимум тем, что на нем написана система.... есть тонны литературы (в которых описываются нюансы программирования в терминах Си и сопутствующих моделей) и высококлассных специалистов.
Первый раз вижу, чтобы высококлассных специалистов тоннами мерили... Хотя почему бы и нет?.. А нет... есть одно возражение. Если мерить тоннами, то американские программисты могут индусов... перевесить. Мой знакомый, переехавший в Штаты, как-то прислал фото с работы. В зале примерно 15-20 рабочих мест, и возле каждого по два стула, но не потому что там фанаты экстремального программирования, просто на одном стуле эти программисты не помещаются. Зрительно их средний вес ~150 кг. Сколь же индусов надо набрать, чтобы их перевесить... ;D
-
Как минимум тем, что на нем написана система.... есть тонны литературы (в которых описываются нюансы программирования в терминах Си и сопутствующих моделей) и высококлассных специалистов.
Первый раз вижу, чтобы высококлассных специалистов тоннами мерили... Хотя почему бы и нет?.. А нет... есть одно возражение. Если мерить тоннами, то американские программисты могут индусов... перевесить. Мой знакомый, переехавший в Штаты, как-то прислал фото с работы. В зале примерно 15-20 рабочих мест, и возле каждого по два стула, но не потому что там фанаты экстремального программирования, просто на одном стуле эти программисты не помещаются. Зрительно их средний вес ~150 кг. Сколь же индусов надо набрать, чтобы их перевесить... ;D
:)Ну это гипербола добавьте слово множество перед высококлассных :) :) если у вас есть проблемы с адекватным восприятием таких вещей (но признаюсь , я просто не вычитал сообщение)
-
Паскаль надо давать на следующем этапе сразу после Фортрана/Си... Тогда он смотрится просто здорово!.. Вообще Паскаль - самый успешный проект Н. Вирта. Самым красивым, я бы назвал Модула2, а самым бесперспективным Оберон/Оберон2... IMHO, разумеется. И GC - это частный пример тотальной неудачи.
Это из серии - разум предполагает , РЕАЛЬНОСТЬ - НЕ располагает.
-
А что должен делать такой анализатор?
Возможно, генерировать код, давать подсказки, по типу визарда.
-
:)Ну это гипербола добавьте слово множество перед высококлассных :) :) если у вас есть проблемы с восприятием
;)
-
А что должен делать такой анализатор?
Возможно, генерировать код, давать подсказки, по типу визарда.
Какой код - мы говорим о создании, уничтожении ДИНАМИЧЕСКИХ переменных.
-
Мой знакомый, переехавший в Штаты, как-то прислал фото с работы. В зале примерно 15-20 рабочих мест, и возле каждого по два стула, но не потому что там фанаты экстремального программирования, просто на одном стуле эти программисты не помещаются. Зрительно их средний вес ~150 кг.
Они сами в этом виноваты. После развала Союза у американцев резко вырос средний вес -- они просто потолстели.
Нефига было разваливать Союз... ;D
-
А что должен делать такой анализатор?
Возможно, генерировать код, давать подсказки, по типу визарда.
Какой код - мы говорим о создании, уничтожении ДИНАМИЧЕСКИХ переменных.
Он должен выдавать динамическую карту памяти.
А для таких целей анализаторы уже есть -- профайлеры...
-
А что должен делать такой анализатор?
Возможно, генерировать код, давать подсказки, по типу визарда.
Какой код - мы говорим о создании, уничтожении ДИНАМИЧЕСКИХ переменных.
Он должен выдавать динамическую карту памяти.
А для таких целей анализаторы уже есть -- профайлеры...
и логгеры - позволяющие делать "слепок" значений интересующих нас переменных в нужное время (точнее, в нужном месте) и записывать их в журнал (и помогать анализировать его) - но они являются ВНЕШНИМИ по отношению к ЯП и принципиально не снимают проблему КОНТРОЛЯ о которой я говорил ранее.
-
А как высококлассные специалисты собираются бороться с фрагментацией памяти?
-
А как высококлассные специалисты собираются бороться с фрагментацией памяти?
:) :) :) Путем создания своих менеджеров памяти, вестимо ;)
-
А как высококлассные специалисты собираются бороться с фрагментацией памяти?
У меня такой проблемы не возникало. Разнородные данные закачиваются из БД, каждый тип в свою область памяти, там и живут, пока нужны. Когда не нужны, все выбрасываются. Чтобы каждому типу хватило памяти, на этапе проектирования программы формируются карта распределения памяти.
С данными каждого типа работают, как с массивом (хотя количество данных меняется в широких пределах, но назвать этот массив динамическим язык не поворачивается). То есть, под массив отводится максимально нужное количество виртуальной памяти, но физически память выделяется в процессе закачки данных.
-
А как высококлассные специалисты собираются бороться с фрагментацией памяти?
Также как обычно. Например в MacOS (классике, а не в OS X) система умела компактифицировать память. То есть бороться с фрагментацией. При этом никаких сборщиков мусора не было.
-
А как высококлассные специалисты собираются бороться с фрагментацией памяти?
Также как обычно. Например в MacOS (классике, а не в OS X) система умела компактифицировать память. То есть бороться с фрагментацией. При этом никаких сборщиков мусора не было.
А можете пояснить в двух словах "как обычно"? Я вот не знаток MacOS классики.
Есть пауза при компактифицировании или нет? Допустим, объем памяти гигантский.
-
Обычные менеджеры памяти (окромя самых древних) в ОС делают дефрагментацию памяти, так что сам сборщик мусора, работающий поверх него, может и не знать ни о какой дефрагментации -- просто выделяет и когда соизволит -- освободит память.
Насколько я знаю, стандартные менеджеры памяти совсем не реал-таймные, пример -- дикие свопинги в винде или линупсе...
-
Обычные менеджеры памяти (окромя самых древних) в ОС делают дефрагментацию памяти, так что сам сборщик мусора, работающий поверх него, может и не знать ни о какой дефрагментации -- просто выделяет и когда соизволит -- освободит память.
Насколько я знаю, стандартные менеджеры памяти совсем не реал-таймные, пример -- дикие свопинги в винде или линупсе...
Не, это Вы зря... Менеджеры памяти и в WinNT/XP/7/серверных вариантах, и в Linux (на уровне ядра) сделаны очень грамотно. Да, и современные процессоры эффективно поддерживают работу с памятью. На физическом уровне вся память разделена на страницы. Никакого сжатия страниц нет. Освободившиеся страницы возвращаются ОС, где очищаются и, если необходимо, то передаются другому процессу, вставляясь в нужное место виртуальной памяти данного процесса. В случае, если физической памяти недостаточно, происходит запись "ненужной" страницы на внешний носитель, после этого страница помечается, как свободная, очищается и передаётся процессу, который запрашивает память. При обращении к выгруженной странице, происходит её загрузка с внешнего носителя на свободную страницу физической памяти и подстановка по заданному адресу. При этом может возникнуть ситуация, когда нет доступных страниц. Поэтому сначала выгружается другая "ненужная" страница, а на её место загружается "нужная". Отсюда и свопинг. Чем меньше физической памяти и чем интенсивнее выдаются запросы на выделение памяти, тем чаще страницы сбрасываются на внешний носитель и загружаются с него. Но другого, сравнимого по эффективности, алгоритма работы/устройства менеджера памяти нет.
-
В случае, если физической памяти недостаточно, происходит запись "ненужной" страницы на внешний носитель, после этого страница помечается, как свободная, очищается и передаётся процессу, который запрашивает память. При обращении к выгруженной странице, происходит её загрузка с внешнего носителя на свободную страницу физической памяти и подстановка по заданному адресу. При этом может возникнуть ситуация, когда нет доступных страниц. Поэтому сначала выгружается другая "ненужная" страница, а на её место загружается "нужная". Отсюда и свопинг.
Это немного не так. Есть разные стратегии. То что описано здесь - это простейший свопинг в ранних линуксах (возможно и в современных - не знаю) и скажем в Haiku. Оно отлично работает когда памяти достаточно и недостаток памяти бывает редко. Работает лучше чем то что в виндах. Но в условиях нехватки памяти (то есть когда памяти нехватает достаточно часто) оно начинает тупить. То есть все было хорошо, бац. памяти нехватило для чего-то. И оно ме-едленно и о-очень занудно начинает скидывать все ненужное в своп.
Винда действует иначе. Оно не дожидается когда же наконец появится задача которая не влезет в ОЗУ. Она старается все ненужное (давно не использующееся) постепенно сливать в своп. Без особого фанатизма, впрочем. То есть винда старается прозапас иметь сколько-то свободной оперативки. Если кому-то требуется память, то она выдается сразу из этой оперативки. А редкоиспользуемые страницы памяти продолжают постепенно уходить в своп. По сути ОЗУ в виндах это кэш для винчестера. Алгоритмы соответствующие - редкоиспользуемое из кэша выкидывается (перекладывается на диск). Таким образом даже если совсем ничего не делать (запущена один и тот же набор программ, никто у системы новую память не просит но и не освобождает), то винда все равно будет шуршать винтом выкидывая старье из оперативки (и закидывая обратно, если эта страница вдруг кому-то понадобилась). Это работает весьма эффективно для десктопа.
Первый вариант хорош для встроенки, серверов и тех случаев когда у нас либо оперативки много на десктопе, либо когда свопинг не желателен (например у нас SSD). Второй вариант хорош когда у нас ну, типичный такой десктоп с винтом и не предсказуемым набором приложений с не предсказуемыми потребностями по памяти. В случае SSD винда может очень быстро его убить свопингом (впрочем, MS вроде бы что-то допиливала чтобы в случае SSD оно не так активно свопилось).
-
Да, а про макось классику я напишу позже :-)
-
Это немного не так. Есть разные стратегии.
Там изложен принцип, в детали я не вдавался...
Сейчас я хочу прикрутить видеокарты для многопоточной обработки данных (на основе OpenCL), появляется третий вид памяти той, что на видеокартах. Интересно, но есть проблемы с когерентностью... поэтому ещё интереснее... времени только не хватает.
-
У меня такой проблемы не возникало. Разнородные данные закачиваются из БД, каждый тип в свою область памяти, там и живут, пока нужны. Когда не нужны, все выбрасываются. Чтобы каждому типу хватило памяти, на этапе проектирования программы формируются карта распределения памяти.
С данными каждого типа работают, как с массивом (хотя количество данных меняется в широких пределах, но назвать этот массив динамическим язык не поворачивается). То есть, под массив отводится максимально нужное количество виртуальной памяти, но физически память выделяется в процессе закачки данных.
Это все классно звучит... Но вот если ближе к мэйнстриму (тому самому, ненавидимому оберонщиками)... Вот мне надо сложить две строки. Какие нафиг карты памяти?
-
если ближе к мэйнстриму (тому самому, ненавидимому оберонщиками)... Вот мне надо сложить две строки. Какие нафиг карты памяти?
Складывание двух строк... это не мэйнстрим. Мэйнстрим - это интернет-общение, интернет-торговля, социалки, интернет-сервисы... а это не складывание строк, это обработка сотен тысяч запросов...
-
Мейнстрим - это подход к решениям задач.
-
Мейнстрим - это подход к решениям задач.
Скорее, определённый класс наиболее востребованных задач, а значит и программ/приложений... К примеру сейчас наблюдается явное смещение в сторону насыщения планшетов простыми программками, игрушками и пр. Андроид оттягивает на себя приличные ресурсы... времени программистов. Понятно, что это явление временное, но за полгода очень серьёзный крен.
-
Ну, конкретное значение этого термина зависит от "предметной области", так сказать. Моё определение касается тех, тех, кто в основном работает с кодом.
-
Ну, конкретное значение этого термина зависит от "предметной области", так сказать. Моё определение касается тех, тех, кто в основном работает с кодом.
Согласен...