Раздвоение личности std::string под minGW (сборка openCV)

Leptonica вообще через задницу написана! Там элементарная операция поиска 4- и 8-связных областей так забыдлокожена, что раз в 10 больше тупит самой элементарной реализации!

Я ее когда-то для морфологических операций использовал, но потом как-то раз, сидя 10 часов в аэропорту (когда надолго задержали рейс), все нужные мне функции написал. Сверил быстродействие и понял, что лептоника — говно!

Стандарты видимо разные...

Ты свой проект с >=11 стандартом собираешь? Ежели так, то opencv собирается со стандартом по умолчанию для компилятора, т.е. это скорее всего 03.

Яж говорю, там нет ничег, кроме UR

Да мне пофиг на оптимизации. Если она осилит задачу - я могу хоть на ночь считать оставить. Ещё раз говорю - мне нужно проверить идею, для этого годится что угодно. Хоть китаец, который вручную будет попиксельно обрабатывать. Китаец даже лучше справится :)

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

А чего же тогда бинарники кутишных семплов под mingw не пускаются с дебажными версиями либ?

Потому что релизные и дебажные dll в Qt называются по-разному, у дежбажных есть суффикс «d». Если собрать дебажную dll с правильным именем, или линковать дебажную сборку с релизной dll, проблем быть не должно, так как нет раздельных «MD» и «MDd»

Угу, а если переименовать - почему не грузятся?

Ты уже третью страницу говоришь, что там ничего нет, и что то похожее где то нагуглил. Лог скинь...

Тогда тебе octave за глаза хватит.

Да, это я погорячился :)

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

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

несколько лет назад мне была интересна возможность использования GPU в вычислениях, чтобы не простаивал зря. например, через OpenCL. но если они хотят для этого проприетарщину втаскивать, то я против. нафиг мне GPU с проприетарщиной? задача сразу теряет смысл. поэтому я это дело забросила.

Я уже дохрена всего нагуглил, толку только.. Мне гиморно логи тащить, сборка на другой машине без сети. Ну ок, пожалуйста:

mingw32-g++.exe -LD:\optical\cv\lib -LD:\optical\cv\bin -o bin\Debug\test1.exe obj\Debug\main.o -m32 -demangle -m32 -lopencv_imgproc340.dll -lopencv_core340.dll -lopencv_highgui340.dll -lopencv_imgcodecs340.dll
obj\Debug\main.o: In function `main':
D:/optical/cv-test/test1/main.cpp:27: undefined reference to `cv::imread(std::string const&, int)'
D:/optical/cv-test/test1/main.cpp:30: undefined reference to `cv::namedWindow(std::string const&, int)'
D:/optical/cv-test/test1/main.cpp:31: undefined reference to `cv::imshow(std::string const&, cv::_InputArray const&)'
collect2.exe: error: ld returned 1 exit status

Такое сообщение с кривообъявленной ф()

D:\optical\cv-test\test1\main.cpp:15:35: error: 'const' qualifiers cannot be applied to 'cv::String& {aka std::basic_string<char>&}'

Вообще я ещё нагуглил, что basic_string это шаблон, на выходе которого может быть как вариант и string (если я правильно понял) а так же wchar, char16 or char32 string Но если так - почему он тут его подставил в чистом виде?

использования GPU в вычислениях, чтобы не простаивал зря. например, через OpenCL. но если они хотят для этого проприетарщину втаскивать, то я против. нафиг мне GPU с проприетарщиной?

Как писал выше - кое-какие вычисления вполне можно на шейдерах делать. В OpenGL например. Правда остаются проприетарные драйвера, куда же без них.

вот именно проприетарщина и не даёт их использовать. я читала, что на открытых AMD-шных дровах OpenCL вроде как наладили. но там ограниченное количество поддерживаемых карт и они довольно слабые. просто не будет профита от таких GPU. а невидия не хочет открывать спецификации. у меня на ноуте она отключена, потому что nouveau данную модель не поддерживает, а проприетарщину я не поставлю. сижу на встроенной карте, мне хватает за глаза.

