abcd0x00

Замени это:

int N;
scanf("%d",&N);
N++;
N *= N;
printf("%u",N);

На это:

int n;

scanf("%d", &n);
n = (n + 1) * (n + 1);
printf("%d", n);

Подскажите какие технологии,или что почитать о парсинге текстового файла?

wiki. автоматное программирование

На C ты просто открываешь файл (fopen() + fclose()), читаешь его построчно (fgets()) или посимвольно (getc()) и подаёшь данные в конечный автомат для анализа. Когда же нужно работать со строками, то ты используешь разные функции из string.h.
Это общий подход, но есть и готовые библиотеки для работы с конретными форматами. Но вот когда библиотек нет никаких или их невозможно поставить, тогда ты должен сам всё написать, а сам ты будешь писать через конечный автомат, потому что библиотеки обычно через него и пишутся.

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

Мобильное приложение разработает лучше ТА КОМАНДА, которая разрабатывает мобильные приложения. Под мобильным приложением, видным пользователю, лежит такой айсберг работы, что один человек либо напишет нефункциональное окно, на которое можно будет только смотреть и радоваться, либо кучу плохо проработанных функций, где всё ломается с каждым днём и превращается в снежный ком из ошибок, которые надо исправлять, а исправлять их не так-то просто. Не надо думать, что если ты легко используешь приложение, то и пишется оно легко.

Сервер компании лучше сделает тот человек, который их постоянно делает. Благо, это больше относится к сисадминству (легче найти специалиста, так как их много). Делает сисадмин, консультируясь с программистом, потому что сервер должен просто предоставлять API (интерфейс), через который с сервером общается робот и через который с сервером общается мобильное приложение. То есть сисадмин должен просто всё установить, подключить и настроить.

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

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

То есть самое главное в этом всём - правильно разделить разботу между конкретными специалистами. Нельзя, например, сваливать на мобильщиков, которые не шарят в нагрузках, а больше привыкли картинки лепить в интерфейсе, работу с десятками тысяч роботов, коннектящихся к серверу. Они просто ничего в этом не понимают (и не должны понимать) и сделают всё плохо. И наоборот, нельзя на системщика сваливать работу с интерфейсом в мобильном, потому что он этим никогда не занимался. Ну, и регистрировать домены программисты у тебя не должны, этим должен заниматься тот, у кого есть время лазить по хостингам.

Конкретные языки узнаешь сам.

Вот git развивает Junio C Hamano, он японец. Если бы он тебе по-японски написал что-то или ты ему по-русски, вы бы друг друга не поняли. А так он пишет по-английски свои идеи, ты их можешь прочитать и ему ответить по-английски своими идеями.

Но дело даже не в том, что в мире 7 миллиардов человек с сотнями разных языков, а в том, что весь компьютерный мир возник и развился в США и Европе, поэтому вся основная документация была написана на английском изначально. А основная документация - это описание всего, что сейчас происходит за кадром (сетевые протоколы, форматы файлов и так далее). Переведено из этого на русский процентов 25, многое переведно не очень качественно (лучше читать в оригинале).

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

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

Надо структурировать информацию об обучении для долгих отрезков времени. Это очень важная составляющая, если собрался чем-то заниматься серьёзно. Чтение книги - не такой уж быстрый процесс. Написание программы - это не только долгий, но и запутанный процесс. А написание нескольких программ и чтение нескольких книг - это всё вместе. Ты никак не обойдёшься без органайзера. Поэтому потрать время на организацию долгих процессов. Изучи, чем и как ты будешь это делать. Что значит "чем" - это средство, программа или несколько программ, потому что разные вещи делаются разными программами. Что значит "как" - это то, как ты будешь пользоваться средствами, потому что использовать их тоже можно как эффективно, так и неэффективно.

Твоя задача: ты записывал информацию на протяжении года, потом был перерыв и через пять лет ты открыл эти данные и ты должен всё понять и вспомнить только по этой информации.

