The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Выпуск пользовательского окружения Enlightenment 0.24 , opennews (ok), 18-Май-20, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


88. "Выпуск пользовательского окружения Enlightenment 0.24 "  +/–
Сообщение от FixingGunsInAiremail (?), 18-Май-20, 14:31 
Каждый раз, когда я вижу новости про это DE, вспоминаю этот блог пост:
https://what.thedailywtf.com/topic/15001/enlightened/2

Ржу до усрачки и больше не хочу иметь ничего общего с этим куском говна. Вряд-ли они хоть что-то исправили за 5 лет.

Ответить | Правка | Наверх | Cообщить модератору

92. "Выпуск пользовательского окружения Enlightenment 0.24 "  +2 +/–
Сообщение от Аноним (7), 18-Май-20, 14:44 
Какой тупой высер существа, неспособного в программирование:

> typedef void(* Evas_Smart_Cb)(void *data, Evas_Object *obj, void *event_info);
> Ok, let’s move on. obj is you Evas_Object, that is anything you can imagine. Is it a button? Is it a text label? Is it a wooden table?

А теперь как это делается в C++ и в Qt в частности:
void func(QWidget* w, ...);

w - это чё? Кнопка, текстовый лейб или деревянный стол? Или это у нас тут полиморфизм через базовый класс?

Все остальное там - такое неосиляторство. Да, особенно про const void *data и строку поржал, спасибо, даун.

Ответить | Правка | Наверх | Cообщить модератору

114. "Выпуск пользовательского окружения Enlightenment 0.24 "  +2 +/–
Сообщение от Аноним (114), 18-Май-20, 15:52 
Справедливости ради, void* поинтеры - способ номер 1 отложить личинку себе в руки что в няшной сишке, что в крестах. В крестах даже reinterpert_cast<>, скажем так, ярче сверкает в исходниках, что в данной точке control flow происходит трансформация ужа в ежа. Типизация спасет мир (искренний привет F* c зависимыми типами).
Вот что пассаж про деревянные столы странный - это да. Как бы сам смысл современного ООП-like программирования в том, чтобы выделить в предметной области "хотспоты", в которых бизнес-логика меняется часто, и представить их в архитектуре как точки расширения, в которые можно воткнуть полиморфное поведение. А еще потом дисциплинировать кодеров, тыкая носом в контракт точки расширения, чтобы принцип подстановки Лисков соблюдали.
Ответить | Правка | Наверх | Cообщить модератору

145. "Выпуск пользовательского окружения Enlightenment 0.24 "  +/–
Сообщение от Ordu (ok), 18-Май-20, 17:54 
> Вот что пассаж про деревянные столы странный - это да.

Суть в том, что когда ты пишешь обработчик on-click для listitem, то ты ждёшь, что тебе в этот on-click будет передаваться listitem, а не стульчак от унитаза. И ежели даже ты принимаешь Evas_Object*, то ты всё равно ждёшь, что это будет указатель, который можно преобразовать к listitem*. В идеале, стоило бы подключить типизацию языка, и объявлять обработчик, явно указывая среди аргументов listitem*. Или не listitem*, а то, что туда будет передаваться.

> Как бы сам смысл современного ООП-like программирования в том, чтобы выделить в предметной области "хотспоты", в которых бизнес-логика меняется часто, и представить их в архитектуре как точки расширения, в которые можно воткнуть полиморфное поведение.

Если каждая функция регистрирующая коллбек будет использовать свой тип коллбека, то тебе никто не мешает писать что-то в стиле:

register_callback([](auto arg1, auto arg2) { return my_generic_callback((void*)arg1, (void*)arg2) });

В C нет лямбд, но это решается элементарно: можно взять компилятор C++, и писать на "C с лямбдами".

Ответить | Правка | Наверх | Cообщить модератору

