lucky_e3: Все логично. Программа кидает Exception, поскольку cornerTop = -1, и row=-1. Мы пытаемся обратиться к largeArr[row,col], то есть row[-1,0]. В largeArr нет ячейки с такими координатами, получается исключительная ситуация.
Собственно, в коде ответа есть комментарий:
// Вставить проверки на выход из границ большого массива.
Если у вас консолька, можете обрамить строку
smallArr[i,j] = largeArr[row,col];
кодом
try
{
smallArr[i,j] = largeArr[row,col];
}
catch(IndexOutOfRangeException)
{
Console.WriteLine("Error on data migration. Args: row={0}, col={1}, i={2}, j={3}.",row,col,i,j);
}
Если приложение формочное - замените Console.WriteLine(...); из примера выше на MessageBox.Show(String.Format(...)); Подход с try-catch грубый, но на первое время его хватит.
Если работаешь с VisualStudio, и вылетело исключение - попробуй навести курсор мыши на переменную, её значение подсветится. Вообще, обязательно посмотри, как дебажить проекты. Как ставить точки останова (они же breakpoints), как двигаться по шагам, с заходом в функции, до точки останова (F10, F11, F5), как открыть панель QuickWatch. Дебаг (debug) - необходимое умение для программиста. Собственно, процесс отладки программы идет по цепочке компиляция -> тесты -> дебаг -> сначала гугление -> потом stackoverflow\toster.
Василий Захарчук: Напиши в резюме, что реализовывал анализатор, и что он конкретно анализировал. Честно признайся на собеседовании, что кода нет, один фиг твои навыки будут проверять на тех-собеседовании или испыталке. Ты же джуном идешь, не сином.
MrDywar Pichugin: для таких маленьких цифр потоки вообще бесполезны. TreadPool - само собой, нечетко выразился в ответе.
По поводу конкуренции записи - а зачем? Каждому потоку свой столбец, и все дела. По крайней мере, если малый массив в это время не используется, а в большой никто ничего не пишет.
Для склейки лучше использовать массивы int[][].
Насчет кеша - неожиданный аргумент. Есть какой-нибудь пример, когда это реально работает? В теории читал, понятно, что такое возможно, но на практике пока не сталкивался.
C# для Unity несколько отличается от стандартного. Не по синтаксису, а в части построения приложения. Или подходу к этому самому построению. При прочих равных, опыт Java будет скорее полезен.
Удачи.
beduin01: Ответственность за доказательство лежит на утверждающем. В данном случае Вы не совсем правы. У С++ есть свои области применения (из того, с чем сталкивался - графические движки), и там он явно лучше за счет быстродействия итогового кода (удобство в том, что не нужно танцевать с бубном ради оптимизации).
Плюс, кроссплатформенность из коробки (удобство в экономии на ксамарине).
В конце концов, человеку, 15 лет кодившему исключительно на плюсах, С++ будет гораздо удобнее.
В смысле современности - тут Вы скорее всего правы, решетки развиваются быстрее плюсов. Является ли это преимуществом - другой разговор.
sivabur: С вебом и Selenium не работал, про WinForms же... Один раз записанный сценарий нельзя изменить, что вынуждает дробить многие действия на части, и записывать каждую часть отдельно. Для небольшого числа неизменяемых тестов это невыгодно, если же тестов много и\или UI меняется - довольно удобно. То есть, разработка не быстрая, зато поддержка радует. Полагаю, аналогичная ситуация и в других подобных фреймворках.
Честно говоря, выбор зависит от размеров команды и целей. Например, CUIT не особо работают с базой. При этом на питерском .NEXT 2014 был доклад про связку FitNess + Selenium, там, если не ошибаюсь, удобно кодировать заполнение БД перед тестом.
Если хочется просто закликать чужую игрушку - кликерман в помощь. Если хочется тестировать свою, в т.ч. с логикой - тут CUIT подойдет.
Сергей Протько: Мой наставник говорил: не изучай больше, чем одну вещь за раз, без особой необходимости. Вадим Егоров: Для ответа на вопрос, чем плох глобалс, отлично подойдет гугл. "Чем плохи глобальные переменные?" Если вкратце - в малых проектах это нормально, в больших можно изменить переменную и не учесть при этом всех последствий.
По поводу наращивания поля - тоже неожиданно. В смысле, диагональная реализация неожиданна.
P.S. По поводу решения ниже: не ожидал, что на Python можно писать (относительно) понятные алгоритмы. Оффтоп, конечно, но зачем создатели вложенность блоков привязывают к отступам? Ради борьбы с многочисленными вложениями?
Александр Гусев: Положим, у нас есть объект. Занимает 200 байт памяти. Есть ссылка на него. В один прекрасный момент мы затираем ссылку на него, предварительно записав на бумажку адрес ячейки памяти, хранящей нулевой из 200 байт. Фактически, сборщик мусора думает, что на эти 200 байт ничего не ссылается, и они по-прежнему хранят информацию объекта.
В итоге у нас есть 200 байт памяти, хранящих некоторую информацию. Штатными средствами до нее не добраться - ссылок-то в системе не осталось. Единственный способ добраться до данных - воспользоваться тем адресом, что мы записали на бумажке. Фактически, мы скрыли объект с данными. Проблема лишь в том, что у нас на руках "горящий" объект - в любой момент его могут перезатереть.
Вопрос: насколько объект "горящий"? Вопрос не практический, скорее исследовательский.
fshp: Хм, в Шарпе такой фокус вроде возможен (я имею ввиду, обращение к переменной, на которую ничто не указывает; хотя в данном случае наверное стоит говорить про ячейки памяти, в которых хранилась переменная). Думаю, в Java тоже можно извратиться. Откуда следует вопрос: при каких операциях GC (либо ОС) переменная может перезатереться?
