СРАЗУ ВОПРОС! Если по Qt, то в @qt_chat

че сразу туда, я например ембеддед в qt creator пишу

че сразу туда, я например ембеддед в qt creator пишу

+

Потому что я его никогда не использовал, считая бесполезной ерундой. Но тут коллеги программисты убеждают меня, что он няшка и удобный. и это путь боли. "автоматически" и "из коробки" - это я просто не знаю, кто такое мог сказать про кьют. У меня уже и мозг и пердак взорвался от простого действия - скомпилить свежесозданный пустой проект. Как можно с этим жить? Как можно жить, когда мануалов, даже на английском, нормальных нет? Как вообще так получается, что самые крутые разработчики в мире на С++, их нас больше чем любых других разработчиков (по крайней мере, долгое время было), но у нас нет нормального ide! Ведь у с++ разработчиков должен быть самый лучший софт для разработки, разве не так? а самый лучший, ну даже не знаю, даже дэлфи блин лучше в плане ide... Я кодю на плюсах в sublime text и компилю мейкфайлом в командной строке

> Я кодю на плюсах в sublime text и компилю мейкфайлом в командной строке всё нормально, ещё чуть-чуть и можно будет вводить животворящий vim

холивары про иде не сюда

холивары про иде не сюда

Извиняюсь

Потому что я его никогда не использовал, считая бесполезной ерундой. Но тут коллеги программисты убеждают меня, что он няшка и удобный. и это путь боли. "автоматически" и "из коробки" - это я просто не знаю, кто такое мог сказать про кьют. У меня уже и мозг и пердак взорвался от простого действия - скомпилить свежесозданный пустой проект. Как можно с этим жить? Как можно жить, когда мануалов, даже на английском, нормальных нет? Как вообще так получается, что самые крутые разработчики в мире на С++, их нас больше чем любых других разработчиков (по крайней мере, долгое время было), но у нас нет нормального ide! Ведь у с++ разработчиков должен быть самый лучший софт для разработки, разве не так? а самый лучший, ну даже не знаю, даже дэлфи блин лучше в плане ide... Я кодю на плюсах в sublime text и компилю мейкфайлом в командной строке

но там все ок, какие мануалы тебе нужны? открываешь cmake и вперед

> скомпилить свежесозданный пустой проект File - New file or Project - Plain C++ Application - Next - Build system: cmake - Next - Next - Finish - Build all - Hello World!

Потому что я его никогда не использовал, считая бесполезной ерундой. Но тут коллеги программисты убеждают меня, что он няшка и удобный. и это путь боли. "автоматически" и "из коробки" - это я просто не знаю, кто такое мог сказать про кьют. У меня уже и мозг и пердак взорвался от простого действия - скомпилить свежесозданный пустой проект. Как можно с этим жить? Как можно жить, когда мануалов, даже на английском, нормальных нет? Как вообще так получается, что самые крутые разработчики в мире на С++, их нас больше чем любых других разработчиков (по крайней мере, долгое время было), но у нас нет нормального ide! Ведь у с++ разработчиков должен быть самый лучший софт для разработки, разве не так? а самый лучший, ну даже не знаю, даже дэлфи блин лучше в плане ide... Я кодю на плюсах в sublime text и компилю мейкфайлом в командной строке

По моим оценкам, QtCreator -- третья или вторая по мощности IDE для C++, вторая из кроссплатформных. С учётом того, что она ещё и бесплатная, это хороший выбор. Creator немного как бы туповат по своим возможностям, и немного заточен на Qt, но есть возможность работать и с С++ общего плана. Зато работает достаточно стабильно и быстро.

> скомпилить свежесозданный пустой проект File - New file or Project - Plain C++ Application - Next - Build system: cmake - Next - Next - Finish - Build all - Hello World!

Вначале не было qmake, пришлось чё-то доставлять, потом не было компиляторов, выяснилось, внезапно, что mingw нужен, а потом (теперь) выясняется, что нет каких-то библиотек, видимо, с виндой что-то связанное... И вот я даже не знаю, где их брать

Потому что я его никогда не использовал, считая бесполезной ерундой. Но тут коллеги программисты убеждают меня, что он няшка и удобный. и это путь боли. "автоматически" и "из коробки" - это я просто не знаю, кто такое мог сказать про кьют. У меня уже и мозг и пердак взорвался от простого действия - скомпилить свежесозданный пустой проект. Как можно с этим жить? Как можно жить, когда мануалов, даже на английском, нормальных нет? Как вообще так получается, что самые крутые разработчики в мире на С++, их нас больше чем любых других разработчиков (по крайней мере, долгое время было), но у нас нет нормального ide! Ведь у с++ разработчиков должен быть самый лучший софт для разработки, разве не так? а самый лучший, ну даже не знаю, даже дэлфи блин лучше в плане ide... Я кодю на плюсах в sublime text и компилю мейкфайлом в командной строке

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

