Функции в структуре Си

Тебе нужен Си++.
В терминах Си ты что-то делаешь не так. У тебя при нормальной формулировке задачи для Си просто не должно быть желания пихать указатель на функцию в структуру. Это нелепо. Это как брюки с 5 штанинами. Возможно, но бессмысленно.

всё нормально, не слушай этого алкоголика выше :)

Просто я видел такое не раз и интересно, есть ли смысл?

А от большого числа функций stackoverflow не бывает?

например, указатели на функции пихают в структуры в разных API, где нужно определить много коллбэков

libpurple к примеру

from http://stackoverflow.com/questions/562303/the-definitive-c-book-guide-and-lis...

to http://www.planetpdf.com/codecuts/pdfs/ooc.pdf

Посмотри на Gtk и испугайся!

Вот и я о том, удобно, когда функции сгрупированны

Я из-за Гтк такое со структурами и вытворяю, пытаюсь понять, как гтк устроен

У тебя вполне нормально все. Разве что для указателя на функцию я бы тип объявил.

И да, у тебя в структуре int (*prop)();, а в реале int prop(int n). Оно хоть и компиляется без вопросов, но может привести к проблемам (забудешь, что там 1 аргумент, да впихнешь где-нибудь два), потому и удобней typedef сначала сделать.

Не надо. GTK — такая дрянь, что просто жуть! Еще дрянности к нему добавляет использование идиотской glib.

Лучше какую-нибудь более приличную сишную библиотечку используй.

Почему ты не читаешь K&R, но бежишь с этими вопросами сюда?

Есть ли какой-нибудь аналог this из Java/JS/other-OOP-lang, что бы обратится к полю уже существующей структуры

Да, передавай объект первым параметров во все “методы”.

все нормально, только у тебя n случайно равен 0 ибо не инициализирован (зафигачь туда еще методы init/deinit или open/close для инициализации/деинициализации, аналоги конструкторов/деструкторов) и функция в main это явно расширение gcc и не переносимо

для ООП необязательно пихать указатели на функции в структуру. тем более, что это никак тебе не поможет получить this.

что тебе надо:

int prop (object *this) {
    return 64+this->n;
}

т.е. явная передача this.

а object определять как

typedef struct {
    int n;
} object;

Привычка организовывать пронстранства имен - плохо ли это в Си? Или забить и использовать static?

в си пространство имен одно. делай префиксы в именах, типа mylib_prop, mylib_object.

А от большого числа функций stackoverflow не бывает?

стек никак не связан с количеством функций.

Покажи пример пожалуйста, а то я не очень то и понимаю )

Понял, спасибо!

Черт, а я дурак думал, что тут есть какие-то пространства имен, а оказывается все кучей в стеке :(

Указатели в структуре нужны для того, чтобы иметь возможность указать, скажем, конструктор или метод объекта. Скажем, один объект будет иметь метод «сумма», а другой — «разность».

А вот насчет this ты правильно говоришь: тяжко в С с этим. Можно, например, так выкрутиться:

#include <stdio.h>

typedef struct object {
  int n;
  int (*prop)(struct object *, int);
} object;

int main(void){
  int prop(object *self, int n){return n + self->n;}
  struct object obj = {26, &prop};
  printf("%d\n", obj.prop(&obj, 10));
  return 0;
}

Круто, я сделал printf(«%d\n», obj.prop(&obj)); и все :-)
Пока мне хватит и этого, еще раз спасибо
Прикольный язык Си, простенький

Указатели в структуре нужны для того, чтобы иметь возможность указать, скажем, конструктор или метод объекта.

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

void object_init(object *this) {
    this->n = 0;
}

или, если не нужно уметь в объекты на стеке, то так:

object *object_init (void) {
    object *this = calloc (sizeof (object), 1);
    this->n = 0;
    return this;
}

зачем тут какие-то указатели на функции?

указатели могут понадобиться, например, если у тебя есть какая-то более продвинутая объектная система, с фабрикой классов, интроспекцией, рефлекшеном, перегрузкой, и т.п.

но в этом случае стоит задуматься, а нужен ли тебе Си.

ООП на Си делается только так:

typedef struct {...} MyClass;
void MyClassMethod(MyClass *this);

Если можешь избежать вложенных функций, избегай.

Кстати, если интересуют clang/gcc-специфичные расширения для ООП, то можно загуглить __attribute__((cleanup(...))) и про реализацию defer.

не только.

посмотри на gobject — там классы и объекты разные сущности, объекты ссылаются на классы, и содержат instance data, а классы ссылаются на методы.

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

зачем тут какие-то указатели на функции?

Ну вот пример: #include <stdio.h>

typedef struct object { int n; int (*prop)(struct object *, int); } object;

