[C][образование] Нужна критика программы курса про Си

Поступить туда всё же непросто, так что тупых почти нет, есть ленивые )

Я промолчу.

Я имел в виду самый примитивный уровень - выделили памяти побольше и стали отдавать кусками поменьше.

Я так и понял. Но тут нужно, для понимания проблемы, понятие о страницах и mmap, а этого нет. Так что это для начального общего курса Си спорная идея.

да ладно, нмейк ты сам туда вписал, реализация мейк так или иначе везде есть. я думаю, сконс/цмейк лучше на какой-нибуть «потом» оставить. сколько все-таки часов на это все выделено? то, что требуется гуй на смежках, до ООП и курса по ГУЯм - печально, но тогда да, лучше ГТК сложно что-то найти. я так понимаю программирование под winapi и posix потом изучаются?

Ладно, cmake помечаем как кандидата на выкидывание.

У нас вообще нет выделенного обязательного курса по гуям в настоящий момент (а если и будет, то слишком поздно).

Про Posix и WinAPI есть в других курсах и будет увеличено.

А что вообще требуется от гуёв? Есть ещё EFL на C, но он, вроде, винду не умеет.

А какие варианты?

Scons, jam, premake.
---

«Программирование, часть 1» (Паскаль)

И тут вначале был паскаль?

И тут вначале был паскаль?

Паскаль преподают не только в школах?

Какая разница, что написать: gcc или icc?

Именно так. Проблема в том, что паскаль — язык хоть и милый, но несколько устаревший и неактуальный. Можно было хотя бы обновить на Модула-2.

По своему опыту скажу что лучше дать не просто make, а вообще CLI утилиты и «основы юникс». У вас там есть «Объектные и исполняемые файлы. Библиотеки», это очень правильно. Ну и рассказать про то что С возник не сам по себе, а именно как часть платформы юникса. А потом он вместе с элементами этой платформы мигрировал и на другие платформы.

Если планируете под виндовсом проводить лабы - используйте cygwin.

То есть уделить специально время системному пониманию роли и месту С в «общей картине всего».

Использование библиотеки на Си из другого языка

Голосую обеими руками, так как это вынудит студентов с этим «другим» языком хотя бы ознакомиться. Да и выбор широкий — Python, Ruby, R. Или даже ФОРТРАН. Вопрос только — хватит ли семестра на такую интенсивную программу?

Про регулярные выражения — соглашусь с прозвучавшим выше мнением, для Си это «внешняя» идея. Я практиковал подобный подход, но заставлял сравнивать самостоятельную реализацию задачи поиска/ обработки строк на C++ с решением той же задачи в Ruby или Python — потому что в этом случае выбор стоит между скоростью выполнения и скоростью разработки/модификации.

Какая разница, что написать: gcc или icc?

1. Да тут все только msvc видели.

2. icc не видел (он не бесплатен для education), но подозреваю что в районе «--std=c99-Wall -Werror -DNDEBUG -Wl,bstatic» будут отличия.

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

Проблема скорее в том, что там дельфя и пол-курса там VCL.

дать не просто make, а вообще CLI утилиты и «основы юникс»

а точнее наверное должны быть _отдельно_ «инструментальные средства разработки», включающий отладчики, трассировщики, верификаторы, линкеры, библиотекари и наконец компиляторы,интерпретаторы, эмуляторы. и прочее-прочее..только вот по уму это отдельная, большая хотя и связная тема. В курсе С допустима краткая сводка с указанием конкретики используемой в лабах/практикумах и ссылками на инструменталку.

что С возник не сам по себе, а именно как часть платформы юникса

есть легенда, что С делался не в последнюю очередь для стар-трека(игруха такая) на PDP. В этом случае обоснованно приложение в виде словаря клингонского языка и лабы «Галактеко опасносте»

Да тут все только msvc видели

Между прочим, даже под мастдай есть gcc и geany - вот вам и компилятор, и IDE.

подозреваю что в районе «--std=c99-Wall -Werror -DNDEBUG -Wl,bstatic» будут отличия.

Просто читаем маны...

Между прочим, даже под мастдай есть gcc и geany - вот вам и компилятор, и IDE.