150. "Выпуск пользовательского окружения Enlightenment 0.24 "  +/–
Сообщение от Аноним (7), 18-Май-20, 18:09 
Ты сам то проверял в какое говно эти твои лямбды компилируются? Даже при условии, что от С++ там будут только одни лямбды и ничего больше.
Ответить | Правка | Наверх | Cообщить модератору

167. "Выпуск пользовательского окружения Enlightenment 0.24 "  +1 +/–
Сообщение от Ordu (ok), 18-Май-20, 19:54 
> Ты сам то проверял в какое говно эти твои лямбды компилируются? Даже
> при условии, что от С++ там будут только одни лямбды и
> ничего больше.

Не, не проверял, но раз ты спросил проверил. Легенда такая: set_callback хочет функцию, которая принимает unsigned int, а наш real_callback принимает unsigned char. То есть требуется преобразование типов, которое даже не удастся оптимизировать в noop. Вот собственно код:

typedef int (*callback_t)(unsigned);

extern void set_callback(callback_t fn);
extern int real_callback(unsigned char);

void do_it()
{
    set_callback([](auto a) { return real_callback(a); });
}

Компилируем в асм, и получаем... Я не буду копировать сюда вывод g++ -O2 -S -fverbose-asm, ты его сам можешь получишь, я упрощу его слегка для читаемости:

lambda:
    movzbl    %dil, %edi    # tmp87, D.43746
    jmp    real_callback    #

do_it:
    leaq    lambda(%rip), %rdi    #,
    jmp    set_callback    #

Какая из перечисленных строк содержит "гoвнo", о котором ты говоришь?

Тут лямбда, которая не полагается ни на какое окружение, ей не нужны malloc'и, это просто безымянная pure функция. При некотором везении преобразования типов это no-op, то есть возможна оптимизация вида не создавать никакой лямбды, и передать вместо неё указатель на функцию, которая вызывается из лямбды.

Вот когда лямбда, например, обращается к переменным из стекового фрейма функции, в которой она объявлена, вот тогда всё становится гораздо интереснее: можно сделать без malloc'а и жирных указателей, но придётся использовать заморочные техники выяснения адресов переменных на стеке, и при этом время жизни лямбды будет ограничено временем жизни стекового фрейма, на котором она объявлена. Альтернатива -- это malloc под environment лямбды и жирные указатели, которые будут объединять в себе указатель на код, указатель на окружение, причём последний ещё и какой-то техникой динамической сборки мусора прикрывать придётся (если речь о C++, то ref_count'ом), потому что это окружение должно существовать пока существует хотя бы один из жирных указателей на эту лямбду, и его надо подчистить, когда заканчивается время жизни последнего. Иначе будет либо утечка памяти, либо обращение к освобождённой памяти.

Но ежели ты идёшь на такие замороки, то ты же должен понимать, что ты делаешь?

Ответить | Правка | Наверх | Cообщить модератору

170. "Выпуск пользовательского окружения Enlightenment 0.24 "  +/–
Сообщение от Аноним (114), 18-Май-20, 20:48 
Я все еще не понимаю, зачем это проверять. Если мой код сегфолтнулся, потому что в него извне передали что-то не то, то это проблемы некорректного внешнего клиентского кода. Указатель на функцию задает некий обобщенный хук, на который можно подвесить твой произвольный коллбэк. В реализации ты кастишь void* указатель к чему нужно (другого рантайм полиморфизма в С нет, уж сорян) и пишешь в Doxygen, что следите за тем, что передаете в эту реализацию хука - внутри есть касты в такой-то тип. Не уследил - сам виноват, тут дикий запад и примитивнейшая типизация, недалеко ушедшая от ассемблера (там-то типы исключительно в голове у разработчика, а для процессора всё просто числа), пиши на Scala, например, тогда.
Ответить | Правка | К родителю #145 | Наверх | Cообщить модератору

