Доброго времени суток Подскажите, пожалуйста, если написать программу на Qt, должны ли быть установлены какие-то библиотеки в системе для выполнения этой программы? Или её свободно можно запускать на таргетных платформах (win64, например)?

@supapro

Доброго времени суток Подскажите, пожалуйста, если написать программу на Qt, должны ли быть установлены какие-то библиотеки в системе для выполнения этой программы? Или её свободно можно запускать на таргетных платформах (win64, например)?

нужно тягать с программой Qt5.dll и ему подобное, либо надеяться что оно есть где-то у пользователя в общедоступном месте

нужно тягать с программой Qt5.dll и ему подобное, либо надеяться что оно есть где-то у пользователя в общедоступном месте

ну или статически слинковаться ?

Если возможность поставлять dll-ки вместе с exe-шником. В таком случае, всё будет окей?

да

Так Илья Звягин писал.

Так приглашай обратно

Если возможность поставлять dll-ки вместе с exe-шником. В таком случае, всё будет окей?

должно быть ок

Спасибо

Всем

если у тебя там не собраны DLL с -march=native ?

Ну статически линковаться, думаю, не вариант. Зачем такой раздутый exe

если у тебя там не собраны DLL с -march=native ?

Да я билдить сам dll не собираюсь, положу собранные от разработчиков. Есть же такие?

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

https://alexpolt.github.io/type-loophole.html

https://alexpolt.github.io/type-loophole.html

спасибо

ну или статически слинковаться ?

всего-то придется GPL, а не LGPL соответствовать

всего-то придется GPL, а не LGPL соответствовать

да, конечно. Но это уже совсем другая история

точнее не так - придется открыть исходники, потому что LGPL только для динамической

смотрите какая задачка: есть пакетный менеджер; есть пакеты; много кто зависит от одного в самом низу с зависимостью вида >=1, этот пакет берёт и ставит на новую версию GPL, получается, что люди, скачавшие другие зависимые пакеты, имеют право всё дерево зависимостей использовать под GPL - их исходники

смотрите какая задачка: есть пакетный менеджер; есть пакеты; много кто зависит от одного в самом низу с зависимостью вида >=1, этот пакет берёт и ставит на новую версию GPL, получается, что люди, скачавшие другие зависимые пакеты, имеют право всё дерево зависимостей использовать под GPL - их исходники

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

? человек им и слинковал с гпл сурсами

пакетным менеджером?

ну линкером через него, подразумевается

есть разница какая-то?

большая

линкует линкер. именно в этот момент надо думать о лицензиях

пакетный менеджер - это уже поздно о них думать

ну линкером через него, подразумевается

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

какое нарушение? всё просто огплилось

(считаем, что лицензии совместимы)

(считаем, что лицензии совместимы)

а если нет?

тогда это описано и конкретная либа не того

примерная ситуация - дерево зависимостей mit/bsd/apache2/mpl2 и добавляем гпл

какое нарушение? всё просто огплилось

по GPL3 "гплится только она сама

ой ли?

не знаю, что тебе на это ответить )

ну почему тогда их не применяют широко, если опасности никакой

и мой код не огплится

гпл3 подразумевает динамическую линковку как основной способ использования. при этом в GPL3 сказано, что GPL3 вменяется только derived продуктам, т.е. тем, которые используют исходные тексты (не заголовочные файлы) исходного продукта

и мой код не огплится

если не можешь что-то победить - возглавь это. ожпээль свой сорс - пусть у остальных болит башка!

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

это LGPL

и еще ты обязан предоставить пользователям возможность слинковаться с новой версией

ладно, подумать есть над чем, оставляем тему на совесть читателя)

это LGPL

ну, перечитаю на досуге,

Вопрос на засыпку: У кого-нибудь есть код, позволяющий из указателя на member function получить указатель на обычную функцию (можно даже немножко с UB)? Что-то наподобие превращения int(foo::*)(char) => int(*)(foo*, char) P.S.: я точно знаю, что в gamedev есть умельцы которые умеют это делать

std::mem_fn?

Но там не то слегка

https://wandbox.org/permlink/l1emIP1ZmrsVnkao а в чём подвох?

Вопрос на засыпку: У кого-нибудь есть код, позволяющий из указателя на member function получить указатель на обычную функцию (можно даже немножко с UB)? Что-то наподобие превращения int(foo::*)(char) => int(*)(foo*, char) P.S.: я точно знаю, что в gamedev есть умельцы которые умеют это делать

А в чём профит?

Вопрос на засыпку: У кого-нибудь есть код, позволяющий из указателя на member function получить указатель на обычную функцию (можно даже немножко с UB)? Что-то наподобие превращения int(foo::*)(char) => int(*)(foo*, char) P.S.: я точно знаю, что в gamedev есть умельцы которые умеют это делать

Я вроде сишно кастовал такое

первый главное чтобы был this

Там запара при virtual void printx(int i)

Вопрос на засыпку: У кого-нибудь есть код, позволяющий из указателя на member function получить указатель на обычную функцию (можно даже немножко с UB)? Что-то наподобие превращения int(foo::*)(char) => int(*)(foo*, char) P.S.: я точно знаю, что в gamedev есть умельцы которые умеют это делать

Оно ведь сильно будет platform dependent