Это примерно и предполагается. В теории.

cmake я бы убрал из такого курса.

игру писали на асме, как и первую реализацию Юникса. это потом уже для портабельности переписали все скопом на Си

Убрано.

Си как кросс-платформенный ассемблер с человеческим лицом.

Должно быть так:
Си как язык абстрактной виртуальной машины с UB, Sequence Points, Integer Overflow, и прочими западнями.

Си как язык абстрактной виртуальной машины с UB, Sequence Points, Integer Overflow, и прочими западнями.

Ну нельзя же так сразу пугать! Это у нас позднее v_v

Хоть там и есть всякие западни, С - самый простой из всех ЯП, которые я встречал.

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

GTK бы выкинуть вообще. Можно давать какие нить лабы с бонусом в виде графического интерфейса на GTK - для самостоятельной инициативы.

вообще-то её изначально писали на Бейсике :) При портировании на PDP были какие-то проблемы, то-ли Бейсик у них был не той модели, то-ли скорости/памяти нехватало..

С - самый простой из всех ЯП, которые я встречал

Это говорит лишь о твоей зашоренности.

Ну нельзя же так сразу пугать!

А так получается, что ты их обманываешь.

Это говорит лишь о твоей зашоренности.

Почему? Сам по себе С действительно прост. А вот писать на нём...тут возможны варианты.

Ну не понимаю я всякие перлы-питоны, что поделать?

Совсем недолго, спустя месяц-другой лектор откроет страшную правда, это ок.

GTK бы выкинуть вообще.

У нас есть проблема необходимости гуя в четвёртом семестре. Лично мне кажется, что имеет смысл подумать о её решении путём ликвидации необходимости в гуе в четвёртом семестре в хотя бы в двух курсах (а к пятому семестру и ООП начитают).

Однако, такое решение этой проблемы маловероятно (

Тебе стоит немного расширить сознание^Wзнание ЯП.
Вот небольшой список простых языков: форт, factor, scheme, lua, tcl, limbo, go, io. Возможно ещё ML, не знаю.

форт, factor, scheme, lua, tcl, limbo, go, io

Слышал только про форт и tcl. Простыми бы их не назвал.

Простыми бы их не назвал.

Тем не менее, тот же retroForth на порядок проще, чем си.

Может я и ретроград, но я бы не отступал сильно от К&R. Там к нему (к переводу на русский, розовая книжечка) в 80х издавался решебник - который надо перерешать хоть раз в жизни (это все задачки из самого учебника). У меня Си был также в курсе ОСей, преподаваемому по учебнику Таненбаума, а практика параллельно шла тоже по К&R (тоже все подобные задачки прорешали, чтобы от зубов отскакивало). Сегодня (в 21 веке) я бы возможно скомбинировал с другой книгой по программированию под линкусом (забыл название), где и getopt и расширенные символы и построение менеджера памяти делается. Хотя я бы это лучше 2й частью сделал. Но гуи - это совсем имхо лишнее. У нас, в 90х, был отдельный курс X windows, вот так бы и здесь - если очень хочется сделать 3й курс - то сделал бы GTK третьим семестром.

Сам по себе С действительно прост.

Спецификация языка занимает 550 страниц. Едва ли это можно назвать словами «действительно прост».

Сам по себе ... действительно прост. А вот писать на нём...тут возможны варианты.

Обычно так брейнфак характеризуют :)

Оберон забыл помянуть.

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

Это случайно не

Advanced Linux Programming
Mark Mitchell, Jeffrey Oldham, Alex Samuel (CodeSourcery LLC)
(New Riders)

имеется в виду? Уж очень по содержанию похожа.

Кстати, «Вильямс» издавал её на русском языке (перевод).

Спецификация языка занимает 550 страниц.

Можно, конечно, читать спецификацию от корки до корки. А можно сначала несколько первых глав K&R. И далее - по необходимости. Научиться писать достаточно полезные программы на С можно за месяц. Если такая цель поставлена.

Обычно так брейнфак характеризуют :)

Ну на брейнфаке что ни напиши, всё равно брейнфаком оно и останется. :)
А вот на С можно написать и «брейнфак», и «фортран», и «code complete». И ещё много чего. :)

