В чем проблема правильно слинковать?

Все вроде правильно делаю, и собирается, но при переносе на другую машину требует opencv dllки

В теории такое делают ?

Да. Какая платформа?

64, вин10

Переношу на 64 вин7

Должно быть, что-то недонастроил в сборке

Ребзяки, у меня есть такая структура: struct Foo { Foo* next; } вопрос такой: Если указатель на Foo поменять на умный, то возможна ли тут ситуация, при которой это будет weak_ptr? Известно, что в эту структуру в поле next вставляется всегда новый уникальный объект.

Переношу на 64 вин7

Тогда там вообще нет смысла возиться со статической сборкой. Все библиотеки в . - и ок

Ребзяки, у меня есть такая структура: struct Foo { Foo* next; } вопрос такой: Если указатель на Foo поменять на умный, то возможна ли тут ситуация, при которой это будет weak_ptr? Известно, что в эту структуру в поле next вставляется всегда новый уникальный объект.

зависит от того, что ты хочешь

Ребзяки, у меня есть такая структура: struct Foo { Foo* next; } вопрос такой: Если указатель на Foo поменять на умный, то возможна ли тут ситуация, при которой это будет weak_ptr? Известно, что в эту структуру в поле next вставляется всегда новый уникальный объект.

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

Я описал условия, которые мне нужны. Хочу понять возможно ли ситуация, когда возникнет потребность в weak_ptr

Переношу на 64 вин7

Утилита depends поможет собрать тебе все нужные тебе .dll. Тебе нужно использовать 64битную версию

Я описал условия, которые мне нужны. Хочу понять возможно ли ситуация, когда возникнет потребность в weak_ptr

Да, если у тебя будут циклические ссылки в данных

Если да, то как воспроизвести эту ситуацию, при условии что в next всегда уникальный указатель укладывается.

Да, если у тебя будут циклические ссылки в данных

Как эту ситуацию получить при условиях выше ?

FooPtr a; FooPtr b; a->next = b; b->next = a; Циклическая ссылка в данных. (поправил)

Я описал условия, которые мне нужны. Хочу понять возможно ли ситуация, когда возникнет потребность в weak_ptr

по твоему описанию std::unique_ptr

Все вроде правильно делаю, и собирается, но при переносе на другую машину требует opencv dllки

у тебя скорее всего не получилась статическая сборка, а либы это импорт либы , которые содержат ссылки на длл

FooPtr a; FooPtr b; a->next = b; b->next = a; Циклическая ссылка в данных. (поправил)

Я для кого пишу,что в некст будет укладываться уникальный указатель?

Я для кого пишу,что в некст будет укладываться уникальный указатель?

Все вы так сначала говорите.

Как эту ситуацию получить при условиях выше ?

Сделай чтобы node ссылалась сама на себя, например

Должно быть, что-то недонастроил в сборке

Только в "Создании кода->Библиотека времени выполнения" поменял на MT. И подключил статические либы opencv. Этого недостаточно ?

Если да, то как воспроизвести эту ситуацию, при условии что в next всегда уникальный указатель укладывается.

Что такое уникальной указатель не понятно

Сделай чтобы node ссылалась сама на себя, например

Такой ситуации тоже не возможно. Еще раз, в next укладывается всегда смарт созданный через new, make etc.

Я не шарю конкретно в VS, я отвечал из общих знаний. Странно, что гугл не помогает.

Только в "Создании кода->Библиотека времени выполнения" поменял на MT. И подключил статические либы opencv. Этого недостаточно ?

нет

Только в "Создании кода->Библиотека времени выполнения" поменял на MT. И подключил статические либы opencv. Этого недостаточно ?

Нет, это ортогональные вещи. Возможно, надо еще флаги препроцессора менять. В общем, гуглить, как правильно.

Такой ситуации тоже не возможно. Еще раз, в next укладывается всегда смарт созданный через new, make etc.

если нет shared_ptr, то и weak_ptr тебе не понадобится

По моему он говорил что его устраивает в качестве зависимости опенсв в текущей папочке

Я для кого пишу,что в некст будет укладываться уникальный указатель?

Концепции уникального указателя не существует. Ты либо будешь проверять эту структуру на зацикленности, либо нет. Если второе, и будешь использовать shared_ptr, то в next надо класть weak

Концепции уникального указателя не существует. Ты либо будешь проверять эту структуру на зацикленности, либо нет. Если второе, и будешь использовать shared_ptr, то в next надо класть weak

существует, unique_ptr

По моему он говорил что его устраивает в качестве зависимости опенсв в текущей папочке

Это проще ?

Такой ситуации тоже не возможно. Еще раз, в next укладывается всегда смарт созданный через new, make etc.

У меня возможно то,что указатель этот будет уводиться наружу без возможности изменения. Но это под шаредрптр идет.А что на счет вика?

Так что ему надо динамическую либу с runpath или что там в винде

Такой ситуации тоже не возможно. Еще раз, в next укладывается всегда смарт созданный через new, make etc.

Все указатели, которые shared , обязательно созданны через new...

