Александр Гусев: Положим, у нас есть объект. Занимает 200 байт памяти. Есть ссылка на него. В один прекрасный момент мы затираем ссылку на него, предварительно записав на бумажку адрес ячейки памяти, хранящей нулевой из 200 байт. Фактически, сборщик мусора думает, что на эти 200 байт ничего не ссылается, и они по-прежнему хранят информацию объекта.
В итоге у нас есть 200 байт памяти, хранящих некоторую информацию. Штатными средствами до нее не добраться - ссылок-то в системе не осталось. Единственный способ добраться до данных - воспользоваться тем адресом, что мы записали на бумажке. Фактически, мы скрыли объект с данными. Проблема лишь в том, что у нас на руках "горящий" объект - в любой момент его могут перезатереть.
Вопрос: насколько объект "горящий"? Вопрос не практический, скорее исследовательский.
fshp: Хм, в Шарпе такой фокус вроде возможен (я имею ввиду, обращение к переменной, на которую ничто не указывает; хотя в данном случае наверное стоит говорить про ячейки памяти, в которых хранилась переменная). Думаю, в Java тоже можно извратиться. Откуда следует вопрос: при каких операциях GC (либо ОС) переменная может перезатереться?
markula: Окей. Пусть длина блока 7 бит, а у вас в сообщении 32 бита. Итого вам нужно 5 блоков. В 5 блоков помещается 35 бит. Создаете BitArray на 35 элементов. В первые ячейки копируете ваши биты, 3 последние забиваете нулями. Итого у вас 5 полностью заполненных блоков по 7 элементов.
И да, как заметили выше, у вас странные результаты перевода строки в биты. Строка состоит из символов каждый по байту (или n байт, зависит от кодировки). Так что в любом случае должно получаться 8*k бит. Лучше приведите перевод к классическому, или в алгоритме выше добивайте полученный BitArray битами справа, после дешифровки выкидывая из строки нулевой символ.
Wolfak: Вам не зря ниже написали про массивы UIElement[]. Кроме того, есть кодогенератор Т4, который нужен для случаев с большим числом элементов и\или сложной логикой.
GavriKos Ради этого ожидания приходится открыть инвентарь, взять свиток, идентифицировать шмотку. Ок. Но в большинстве случаев вещь идентифицировалась лишь ради навара. И бесконечные клики лишь утомляли. В Д2 хоть Каин был, сокращал рутину (в PoE, TitanQuest аналогов вроде не было).
В итоге частая рутина ради относительно редких моментов неизвестности.
Вы можете наследовать ваши классы от созданного пустого интерфейса.
public interface AnyInterface{}
public class productA : AnyInterface{...}
public class productB : AnyInterface{...}
public class productC : AnyInterface{...}
public class productD : AnyInterface{...}
Mintormo Строго говоря, иногда я пишу программы, и не думаю об алгоритме. Причина проста: писать алгоритм сразу несколько неудобно, много деталей надо держать в голове, искать возможные ошибки. Проще накатать базовый рабочий код, поглядеть, что получилось (и что говорит Решарпер), потом пару раз пробежаться с тестами и дебагом. Для вспомогательных\тестовых скриптов\утилит это вполне нормальный вариант.
Кое-какой код трехлетней давности и специфической области работает, но его алгоритм я осознать не в состоянии (по крайней мере, с наскоку).
Хочется верить, что с опытом перестаешь задумываться о алгоритмах, и пишешь хороший код на инстинктах. То есть, гуру по Вашему принципу не отличается от новичка. В математике, кстати, такое тоже пару раз замечал.
Увы, там сильно желто.
В первом примере не учитывается, что 18 млн долларов тогда - это далеко не то же самое, что и сегодня.
Во втором на программиста свалили ошибку архитектора (либо ПМ, который отдает архитекторские задачи программисту).
По поводу черного понедельника тоже неясно. Учитывая сумму "потерь", крайней вполне могли выставить программу. Кстати, почему потерь? Кто-то эти 500 лярдов наварил.
"Буря в пустыне" - учитываются только американские жизни. То, что каждая ракета не задела одного иранца (иракца? вечно их путаю), не учитывается. Добавим сюда, что оборудование использовалось в непредназначенном режиме, так что не программистов это вина.
В итоге у нас есть 200 байт памяти, хранящих некоторую информацию. Штатными средствами до нее не добраться - ссылок-то в системе не осталось. Единственный способ добраться до данных - воспользоваться тем адресом, что мы записали на бумажке. Фактически, мы скрыли объект с данными. Проблема лишь в том, что у нас на руках "горящий" объект - в любой момент его могут перезатереть.
Вопрос: насколько объект "горящий"? Вопрос не практический, скорее исследовательский.