int main(void){ int plus(object *self, int n){return self->n + n;} int minus(object *self, int n){return self->n - n;} object objs[2] = {{26, &plus}, {99, &minus}}; printf(«1: %d, 2: %d\n», objs[0].prop(&objs[0], 10), objs[1].prop(&objs[1], 10)); return 0; }

gcc 2.c -o 11 && ./11 1: 36, 2: 89 Хотя у меня ни разу не возникало нужды в подобном — тащить вместе с объектом какие-то функции.

Еще чуть чуть и ты изобретешь таблицу виртуальных методов :D

Хотя у меня ни разу не возникало нужды в подобном — тащить вместе с объектом какие-то функции.

правильно, потому что функции нужны _в классе_, а не в объекте.

а классы в примитивных объектных системах не используются.

классом, по сути, является набор методов для работы с объектом.

твой пример понятен, но это не самая лучшая реализация.

гораздо приятнее работать, если класс и объект разделены.

тогда у тебя получится вот такой класс:

typedef struct {
  void (*)prop(object *this, int n);
} class;

объект:

typedef struct {
  class *klass;
  int n;
} object;

создаем классы:

  class plus_class = {
    .prop = plus
  };
  class minus_class = {
    .prop = minus
  };

создаем объекты

  object objects[2] = {
    {
      .klass = &plus_class,
      .n = 10
    },
    {
      .klass = &minus_class,
      .n = 20
    }
  };

дальше дергаем:

objects[0].klass->prop(&objects[0], 50);
objects[1].klass->prop(&objects[1], 25);

Почему на ЛОРе столько примитивных вопросов по сишке? RTFM!

Плюсую. Учитывая, что именно в это разворачиваются методы в С++.

Только, лучше конечно, еще для собствннной безопансти поставить константу.

У тебя при нормальной формулировке задачи для Си просто не должно быть желания пихать указатель на функцию в структуру.

И кто же наградил вас таким великим знанием?

Здравый смысл, который подсказывает, что сама идея объединять функции и данные для Си чужда.

указатель на функцию - это данные

указатель на функцию - это данные

Ого-го. Смотрите, буквоед-демагог в треде! Кыш отсюда..

ваше мнение очень важно для нас

Именно поэтому я так заботливо вам его сообщаю.

Здравый смысл, который подсказывает, что сама идея объединять функции и данные для Си чужда.

Авторы SQLite, например, считают иначе, что у тебя есть им противопоставить?

С чего ты взял, что они так считают? Если они так делают, то не факт, что они считают это чем-то хорошим. Костыли, знаешь ли, призваны поддерживать код, а не просто уродовать фасад.

Если они так делают, то не факт, что они считают это чем-то хорошим.
Костыли, знаешь ли, призваны поддерживать код, а не просто уродовать фасад.

Возьмем публичное API:

int sqlite3_create_collation_v2(
  sqlite3*, 
  const char *zName, 
  int eTextRep, 
  void *pArg,
  int(*xCompare)(void*,int,const void*,int,const void*),
  void(*xDestroy)(void*)
);

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

а где тут пихание указателей на функции в структуру?

а где тут пихание указателей на функции в структуру?

Здесь:

struct CollSeq {
  char *zName;          /* Name of the collating sequence, UTF-8 encoded */
  u8 enc;               /* Text encoding handled by xCmp() */
  void *pUser;          /* First argument to xCmp() */
  int (*xCmp)(void*,int, const void*, int, const void*);
  void (*xDel)(void*);  /* Destructor for pUser */
};

Я не знаю что делает эта функция и поэтому мои возможности по исправлению всего этого невелики, но если ты считаешь, что int(*xCompare)(void*,int,const void*,int,const void*) не уродливо, то у меня для тебя плохие новости.
Впрочем, это, скорее всего, какой-то коллбек или что-то в этой роде.
А топик про попытку слепить что-то вроде плюсового класса, но в Си. И суть желания ТСа не в указателе на функцию как таковую, а в (цитирую) «организовывать пронстранства имен».

говнокод только в смысле что используется вложенная функция (main::prop) это gcc-изм, недопускаемый в классике С. Вынеси int prop() из main() и наступит счастье, для полноты можно ещё static.

но если ты считаешь, что int(*xCompare)(void*,int,const void*,int,const void*) не уродливо, то у меня для тебя плохие новости.

Оно уродливо только потому, что сам С уродлив. Или ты считаешь, что qsort, например, не из той же оперы?

А топик про попытку слепить что-то вроде плюсового класса, но в Си.

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

Здравый смысл, который подсказывает, что сама идея объединять функции и данные для Си чужда.

Ваш здравый смысл вас подводит.

И если нужны еще примеры, то, например, авторы питона тоже не гнушаются такого подхода.

Всё нормально.