да (

я надеялся у кого-то есть хитрая функция с кучей #ifdef

Там запара при virtual void printx(int i)

а это что, можно как-то нормально разрулить? оО

я надеялся у кого-то есть хитрая функция с кучей #ifdef

Мне кажется лучше самому написать, могу дать заготовку для тривиального случая https://ideone.com/HdN7WL https://godbolt.org/z/orbSMT

а еще я слабо представляю как определить то, что функция виртуальная или нет если только какими-то эвристиками по адресам

я надеялся у кого-то есть хитрая функция с кучей #ifdef

https://github.com/IngwiePhoenix/AngelScript Вот тут глянь

Вопрос на засыпку: У кого-нибудь есть код, позволяющий из указателя на member function получить указатель на обычную функцию (можно даже немножко с UB)? Что-то наподобие превращения int(foo::*)(char) => int(*)(foo*, char) P.S.: я точно знаю, что в gamedev есть умельцы которые умеют это делать

а так нельзя? https://gcc.godbolt.org/z/1wWweA (GCC упал с ICE)

а так нельзя? https://gcc.godbolt.org/z/1wWweA (GCC упал с ICE)

Зачем operator+?

https://github.com/IngwiePhoenix/AngelScript Вот тут глянь

#ifdef GNU_STYLE_VIRTUAL_METHOD if( (size_t(ptr.ptr.f.func) & 1) ) internal->callConv = (internalCallConv)(thisCallConv + 2); #endif Тут прям срашная магия

Зачем operator+?

чтобы получить function pointer из lambda

а так нельзя? https://gcc.godbolt.org/z/1wWweA (GCC упал с ICE)

Круто, надо запомнить

#ifdef GNU_STYLE_VIRTUAL_METHOD if( (size_t(ptr.ptr.f.func) & 1) ) internal->callConv = (internalCallConv)(thisCallConv + 2); #endif Тут прям срашная магия

Да, вот она и нужна (

25 сентября стартует новый курс по С++ для продолжающих: https://otus.pw/Uolk/ Для тех, кто уже шарит в классических плюсах и хочет прокачаться в новых стандартах, лямбдах, паттернах, асинхронности и прочих продвинутых фишках. В свежем обновлении в курс включили и С++17. Ведёт Дмитрий Шебордаев — опытный преподаватель. Использует плюсы уже больше 20 лет, сейчас руководит отделом разработки технологий в Rambler&Co. Кстати, 11 сентября в 20:00 Дмитрий Шебордаев проведет практический вебинар на тему: «Cтранно рекурсивный шаблон». Регистрируйтесь и присоединяйтесь: https://otus.pw/AKRV/ #cpp #webinar #courses

Никто не в курсе, нету в планах сделать такой код корректным? for (auto &&x : f().g()) { //... }

Он вроде корректный же, разве нет?

Если f() возвращает временный объект, а g() возвращает ссылку на него или его часть, то время жизни результата f() не продлевается.

Если f() возвращает временный объект, а g() возвращает ссылку на него или его часть, то время жизни результата f() не продлевается.

сделали уже - http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0614r1.html

это не совсем то что хотелось бы. Хочется именно изкоробочное решение, чтобы пользователю не надо было задумываться, где писать f()

но кажется, что этому пока не суждено случиться

сделали уже - http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0614r1.html

Это немного не то. Есть некая ассиметричность. foreach(f().g(), [](auto &&x) {})Корректный код, а если развернуть в for, то он перестает быть корректным.

Это немного не то. Есть некая ассиметричность. foreach(f().g(), [](auto &&x) {})Корректный код, а если развернуть в for, то он перестает быть корректным.

В каком смысле? Он превращается в for (auto && g = f().g(); auto && x : g) {}

В каком смысле? Он превращается в for (auto && g = f().g(); auto && x : g) {}

И это не работает

И это не работает

Почему?

А работает for (auto tf = f(); auto &&x : tf.g())

А работает for (auto tf = f(); auto &&x : tf.g())

Да, был неправ. Ну в общем проблема решена :)

это не совсем то что хотелось бы. Хочется именно изкоробочное решение, чтобы пользователю не надо было задумываться, где писать f()

Почему кстати? Нельзя сказать что время жизни временных объектов в range expression это сам цикл?

А работает for (auto tf = f(); auto &&x : tf.g())

ну это правда c++20

Ну так себе решена. Если бы for заменялся на [&](auto &&arr) { for (auto &&x : arr) { // } } (f().g());То все продлевалось бы.

Почему кстати? Нельзя сказать что время жизни временных объектов в range expression это сам цикл?

Это очень необычно и такого нигде в других местах пока нет.

И наверняка это что-то кому-то сломает.

Ну так себе решена. Если бы for заменялся на [&](auto &&arr) { for (auto &&x : arr) { // } } (f().g());То все продлевалось бы.

Почему в последнем примере нет той же проблемы? All temporary objects are destroyed as the last step in evaluating the full-expression. Насколько я понимаю когда вычислится значение параметра объект который вернулся из f() умрет.

Хотя full-expression в этом случае это вызов лямбды похоже.

Почему в последнем примере нет той же проблемы? All temporary objects are destroyed as the last step in evaluating the full-expression. Насколько я понимаю когда вычислится значение параметра объект который вернулся из f() умрет.

Ну мы функцию вызываем. Вызов функции это expression. Все временные объекты живут пока жив expression.

Ну мы функцию вызываем. Вызов функции это expression. Все временные объекты живут пока жив expression.

Ну эта конструкция тогда как раз эквивалентна тому что я предложил.

@antoshkka ты говорил про возможное появление constexpr vector. А почему только vector? какие там проблемы с теми же строками?

И мапу. Мапу тоже хочу consexpr.

И мапу. Мапу тоже хочу consexpr.

просто все контейнеры ?