Вот у меня, допустим, книга появляется. Я решил, что я должен её прочитать и пройти всю, потому что мне это даст то-то и то-то. Я готов на это потратить год или два. Я создаю для неё её индивидуальную среду - как бы проект по изучению этой книги. Дальше в нём распределяю, где я буду хранить закладки прохождения книги, заметки по главам, примеры кодов из самой книги по главам, тренировочные коды для экспериментов по главам. Важно бэкапить этот проект, чтобы в один прекрасный день не потерять информацию, копившуюся полгода - настраиваешь бэкап, находя под него место, делая скрипты автоматического бэкапа, чтобы быстро всё было (скрипты готовы с прошлых книг). Вот у тебя получается такая заготовка для изучения книги. И после этого ты начинаешь, например, переносить все пункты в отдельный файл пройденных пунктов. Прочитал первый пункт первой главы - сохранил по нему важные моменты в отдельный файл с конспектом первой главы. Отмечаешь в файле пройденных пунктов, что пункт прочитал. Заметки по этому пункту пишешь в отдельный файл с заметками для первой главы. В общем, первая глава превращается в такую папку с данными только для неё, вторая глава превращается во вторую папку с данными только для неё. Не надо ничего мешать в кучу. Лучше максимально раскидать по индивидуальным папкам и файлам, а потом создать шапку-центр, который это всё объединяет воедино где-нибудь наверху. Это как html-файл со ссылками на главы, где каждая ссылка ведёт на html-файл со ссылками на пункты. Всегда надо знать (видеть), что ты прошёл и что ты не прошёл, чтобы ты мог посмотреть на пройденное и сказать "пройдя вот это всё, из нового я узнал вот это, это и это". Если нужно что-то перечитать, не бросайся на это сразу, запиши себе заметку в файл с заметками, прямо так и пиши себе на будущее "перечитай такой-то пункт, чтобы узнать про ту вещь поподробнее". Когда пишешь себе заметки, не оставляй моментов, где надо вспоминать или догадываться о деталях, помни, что когда ты это будешь читать, ты не сможешь ничего вспомнить из того, что сейчас кажется очевидным, так что пиши себе заметки, как незнакомому человеку писал бы. Если задание выполнил из заметки, запиши себе дату и "я задание выполнил". Всё, после этого ты можешь читать книгу как угодно, вся регистрация по её прохождению идёт и даёт полную картину.

С программами потяжелее всё, так как надо ещё подробнее всё писать там и оно может меняться по сто раз. Это наука не простая, нужно много изучать и про версионирование, и про системы по слежению за багами. Может пройти какое-то время и старая система может показаться безграмотной, надо будет всё переделывать. Где-то ты работал по водопаду, потом оказалось, что есть скрам. Где-то ты работал напрямую, потом оказалось, что есть юнит-тесты до кода. Потом ты начинаешь тесты писать, а вся программа останавливается. А потом идеи, которые были, уже не подходят, потому что ты решил всё переделать, так как для тестов будет лучше определённым образом всё писать. Если же ты этого не делаешь, то надо программу продолжать писать безграмотно и результат получается совсем неприятный (программа идёт в тупик шаг за шагом и потом её только заново написать остаётся, чтобы хотя бы продолжать её развивать). Так что лучший совет здесь - всегда смотри за другими проектами, смотри, как ими управляют, если даже сложно это всё, изучай это сложное управление. Имея все эти знания, вырабатывай свой стиль управления проектом, потому что модные стили тоже не являются гарантией эффективности, и фуфло может быть модным и признаваться с умным видом на конференциях, но потом все скрупулёзно всё равно ищут что-нибудь получше (сами сделать не могут же ничего обычно ;-) только разговоры разговаривать).

Очень много книг надо прочитать очень медленно и очень много программ надо написать не самых простых. Надеюсь, всё это ты не собрался держать в голове.

Подскажите пожалуйста в каком направлении смотреть, где с моим опытом будет проще, где будет возможность срезать углы?

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

Напиши программу cat или ls. Просто берёшь, смотришь на поведение программы и пишешь свою программу, которая делает всё то же самое. Вот это простые программы, но ты их не напишешь. И все об этом знают.