По моим оценкам, QtCreator -- третья или вторая по мощности IDE для C++, вторая из кроссплатформных. С учётом того, что она ещё и бесплатная, это хороший выбор. Creator немного как бы туповат по своим возможностям, и немного заточен на Qt, но есть возможность работать и с С++ общего плана. Зато работает достаточно стабильно и быстро.

ничем не заточен, кроме пары плагинов

которые отключаются

Вначале не было qmake, пришлось чё-то доставлять, потом не было компиляторов, выяснилось, внезапно, что mingw нужен, а потом (теперь) выясняется, что нет каких-то библиотек, видимо, с виндой что-то связанное... И вот я даже не знаю, где их брать

Creator поддерживает и CMake.

Вначале не было qmake, пришлось чё-то доставлять, потом не было компиляторов, выяснилось, внезапно, что mingw нужен, а потом (теперь) выясняется, что нет каких-то библиотек, видимо, с виндой что-то связанное... И вот я даже не знаю, где их брать

а, на винде да, всё хуже но всё равно жить можно

Вначале не было qmake, пришлось чё-то доставлять, потом не было компиляторов, выяснилось, внезапно, что mingw нужен, а потом (теперь) выясняется, что нет каких-то библиотек, видимо, с виндой что-то связанное... И вот я даже не знаю, где их брать

умеет и в мейк и смейк, тут уж такое

ничем не заточен, кроме пары плагинов

Я имел в виду, что там много функционала , заточенного на Qt, но его можно не использовать.

@MasterZiv ой все, давай уже не холиварить про ide

Я заткнулся.

у нас там холивары стынут :)

https://godbolt.org/z/AqM9EC VS взбесилась со своими __vectorcall

https://godbolt.org/z/AqM9EC VS взбесилась со своими __vectorcall

ну тестить на godbolt msvc такое себе :/

там самая первая версия 2017

но ведь он проверял на 2015 U3

так она и у меня локально не лучше - только помимо cdecl и vectorcall предлагает stdcall/thiscall

так она и у меня локально не лучше - только помимо cdecl и vectorcall предлагает stdcall/thiscall

а это странно, под х64 разницы то нет

кроме векторколла

х32

ну тогда держись

ах ты ж, картинку не дают залить. Короче проверил локально (вчера ничего не работало): 1) интеллисенс говорит "ай-ай-ай, тут 4 возможных каста" (тут должна быть картинка) 2) компилятор.. компилирует. что я делал вчера не так - хз

@antoshkka Воркшоп на Corehard'e будет почти такой же как и в прошлый раз?

Ага. +/- вещи которые я успел узнать/забыть за пол года

Круто. Мне в прошлый раз очень понравилось

Ребят, а можно ли как то сделать контейнер который будет хранить std::function с одной и той же сигнатурой входных параметров, но при этом с разным return type ?

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

У них же сигнатура таже, но возвращаемые значения разные. Я так понимаю, что так нельзя ?

нельзя, разве что они все будут обёрнуты какой-то промежуточный void wrapper(T...Args){ actual_func(Args...); }

thx, но печально, хотя и логично

thx, но печально, хотя и логично

Допустим, это можно было бы сделать... А как ты потом будешь их вызывать?

Ну а чо там вызывать, в конкретно моем случае - мне нужно просто передать туда параметры

а возвращаемое значение, не нужно. Оно, скорее для удобства.

А получать что ты будешь?

А мне в том и дело, что получать ничего и не надо

Тогда объявляйте все функции void, и ты у цели...

а что если вот так сделать? std::vector<std::function<std::any(int)>> vec; vec.push_back([](int){ return std::any("azazaza"); }); vec.push_back([](int){ return std::any(42); });

а функции уже объявлены в каком-нибудь винапи, и приехали

понимаю, что тоже враппер. но всё же

У них же сигнатура таже, но возвращаемые значения разные. Я так понимаю, что так нельзя ?

Лямбды сунб туда

[] {foo();}

Лямбды сунб туда

+1

Тогда объявляйте все функции void, и ты у цели...

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

Ну да так и надо, писать враппер-функцию, возвращающую void. Это можно на шаманить на lambdas

С лямбдами ты еще и явно всираешь ретурн велью

