...просто как и автор, так и мы все вместе начали недетально описывать, а упрощать и сводить всё до 'кучи', потом, когда в дискуссии и регистры были произнесены, команды ассемблер, то и я совсем сбился. И на уровень ассемблера перешёл. Хотя надо было всего то про GC говорить. Или о описании CLI — ECMA 335 - там много чего интересного.
Но с вами соглашусь, для упрощенного понимания вы со своим ответом дали информацию, которой хватает для понимания.
Извиняюсь, много смешалось в голове. В с# под это выражение подходят все функциональные переменные у классов с префиксом static - для организации в памяти они глобальные.
insighter, ответил в одной из других ветках детальнее. Например после вызова функции, все её локальные переменные укладываются в стек. Но не совсем так как мы это привыкли понимать, а в структуре под названием stack frame. Там лежат и другие вещи. Но не динамические инстанции объектов. Они как раз в heap откладываются. Так удобнее, пото у что они очень могут быть большими. А локальные переменные от int, bool итд. - это всё мелочи. И потом после завершения функции и передачи параметров возвращения весь stack frame выбрасывается одним махом.
Vadim Nikiforov, не совсем понял. А про что вопрос, если вы на уровне с# разбираться хотите. Не ниже. Ни операционка, ни ассемблер, а просто с#. Даже Java с JVN свою организацию модели памяти делает, тем более иногда разную под разные процессоры.
С# - хороший язык. Но. Где вы сталкиваетесь с реализацией и ставите под вопрос - хорошо то или иное решение в операционке или компайлере или нет? Если вам до него не достать? Много деталей можно в инете и литературе под названием Системное программирование найти.
insighter, ну конечно-же. Другого я и не мог от вас услышать. Вас спросили про хранение переменных/объектов, а вы про PUSH & POP.
Дла того, чтобы понять как работает механизм организации переменных, надо во-первых оговорить, говорим-ли мы про c, или нет. Если - да, то надо говорить о том, о каких переменных идёт разговор.
Если это глобальные, то они будут сразу-же после блока с программой и константами установлены. Но и тут один нюанс. Если переменные сразуже инитиализированы, то они укладываются в первой части - в блоке с инитиализированными переменными. Если переменные просто задекларированы, но не имеют значения, то они укладываются во второй части - в блоке с неинитиалиизированными переменными.
Идём дальше. Теперь переменные в функциях - они (с auto: и без оного) - переменные укладываются в стеке, но совсем просто так, а в специальной конструкции как stack frame.
И в этой конструкции укладываются не только локаьные переменные, но и параметры для вызова, адресс возврата, места для переменных, которые будут возвращены назад. Итд.
Для чего последний шаг? Для того, чтобы после выполнения функции - всё, что было связано с этой функцией было за раз удалено. Все локальные переменные за раз. Одним махом.
Если речь идёт о динамических обьектах, то да - они укладываются на heap. Резервирование происходит с malloc() или calloc(). и освобождение с командой free(). И вопрос касался именно - почему то там, то в другом месте. А вы про PUSH и POP. И суть в том, что так для организации удобно. А не потому что PUSH и POP быстрее или нет.
Но это не вся правда. От компилятора тоже многое зависит. От платформы тоже. Единственно возможных вариантов в реализации переменных в памяти нет.
Может быть поймете, что вы описываете не то, о чем вас спрашивают, но вы это как ответ видите, а автор вопроса - все равно как вопрос. Но. Вы правы. Давайте оставим это.
Не стек, а статическая память выделяется до начала работы программы, а статические переменные создаются и инициализируются до входа в функцию main. Например, при объявлении переменной int а [ 10 ] ; автоматически выделяется 10 ячеек памяти, каждая из которых предназначена для хранения целого значения.
Ну почему нельзя- можно. Просто так легко всё это организовать. Это также как в жизни. У нас есть коробочки для различных шурупы, хотя все можно в кучу скинуть. Просто потом и поиск нужных, а тем более ненужных шурупов усложняется. Например я все шурупы 5 лет назад у себя сдал в утиль - с прямым срезом. Крестовые и шестигранники- на них остался.
Ведь с разными коробочками - проще. Даже, если они не все одинаковые. Хотя ради того, что многие коробки разные - найти нужные - ещё быстрее.
И по факту добавлю. Так раньше со string(ом) и было. Раньше пстроковую переменную не сохранялись по адресу. А сейчас- да. Потому что упрощает изменять, добавлять, убирать части итд. А там, где адрес - там всё стабильно - там никаких изменений. Сколько бай зарезервировать как адрес для строгая, столько и стоит.
insighter, не совсем понятно, при чём тут регистры - а при чём вопрос, заданый автором.
Вы даже упоминаете проверки безопасности итд. Всё это делает ос. Никакой процессор о безопасности не имеет никакого понятия, кроме как исполнить команду или не исполнить в user mode/kernel mode.
Ну да ладно.
ну в вопросе стоит ниже физических устройств и цифрового логического уровеня — физическое устройство - не есть физический уровень. Последовательность такая - транзисторы/логи. гаттеры/микроархитектура (SISC & RISC)/ISA (instruction set architecture)/OS/ассемблер/пользовательские программы..
Поэтому и сказал, что ниже лог. элементов - находятся задачи по реализации транзисторов на платинах. Ну и другие задачи по оптимальному распределению элементов на чипе.
Может быть по-проще что-нибудь вначале делать?! Понимаете, дело даже не в функциях, которые вы может быть и не знаете. Ваш словарный запас говорит т том, что вам ещё много чего надо переделать, прежде чем за такие вещи браться. Не отговариваю, просто не разогревшись, да какой разогревшись - без тренировки вы хотите марафон пробежать.
#ирония Или ладно, что стесняйтесь - сразу беритесь за операционку....
Во первых - индексы нужны в первую очередь для тех полей, по которым идёт фильтрация, и которые имеют различные значения. Если 80% всех значений одного индексного поля имеют одно и тоже значение, то и смысл теряется и время на создание индекса, и самое главное - он ничего не принесёт, а иногда и не используется. Но тут немного другое, но это так - для информации, хотя именно такие поля как enabled очень часто такой плохой разброс в значениях могут иметь. Но это было-бы важно, если бы ты спросил, почему не использовался бы индекс по полю enabled.
Теперь конкретно к твоей задачи. В первом случае используется индекс, потому что для значений table_data.table_id происходит поиск эквивалентнов. Т.к. это поле индекс, то он и используется. Те. вторая таблица подсоединяется к первой. Поэтому поиск пары для table_id происходит в таблице table по индексу. И так как поле id имеет хороший разброс в значениях, то он и используется.
Теперь второй случай. Здесь происходит фильтрация по полю из таблицы table и только потом происходит соединение поля table.id с полем из другой таблицы, с table_data.table_id. Те. вначале находится id, а потом происходит соединение. Те. индекс на id здесь не нужен, тк. значение id - есть результат фильтра. Если поле table_id не проиндексировано, то для соединения приходится всю таблицу table_data перелопатить, прежде, чем найдётся парочка для id.
Предполагаемые решения:
-даже без этой проблемы, обязательно создать индекс для поля table_id для второй таблице.
-создать индекс для поля enabled, но учитывать большинство значений в этом поле. И если почти все из них будут или 1 или 0, а только парочка другого, то...
-для фильтрации использовать дополнительные поля, которые обладают большим разбросами в значениях.
Делайте так, как вам подсказывает сердце, но так, чтобы в конце ваших усилий получился результат. Если финансы сегодня играют большую роль в выборе, то так оно и есть. Не надо себя обманывать. Своим трудом и усилиями вы всегда это сможете изменить. Хуже будет, если вы с первого момента взвалите на себя непосильную ношу.
Извини меня и не обижайся, но - я живу почти 30 лет за рубежом и почти не разговариваю на русском языке, но так непонятно я не пишу свои мысли. А ведь это важно - правильно излагать свои мысли, тогда тебя понимают и скорее всего- помогут. Что значит - преобразовать числовые элементы в массив в textBox'е?
В textbox(e) должно что-то показаться? Судя по коду, в textbox(e) берётся число и используется как количественный фактор для генерации случайных чисел. Если так, то указание в textBox'e грамматически не имеет никакого смысла. Ведь направление не в TextBox, а в массив. Но при этом учитывается значение из textBox'a.
Это первое, а второе. Код, который ты указал, хоть и не лишён возможных ошибок при вводе не чисел, но всё равно - в принципе делает то, что ты вроде описал. Так тогда - в чём проблема?
Из правил UX я бы не делал это действие через кнопку, а именно в каждом из textBox'ов, после нажатия клавиши Ввода. Тогда держа руки на клавиатуре можно забить кучу разных случайных чисел, не прибегая к мышке или клавиши Tab для перемещения к кнопке. Она лишняя. При этом можно протоколировать в дополнительном массиве количество генерируемых значений и можно будет даже функцию отменить предусмотреть. Те. При нажатии cntrl+z или какой другой комбинации можно из списка удалить именно столько элементов, сколько было внесено при последней генерации. Ещё одно нажатие cntrl+z и следующие сгенерированные элементы удаляются итд. до последнего, те первого генерирования.
edward_freedom, согласен с вами, но почему-то подмал,что автор исключил, что он вызывает функцию, которая ожидает параметры, а он их туда не передал. Беру свои слова назад ;)
А воообще какай-то мудрёная функция, которую он вызывает. Она висит на классе Airplane, но получает array со многими аэропланами и номер, чтобы какой-то из них указать. Но ведь сама функция уже у инстанции вызывается к аэроплану, который скорее всего под номером n будет указан. Совсем я потерялся ;)
Или, если это номер Аэроплана, который в списке, но до которого путь дожен быть высчитан, то я тогда-бы не эти два параметра туда передавал-бы, а reference на один из нужных Airplan, который до этого выбирается из списка по номеру.