нужна помощь по qt

не тот чатик

а когда в заголовочном файле объявляю QStringList* strlist11; в исходнике пишу : strlist11 = new QStringList();

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

а когда в заголовочном файле объявляю QStringList* strlist11; в исходнике пишу : strlist11 = new QStringList();

потомучто ты указатель сделал

@supapro

то такое добавление уже не работает strlist11<<"clovo";

(*strlist11)«"clovo";

вопрос зачем там new

и указатель

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

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

и хз как тут быть

короче хз о чем спорить пока не релизнули

и хз как тут быть

что значит форматы разные?

причем шланг настолько "охуенен" что в режиме vc++ он не умеет кучу опций

пока релиза Стандарта нет, будет разброд

что значит форматы разные?

выхлоп от модулей, расширение модулей

вот как зарелизятся, разрабы будут вынуждены делать так, как в Стандарте

у шланга у модулей должно быть расширение .cppm

у студии , .ixx вроде б

я пока слабо представляю как должны ide и редакторы такое парсить

короче хз о чем спорить пока не релизнули

когда релизнут будет поздно спорить

там в основе ipr но у каждого своя модификация

когда релизнут будет поздно спорить

насколько я знаю еще не выбрали

там в основе ipr но у каждого своя модификация

https://github.com/GabrielDosReis/ipr

я не понимаю что вы предлагаете например?

что не выбрали? есть только одно TS

я не понимаю что вы предлагаете например?

руби?

я про Анатолия

что не выбрали? есть только одно TS

его тоже не выбрали

что не выбрали? есть только одно TS

было два предложения же, щас второе допиливают

первое это от шланга модули, второе это от майкрософт которое в TS

было два предложения же, щас второе допиливают

врёшь. было одно предложение

в где почитать про второе? я видел только n4720

в где почитать про второе? я видел только n4720

а нигде. второго не было 😊

были реализации

врёшь. было одно предложение

ну то что шланговцы может не дотянули до подачи пропозала их проблемы

реализации две разные, а вот предложение только одно

ну то что шланговцы может не дотянули до подачи пропозала их проблемы

факт остаётся фактом - пропозал был только один

но на момент подачи, была реализация от шланга

в где почитать про второе? я видел только n4720

-modules -modules-ts сам ищи

мне лень

шланг пилил "модули" для obj-c

потом они допилили и для С и С++

шланг пилил "модули" для obj-c

нет

https://clang.llvm.org/docs/Modules.htm

но на момент подачи, была реализация от шланга

да плевать на реализацию. они реализовали что-то. ну окей, молодцы, чо

тут многое напоминает обжектив с?

теперь это выкинут и напишут заново

тут многое напоминает обжектив с?

http://releases.llvm.org/5.0.0/tools/clang/docs/Modules.html#objective-c-import-declaration > At present, there is no C or C++ syntax for import declarations я когда это читал, запомнил только эту фразу, и у меня сложилось впечатление что они запилили модули только для objc

Можно, -I

изначально проблема была "отучить либкланг искать #include <string> в /usr/include и вместо этого искать в /my/dir/include" проблема частично решилась через -nostdinc++ -isystem /my/dir/include, но builtin headers кланга всёравно лезут в /usr/include

изначально проблема была "отучить либкланг искать #include <string> в /usr/include и вместо этого искать в /my/dir/include" проблема частично решилась через -nostdinc++ -isystem /my/dir/include, но builtin headers кланга всёравно лезут в /usr/include

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

да *чует подвох*

Берешь в одну руку пустую директорию и разворачиваешь там окружение под нужную архитектуру из какого-нибудь дистрибутива. В другую руку берешь Qemu и включаешь binfmt, чтобы ядро научилось запускать бинарики под другую архитектуру. Делаешь chroot внутрь и получаешь как-бы контейнер но с системой под другую архитектуру, где дальше сборка будет проходить "нативно", без костылей.

Вот такой есть вариант, но это немного не то, как ты решаешь

А какие нужны опции - я не знаю

ммм, что именно входит в "окружение под нужную архитектуру"?

просто файлы ОС, обычно под ARM раздают какие-нибудь образы или архивы с корневой файловой системой. там будет стандартный набор /bin /usr /etc вот это всё

http://download.opensuse.org/ports/armv7hl/factory/images/openSUSE-Tumbleweed-ARM-JeOS.armv7-rootfs.armv7l-2018.03.18-Build2.1.tar.xz Типа этого, но какой-нибудь дебиан или убунту возьми например

Потом доставишь туда нужные пакеты

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

да

у меня прокатывает

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

изображая, что ты запускаешься на целевой системе

решение, согласен, но очень уж закоулками спасибо, будет как fallback если ничего лучше не найду

вот как зарелизятся, разрабы будут вынуждены делать так, как в Стандарте

Увы, но стандарт не описывает формат хранения собранных модулей

Увы, но стандарт не описывает формат хранения собранных модулей

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

Там создатель модулей пытается продумать общий формат, но идёт туго

и скорее всего по старым-добрым традициям у нас будет 2-3 разных формата

и скорее всего по старым-добрым традициям у нас будет 2-3 разных формата

14-15

изначально проблема была "отучить либкланг искать #include <string> в /usr/include и вместо этого искать в /my/dir/include" проблема частично решилась через -nostdinc++ -isystem /my/dir/include, но builtin headers кланга всёравно лезут в /usr/include

-nostdinc -nostdinc++ так не будет работать? https://clang.llvm.org/docs/ClangCommandLineReference.html#include-path-management

Там создатель модулей пытается продумать общий формат, но идёт туго

это меня немножко печалит

изначально проблема была "отучить либкланг искать #include <string> в /usr/include и вместо этого искать в /my/dir/include" проблема частично решилась через -nostdinc++ -isystem /my/dir/include, но builtin headers кланга всёравно лезут в /usr/include

да чрутнись

увы, но нет ... arm-hisiv300-linux/bin/marker -s src/grabcommon/rtp_assemblers.cpp In file included from src/grabcommon/rtp_assemblers.cpp:1: ... In file included from /arm-hisiv300-linux/target/usr/include/limits.h:125: In file included from /arm-hisiv300-linux/bin/../lib/clang/5.0.1/include/limits.h:37: >>> /usr/include/limits.h:145:5 <<< error: function-like macro '__GLIBC_USE' is not defined #if __GLIBC_USE (IEC_60559_BFP_EXT) пойду схожу в слаку, но видимо придётся искать, как переобучить clang::tooling::RefactoringTool или кого-то из его братии

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

-nostdinc -nostdinc++ так не будет работать? https://clang.llvm.org/docs/ClangCommandLineReference.html#include-path-management

.

да чрутнись

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

или забинди на время в /usr/include

...гм

на cppref уже подьехал обновлённый раздел со временем: http://en.cppreference.com/w/cpp/chrono ссылки пока что не заполнены, но хоть с интерфейсом ознакомьтесь