173. "Выпуск пользовательского окружения Enlightenment 0.24 "  +1 +/–
Сообщение от Ordu (ok), 18-Май-20, 21:20 
> В реализации ты
> кастишь void* указатель к чему нужно (другого рантайм полиморфизма в С
> нет, уж сорян) и пишешь в Doxygen, что следите за тем,
> что передаете в эту реализацию хука - внутри есть касты в
> такой-то тип. Не уследил - сам виноват, тут дикий запад и
> примитивнейшая типизация, недалеко ушедшая от ассемблера (там-то типы исключительно в
> голове у разработчика, а для процессора всё просто числа), пиши на
> Scala, например, тогда.

Компьютер нам нужен для чего? Для того, чтобы автоматизировать рутину связанную с хранением, передачей и обработкой информации. Написание программ -- не исключение. Зачем писать в doxygen, если можно всё записать типами аргументов, и тогда оно не просто будет записано в понятном программисту виде, оно ещё и будет проверяться компилятором. Да мало того, если у тебя няшно всё описано типами, и правильно подобранными идентификаторами, то тебе IDE будет подсказывать сигнатуры функций/методов, и ты из этих сигнатур будешь извлекать всю информацию о том, как функцию можно использовать. Тебе не нужна будет документация.

Бывают ситуации, когда без документации не обойтись -- не подобрать хорошего идентификатора, или, например, glBegin/glEnd надо использовать в паре, и описать это на C не удастся. Но фишка в том, что даже это не какое-то там фундаментальное ограничение языков, скажем на lisp'е можно написать так:

(with-gl-begin :triangle-strip
    (draw_triangles))

> Я все еще не понимаю, зачем это проверять.

А я не понимаю, почему бы это не проверять компилятором. Какой смысл отказываться от этой автоматической проверки? Ради того, чтобы почувствовать себя ковбоем на Диком Западе? Других способов самореализации не найти?

Ответить | Правка | Наверх | Cообщить модератору

184. "Выпуск пользовательского окружения Enlightenment 0.24 "  +/–
Сообщение от Сишникemail (?), 19-Май-20, 10:16 
В сишоньке можно как-то так написать:
void someFun(View *view) {
    //TODO somejob
}

static LayoutsParams lpBigRedButton = {.widthPercent = .5f, .heightPercent = .5f, .gravity = CENTER};
View bigRedButton = {.onClick = &someFun, .type = BUTTON, .layoutParams = &lpBigRedButton, .skin = &sRedButton, .text = "some text"};

Всё чётко и понятно без документации, ошибиться практически невозможно, автоматизировать создание кнопок с шаблонными полями можно макросами.

glBegin + glEnd можно в функцию поместить, в которую передаётся указатель на другую функцию, которая должна быть выполнена между ними.

Ответить | Правка | Наверх | Cообщить модератору

186. "Выпуск пользовательского окружения Enlightenment 0.24 "  +/–
Сообщение от Ordu (ok), 19-Май-20, 10:44 
> В сишоньке можно как-то так написать:
> ...

Проблема несовпадающих типов функций таким образом не решается.

> glBegin + glEnd можно в функцию поместить, в которую передаётся указатель на
> другую функцию, которая должна быть выполнена между ними.

Неудобно -- промежность между glBegin и glEnd придётся выкидывать в отдельную функцию. Лучше макросами:

WITH_GL_BEGIN(GL_TRIANGLE_STRIP, {
    draw_triangles();
});

Ответить | Правка | Наверх | Cообщить модератору

189. "Выпуск пользовательского окружения Enlightenment 0.24 "  +/–
Сообщение от Сишникemail (?), 19-Май-20, 11:49 
В си нет с этим проблемы, потому что функция там это просто указатель на адрес в памяти. Могу любую другую передать, если аргументы не важны, и она выполнится. Хотя компилятор ругнётся на любую, чья сигнатура отличается от void (View*).
Ответить | Правка | Наверх | Cообщить модератору

