Griboks, к сожалению и так бывает, я Вам больше скажу, очень часто люди просто из принципа не правят ошибок, потому что почему-то считают, что им на них указывают, чтобы их оскорбить, и вообще: слишком ты пожил мало, чтобы мне советовать. Удручает. Очень.
Тем не менее творениями классных спецов брезговать не стоит, обратите внимание на приведенные мною примеры, они Вас очень приятно удивят. Только читайте обязательно в оригинале.
И.. да, используя голову по назначению можно добиться очень многого, под этим готов поставить свою подпись. :)
Griboks, Я всё же пишу не с 15 лет, а на протяжении 15 лет :)) Но мы не о том. В принципе, я согласен с Вами, что учиться надо на практике и без нее читать что-то просто бесполезно. Но... Вы ведь из головы не сможете понять, что такое рефлексия, как работает сборщик мусора, как устроены объекты, структуры. Очень жаль, что Вам попались плохие книги, тем не менее, есть же откровенные шедевры, которые прочитать просто необходимо, например, книги Джеффри Рихтера и Джона Скита. Книги Конрада Кокосы про управление памятью и Андрея Акиньшина по бенчмаркингу тоже очень сложно назвать лживыми или плохими, а говорить, что они ничему не учат... ну, мягко говоря странно. Опять же повторюсь, что без практики всё это не имеет значения.
Не у всех, кто пишет книги или учит людей целью является заработать деньги, мне, например, банально приятно делиться знаниями, в конце концов, кто, если не мы? Безусловно, если мне предложат за это платить, я не откажусь.
Базовые алгоритмы, паттерны и принципы проектирования также лучше всё же узнать из книг, а не придумывать самому. Я в действительности раньше тоже думал в точности, как Вы, в своё время дошёл до доброй половины GoF-паттернов сам, да, это круто, согласен, но не брезгуй я в то время чтением, своего текущего уровня я достиг бы гораздо раньше. Сложные фреймворки опять же проще и быстрее изучать с хорошей книгой.
Хотя, возможно, я так считаю, потому что учился в то время, когда столько онлайн-ресурсов по программированию просто не было. ;)
Есть ли такая книжка типа «словаря» по авиалайнерам, т.е просто в столбик расписаны все «слова» с пояснением?
Типа "авиагоризонт - это, делает что-то" "закрылки - это" и т.д. Как для Боинга-737, так и для А-320. Я вообще ни одного самолета в жизни не видел, а аэродинамика для меня -- тёмный лес. Хочу научиться водить авиалайнер, чтобы летать с друзяшками побухать в деревню. Только НЕ ОБУЧАЯСЬ в лётном училище на пилота и вообще не изучая ничего . Если нет, то как научиться летать?
А такая же книга по устройству человеческого организма есть? А то хирургом быть я тоже не против!
Смешно, может быть даже обидно? А мне грустно и тоже, честно говоря обидно за то, что вот такое новое поколение инженеров растёт. Вы бы хотели летать с таким пилотом? Или лечь на стол к подобному хирургу? Нет? Так почему же, чёрт дери, все считают, что программированию надо учиться спустя рукава!? Что здесь, что на SOru тусит целая армия Unity-"программистов", которая искренне считает, что тратить время/силы/деньги на обучение #ненужно, а всё как-нибудь само наладится, которая задаёт такие вопросы, что волосы на одном месте дыбом встают. Если Вы не хотите пополнить её, то отнеситесь к делу серьёзно.
Без курсов, которые, кстати бывают бесплатными и серьёзных книг по одним справочникам, которые хоть и не в том виде, в котором Вы сказали, но существуют, Вы не сможет изучить программирование, не сможете решать серьёзные задачи, не сделаете ничего стоящего, тем более, если не знаете ни одного языка. Я программирую на C# 15 лет и не считаю зазорным учиться и чем больше узнаю, тем больше появляется вопросов. Программирование -- это, вообще, сфера, где надо постоянно учиться или не надо за него браться.
OMG, люди, да выйдите вы уже из анабиозной камеры, все разговоры об убогости и неюзабельности Линукса и шутки про стоп-экран, он же BSOD в Винде были актуальны лет так 5-6 назад.
ase2015, вот знаете, жутко не люблю такие комменты, честное слово, но... Вот заходишь в вопрос, вроде бы не самый глупый, честно хочешь ответить... Потом видишь, что это опять очередной вопрос про Вашу курсовую, семестровую или что это там... и... желание тут же пропадает, нет, не потому что вопросы глупые, нет, у меня такие же были чуть более 15 лет назад, да у всех они были и это -- нормально, а просто потому что поток вопросов именно вот об этом "проекте" и именно от Вас просто нереален, что здесь, что на Stackoveflow, благо там все гораздо жестче и их просто закрывают и ни в одном вопросе я не видел желания понять и разобраться, ни в одной формулировке вопроса я не видел даже намека на понимание того, что именно и зачем Вы делаете, все в стиле "Сделайте за меня". Так вот, учебные задания, а тем более такие интересные, я серьезно, мои сокурсники в свое время Вам бы позавидовали, надо делать самому, если, конечно, Вы хотите научиться программировать...
Maksimka00, у Вас рядом со словом "присоединение", справа, есть такой небольшой серый треугольник, Вам надо нажать на него, тогда появится выпадающее меню, там должен быть пункт "запуск".
ase2015, если я все правильно понял, то Вам надо считать время за которое игрок нашел все картинки и сохранять эти данные где-то. У вас ведь есть изначальное значение таймера 3 минуты? Если от них отнять время, оставшееся, после прохождения, то очевидно, получится время, за которое игрок отыскал все картинки. Чтобы запоминать это значение между запусками приложения, Вам надо где-то сохранять это число, мне что-то подсказывает, что в данном случае -- на диске, для этого можно использовать, например SQLite (заодно получите опыт работы с РСУБД), хотя в данном случае это видится оверхедом: можно ограничиться просто файлом (текст, JSON, XML...)
#, Вы не правы. DbContext по большому счету -- обертка над соединением, то есть, создавать его надо только в тот момент, когда он необходим, а жить он должен как можно меньше времени. Открывать соединение к БД в начале работы приложения -- гут, но, только в том случае, если приложение десктопное или мобильное, при этом БД пользуется только оно (нет конкуррентных подключений), в случае серверного приложения держать соединение открытым так долго идея не из лучших.
Вы не поверите, но вот эта вот простыня по ссылке и есть "обычный" JSON, а "вот это", без которого Вы хотите видеть JSON -- ни что иное, как данные, которые в нем содержатся.
Если Вам надо проводить какие-либо манипуляции с ним, установите пакет для этого, самый, наверное, известный среди них -- Json.NET, он же Newtonsoft.Json. Библиотека очень мощная и покрывает, наверное, все аспекты работы с JSON.
Также не совсем понятно, в массив каких объектов Вы хотите его "декодировать" и что потом с ним (массивом) делать? Думаю, что, если Вы хоть немного расскажете о контексте Вашей задачи, вероятность того, что Вам помогут очень сильно вырастет.
Для начала, думаю, стоит привести код, который Вы запускаете, а потом показать кто пишет указанное сообщение и какое исключение при этом происходит, также было бы неплохо, указать в какой момент.
Но, вообще говоря, это системная ошибка Windows, говорящая о переполнении стека:
STATUS_STACK_OVERFLOW
Код ошибки: 0xC00000FD
Не удается создать новую страницу защиты для стека.
А призыв ее выучить основывается на Вашем неполном понимании того, как работает сборщик мусора.
Давайте все же немного копнем в сторону управления памятью. Есть два типа данных -- классы (ссылочные типы, типы-ссылки) и структуры (значимые типы, типы-значения). Между ними есть огромная разница: данные ссылочного типа всегда располагаются строго в управляемой куче, данные же значимого (структуры) там, где, если можно так сказать, используется его экземпляр.
Грубо говоря, когда Вы определили переменную класса, то в стеке потока, в котором исполняется Ваш метод хранится только ссылка (указатель) на область памяти, в которой расположены данные, если Вы объявили переменную значимого типа (структуры), то в стеке потока располагаются сами данные.
Когда структура является полем объекта ссылочного типа, то ее данные опять же расположены прямо в теле объекта (если полем является экземпляр класса, то в теле объекта находится опять же только ссылка).
Безусловно, есть различия в том, как разные типы передаются в метод и возвращаются из него. В случае класса возвращается (передается) ссылка, а вот в случае структуры -- все данные.
Кроме всего, существуют параметры ref и out (емнип, в последней версии языка есть еще in), так вот, когда параметр помечается ключевым словом ref (равно как и out), передается не он сам, а его адрес, в случае, когда по ссылке передается экземпляр класса, передается, простите за тафтологию, адрес адреса.
Кортежи в C# -- это синтаксический сахар над структурой ValueTuple, в Вашем случае ValueTuple{byte[], byte[]}, он параметризован массивами, которые в свою очередь -- типы ссылочные (классы).
Ссылочные типы удаляются сборщиком мусора при его запуске и необходимым, но не достаточным условием очистки памяти, занимаемой объектом является отсутствие ссылок на него, то есть, когда сборщик мусора запустится, он удалит объект (здесь опять же есть ньюансы, касающиейся деталей работы сборщика мусора, но о них чуть ниже), но это не значит, что когда ссылок на объект не остается, он тут же удаляется.
Кроме всего прочего, существует понятие поколения объекта и кучи больших объектов. Все новые объекты, занимающие непрерывный участок памяти менее 85000 байт именно так, а не 85КБ, попадают в поколение 0, в нем чаще всего происходит сборка мусора. Все пережившие одну сборку попадают в поколение 1, в котором сборка происходит гораздо (на один или несколько порядков) реже, все, кто переживает сборку мусора в поколении 1 попадают в поколение 2, которое не собирается никогда, ну, вернее, почти никогда, сборка мусора в нем инициируется только в том случае, когда не удается выделить память под большой (85000+ байт) объект.
В кучу больших объектов попадают экземпляры, занимающие непрерывный участок памяти 85000 байт и более (Ваш массив из 12345678 байт как раз такой объект, потому как массив -- непрерывная область памяти), особенность этой области управляемой памяти в том, что сборка мусора в ней во-первых происходит только при сборке второго поколения, а во-вторых в ней не происходит уплотнения, таким образом, возможна ситуация, когда у Вас есть пара гигабайт свободной памяти, а выделить участок для массива из 1024 байт невозможно -- нет свободного участка.
Вы на каждую итерацию выделяете два массива, один из них размером около 12 мегабайт, почему выделяется аж 150 сказать не могу, потому что скорее всего Вы привели не весь код. Памяти у Вас скорее всего вполне достаточно для того, чтобы 10 раз выделить по 150 Мб, то есть сборки мусора не происходит и это нормально. Именно поэтому У Вас просят привести пример боевого кода, тогда будет понятно куда девается память и как все это оптимизировать.
Вообще говоря, если Вы работаете с большими объемами бинарных данных, то я бы посоветовал Вам посмотреть, кроме System.Buffers, в сторону неуправляемой памяти и "сырых" настоящих указателей, не стоит их бояться, при условии, что Вы понимаете, что делаете.
P.S. Под утечкой памяти и ресурсов вообще, обычно понимается ситуация, когда у Вас не осталось возможности очистить ресурс (например, Вы потеряли указатель на область памяти), то есть то, что описываете Вы, утечкой, строго говоря, не является.