В принципе, для начала стоит перечислить, что вообще есть в C, и чему будет учить. Каждый пункт стоит расписать в трех уровнях – обязательном, продвинутом и доскональным.

1. Синтаксис и пунктуация самого C. Все базовые типы, функции, операторы, а также понятие о точках следования. На следующем уровне – var_arg, продвинутая арифметика указателей, чтобы можно было расшифровать вот такое спаслание: http://isis.poly.edu/kulesh/stuff/src/klist/

   #define list_entry(ptr, type, member) \
   	((type *)((char *)(ptr)-(unsigned long)(&((type *)0)->member)))
   

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

   (char *(*(**foo[][8])())[]; )

   , и всех ключевых слов, включая const, volatile, register и их комбинации.

   const int a;
   
   int const a;
   
   const int *a;
   
   int * const a;
   
   int const * a const;
   

   В качестве источника каверзных вопросов можно использовать тесты вроде этого: http://www.rmbconsulting.us/a-c-test-the-0x10-best-questions-for-would-be-embedded-programmers

2. Связь с «железом»: куча и стек. Про продвинутый уровень сложно что-то добавить, разве что выбрать конкретную архитектуру и по ней тщательно пройтись.
3. Препроцессор. Всем известные #include, #define, #ifdef etc, более редкие вроде #, ##, #line, и, наконец, тонкости вроде скобок вокруг аргументов и #define…do{…}while (0)
4. Стандартная библиотека. Здесь дается или только то, что нужно для курса, или же рассказываются общие возможности (в т.ч. va_arg и setjmp). Плюс подводные камни (вроде недавнего memcpy и memmove), или же все рассказывается от корки до корки, с добавкой нестандартных, но распространенных функций вроде тех же strdup, itoa.
5. Инструменты. Прежде всего IDE с отладчиком (XXI-й век на дворе!), во вторую очередь SVN или его замена, и только в последнюю – CLI-утилиты. В CLI-части можно еще дополнительные акценты поставить на необязательных, но полезных ключах, вроде -Wall или -Werror.
6. Переносимость. Big/little endian, stdint/stdbool, выравнивания, упаковки данных. Тут у меня подводных камней было мало, так что про сложные вещи ничего посоветовать не могу. Разве что можно указать принцип, что если можно не привязываться к архитектуре – привязываться не нужно. Ну и плюс написание простенькой программы «приняли по сети сообщение – посчитали – отдали результат», которая бы работала и на PC, и на ARM (или лучше AVR, там инициализационной обвязки поменьше).
7. Расширения C. С одной стороны, идет вразрез с пунктом 6, с другой – очень не помешает иметь о них хоть какое-то понятие. Как об опциональных расширениях под отдельные компиляторы, вроде вложенных функций GCC, так и тех, без которых не обойтись на микроконтроллерах (вроде xdata).
8. Многопоточное программирование. Обширная и непростая тема.
9. Проектность. О том, как вообще вести большой проект на C. Тут, опять же, у меня есть одни домыслы. Разве что посоветовать технические моменты: прятать все, что можно, под капот и делать как можно более простые интерфейсы к модулям, а также социальные: рассказать о VCS, багтрекерах, форумах и мылах. Ну и еще разобрать примеры – например, файловую часть ядра Линукса, заодно и ООП на C пройти. А по социальный части почитать маты Линуса в lkml.

Можно, конечно, читать спецификацию от корки до корки. А можно сначала несколько первых глав K&R.

++

Точно так же и латех можно начать изучать с Львовского и Балдина, а можно сразу начать мучить Кнута...

Кажется нет, не припомню 3х авторов. Там был один автор. И она не переводилась, вроде.

Понятное дело, что все это за один предмет одного курса не осилить. Так что стоит определиться, какими гвоздями подковывать студентов. Входные курсы доверия не внушают, но самое интересное – последующие занятия. Судя по всему, курс по C довольно-таки транзитный, раз потом будет только ООП на C++. Так что можно смело выкидывать пункты с шестого по последний, инструменты оставить на уровне IDE и небольшого рассказа о подноготной (без четырех занятий на «редактор + CLI»!). Из остального – не заходить дальше несложных примеров на арифметику указателей.