193. "Выпуск пользовательского окружения Enlightenment 0.24 "  +/–
Сообщение от Ordu (ok), 19-Май-20, 14:00 
> В си нет с этим проблемы, потому что функция там это просто
> указатель на адрес в памяти. Могу любую другую передать, если аргументы
> не важны, и она выполнится. Хотя компилятор ругнётся на любую, чья
> сигнатура отличается от void (View*).

Ну да, но проверка типов не будет выполняться. И если необходимое преобразование типов аргументов не является noop, то у тебя в программе баг. И тут как на диком западе -- если твоего внимания не хватило заметить это, то о баге ты узнаешь от пользователей в багтрекере.

Ответить | Правка | Наверх | Cообщить модератору

196. "Выпуск пользовательского окружения Enlightenment 0.24 "  +/–
Сообщение от Сишникemail (?), 19-Май-20, 17:43 
Как это не будет выполняться, выполняется же. Если я в качестве в колбека передаю функцию вида void a(View *view) {}, то всё ок, могу передать int b(){} например, и мне ничего за это не будет, она вызовется и правильно без багов отработает, только gcc варнинг кинет.

>И если необходимое преобразование типов аргументов не является noop, то у тебя в программе баг.

Было бы очень странно в качестве колбека передавать что-то, что требует чего-то кроме ссылки на View, в таком случае проблема явно не в языке.

Ответить | Правка | Наверх | Cообщить модератору

198. "Выпуск пользовательского окружения Enlightenment 0.24 "  +/–
Сообщение от Ordu (ok), 19-Май-20, 19:57 
> Как это не будет выполняться, выполняется же. Если я в качестве в
> колбека передаю функцию вида void a(View *view) {}, то всё ок,
> могу передать int b(){} например, и мне ничего за это не
> будет, она вызовется и правильно без багов отработает, только gcc варнинг
> кинет.

Это зависит от конвенции вызова. На самом деле это UB. Никаких гарантий на результат тебе компилятор не даёт.

>>И если необходимое преобразование типов аргументов не является noop, то у тебя в программе баг.
> Было бы очень странно в качестве колбека передавать что-то, что требует чего-то
> кроме ссылки на View, в таком случае проблема явно не в
> языке.

Можно передать SubView, если он производный тип от View. Впрочем, мне кажется, в EFL это сработает так, как ты описываешь, потому как преобразование типа от SubView к View -- это noop в EFL. А вот если SubView не является подтипом, тогда в лямбде ты можешь завернуть его в тип-адаптер, который будет реализовывать методы View, транслируя их в вызовы SubView.

Ответить | Правка | Наверх | Cообщить модератору

174. "Выпуск пользовательского окружения Enlightenment 0.24 "  +1 +/–
Сообщение от Аноним (174), 18-Май-20, 21:32 
Вот нормальный правильный коммент. А то пришли тут плюсовики со своими лямбдами-шлямбдами. void*, va_list и указатель на функцию - все, что нам нужно.
Ответить | Правка | К родителю #170 | Наверх | Cообщить модератору

176. "Выпуск пользовательского окружения Enlightenment 0.24 "  +/–
Сообщение от Аноним (176), 18-Май-20, 21:43 
Кстати, вот сразу видно специалиста. Поясни мне, как специалист, почему когда я хукаю open64, софт сегфолтится? Как я понял, там есть 2 версии open64, одна с va_list, другая без. если я хукаю без va_list, то всё в порядке (но половина вызовов проходит мимо меня), а если с ним, то всё падает. Я бы, возможно. и не заметил, просто есть софт, который дёргает все эти __lxstat64 напрямую. Это электрон если что. Хромиум у меня с va_list по-моему работал, а вот электрон сегфолтится на этапе инициализации.
Ответить | Правка | Наверх | Cообщить модератору

187. "Выпуск пользовательского окружения Enlightenment 0.24 "  +/–
Сообщение от Аноним (7), 19-Май-20, 10:50 
А дебагер что показывает?
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру