Как напсать online игру используя SDL

Да нет, имхо, толковых книг очень много, особенно по распространненным языкам. В этом-то вся и проблема. Хотя я вообще почти никаких книг не читал, так что это требование не обязательное. В C, к примеру, главное понимать суть работы с памятью, чтобы не делать ляпов с указателями. Всякие приемы можно подсмотреть в ядре или в nginx - тоже очень качественное C-приложение. Для C++ - QT или wxWidgets, очень агрессивно использующие ООП и шаблоны. Т.е. если вы думаете что-то сделать, но не знаете как - подсматривайте в другой программе, как самый простой вариант. Это не всегда будет эффективно, в плане того, что может можно сделать вообще иначе и еще лучше, но это уже следующий этап =)

Да, так. Ну разве что с терминологией: подключаются хеадеры библиотек (приминительно к C[++]), а сами библиотеки "подключатся" компилятором. Но это, вообщем-то, не суть важно

QT/wxWidgets - это библиотеки C++. Вообще говоря рисовать формочки в них можно и без всяких GUI приложений (на них можно даже не GUI делать, но, имхо, это разврат). У QT есть какая-то своя программка, которая позволяет нарисовать формочку мышкой, но она делает C++ исходник только этой формочки, а саму инфраструктуру и все рабочие классы писать все равно надо руками =).

Для C - да, библиотека - это набор подпрограмм. Для C++ это еще и набор классов/шаблонов. Тут все довольно просто понять. Когда вы компилируете (вообще говоря, правильный термин - "транслируете") исходный файл получается объектный код - это, грубо говоря, набор комманд процессора в синтаксисе понятном операционной системой (в нашем случае - ELF). Каждый исходный файл, вообще говоря, компилируется отдельно, и он не знает о существовании "внешних" объектных файлов. Подключаемые заголовочные файлы обычно содержат лишь объявления, т.е. указания какие функции бывают, без конкретного кода, чтобы компилятор мог определить вызов какой-то функции как "вызов во вне".

Чтобы получить программу объектные файлы надо объединить в один файл, грубо говоря. Этим занимается линкер (*ld), которому, в качестве аргументов, передаются библиотеки которые надо "залинковать". Он проходит по каждому файлу, ищет "внешние вызовы" и, если это вызовы к функции из той же программы, просто в другом объектом файле, заменяет на получившийся указатель этой вызываемой функции внутри уже готовой программы, либо, если это вызов функции из библиотеки, он смотрит на то, какая это библиотека.

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

Динамические библиотеки подгружаются (.so) в момент исполнения в свою память, и одна загруженная в память библиотека может быть использованна несколькими загруженными программами - экономия места и памяти. Линкер, в случае динамических библиотек, просто прописывает "ссылку" на эту библиотеку, указывая операционной системе, откуда надо брать вызовы функций. Однако, в таком случае, в момент запуска программы библиотека "слинкованной" версии должна быть в системе, причем даже ее наличие не гарантирует работоспособности - некоторые библиотеки меняют API без изменения т.н. so-name (версии lib<name>.so.<major>.<middle>.<minor>), что приводит к странным сообщениям о missing symbol, при попытке запуска (операционная система не нашла такой функции в указанных библиотеках). Собсно любой достаточно опытный гентушник очень хорошо знаком с ситуацией битых линков на библиотеки =).

Не совсем. Языки бывают компилируемые и интерпретируемые. Первые надо сначала скомпилировать (и слинковать, однако обычно это опускают, понимая под "компиляцией" процесс получания исполняемого файла (как я уже говорил, правильный термин для получения объектных файлов - трансляция, но уж так сложилось)) целиком, и только потом запускать. Вторые какбы "компилируют" читаемую программу строка за строкой, сразу же выполняя полученный код (грубо говоря). Еще есть языки с виртуальной машиной (Erlang, Java, Python) - они сначала компилируют программу в т.н. "байт-код", т.е. машинно-независимый бинарный код, понимаемый из вируальной машиной, которая, уже выполняя программу, интерпритирует данный бинарный код в машинный код.

Есть мнение, что виртуальные машины - суть зло и мало отличаются по скорости от интерпретируемых языков. Сие не есть правда, ибо существует как минимум два типа - stack-based и registy-based. Python - stack-based и потому медленный, Java и Erlang - registy-based и потому быстрые. Другой миф, особенно про Java, что в некоторых случаях она может быть "быстрее С". Не может быть, ибо она написана на C, а любой overhead всяких автоматических управлений памятью, динамических конструкций и garbage collection, безусловно, скорости не добавляет. Можно говорить о том, что одинаково квалифицированный код сделанный за одинаковое время на Java/Erlang для определенного круга задач может работать быстрее чем на C. Но это только потому, что реализация некоторых вещей, которые эффективны в данной задаче и идут в упомянутых языках "из коробки", на C (в случае Erlang, например, легкой многопоточности), потребует намного большего времени и квалификации. Однако устремить "квалифицированность" программистов к бесконечности в обоих случаях (если считать, что с повышением квалификации время на разработку уменьшается), то за любой промежуток времени программа на C будет работать быстрее (причем значительно)

Да, это (любое из перечисленных) код, который:
а) Не красивый - без отступов, или с корявыми отступами, без четко выраженного стиля, и т.п.
б) Не корректный - делает что-то так, как это делать не нужно (есть примеры на лурке, например bool.toString() == "true" на каком-то языке (C# вроде, да будь он проклят =))). Обычно из-за недостаточного понимания механизов работы языка или конструкций языка.
в) Не стандартный - ну, почти всегда, да, потому что, обычно, не соблюдение стандартов ввиду того, что "по стандарту не получается", свидетельствует о низкой квалификации программиста или недостатке времени на разбирательство, получается см. пункт (б).
г) Плохо структурированный - когда нет четкой логики программы, а наляпано все как наляпалось, вроде работает, но фиг поймешь как. Обычно включает в себя пункт (б). Сюда же входят копипасты кода вместо выделения его в функции, includ'ы исходных файлов в C (кроме случая с шаблонами в C++) и прочая. Сюда же применение goto где его не стоит применять (в C он часто используется для выхода из функции по ошибке, с выполнением некоторых "завершающих" действий, вроде деинициализации каких-нибудь структур, что есть грамотное (и, практически, общепринятое) его использование), ибо скакать по коду пытаясь отследить куда и что пошло в каких случаях очень неприятно.

Ну а вообще быдлокод сложно описать. Обычно когда на него натыкаешься, сразу понятно, что это он =)

P.S. Это не у меня количество букв возрастает, это пост вправо сползает ;)