Еще не помешает глянуть, что ж творится в тамошних ВУЗах, благо, сейчас онлайновые курсы доступны как никогда. Из первых, пришедших на ум: MIT: http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-087-practical-programming-in-c-january-iap-2010/assignments/ , и Essential C от Стэнфорда: http://cslibrary.stanford.edu/101/ , его можно использовать как план-минимум.

Самое заметное отличие тамошних курсов – практика начинается с самой первой лекции, и практически отсутствуют такие обширные темы, как затронутые в лекциях 3, 4, 5.

Поэтому начинается критика:

• Лекция 1, подкрепляется семинаром. Общие слова про архитектуру выкидываются, дается введение на 3 минуты про C, и публике представляется «Hello, World». После чего он модифицируется, чтобы была парочка массивов и переменных, глобальных и локальных, а также несколько функций. Здесь же рассказывается о куче и стеке. Показываются проблемы с нулевым указателем, делением на ноль, а также рекурсия с выбиванием стека. Эти проблемы браво решаются в IDE. Можно здесь же рассказать про разные типы, их разрядность, и заполировать объединениями. На кадре стека лучше не акцентироваться, про регистры и символы вообще ничего не рассказывать. Про библиотеки и исполнение программ, по-моему, несколько рановато.
• Лекция 2. Стандарты – слишком оторвано от практики, лучше о них рассказать попозже. Остальное нравится.
• Лекция 3. Совсем не нравится – не слишком в тему курса. Можно посвятить указателям и массивам, все-таки это главная проблема в C.
• Лекция 4. То, что есть сейчас – лучше сжать по максимуму. Акцентироваться на исполнении программы, затронуть точки следования. Осветить стандартную библиотеку по основным пунктам.
• Лекция 5. Тоже можно урезать текущего осетра, лучше здесь рассказать о библиотеках и чиркнуть пару строк про стандарты.
• Лекция 6. Библиотеки ушли в п.5, здесь можно в общих чертах рассказать о том, что в курсе не затронуто, и куда копать в случае пожара. Здесь же можно показать структуры с указателями на функции (ООП), и кинуть мостик к C++ с абстрактными типами данных.

…

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

…

Про практические занятия конкретику сейчас не придумать. Есть только напутственные слова: во-первых, строки в C – один из самых больших его кошмаров, и акцент на них может быть только сержантского типа: «Вы у меня будете сеть тянуть 25 часов в сутки! Ночью и в дождь! Нефиг расслабляться!». Во-вторых, если они будут связаны с текущими лекциями-семинарами, то всем будет лучше. В-третьих, совсем классно получится, если, скажем, две-три работы будут продолжением друг друга, этакий мини-курсовик. Здесь код раздуется сам собой, и модульность-разбивка на файлы получится совершенно прозрачной. Когда технологию требует задача, а не препод, то студенту и сердиться не на кого.

А можно сначала несколько первых глав K&R.

Так писал бы с самого начала: «первые главы K&R действительно просты».

(type *)((char *).....)

Говнокод. http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-ali...

Связь с «железом»: куча и стек.

В Си нет никакого стека.

Мой пойнт - это то что надо K&R хорошо освоить, все задачки прорешать, а это один курс уже, если глубоко и по-хорошему, не по верхам. Нас муштровали с пойнтерами так, что были задачки типа «пойнтер на функцию, возращающую пойнтер на функцию, принимающую пойнтер ... возвращающую ...» (и так построки исписаны) и надо было эти синтетические примеры правильно парсить. После таких задачек - ошибок в реальных примерах уже не делали.

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

Вот именно про это и речь. Я, например, о «простоте»/«сложности» инструмента сужу по времени погружения в него на такую глубину, с которой становится возможным решение необходимых практических задач, а не по толщине «спецификаций» и «стандартов».

PS: Необходимость «спецификаций» и «стандартов» это не отменяет, равно как и необходимость их использования в качестве справочных материалов.

В Си нет никакого стека.

А где хранятся локальные переменные, декларированные в функции?

Частное мнение.

А где хранятся локальные переменные, декларированные в функции?

Это не специфицировано. Где компилятор захочет, там и хранит.

И почему мы получаем stack overflow ?