По опыту (правда этот опыт набирался на Qt4) emit все же как-то используется. Я встречался с ошибками, приводящими к SegmetationFault и решавшимися добавлением emit.

-6

ixSci Mar 3 2014 at 09:40

emit это пустой макрос и влиять он никак не может. А segmentation fault отлавливаются специальными, а не шаманскими средствами ;)

DancingOnWater Mar 3 2014 at 09:51

Я в курсе, но valgrind ничего толкового не показывал, а падало все при входе в сигнал.

ixSci Mar 3 2014 at 10:58

Такое поведение характерно для ситуации, при которой используются release и debug сборки совместно

DancingOnWater Mar 3 2014 at 13:59

Допустим(я почти уверен, что не так, но было уже давно), ну как тогда объяснить, что добавление пустого макроса решило проблему?

ixSci Mar 3 2014 at 14:39

Понятия не имею. Вероятнее всего — «просто так, вот, случилось». Так бывает. Именно поэтому я и рекомендовал искать настоящую причину, т.к. от такого «исправления» она никуда не делась.

DancingOnWater Mar 3 2014 at 15:30

И так несколько раз в разных ситуациях? «Просто так вот получилось» — это не ответ. Да и шаманизма в программирование не бывает.

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

Я не копался в моке, но что-то мне подсказывает, что отсутствие в доке кода без emit — это не случайно.

Lol4t0 Mar 3 2014 at 20:40

Шаманизма в программировании не бывает, а undefined behavior бывает.

Вообще, возможно, что-то не так собралось (make не пересобрал какой-то файл), а добавление emit изменило файл и инициировало пересборку.

DancingOnWater Mar 4 2014 at 09:27

С пересборкой возможно, это было уже года 3-4 назад, детали уже позабылись. К сожалению, провести тщательное расследование сейчас не представляется возможным, но мне почему-то помниться, как я убедился, что добавление emit-а убирает ошибку, а удаление — добавляет.

NeoCode Mar 3 2014 at 10:20

Кстати, кто какие знает системы позднего связывания и динамических возможностей в статически типизируемых компилируемых языках?
Наиболее известные:
1 Виртуальные фукнции С++
2 Сообщения Objective C
3 Сигналы и слоты Qt
Что есть еще? Меня весьма интересует данная тема.

Monnoroch Mar 3 2014 at 10:25

Еще есть динамические языки, где, условно, a.b === a[«b»] и оно как-то проксируется на хэш таблицу (дерево, список) с методами.

NeoCode Mar 3 2014 at 10:27

Ну с динамическими все понятно, там вообще eval() есть. Меня интересуют в основном статические.
Хотя вы тоже правы, можно добавить четвертым пунктом рефлексию.

Monnoroch Mar 3 2014 at 10:30

На C++ тоже можно запилить свой eval(). Переменные в текущий скоуп, правда, не получится, но вычисление строки — вполне возможно.

Lol4t0 Mar 3 2014 at 20:43

Ну вообще-то нет. Попробуйте объявить свой тип данных и использовать его. В общем случае, вам потребуется компилятор в рантайме.

Monnoroch Mar 3 2014 at 23:03

Я же сказал, что в текущий скоуп не получится экспортировать переменные. И классы. Я имел ввиду любые имена, кроме, кстати, c-like функций. А вычислить любое корректное выражение на плюсах — пожалуйста :)
Кстати, если уж на то пошло, то заэмбеддить clang в приложение не такой уж большой гемор, но можно обойтись и system("...").

Sap_ru Mar 3 2014 at 12:39

Лямда-функции всякие не подходят? Тогда C++ и Java новые версий.

blackmaster Mar 3 2014 at 13:27

Лямда-функции в данном контексте можно рассматривать как указатели на функцию (вырожденный случай виртуальных функций).

NeoCode Mar 3 2014 at 13:37

Оно все в конечном итоге сводится к косвенному вызову функции (т.е. к указателям на функции). Интерес представляют более высокоуровневые конструкции.

Sap_ru Mar 3 2014 at 14:14

Тогда всё равно Java, так как там и полностью динамические вызовы есть (хоть их и нет в самом языке Java 7, но в других языках для JVM они есть и есть в Java 8).

-1

Monnoroch Mar 3 2014 at 12:54

Есть еще ручное динамическое связывание: object->onClick = base->onClick;

unwrecker Mar 3 2014 at 12:52

А является ли первая картинка неким посылом к понимаю содержимого статьи?

На картинке мы видим совершенно избыточный элемент — ленту ФУМ, намотанную под гайки ПНД тройника. Это совершенно ничего не даёт, так как уплотнительным элементом в этом тройнике являются резиновые кольца. Подобная же намотка не поможет и в случае протечкам по кольцам — вода просто вытечет со стороны трубы.

blackmaster Mar 3 2014 at 13:26

Смотря на картинку, нельзя с 100% уверенностью сказать, что по трубам течёт именно вода, а не другая, более вязкая, жидкость.

unwrecker Mar 3 2014 at 13:31

Вода, вода там :)
Вот источник фотки: dacha.innsk.ru/444

blackmaster Mar 3 2014 at 13:33

Эх… убедили))

avn Mar 3 2014 at 19:24

Google картинки рулят!

namespace Mar 3 2014 at 21:33

Замечательная статья, замечательный перевод, но хочу присоединиться, что явно не хватает второй части для нового синтаксиса (Qt 5+).

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

blackmaster Mar 10 2014 at 03:34

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

Show the best of all time