Это проще ?

Ещё раз.... НЕ ИСПОЛЬЗУЙ СТАТИЧЕСКУЮ СБОРКУ. Клади все .dll в каталог, откуда запускается приложение или в PATH.

Так что ему надо динамическую либу с runpath или что там в винде

PATH

Пробую с локальными либами

@kvoistinov ты можешь конкретизировать свои требования структуре к данных, которая будет хранить указатель на next? пока по твоим описаниям все вписывается в unique_ptr. если на один и тот же объект может быть ссылка с различных узлов, то shared_ptr.

Все указатели, которые shared , обязательно созданны через new...

Достоверно известно, что поле next не будет указывать на какой-либо созданный объект списка или самого себя, вот

Достоверно известно, что поле next не будет указывать на какой-либо созданный объект списка или самого себя, вот

Тогда нет причин использовать weak

Спасибо, локальное подкладывание dll работает

Но я бы использовал. Стоимость ноль.

@kvoistinov ты можешь конкретизировать свои требования структуре к данных, которая будет хранить указатель на next? пока по твоим описаниям все вписывается в unique_ptr. если на один и тот же объект может быть ссылка с различных узлов, то shared_ptr.

ок class foo { Foo* next; Callback func; } заметим, что поля приватные. Доступ через френд класс. Когда мы делаем добавление в список, вызывается примерно такой код: Wrapper add( Foo ...abc) { next = make_shared(abc); return Wrapper(next); } В next всегда лежит объект, который еще не укладывался в список, работа ведется через Wrapper. Wrapper не дает пользователю на прямую менять данные ( в частности наш shared_ptr). Обратите внимание на то, что внутри содержится callback. И возникает вопрос - какой умный указатель выбрать для Foo, shsred или weak

unique

ок class foo { Foo* next; Callback func; } заметим, что поля приватные. Доступ через френд класс. Когда мы делаем добавление в список, вызывается примерно такой код: Wrapper add( Foo ...abc) { next = make_shared(abc); return Wrapper(next); } В next всегда лежит объект, который еще не укладывался в список, работа ведется через Wrapper. Wrapper не дает пользователю на прямую менять данные ( в частности наш shared_ptr). Обратите внимание на то, что внутри содержится callback. И возникает вопрос - какой умный указатель выбрать для Foo, shsred или weak

почему не unique_ptr?

почему не unique_ptr?

Wrapper может где-то храниться снаружи, если же тут использовать unique_ptr , то указатель внутри Wrapper точно умрет, здесь идет разделение данных. Одни данные хранятся внутри списка, другие внутри Wrapper.

Wrapper может где-то храниться снаружи, если же тут использовать unique_ptr , то указатель внутри Wrapper точно умрет, здесь идет разделение данных. Одни данные хранятся внутри списка, другие внутри Wrapper.

ты не перемудрил?

Работа идет и со списком( т.е. он должен быть целостным) и снаружи через Wrapper.

ок class foo { Foo* next; Callback func; } заметим, что поля приватные. Доступ через френд класс. Когда мы делаем добавление в список, вызывается примерно такой код: Wrapper add( Foo ...abc) { next = make_shared(abc); return Wrapper(next); } В next всегда лежит объект, который еще не укладывался в список, работа ведется через Wrapper. Wrapper не дает пользователю на прямую менять данные ( в частности наш shared_ptr). Обратите внимание на то, что внутри содержится callback. И возникает вопрос - какой умный указатель выбрать для Foo, shsred или weak

Разница между shared_ptr и weak_ptr во владении. Кто является хозяином объекта, на который ссылается next? Когда он должен удаляться? Напомню, если все shared_ptr уничтожатся, объект тоже уничтожится, не смотря на то, что на него ссылаются weak_ptr. Получается, что если цель - список из которого можно выдавать "наружу" указатели на узлы, при этом не переживая, что может быть доступ к уже удалённому объекту, то внутри списка должны быть shared_ptr, а отдавать наружу нужно weak_ptr.

ты не перемудрил?

Нет, не перемудрил. Вопрос остается тем же shared или weak. Единственное нет в сторону weak, это не могу понять ситуации, когда могут возникнут циклические зависимости в ДАННОЙ задаче

Разница между shared_ptr и weak_ptr во владении. Кто является хозяином объекта, на который ссылается next? Когда он должен удаляться? Напомню, если все shared_ptr уничтожатся, объект тоже уничтожится, не смотря на то, что на него ссылаются weak_ptr. Получается, что если цель - список из которого можно выдавать "наружу" указатели на узлы, при этом не переживая, что может быть доступ к уже удалённому объекту, то внутри списка должны быть shared_ptr, а отдавать наружу нужно weak_ptr.

Вот это ближе к задаче.

Разница между shared_ptr и weak_ptr во владении. Кто является хозяином объекта, на который ссылается next? Когда он должен удаляться? Напомню, если все shared_ptr уничтожатся, объект тоже уничтожится, не смотря на то, что на него ссылаются weak_ptr. Получается, что если цель - список из которого можно выдавать "наружу" указатели на узлы, при этом не переживая, что может быть доступ к уже удалённому объекту, то внутри списка должны быть shared_ptr, а отдавать наружу нужно weak_ptr.

