Потому как люди, надо немного больше написать, зато будет читаться легче:
typedef void (*fp)(int);
и наша запись возвращается в ряды 2-ого примера:
fp (*signal)(int, fp);
Спасибо!
Внятно написано. Попробовал — отнимает больше времени, но в запутанных выражениях чужих исходников реально помогает понять, что же наворотил автор…
Статья рассматривает вопрос о де-факто свершившемся акте насилия над C++, т.е. когда ничего не остается, кроме как копаться в чужой фантазии.
А так естественно в собственном коде такое надо избегать.
Не знаю где вы тут С++ увидели.
Тут Си, язык продуманный до мелочей.
Статься бесполезна.
Я с самого рождения могу прочесть любое объявление на Си без каких-либо раздумий.
Для тех, кто таким даром не обладает, Керниган и Ритчи написали целую страницу.
Называется она — «Сложные объявления».
Мне вот интересно. Как метод автора справится с char (*(*x[3])())[5]
Ну холивар C vs C++ это явно не тема этого топика.
Имхо статья подает ту самую страницу из K&R в более запоминающейся форме.
Да и с вашим примером метод вроде справляется, или я что-то не понял подвоха?
Есть даже тул для этого написанный. Называется cdecl (http://gd.tuwien.ac.at/linuxcommand.org/man_pages/cdecl1.html). И у него даже есть онлайн версия (http://cdecl.org/).
После нескольких дней чтения исходников всяких gnome-овских приложений окончательно убедился, что Си — это ад. Но за статью спасибо, очень доступно. Хотя думаю после недельных перерывов без С++ по-прежнему буду входить в ступор при виде 'char * const' и 'const char*' :)
Что хочется отметить. Статья вовсе не про С++.
Все приведенные примеры — чистый Си.
Да, конечно С++ позволит вам написать те же самые конструкции, но… тем не менее на С++ так обычно не пишут. Обычно так пишут как раз на Си.
Пример номер 3, как уже отмечали — пример плохого кода. Этот код сложно:
1. Читать
2. Понимать
3. Исправлять
4. Дополнять.
Я понимаю, что автор кода преодолеет все 4 указанные сложности, но если он этот код передает другому человеку (коллективная разработка), то код становится источником постоянных ошибок и фиксов.
Замечательно конечно. Но именно такие вещи как правило и отталкивают.
Лютвидж Доджсон(aka Льюис Кэрролл) не застал все эти компьютеры и языки программирования. Его код и методы разработки особенно интересно было бы читать…
Правило чтения по спирали