PK
Я так понял, что например static_cast<T*>(this)->implementation(); вызывает метод наследника
блин, не трогай this с кастом, пожалуйста :) глаза кровоточат
Size: a a a
2020 March 03
AN
блин, не трогай this с кастом, пожалуйста :) глаза кровоточат
А шо в этом такого?
IZ
блин, не трогай this с кастом, пожалуйста :) глаза кровоточат
Согласен с предыдушим оратором...
PK
да много чего: с множественным наследованием можно сегфолт поймать, если бездумно пользоваться, или когда this конст_кастят, чтобы поле изменить -- это поле надо mutable делать... и в целом это выглядит дико
AN
Множественное наследование вообще опасная штука)
AN
А вот const_cast для изменения это явный выстрел себе в ногу и чисто UB
PK
у тебя просто очень свободный пример, можно много чего домыслить, вот у меня и флэшбеки пошли :)
IZ
да много чего: с множественным наследованием можно сегфолт поймать, если бездумно пользоваться, или когда this конст_кастят, чтобы поле изменить -- это поле надо mutable делать... и в целом это выглядит дико
static_cast же, компиль не будет делать то, что нельзя.
IZ
да много чего: с множественным наследованием можно сегфолт поймать, если бездумно пользоваться, или когда this конст_кастят, чтобы поле изменить -- это поле надо mutable делать... и в целом это выглядит дико
Павел, IMHO ты неправ...
IZ
Множественное наследование вообще опасная штука)
С чего она опасная?
IZ
Множественное наследование вообще опасная штука)
Не надо нам тут Java проповедовать...
BH
да много чего: с множественным наследованием можно сегфолт поймать, если бездумно пользоваться, или когда this конст_кастят, чтобы поле изменить -- это поле надо mutable делать... и в целом это выглядит дико
Прибежал поглазеть, где ты не прав, гггг
I
С чего она опасная?
Я вот тоже согласен, что тут пролетает много непроф. тпрминов и определений!
PK
static_cast же, компиль не будет делать то, что нельзя.
не могу пример найти, про который думал :( понятно, что если аккуратно пользоваться, ничего не взорвется, речь про подход "да закастим и норм"
PK
Прибежал поглазеть, где ты не прав, гггг
да много где о__О что тут такого?
BH
да много где о__О что тут такого?
ничего же
S
Господа, никто не доводил до ума вот этот проект?
https://github.com/danielsuo/cuSIFT
У меня есть багфиксы к нему по части обращения с памятью, но результат расчёта для двумерного случая всегда нулевой.
https://github.com/danielsuo/cuSIFT
У меня есть багфиксы к нему по части обращения с памятью, но результат расчёта для двумерного случая всегда нулевой.
A
Господа, никто не доводил до ума вот этот проект?
https://github.com/danielsuo/cuSIFT
У меня есть багфиксы к нему по части обращения с памятью, но результат расчёта для двумерного случая всегда нулевой.
https://github.com/danielsuo/cuSIFT
У меня есть багфиксы к нему по части обращения с памятью, но результат расчёта для двумерного случая всегда нулевой.
Есть какие-то преимущества над opencv реализацией?
S
Предполагалось, что будет работать быстрее (нет), предполагалось, что если у тебя данные уже на видеокарте, то вызов функции estimateRigidTransform этой реализации обгонит cudaMemcpy * 2 + cv::estimateAffineTransform2D (нет). Но если уж я довёл это до состояния "не падает", то хотелось бы довести до правильной работы собственно численного метода. Пускай, на Ryzen 9 это и быстрее, чем на 2080Ti.
A
Предполагалось, что будет работать быстрее (нет), предполагалось, что если у тебя данные уже на видеокарте, то вызов функции estimateRigidTransform этой реализации обгонит cudaMemcpy * 2 + cv::estimateAffineTransform2D (нет). Но если уж я довёл это до состояния "не падает", то хотелось бы довести до правильной работы собственно численного метода. Пускай, на Ryzen 9 это и быстрее, чем на 2080Ti.
Я ошибся, кстати, похоже в opencv на GPU только SURF, но не SIFT.