Если я отдаю наружу shared_ptr, то я не совсем понимаю почему это не будет работать

Нет, не перемудрил. Вопрос остается тем же shared или weak. Единственное нет в сторону weak, это не могу понять ситуации, когда могут возникнут циклические зависимости в ДАННОЙ задаче

weak_ptr не удерживают объект от удаления. Построить на них список, который хранит элементы (т.е. никакие shared_ptr на него не ссылаются) не получится (они сразу же будут удаляться).

Если я отдаю наружу shared_ptr, то я не совсем понимаю почему это не будет работать

Это будет уже не список содержащий элементы, ссылки на которые отдаются наружу, а список слабых ссылок на узлы, лежащие снаружи. weak_ptr становятся пустыми, когда shared_ptr хранящие объект удаляются. Т.е. если на какой-то узел все отданные shared_ptr удалятся, кусок списка идущий за ним станет не доступен.

То есть во всех контейнерах это нормально, а тут - ОПАСНО!!

но интервальный конструктор контейнеров копирует все элементы, разве нет? у листа, помнится, копировал

@antoshkka Антон, а почему не завезли с самого начала интервальный конструктор в std::basic_string_view?

Причины мне не ведомы. Могу только догадываться, что требуется continious iterator, а вот проверить что итератор именно такого типа в данный момент не возможно

Причины мне не ведомы. Могу только догадываться, что требуется continious iterator, а вот проверить что итератор именно такого типа в данный момент не возможно

Спасибо, Антоша! @smertig ^

господа, возможно странный вопрос. А чем сейчас модно делать fft? dlib, fftw или руками по старинке?

Модно делать блокчейн и машинное обучение А если нужно что-то, что работает - то fft самое то!

Модно делать блокчейн и машинное обучение А если нужно что-то, что работает - то fft самое то!

fftw то бишь?

Кхм.. а что за fft?

преобразование фурье

fftw собственно не подводит, и в openmp пихается, но вдруг есть что-то чего мы с гуглом не знаем

Кхм.. а что за fft?

Быстрое преобразование Фурье

господа, возможно странный вопрос. А чем сейчас модно делать fft? dlib, fftw или руками по старинке?

Да его руками наклепать минут за 20 можно

Да его руками наклепать минут за 20 можно

да

я собственно оттого и спрашиваю, вдруг есть что модное

я собственно оттого и спрашиваю, вдруг есть что модное

Это странный вопрос)

Это странный вопрос)

как я и обозначил в заголовке вопроса

как я и обозначил в заголовке вопроса

В таком случае вечное и модное FFTW

В таком случае вечное и модное FFTW

ок, спасибо ?

Причины мне не ведомы. Могу только догадываться, что требуется continious iterator, а вот проверить что итератор именно такого типа в данный момент не возможно

спасибо

@antoshkka Вопросик по boost.dll. Оно с c++11 совместимо?

@antoshkka Вопросик по boost.dll. Оно с c++11 совместимо?

А что за boost.dll, они же все раздельно собираются...

А что за boost.dll, они же все раздельно собираются...

библиотека такая в бусте)

которую Антон и писал

Ладно...

бедный Антон.. и по библиотекам отвечать, и за стандарт, и за пропозалы..

А что за boost.dll, они же все раздельно собираются...

Библиотека подгрузки .dll/.so. Причём тут раздельная сборка? У меня есть dll/so, которую нужно грузить в runtime. Вопрос, собственно, в минимально поддерживаемом стандарте.

https://onlinegdb.com/BkDVTLgKX

?

бедный Антон.. и по библиотекам отвечать, и за стандарт, и за пропозалы..

Антону респект!!!

бедный Антон.. и по библиотекам отвечать, и за стандарт, и за пропозалы..

И за книгу, тоже, наверное Большой популяризатор плюсов. Респект Антону.

Это странный вопрос)

ну речь про то как "всю жизнь юзали rapidjson, а потом пришёл нил ломанн и запилил modern json, и все 'ооо удобно стильно с++шно меньше строчек'"

ну речь про то как "всю жизнь юзали rapidjson, а потом пришёл нил ломанн и запилил modern json, и все 'ооо удобно стильно с++шно меньше строчек'"

и чо, также быстро?

не знаю, не сравнивал)

не знаю, не сравнивал)

https://github.com/miloyip/nativejson-benchmark UPD. Где-то в середине Nlohmann

Вопрос про компиляцию шланга как кросс компилятора куда лучше задать? Третий день на дебине пытаюсь собрать шланг как кросскомпилятор для arm-none-eabi и че то не выходит нормально, библиотеки не собираются. Курил доки на английском, шерстил инет, голова пухнет, а ясности и понимания не добавляется. Ткните на толковый мануал или зотя бы канал по теме

что, там же uintptr_t

Таки какое именно значение лежит по адресу, который хранится в x и p?