Наверное там есть аналог soname, записанный внутри dll

Кстати с msvc тоже можно линковать релизные dll с дебажными сборками. А вот все объектники и статические либы должны быть собраны с одним рантаймом, либо MD либо MDd

A std::string is an instantiation of the std::basic_string template with a type of char

Что это даёт и почему разница таки есть - по прежнему непонятно

кое-какие вычисления вполне можно на шейдерах делать. В OpenGL например

Любые шейдеры это и есть вычисления на GPU, что в программе напишешь, то она считать и будет. Но все типы кроме compute shader являются частью графического пайплайна, в котором не все стадии можно программировать, а compute shader просто запускается и считает

London is the capital of Great Britain

Ты ошибки, ошибки показывай

Ты ошибки, ошибки показывай

>>???<<<

Любые шейдеры это и есть вычисления на GPU, что в программе напишешь, то она считать и будет.

Это как-то расходится с моими словами? Просто вариант обойтись без openCL. Без драйверов, увы, не обойтись.

Стадии не нужно программироватью На шейдерах втупую вполне можно считать на фрагментных. Одна/несколько текстур на входе, одна/несколько текстур на выходе. Некоторые вещи вполне неплохо считает. Правда иногда требуется алгоритм немного вывернуть, чтобы адаптировать под такой формат.

А ты без проприетарщины на GPU ничего и не сделаешь, потому что кроме CUDA нормальных средств нет. А OpenCL наркоманы какие-то писали. Один и тот же код на CUDA и OpenCL по размеру в несколько раз отличается, потому что на CUDA раз-два и готово, а на OpenCL гемор сплошной.

Это как некоторые наркоманы мне тут советовали в OpenGL для элементарных вещей вместо GLUT использовать шейдеры. Упоротые товарищи...

Эмм... А вместо чего в глют можно шейдеры? Glut - это обёртка над окошками (кривая довольно). Ну простые фигуры и текст выводить ещё умеет. Собсно больше там ничего нет.

Дык, мне opengl нужен лишь для того, чтобы картинку показать (статика или видео), крестики там нарисовать, да график какой. Тут шейдеры не нужны. В дальнейшем, возможно, придется еще GUI делать — кнопочки всякие добавить...

Тогда да, глюта достаточно. Но рекомендую glfw. Те же яйца, только в профиль. Но сильно лучше. Перешел на него когда глют окончательно задолбал и вполне доволен. С ним отлично стыкуется imgui - кнопочки в всякое прочее.

Пока что я сторонюсь GUI как сифилиса. Но если прижмет, придется заразиться по-полной...

imgui крайне простой. он только отрисовывает его. Ну в общем моё дело предложить...

Ну так я изначально про разный рантайм и говорил. Т.е. можно иметь дебажную сборку с релизным рантаймом по идее, и линковать её с релизной либой. Но смысл такой дебажной сборки?

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

Как то у тебя линкер перестарался с демэнглингом :)

Пока у меня что-то нет больше идей в чём может быть дело.

Попробуй, сделать таки хеллоуворлд на cmake + findopencv.

Ещё - попробуй полные абсолютные пути до либ прописать, хотя это врят ли поможет...

А ты opencv дебажную пробовал собирать?

cmake -DCMAKE_BUILD_TYPE=Debug <other options>

Как то у тебя линкер перестарался с демэнглингом :)

В смысле? На самом деле этот ключ (я писал уже) ни на что не влияет. Просто удалить его забыл.

Пути точно не помогут. Проблема не во время сборки. Проблема ДО сборки. Пока компилятор не будет генерить одинаковые сигнатуры - хрен оно соберётся.

Похоже, что std::string по разному разворачивается, хотя не могу понять как и почему.

А ты opencv дебажную пробовал собирать?

Могу попробовать, но что это даст?

