Войти
ФлеймФорумПрограммирование

Вопрос по ООП (4 стр)

Страницы: 13 4 5 617 Следующая »
#45
(Правка: 18:37) 18:36, 17 дек. 2019

nes
> Оно знает, что освобождает блок памяти, больше оно ничего не освобождает.

А CloseHandle должен и сокет освободить и файл закрыть - без этого ООП-а не будет.
Сила ООП-а как раз в том, что клиентский код НЕ ПАРИТ с чем он там работает и ему не нужна лапша из switch(type) чтобы упороться и в конце концов завязнуть в собственной сложности на каждых 100 строках программы.


#46
18:47, 17 дек. 2019

=A=L=X=
Это понятно, не понятен был посыл про free.

#47
18:50, 17 дек. 2019

nes
> Это понятно, не понятен был посыл про free.

free - это классическая процедурная функция - принимает указатель на заранее известную сущность - аллокацию в куче и вычёркивает её из кучи. Никаким другим заранее неопределенным поведением её вызов обладать не может, т.е. это процедурщина as is.

#48
18:50, 17 дек. 2019

=A=L=X=
А, ну это да, я то думал ты обратное пытался донести )

#49
18:57, 17 дек. 2019

Misanthrope
> схренали?
Оперирует сущностями о которых понятия не имеет. Судя по озвученному ранее подходит.

=A=L=X=
> ну это просто другое - дизайн вещей типа qsort использует одну
> функцию-компаратор к массиву одинаковых сущностей.

> а объекты должны быть напротив - массивом разных сущностей что гарантируется
> разными (как минимум потенциально) функциями для каждого из них.
А если засунуть в массив разные сущности с разными функциями и вызывать их из одной функции компаратора? )))

> free как раз ничего не знает что освобождает и не может гарантированно
> правильно освободить ресурсы - не хватает аналога виртуального деструктора как
> раз.

ну ок, пусть это будет не просто free(void*), а my_free(void*) внутри которой дополнительно вызывается деструктор.

#50
19:01, 17 дек. 2019

exchg
>my_free(void*) внутри которой дополнительно вызывается деструктор.
Деструктор чего?

#51
(Правка: 19:14) 19:06, 17 дек. 2019

nes
> Деструктор чего?
Какая разница чего? Пусть например будет вот так:

void* my_alloc(size_t size, void (*deinit)(void*));
void  my_free(void*);

static 
void deinit_cb(void*)
{
}


main ()
{
  struct my_struct* s = my_alloc(sizeof(*s), deinit_cb);
  if (s)
  {
    my_free(s);
  }
}

#52
19:36, 17 дек. 2019

exchg

Это шаг к ООП, но лучше уж тогда простой, но комплексный пример.
В библиотеке SDL есть структура SDL_RWops: https://wiki.libsdl.org/SDL_RWops
Это структура в которой клиентский код должны интересовать только 5 полей указателей на функции: size, seek, read, write, close.
Здесь первым параметром во все эти функции должен передаваться указатель на SDL_RWops чья функция вызывается, а остальное всё по смыслу и параметрам совпадает с библиотекой stdlib по части FILE *.
Кроме как раз close, так типовая реализация close предполагается такой: https://wiki.libsdl.org/SDL_FreeRW

/* this would be your SDL_RWops implementation's "close" method. */
void close_my_rwops(SDL_RWops *rw)
{
    if (rw != NULL) {
        /* close any other resources. */
        SDL_FreeRW(rw);
    }
}
Сама SDL при этом предоставляет ряд функций конструирующих заранее полезные варианты SDL_RWops, такие как:
https://wiki.libsdl.org/SDL_RWFromFile
https://wiki.libsdl.org/SDL_RWFromMem
https://wiki.libsdl.org/SDL_RWFromFP

Это всё есть ничто иное как объекто-ориентированный подход в рамках plain C к созданию понятия потока ввода-вывода, которые на С++ реализовывался бы через абстрактный класс с виртуальными функциями и деструктором конечно же. Но в plain C приходится изобретать велосипеды, да.

#53
(Правка: 20:15) 19:56, 17 дек. 2019

=A=L=X=
> Это шаг к ООП
А чего там не хватает для точно ООП ?

> но лучше уж тогда простой, но комплексный пример.
Я в курсе про 'fopencookie()' и производные (там даже с 'close()' ).

> Но в plain C приходится изобретать велосипеды, да.
Вопрос же не в велосипедах и в том на каком языке его удобней готовить, а в том, что меня заинтересовало где ООП начинается и как определить что оно уже началось.

#54
(Правка: 20:05) 20:04, 17 дек. 2019

=A=L=X=
> Это всё есть ничто иное как объекто-ориентированный подход в рамках plain C
И чем это по твоему принципиально отличается от передачи компаратора в 'qsort()' ? Только тем, что в 'qsort()' массив условно гомогенен? И количеством колбеков?

#55
20:46, 17 дек. 2019

тему метаклассов яля CLOS поднимали ?

#56
(Правка: 22:55) 22:47, 17 дек. 2019

=A=L=X=
> А CloseHandle должен и сокет освободить и файл закрыть - без этого ООП-а не
> будет.
> Сила ООП-а как раз в том, что клиентский код НЕ ПАРИТ с чем он там работает и
> ему не нужна лапша из switch(type) чтобы упороться и в конце концов завязнуть в
> собственной сложности на каждых 100 строках программы.
Это полиморфизм, но это ещё не ООП. Ничто не мешает CloseHandle под капотом распределяться через switch (handleType); и, учитывая возраст NT kernel, оно наверняка так на самом деле и сделано.
_

Note that Windows uses objects as an abstraction for resources. However, Windows is not object-oriented in the classical C++ meaning of the term. Windows is object-based. For more information on what object-based means for Windows, see Object-Based.

Прикольно, доки к винде специально утверждают, что их архитектура не имеет к ООП никакого отношения.
#57
(Правка: 23:11) 23:03, 17 дек. 2019

Delfigamer
> что их архитектура не имеет к ООП никакого отношения.

Справедливости ради - к ООП в терминах С++. Но с С++ вообще все сложно, например Степанов говорил, что STL вообще не объектно ориентирована. Ну и Кей в свое время еще досыпал.

#58
(Правка: 0:39) 0:35, 18 дек. 2019

exchg

Оперирует сущностями о которых понятия не имеет.

Я кстати так и не понял почему это является критерием по которому мы определяем ООП код, но спорить не стал.
Например выведи все методы и поля в public, и все сущности будут доступны. И что, магия ООП исчезает при этом?

#59
0:40, 18 дек. 2019

Спустя 4 страницы обсуждений я понял, что ничего не смыслю в ООП...

Страницы: 13 4 5 617 Следующая »
ФлеймФорумПрограммирование