Почему ты не напишешь их? Потому что тебе кажется, что ты там что-то знаешь, а на самом деле ты не знаешь ничего, потому что ничего не изучал.

(Я тебе даже расписывать не буду, хотя написать есть много чего. Просто если ты не изучал это, то ты этого и не знаешь. И из космоса ты это не узнаешь.)

Имею 10 лет в телекоме. Знания на уровне CCNP с просроченным CCNP R&S. Cisco, и ему подобное сетевое железо, jun'ы. Linux(RedHat,Debian), Freebsd, на уровне среднего и ниже админа.

Ну вот, напиши cat. Как это тебе поможет? man cat только нужно и всё, чтобы все фичи узнать.

Как это будет лучше реализовать, можно ли оптимизировать алгоритм?

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

1. Найти все jpg в выбранной папке.

Ну, вот один скрипт находит все jpg файлы в заданной папке и переносит их в новую папку, которая предназначена для дальнейшей обработки (какой обработки - он не знает и не должен знать).
Скрипт принимает имя папки, искомое расширение файлов и имя новой папки для сохранения.

2. Для каждого jpg проверить заголовки (могу ошибаться, но они вроде есть в jpg) на целостность (мало ли файл повреждён или файл не является фотографией, а просто файлом с расширением jpg).

Второй скрипт так же принимает папку и проверяет в ней файлы на целостность. Результат его работы какой? Например, перенос нецелых файлов в новую папку. Дальше он тоже не знает, что там будет делаться с целыми или нецелыми файлами.
Скрипт принимает имя папки, искомое расширение файлов и имя новой папки для сохранения.

3.Информацию о каждом файле (имя и относительный путь, хэш, exif-тэги) записать в csv файл (или что-то подобное).

Третий скрипт принимает папку и пишет информацию о файлах в ней в csv-файл.
Скрипт принимает имя папки, искомое расширение файлов и имя файла для сохранения.

4.Найти дубликаты и применить фильтры (допустим - должны быть все exif тэги).

Четвёртый скрипт принимает папку, ищет дубликаты и удаляет их.
Пятый скрипт принимает папку и применяет фильтры к файлам в ней.
(Надеюсь, ты понял, что их нельзя объединять в один скрипт.)

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

Шестой скрипт принимает папку и перемещает файлы из неё в структуру папок.
Скрипт принимает имя папки и имя новой папки для сохранения.

Вот, и в конце ты пишешь седьмой скрипт, управляющий этими скриптами, который знает, куда и какую папку подавать на каждом этапе.

Пройдя этот курс в голове по-любому останется хоть какая-то база по С++, но будут ли базовые знания Си? Или всё же Си надо изучать отдельно?

У них разые стили при написании программ. C++ стремится к одному, оттуда и стиль свой. C стремится к другому, оттуда и стиль свой. То есть ты не только будешь напарываться на различия в синтаксисе (которые есть), но и писать на C неправильным стилем, делая всякие избыточные и ненужные вещи. Программы на C получаются намного короче аналогичных (эквивалентных) программ на C++.

Для примера тебе:
В C++, если есть приведение типа, оно делается явно, причём с выбором правильной операции приведения типа (кастования).
В C то же самое пишется просто без каких-либо операций, потому что существует неявное приведение типа (по стандарту), про которое ты знаешь, а потому и писать ничего не надо.
То есть уже минус одна заморочка, которая в C++ жрёт текст исходника, а в C она вообще не используется, оставляя исходник чистым и кратким.

Представь, например, что у тебя есть точка, которая описывается массивом её координат:
typedef int Point2D[2];
И дальше ты делаешь массив таких точек:
Point2D array[5];
А потом ты выводишь их по очереди:

Point2D *p, *q;

for (p = array, q = p + 5; p < q; p++) {
    print_point(*p);
}

А вот немного по-другому записано - и у тебя уже прямая получается:

typedef struct {
    Point2D *pt1;
    Point2D *pt2;
} Line2D;

