Программируй через пот и слезы!

Добрый вечер, форумчане! Я за месяц обучения программированию дошел до темы ООП. Уже разобрался в классах, в конструкторах... Проблема вот в чем: сижу и решаю ПРОСТЫЕ задачки по разным темам. Щелкаю их как семечки. Как только дело доходит до более серьезных задач, так все... Моя голова - как белый лист. Продумываю алгоритм, проговариваю в слух, что сначала написать, что потом. Либо тонна ошибок, либо программка работает не так, как надо. Уже кружку одну разбил - кинул в стенку из-за того, что все полетело к чертям в коде (писал игру "анаграммы"). Прошу вас, направьте меня и всех новичков, читающих данную тему, на правильный путь! Может я слишком быстро изучал темы? Может программирование это не мое? Может забить на все это дело? У меня есть огромное желание стать разработчиком игр! Хотелось бы сделать это одной из частью смысла жизни!

Заранее спасибо!

0

На мой взгляд анаграмма через месяц обучения - это слишком рано

ООП, классы, конструкторы - всё это не надо. Для начала достаточно уметь с простыми операторами, массивами, структурами, циклами. Этот тот необходимый минимум, при понимании которого в теории можно сделать всё на свете

Ты слишком много читаешь про устройство языков программирования. Потрать это время на то, чтобы при помощи имеющихся минимальных знаний решать большинство задач. Чтобы решить сложные задачи типа анаграмм, не нужно читать книги по языкам программирования и языковым конструкциям. Лучше читай книги по алгоритмам. Во времена СССР очень много книг использовали вообще некий математический псевдоязык для описания именно логики работы. А ООП, классы, конструкторы - это всего лишь языковая шелуха и особенности синтаксиса. Если ты не умеешь алгоритмически мыслить, то можешь знать хоть все на свете языки программирования - ты всё равно ничего не сможешь запрограммировать. Если ты научился мыслить алгоритмически, то тебе будет достаточно взять книгу или справочник по любому языку программирования, через оглавление найти разделы с нужными языковыми конструкциями, и с ходу напишешь нужный тебе программный код. Понятно, что я утрирую, но в общем и целом оно примерно так и есть. Программирование сводится к умению подойти алгоритмически к решению задачи, а в вовсе не к "выучиванию" языка программирования

5

Сообщение от astantez У меня есть огромное желание стать разработчиком игр!

я монополию в консольке фигачил.

и в принципе каких то базовых знание за глаза хватало,
что бы доделать текстовую игрушку.

но вот я прошел классы.
и афигать, как все можно было бы проще и изящнее сделать.

тут я прошел полиморфизм...
и давай все опять по новой переписывать.

ну а там и std:: со всеми своими шаблонами пошел...

в общем, я эту монополию с нуля раз 20 переписывал.
по мере овладевания новыми техниками.

а смысл прост:
есть задача.
и нужно её порешать забив на все эти языковые возможности.
используя то, что уже сейчас изучилось.
для закрепления материала.

и уже потом двигаться дальше.


сейчас такое впечатление,
что у вас в голове слишком много новых данных.
но вы ещё не успели закрепить пройденный материал.
вам просто нужно побольше практики.
без наседания на много-много теории.

1

Сообщение от hoggy вам просто нужно побольше практики. без наседания на много-много теории.

Эх, обычно-то тут как раз обратная ситуация - лезут в программирование без малейшего понимания матчасти.

Сообщение от astantez У меня есть огромное желание стать разработчиком игр!

Тут, конечно, на любителя, но лично мне была интересна работа с графикой. Откопайте древний доисторический TurboC (еще досовский) и почитайте там про графику, благо это одна из самых простых графических систем, которые я видел: две строчки инициализация, еще одна - закрытие. Ну а там - движение точки по клавишам WASD (со стрелками чуть сложнее) или по заданным траекториям, фракталы и тому подобное. Не буду говорить что это сверхполезная практика, но, по крайней мере, визуализация возможностей. А потом можно и на современные системы переходить, но там графика куда сложнее (в WinAPI или xWindows у меня заняло более 50 строк только инициализация + деинициализация).

0

astantez, если ты решаешь простые задачи как семечки, то сможешь решить и большую задачу, которая как и все на этом свете состоит из элементарных частей. разделяй и властвуй, тебе нужно научится разбивать большую задачу на маленькие.

Добавлено через 3 минуты

Сообщение от Evg Потрать это время на то, чтобы при помощи имеющихся минимальных знаний решать большинство задач.

самая первая конструкция которая мне понравилась, это цикл, ведь по сути цикл основа работы ЭВМ.

0

Сообщение от _stanislav ведь по сути цикл основа работы ЭВМ.

