typedef struct {
  void (*exec)(void*);
} task;
typedef struct {
  task parent;
} special_task;
static void exec_special_task(void*);
void f() {
  void **tasks;
  void **it;
  special_task task1;
  special_task task2;
  ((task*)&task1)->exec = exec_special_task;
  ((task*)&task2)->exec = exec_special_task;
  tasks = calloc(sizeof(void*) * 3);
  tasks[0] = &task1;
  tasks[1] = &task2;
  for(it = tasks; it && *it; ++it) {
    task *t = it;
    t->exec(it);
  }
}
static void exec_special_task(void *this) {
  // do something
}

быдлокод, конечно, но что-то типа того

потому что у тебя -Wall

И что?

Я бы на месте разработчиков gcc убрал опции -Wall -Werror -Wextra, включив их по умолчанию, чтобы отключать никогда нельзя было! Достали уже эти быдлокодеры: как ни собираешь что-нибудь в генте, так куча предупреждений вылезает. А не должно быть ни одного!

Если бы да кабы :) Это был бы уже другой язык.

Нет. Нормальный С. Только с защитой от слишком охамевших быдлокодеров.

Котятки, а int32_t и иже с ним вместо обычных int использовать стоит, или це не слишком нужно без необходимости?

Я жду пример хоть из веба.

к сожалению

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

ошибка: в передаче аргумента 1

cc1: all warnings being treated as errors

Мои глаза! Мало того, что стоит русская локаль (вот зачем?), так ещё и переведено не всё.

Для чего? Для счётчика в цикле - нет, для данных из сети - да.

Бля, ну смотря для чего. Если в структуре, представляющей заголовочник какого-нибудь формата данных, который, ясен пень, от архитектуры не зависит, то надо int32_t. А если machine-dependant или тупо счетчик в цикле от 1 до ста, то int

нормальное ООП
C++

Сейчас придут умные люди и объяснят что «нормальное ООП» и C++ в одном предложении не ставят. Меня ООП в плюсах устраивает, но я не прям так чтобы гуру-программист, наваявший 100500 успешных проектов.

почему не подходят? symbian целиком написан на крестах

Если хочешь гарантировать одинаковый размер переменной на разных платформах - стоит

А если счётчик от 0 до 100, почему-бы не поюзать uint8_t?

Почему драйверы и прочую системщину пишут, в основном, на C, а не на C++? (комментарий)

потому что он тормознее инта, а память дешевая

А, понятно, спасибо. Т.е. там, где нет жёсткой привязки к границам/размеру, можно пихать обычные типы.

Т.е. там, где нет жёсткой привязки к границам/размеру, можно пихать обычные типы.

я бы сказал «нужно», используй типы *int*_t только где оно реально нужно

Хорошо, спасибо. Я, правда, на сях/плюсах не пишу, но подумывал осилить немного. А пациент (плюсы) вообще жив ещё? Может все белые люди уже всё подряд на Python пишут, а критичное к производительности в сишные модули выносят.

Пример того, как на плюсах писать не надо.

Ты считаешь ОП не слишком толстый? 😉

Решил ещё сверху накинуть?

Сейбел П. - Кодеры за работой 2011

глава 12. Кен Томпсон стр 417

Меня ООП в плюсах устраивает

а вот Страуструпа неа.

ну так осведомись

Pike:

10) Biggest problem with Unix - by akaina Recently on the Google Labs Aptitude Test there was a question: «What's broken with Unix? How would you fix it?»

What would you have put?

Pike: Ken Thompson and I started Plan 9 as an answer to that question. The major things we saw wrong with Unix when we started talking about what would become Plan 9, back around 1985, all stemmed from the appearance of a network. As a stand-alone system, Unix was pretty good. But when you networked Unix machines together, you got a network of stand-alone systems instead of a seamless, integrated networked system. Instead of one big file system, one user community, one secure setup uniting your network of machines, you had a hodgepodge of workarounds to Unix's fundamental design decision that each machine is self-sufficient.

Nothing's really changed today. The workarounds have become smoother and some of the things we can do with networks of Unix machines are pretty impressive, but when ssh is the foundation of your security architecture, you know things aren't working as they should.

Looking at things from a lower altitude:

I didn't use Unix at all, really, from about 1990 until 2002, when I joined Google. (I worked entirely on Plan 9, which I still believe does a pretty good job of solving those fundamental problems.) I was surprised when I came back to Unix how many of even the little things that were annoying in 1990 continue to annoy today. In 1975, when the argument vector had to live in a 512-byte-block, the 6th Edition system would often complain, 'arg list too long'. But today, when machines have gigabytes of memory, I still see that silly message far too often. The argument list is now limited somewhere north of 100K on the Linux machines I use at work, but come on people, dynamic memory allocation is a done deal!

