Посоветуйте книгу для систематизации разрозненных знаний по С

так то практика батенька, за Вас её никто не выучит, открывайте любой нормальный проект и начинайте изучать, а ещё лучше подпишитесь в какой-нибудь opesource проект (например гнум разрабатывать) - и сообществу профит и Вам опыт

и да, держите K&R под рукой, полезно

а такой супер книги в которой написано как всё сделать хорошо я не видел

Посмотри «искусство программирования на С» Хэзфилда и Кирби.

> для систематизации разрозненных знаний по С

Спецификация языка.

но не ситуации, когда их нужно применять

А это только практикой. Читать код и писать код, года два хотя бы.

ИМХО если в С не знать что такое указатель, сообществу можно принести только вред.

По теме: Kernigan and Ritchie читать обязательно. Если не знаешь как работать с указателями, считай не знаешь C совсем. А дальше можно и на какой-нибудь проект подписаться.

> В сотый раз изучать синтаксис printf не хочется.

Прочитай K&R от корки до корки. Да, про printf там тоже будет, ведь никто из авторов нормальных книг не затачивался под твои огрызочные познания.

ИМХО если в С не знать что такое указатель, сообществу можно принести только вред.

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

//и да, я верю в ТС :)

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

Ага, вчера 2 часа пытался понять, почему у меня программка падает, пока не нашел разыменование указателя, указывающего черт знает куда. А падала программка совсем не на разыменовании, а вообще в произвольных функциях после этого. Причем падала тихо, безо всяких сегфолтов :(

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

> Ага, вчера 2 часа пытался понять, почему у меня программка падает, пока не нашел разыменование указателя, указывающего черт знает куда. А падала программка совсем не на разыменовании, а вообще в произвольных функциях после этого. Причем падала тихо, безо всяких сегфолтов :(

Ага. У меня программа падала в случайных местах после fclose нулевого указателя.

падала в случайных местах после fclose нулевого указателя.

Нулевого? Жесть. Привык думать, что при обращении по нулевому указателю программа тут же падает по сегфолту.

>имхо знание это не сильно сакральное, что такое указатель можно понять за 5 минут на пальцах За 5 минут на пальцах вряд ли объяснишь, нужно какое-то время, чтобы это осознать. Но то что ничего сложного нет - согласен.

знание мест где можно сломать ноги - про это в книжках особо не пишут

Это да. Тут помогает только опыт, да и то - не всегда.

Я просто хотел сказать, что C это не настолько простой язык, чтобы сразу начать создавать что-то полезное. Не стоит сразу браться за OS проект - лучше сначала попробовать написать что-то для себя.

И да, я тоже верю в TC

Просто начал читать книгу по openGL и первый же пример стал сегфолтится(пришлось откорректировать, в книге main была без параметров и без initGlut, которому они нужны) из-за того, что в параметрах main вместо argc поставил *argc.

Хочется сделать онлайн-слешер(симулятор дуэлей на холодном оружии),т.к. AI пока, боюсь, не осилю. Будет совсем здорово, если хоть что-нибудь успею до КРИ, куда собираюсь пока в качестве зрителя

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

На питоне я в блендере сделал аналог шашек в кубе 10х10х10, хочется что-то «нормальное», да и примеры в книжке на Си. Наверное, K&R стоит пока отложить и обращаться в случае, если будет что-то конкретное непонятно

Я просто хотел сказать, что C это не настолько простой язык, чтобы сразу начать создавать что-то полезное. Не стоит сразу браться за OS проект - лучше сначала попробовать написать что-то для себя.

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

а большая команда лучше тем что там скорее найдётся ментор

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

> Наверное, K&R стоит пока отложить и обращаться в случае, если будет что-то конкретное непонятно

Систематизации ты так не добьешься.

И если уж «обращаться», то не к K&R, а к тексту Стандарта. K&R - это учебник, а не справочник.

как-то так, например. и практика

Сегодня главу с упражнениями закончу, а там видно будет. Хотя если идти совсем сначала, то до Кернигана и Ричи нужно было прочитать «Алгоритмы и структуры данных»

+1

> Хотя если идти совсем сначала, то до Кернигана и Ричи нужно было прочитать «Алгоритмы и структуры данных»

Э, нет. Быдлокодинг на отдельно взятом языке - сам по себе, дискретная математика - сама по себе.

А как быдлокодить без знаний математики?

K&R

> А как быдлокодить без знаний математики?

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

Как раз быдлокодить-то это совсем не мешает:) Хочется перестать быдлокодить и начать жить

А мне «быдлокоденье» нужно для решения определенного круга своих задач. И без математики совсем никак. Пока мат. модель сотворишь, пока оценишь что да как, пока алгоритмы разработаешь. А потом остается самое сложное - превратить формулы в быдлокод, который еще и работать должен... :D

> А мне «быдлокоденье» нужно для решения определенного круга своих задач. И без математики совсем никак. Пока мат. модель сотворишь, пока оценишь что да как, пока алгоритмы разработаешь.

У тебя математика торчит из предметной области, верно? А бывают предметные области, где математики почти нет, а та, что есть - давно упрятана в стандартные библиотеки. Какую-нибудь бизнес-логику для рисования окошек на экране описывать (хотя Си для этого - ужасный выбор), или там микросхемы за ножки дёргать в драйвере..

Микросхемы «за ножки дергать» мне тоже иногда приходится :)

Просто для твоей области оправдано построение математических моделей. Есть области с гораздо менее формальной постановкой задачи, для таких областей более полезно объектное моделирование. Есть области, где больше подходит функциональный анализ (я сейчас не про ФП).

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