основа эвм - сложить/вычесть/умножить/разделить, и goto.

представьте себе, что в вашем процессоре нет встроенного оператора if.
вы можете только складывать/вычитать/умножать/делить.
и выполнять жамп на ячейку памяти.
вот как вы сможете при помощи простейшей математики и goto,
реализовать оператор if ?

без оператора if не возможен цикл.

0

hoggy, давай углубляться, НЕ И, НЕ ИЛИ, ИНВЕРТОР.

Добавлено через 1 минуту

Сообщение от _stanislav самая первая конструкция которая мне понравилась, это цикл, ведь по сути цикл основа работы ЭВМ.

тут имеется ввиду, что в компьютере все зациклено.

0

Сообщение от hoggy представьте себе, что в вашем процессоре нет встроенного оператора if.

путем хитрых математических выражений вычислить длину прыжка goto. Где-то, кажется, на easyelectronics, видел такой стиль программирования, но там старались вообще не использовать goto.

Сообщение от _stanislav тут имеется ввиду, что в компьютере все зациклено.

Напротив, там все линейно. А оператор goto это стресс для процессора, ему приходится чистить конвейер инструкций и спешно подгружать новые.

0

Сообщение от COKPOWEHEU Напротив, там все линейно.

если бы линейность не была зациклена, тогда после каждой задачи приходилось бы включать его заново.

0

Какие задачи вы не можете решить?

0

_stanislav, так и есть. Когда одна программа завершается, ее можно запустить заново. А можно запустить другую. Собственно, большинство программ так и устроены: запуститься, считать входные данные, обработать их, выдать выходные и завершиться.
То что в большинстве (даже не во всех!) программах где-то внутри используются циклы не значит что "в компьютере все зациклено".

0

Сообщение от COKPOWEHEU Напротив, там все линейно. А оператор goto это стресс для процессора, ему приходится чистить конвейер инструкций и спешно подгружать новые.

Давно уже есть такая штука как "предсказание переходов". На сколько я помню, она даже специально собирает статистику сработал данный переход или нет. Проблема только с действительно случайными переходами, на которых предсказалка стабильно дает сбой.

0

COKPOWEHEU, про цикл обработки команд ЦП слышал?

Сообщение от COKPOWEHEU приходится чистить конвейер

процессор без циклов даже конвейер не сможет почистить. циклы вообще везде в нашей жизни присутствуют не только в ЦП.

Добавлено через 2 минуты

Сообщение от COKPOWEHEU большинство программ так и устроены: запуститься

и как интересно программа сможет сама запустится, без вмешательства из вне, программу запускает либо цикл либо человек.

0

0

Сообщение от Evg ООП, классы, конструкторы - всё это не надо

вредный совет!

тем более автор написал же, что хелловордами проблем нет, а речь об игрострое.

ооп как раз и придумали, чтобы сложные задачи делать простыми,
чтобы программист мог кодируя задачу, оперировать терминами самой задачи, а не терминами аппаратуры, для которой этот код будет исполняться.

0

XLAT, ТС же писал что месяц как учит программирование, рановато для ООП.

0

Сообщение от XLAT ооп как раз и придумали, чтобы сложные задачи делать простыми

Бред какой-то. Даже не знаю что тут и ответить. Если задача алгоритмически сложная, то ООП ее простой никак не сделает.

0

Сообщение от Новичок Если задача алгоритмически сложная, то ООП ее простой никак не сделает.

ну, да,
пусть учит массивы с форами, чтобы писать свои сортировки с векторами?
ага ооп там конешно не нужен?

А вот есть задачи, типа генератора парсеров регулярок(re2c), изобиливаещего гоуту, поэтому и рвущего конкурентов по скорости. Может пусть автор гоуту учит ждва года?

Если задача алгоритмически сложная, то одними массивами с форами её тоже не сделать.
Нужно обращать за скрытыми(а вдруг они есть) возможностями собственного серого вещества.

0

Сообщение от XLAT пусть учит массивы с форами, чтобы писать свои сортировки с векторами?

Что в этом кстати плохого? В целях обучения можно покодить свои сортировки вместо использования std::sort(хотя понятно что на практике надо конечно же использовать готовую сортировку).

Сообщение от XLAT ага ооп там конешно не нужен?

Как ООП поможет отсортировать массив? Какой толк от человека знающего ООП, если у него вообще нет алгоритмического мышления? Никто не против ООП, но вот это слишком громко сказано.

Сообщение от XLAT ооп как раз и придумали, чтобы сложные задачи делать простыми

0

Сообщение от Новичок сложные задачи делать простыми

сложная задача не может стать простой, ее можно разделить на простые, и для этого нужно использовать ООП.

0