I started keeping a list of these annoyances but it got too long and depressing so I just learned to live with them again. We really are using a 1970s era operating system well past its sell-by date. We get a lot done, and we have fun, but let's face it, the fundamental design of Unix is older than many of the readers of Slashdot, while lots of different, great ideas about computing and networks have been developed in the last 30 years. Using Unix is the computing equivalent of listening only to music by David Cassidy.

Потому что не нужно. ООПщина нужна лишь в гуйне.

Ахах, Эдик, что ты делаешь, прекрати... В ведре линукса ООП используется на сях http://lwn.net/Articles/444910/ :)

какое-то подмножество С++.

Мультипарадигменный язык, мб слышал? Так вот, в нем это нормально. Т.е. пользоваться std никто с пистолетом к виску не заставляет.

Ну вы сравнили одну особенность против целой пачки.

Ну я ж не спорю, что в C++ гораздо больше неочевидного и скрытого поведения, но одна только эта «фича» Си делает этот язык непригодным для работы с бинарными протоколами. Поэтому писать системщину можно только на модифицированном Си, в котором либо отключён strict-aliasing, либо есть средства управления алиасингом. Первый подход используется в ядре линукса, второй также поддерживается gcc.

А виртуальные функции?

Тебе тут надо посмотреть простыню указателей на функции или сам догадаешься?

ООП - это подход к программированию :) Можно на ку-васике изобразить, при большом желании.

«крестам» требуется очень жирный рантайм.

4.2. Читать 1.4.7 стандарта:

Two kinds of implementations are defined: a hosted implementation and a freestanding implementation. For a hosted implementation, this International Standard defines the set of available libraries. A freestanding implementation is one in which execution may take place without the benefit of an operating system, and has an implementation-defined set of libraries that includes certain language-support libraries (17.6.1.3).

Т.е. ядро или драйверы на C++ не будут иметь доступ к своему жирному рантайму, т.к. он будет тупо не реализован для случая запуска без ОС.

move-семантику

За ее использование в ядре я бы убивал.

то она обогатилась атомарными операциями и потоками

Второго во freestanding implementation не будет по очевидным причинам, а первое неюзабельно ввиду убогого API, которое не покроет все аппаратные платформы (даже если будет реализовано во freestanding implementation).

chrono

Ага, без ОС.

move-семантику

За ее использование в ядре я бы убивал.

За использование в ядре или вообще? Если только в ядре - чем же ядро такое особенное?

писать системщину можно только на модифицированном Си, в котором либо отключён strict-aliasing, либо есть средства управления алиасингом

А писать на си с учетом алиасинга - что, совсем rocket science?

Сейчас придут умные люди и объяснят что «нормальное ООП» и C++ в одном предложении не ставят

Нормальное по сравнению с таковым в Си. Я вовсе не утверждаю что реализация ООП в плюсах идеальна. Это лично моё мнение, никому не навязываю.

Сейчас придут умные люди толстые тролли и объяснят разведут срач о том, что «нормальное ООП» и C++ в одном предложении не ставят. Меня ООП в плюсах устраивает, но я не прям так чтобы гуру-программист, наваявший 100500 успешных проектов.
fixed

Не соглашусь. Само по себе дерево драйверов в линуксе очень отлично вписывается в ООП. Фактически там уже в неявном есть некоторые его элементы (кривой полиморфизм и кривое наследование).

А писать глючный и тормозной говнокод можно на любом ЯП.

Я вовсе не утверждаю что реализация ООП в плюсах идеальна.

Она нигде не идеальна, даже в в «абсолютно объектно ориентированных языках», коими себя позиционируют жава и додиез.

А почему он тормознее, кстати?

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

А писать на си с учетом алиасинга - что, совсем rocket science?

Вот есть у меня массив чаров с данными. Привести его к структуре с учётом алиасинга можно только скопировав этот массив в юнион из массива и структуры и прочитав структуру оттуда. Это и лишнее копирование, и убогий union cast, что раздувает код неимоверно и делает его нечитаемым, когда можно было бы просто отключить алиасинг (либо глобально, либо для одного указателя) и привести указатель на чар к указателю на структуру и пользоваться на здоровье.

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

тормоза доступа к невыровненным данным оправдывают экономию на спичках копирования?

хм. только если данные читаются один раз. куда, кстати? :)

А пояснить, что именно он имел в виду слабо? Чет похоже на пердеж в лужу ретрофага. План 9 у него решает проблемы, с которыми линупс не справляется ага ага.

тормоза доступа к невыровненным данным

Массив чаров можно объявить так, чтобы данные были выровнены. И это уже даже не нестандартное расширение, в C11 есть _Alignas.

неверно

чтобы данные были выровнены => чтобы некоторые данные были выровнены. мы же говорим о структуре, ене правда ли? :)

не должно быть ни одного!

EMERGE_DEFAULT_OPTS="--quiet-build=y"

Угу, если у тебя болит голова, ее надо отрубить...

если голова болит, то пусть болит не у меня

Почему драйверы и прочую системщину пишут, в основном, на C, а не на C++?

Простота отладки, минимум оверхеда.

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