0xd34df00d
13.11.2012 10:28 Azoth_mac
Посоны, помогите ошику исправить позязя: http://bpaste.net/show/HMbOlfO4DcL8mA7pR...
Посоны, помогите ошику исправить позязя: http://bpaste.net/show/HMbOlfO4DcL8mA7pR...
А НЕХУЙ БУСТ НЕСТАБИЛЬНЫЙ СТАВИТЬ!
В HOMEBREW УЖЕ ЕСТЬ
Найс.
Святые хуи из преисподней.
Я люблю йбаццо^W Boost. Хотя один хуй.
Нет :(
/usr/local/include/boost/fusion/container/list/cons.hpp:99:32: error: no matching function for call to 'begin'
, cdr(fusion::next(fusion::begin(seq)), mpl::true_()) {}
^~~~~~~~~~~~~
Это же из кода бустца.
А где код-то, который исправить?
Ты бедному begin не cons подсунул в seq, а хуйню какую-то
offending-строчке (и файле) нет ни единого вызова begin(). Если что, ругать идет на строчку, строящую грамматику как ItemEnd_ = qi::lit ("END:") >> qi::lit (qi::_r1) >> '\n';
И судя по тому, что на всех прыщемашинах это конпелируется на ура, проблема в макобусте.
Сверь версии
1.52 везде. А, ну и на макомашине еще clang, да, патченный эпплом во все щели.
расскажи, чем всё кончится, в общем.
Пока кончилось тем, что я отключил ненужный модуль.
Кстати, с Boost 1.51 тоже были проблемы, но тогда они решились добавлением recursive_wrapper где-то внутри бустца, не помню уже.
интересно, а как такое вообще дебажить? есть ли способ запринтовать вывод типа или что-то в этом духе?
форсировать инстанцирование промежуточных типов.
А по уму если — не использовать такое.
Бузд не использовать?
нет, не использовать boost.fusion/boost.mpl/boos.spirit
Почему? А что вместо?
сам буст использовать
потому что наебёшься и напляшешься.
это как? инстанцировать левоту всякую? можно чуть подробнее попросить?
приведите код с проблемой, я скажу как.
начать можно с того, что подготовить отдельный cpp-файл с минимальным примером с проблемой
кстати, такие проблемы иногда бывают из-за того, что ты включаешь какой-нибудь cstdio после включение бустовых хедеров
ну я конкретно про код из /0, какие шаги (кроме отключения модуля) стоит применять, чтоб найти ошибку?
https://github.com/0xd34df00d/leechcraft... строки 113-117.
Извини за неминимальность, я щас не у мака уже.
я в /0 никакого кода не видел
конструкция, что на 103 строке начинается — для начала убрать <<; разбить на отдельные токены, посомтреть, собирается ли
Минимизировать конкретный токен.
В итоге переходя от базовых конструкций до составных ты найдёшь проблемное сочетание
Проблемное сочетание в qi::string (qi::_r1), это я уже проверил.
а если всякие "END: " убрать?
Проверял, те же ошибки.
а если в отдельный файл без всего вытащить?
Это я еще не пробовал, лол. Попробую завтра на парах.
да, собственно, интересует, что делать дальше? (кроме как тыкать туда-сюда компилируется-некомпилируется)
то есть, по сути, нам необходимо найти вот здесь
/usr/local/include/boost/fusion/container/list/cons.hpp:99:32: error: no matching function for call to 'begin'
, cdr(fusion::next(fusion::begin(seq)), mpl::true_()) {}
тип переменной seq, и понять, почему fusion::begin для него не определен. там мы уже и минимальный пример сможем создать и так далее. но как это сделать? (найти тип в момент компиляции)
Файлить багу на шланг скорее.
чё? да нет же. я не про шланг и не про еще что-то. я про то, как багу вообще найти.
похоже какая-то хуйня с namespace resolution.
Надо вытащить в отдельный файл и попробовать всё тоже самое с using namespace по все поля
Скорей всего понадобится что-то типа using boost:fusion::begin или что-то типа
А с чего ты взял, что бага в этом коде или в бусте?
вполне может быть, что со strict точки зрения шланг прав.
Я гонял код с -pedantic -Wall (хотя это не аргумент, конечно).
не аргумент
я понимаю, но мне это не интересно :) интересен гарантированный метод ловли таких багов, кроме как тыканиями.
да ничего я не взял. я говорю, что мне интересно, как понять, кто виноват, отсутствие имплементации или неверный тип, если в стек трейсе тип не пишется.
s/стек трейсе/выводе компилятора/
нормальный способ. Редуцируешь пример до просто и понятного
При ловле runtime ошибок редуцируется runtime пример, а тут редуцируется пример для компиляции
ну это тоже понятно. ладно, в общем, наверное лучше читать доки к компиляторам, т.к. это возможности скорее их будут (типа дебаг вывода типов и т.п.). просто интересно было вскользь узнать, есть ли что подобное.
в настоящий момент доступный дебаг — только редукция примера до минимального