Почему здесь указатели? Да потому что они жрут меньше памяти, чем массивы чисел. Так одна прямая жрёт 8 байт, а без указателей она жрала бы 16 байт. А была бы прямая в трёхмерном пространстве, то это так же занимало бы 8 байт, а без указателей - 24 байта.

Дальше код пошёл:


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

Казалось бы легко -

Это только кажется, и дело тут не в том, как определить строчную или прописную букву. Дело в алгоритме. Это задача относится к написанию лексического анализатора, а пишутся они через конечные автоматы.
wiki. конечный автомат (пример)

MySQL. Как загружать данные в Linux (Mint)?

Здесь про угол между векторами
угол(a, b) = arccos((a * b) / (|a| * |b|))
a * b - скалярное произведение (сумма произведений координат)
|a| - длина вектора (корень из суммы квадратов его координат)

Подскажите пожалуйста курсы (именно курсы), пусть платные и на зарубежных ресурсах, где можно изучить алгоритмы и структуры данных

Курсы - это ерунда. Если не можешь поступить в вуз, делай то же самое, что делают в вузе. Курсы - это полная ерунда, на них не дают и десятой части того, что дают в вузе.

Операция "запятая" - бинарная операция, которая выполняется слева направо. Сначала вычисляется левый операнд, затем вычисляется правый операнд. После этого вычисленное значение правого операнда становится результатом операции.

Это три операции "запятая".
(key, array, max, min)

Выполняется это вот так
((key , array) , max) , min)

Чтобы не путать операцию "запятая" со списками инициализации, перед запятой в операции "запятая" принято ставить пробел.

В C++ есть функция cout.flush(), которая, как написано в документации, "очищает буфер". Что это значит?

Это значит, что вывод на экран - слишком затратная операция, чтобы её выполнять для каждого символа по очереди. Поэтому символы пишутся в буфер (массив в оперативной памяти), а потом этот буфер один раз выводится на экран. Называется "буферизованный вывод".

И у меня появился вопрос: куда все это выложить

Опыт показывает, что всё это можно выкинуть, так как нужно оно только для самообучения (формирования мозгов). Хранить надо только то, чем пользуешься постоянно (шаблоны кода).

Можно ли язык C заменить perl?

Их надо знать оба. Бывает так, что основная программа пишется на C, а управляющий скрипт для этой программы пишется на интерпретируемом языке (Perl'е или Python'е).

Почему в вузах изучают C - потому что он содержит всё необходимое и не содержит ничего лишнего (можно сконцентрироваться на задаче).

Вот ты запускал какой-нибудь скрипт на Perl'е? А знаешь, что он выполнялся в интерпретаторе, который написан на C? На C написано много всего, о чём ты даже не думаешь. Даже этот сайт работает через nginx, а nginx написан на C.

Если ты выберешь один Perl, то не сможешь понимать исходники на C. А исходников на C с какими-либо примерами (вращение деревьев, например) больше, чем исходников на Perl'е. Так тебе нужно будет что-нибудь узнать, а ты не сможешь, потому что исходников на Perl'е не будет нигде.

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

Нет, он сделан гораздо хуже, чем C. В нём многие недоделки выдаются за такие якобы гениальные возможности. Например, необходимый копипаст или if'ы на три страницы выдаются за очень ясный код, поэтому его типа так много. А дело только в том, что они придумали, что фигурные скобки должны стоять всегда и на отдельных строках. В C функция занимает одну или две строки, в Go та же самая функция занимает шесть строк и это всё выдаётся за гениальность. В итоге код из трёх функций в C занимает 25 строк, а в Go - три страницы. Также если брать длину строки в коде, то в Go вернулись к длинным строкам в стиле PHP, когда это всё просто невозможно читать, потому что для прочтения одной строки нужно три раза ходить чай пить. Когда в Питоне, например, вводят правило 80 символов на строку, которого даже в C не было, хотя оно хорошее и снимает много проблем, то в Go делают наоборот и на все вопросы заявляют, что они гении, поэтому знают, как лучше. Поэтому никакого желания читать Go'шный код нет, так как каждый раз ты знаешь, что это неповоротливый код в три строки, размещённый на трёх страницах.