Появилась на первый взгляд тупая мысль, но, попробуй всё же так:

mingw32-g++.exe -LD:\optical\cv\lib -LD:\optical\cv\bin -o bin\Debug\test1.exe obj\Debug\main.o -m32 -demangle -m32 -( -lopencv_imgproc340.dll -lopencv_core340.dll -lopencv_highgui340.dll -lopencv_imgcodecs340.dll -)

или так:

mingw32-g++.exe -LD:\optical\cv\lib -LD:\optical\cv\bin -o bin\Debug\test1.exe obj\Debug\main.o -m32 -demangle -m32 -\( -lopencv_imgproc340.dll -lopencv_core340.dll -lopencv_highgui340.dll -lopencv_imgcodecs340.dll -\)

А в чём смысл и в чём разница между ними?

А как заставить make пересобрать всё, а не перелинковать старое?

А с чего ты вообще взял, что cv::String == std::string?

Очень похоже на то, что у них есть своя реализация, совместимая с std::string, и при каких то условиях возможно используется std::string вместо их реализации.

Вот неплохой сайтец: https://demangler.com/

Ты сначала попробуй, а смысл можешь в man почитать, если поможет - то расскажу в двух словах об чём речь.

В общем, твоя задача, для начала разобраться, почему в твоём коде используется std::string а не этот вариант, который исопльзуется при сборке либы.

А с чего ты вообще взял, что cv::String == std::string?

Так у меня же его хедеры в проекте.

Блин, Действительно внутри есть другая реализация. А как он их тогда вообще сможет совместить, если это разные классы???

Не знаю, какой версии у тебя хидеры в проекте, но в актуальной версии нет тайпдефа ни одного который обьявлял бы std::string как cv::String

А если ты использовал какие то другие хидеры, а не те, которые поставляются с либой, то больше никогда так не делай...

1. Похоже я в своих мучениях по сборке в 3.4 засунул хедеры от 2.4. 2. В хедерах от 3.4 (публичных, как я понял, которые в include) String вообще нет. Ну хоть что-то понятно стало, спасибо.

А вот нихрена. Хедеры я брал из того каталога, который cmake сделал.

Или нет. make install копирует из сырцов другие, они не полные. Сам install падает т.к. ему тоже одного хедера не хватает. Почему при сборке всего хватало - хз. Похоже он должен догенерить часть хедеров.

ДА! Хедеры вручную пришлось собирать, install упорно падал. Но всё собралось.

на CUDA раз-два и готово, а на OpenCL гемор сплошной.

ну так если на проце общего назначения делать то, к чему он по дизайну не приспособлен, то понятно, что будет медленно.

без проприетарщины в GPU можно кое-что делать. радеоновский драйвер OpenCL поддерживает, хотя и частично. но таких карт немного и они слабые. так что я отказалась от этой идеи. других готовых решений для параллельных вычислений я не знаю. у меня есть всякие тестовые платы с FPGA. можно их приспособить. но это не типовое решение будет.

Хз что у интела с дровами, но на встроенной интеловской видяхе шейдеры тоже вполне крутятся. И по скорости на подходящих задачах рвут ЦП в клочья.

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

Уже писал выше. CL для этого не обязателен. У моей видяхи вообще OpenGL 2.2 потолок, CL с такими не работает. Используется это немного через задницу. Просто через OpenGL рендеришь на экран квад нужного размера, В качестве вычислителя цепляешь ему фрагментный шейдар, а данные передаются через юниформ текстуры на входе и текстуры, в которые он рендерит на выходе.

Можно на shadertoy.com глянуть примеры всяческих симуляций, вроде Навье-Стокса и т.д. которые хорошо на сетку ложатся.

кхе-кхе... это и взаправду малость через одно место. придумали, как натянуть проприетарщиков :) но это всё равно не управление шейдерами, а только частное решение. хотя соглашусь, что тоже рабочий вариант, если других решений нет.