А без неявно

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

Враппер-функцию можно автоматом генерировать из лямбды

да я понимаю, ИМХО. Все равно телодвижения Ж.

Явное лучше неявного

Жизнь боль, а двигаться полезно

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

template<class Func> function<void(int,float,str)> wrap(Func f) { return [&f](int a,float b,str c) { return f(a,b,c); }; } vec.push_back(wrap(myfunc)); vec.push_back(wrap(anotherfunc)); я таким пользовался, если правильно помню

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

template<class Func> function<void(int,float,str)> wrap(Func f) { return [&f](int a,float b,str c) { return f(a,b,c); }; } vec.push_back(wrap(myfunc)); vec.push_back(wrap(anotherfunc)); я таким пользовался, если правильно помню

К тому же это неправильно, слишком узко в смысле параметров

Ребят, а можно ли как то сделать контейнер который будет хранить std::function с одной и той же сигнатурой входных параметров, но при этом с разным return type ?

Можно: https://wandbox.org/permlink/EzDPZmXugAtWgB1P

Если что, std::function вполне может содержать приводимые к хранящемуся типу вызываемые объекты, полное совпадение аргументов и возвращаемого значения не обязательно.

Комментатор выше предложил сигнатуру с any на случай, если тебе вдруг понадобится результат

Да, понял. Спасибо - мне скорее, как я и описывал, результат не нужен.

@antoshkka , а magic_get пойдёт на 2015 ой или 2017-ой студии (MSVC)? Я прочитал, что 14ый стандарт нужен, но ВЕСЬ или нет?

@antoshkka , а magic_get пойдёт на 2015 ой или 2017-ой студии (MSVC)? Я прочитал, что 14ый стандарт нужен, но ВЕСЬ или нет?

пойдёт

Ребят а по стандарту безопасно делать так? std::string_view view; { view = "Example"; } Ну типо есть гарантия того, что "Example" будет жить вне скоупа?

Ребят а по стандарту безопасно делать так? std::string_view view; { view = "Example"; } Ну типо есть гарантия того, что "Example" будет жить вне скоупа?

Конечно есть, т.к. это строковый литерал. Иначе все использования строковых литералов были бы UB

Ребят а по стандарту безопасно делать так? std::string_view view; { view = "Example"; } Ну типо есть гарантия того, что "Example" будет жить вне скоупа?

А вот если ты стринг туда фиганешь, будет больно, но не долго

Конечно есть, т.к. это строковый литерал. Иначе все использования строковых литералов были бы UB

ну все да не все :) например, если бы вместо string_view был бы string, то там строчка бы просто копировалась

А вот если ты стринг туда фиганешь, будет больно, но не долго

да со стрингом то ясно понятно))

хотя можно забить саморезы наверняка: std::string_view view; { static const char *example = "Example"; view = example; }

Ребят а по стандарту безопасно делать так? std::string_view view; { view = "Example"; } Ну типо есть гарантия того, что "Example" будет жить вне скоупа?

Строковые литералы хранятся в static storage так что их время жизни - вся программа

Строковые литералы хранятся в static storage так что их время жизни - вся программа

пасиба

Ребят, а можно ли как то сделать контейнер который будет хранить std::function с одной и той же сигнатурой входных параметров, но при этом с разным return type ?

Нафиг враперы. Складывай в tuple указатели на функции и возьми tuple_foreach, которой передавай визитора. Неплохая имплементация есть тут: https://github.com/ymarkovitch/libpcomn/blob/master/pcommon/pcomn_tuple.h#L87

@antoshkka , а magic_get пойдёт на 2015 ой или 2017-ой студии (MSVC)? Я прочитал, что 14ый стандарт нужен, но ВЕСЬ или нет?

На 2017 запускается и работает. Я там CI гоняю https://ci.appveyor.com/project/apolukhin/magic-get/branch/develop#L453

На 2017 запускается и работает. Я там CI гоняю https://ci.appveyor.com/project/apolukhin/magic-get/branch/develop#L453

А 15 типа мимо?

да, там у них было печально с шаблонами но может накатили какой-о фикс и теперь работает (сомневаюсь)

да, там у них было печально с шаблонами но может накатили какой-о фикс и теперь работает (сомневаюсь)

@zamazan4ik , а ты что скажешь про 2015ую ? (твой ответ выше неоднозначен)

@zamazan4ik , а ты что скажешь про 2015ую ? (твой ответ выше неоднозначен)

да, там у них было печально с шаблонами и не компилировалось но может накатили какой-о фикс и теперь работает (сомневаюсь)