у каждого инстанса foo свой вектор

А там, где ты эти инстансы объявлять будешь, тип T тебе ведь уже известен будет?

Так, Никита

вот все вспомогательные ограничения которые я могу дать: 1. для одного и того же инстанса foo, тип T, с которым будет вызван operator() всегда будет один и тот же 2. размер, до которого нужно скапливать элементы в векторе, известен в момент создания инстанса foo

вроде бы всё

std::vector<int> v; v.push_back(10); v.push_back(20);

и не имей мозг

std::vector<int> v; v.push_back(10); v.push_back(20);

чем вот этот код отличается от того, что ты пытаешься высосать из пальца?

А там, где ты эти инстансы объявлять будешь, тип T тебе ведь уже известен будет?

в том то и дело, что нет

чем вот этот код отличается от того, что ты пытаешься высосать из пальца?

я не знаю тип int заранее

я не знаю, int это или какой то другой тип

приведи пример использования, от объявления до вызова функтора

окей

https://wandbox.org/permlink/Z2NNzbB1RPnLIDfh

generateFunctor нельзя шаблонным сделать?

можно хоть как, главное чтобы его использование выглядело строго вот так : generateFunctor(10);

да хоть классом сделать

если это поможет

т.е. вручную тип хочется не указывать

даже decltype-ом

Народ, есть ли разница между инициализацией членов класса в обычных скобках, в фигурных скобках или в теле конструктора? 1) Test(int val1, float val2) : x(val1), y(val2) {} 2) Test(int val1, float val2) : x{val1}, y{val2} {} 3) Test(int val1, float val2) { x = val1, y = val2 }

ага, требование такое

т.е. вручную тип хочется не указывать

даже decltype-ом

читаем правила чата

Народ, есть ли разница между инициализацией членов класса в обычных скобках, в фигурных скобках или в теле конструктора? 1) Test(int val1, float val2) : x(val1), y(val2) {} 2) Test(int val1, float val2) : x{val1}, y{val2} {} 3) Test(int val1, float val2) { x = val1, y = val2 }

1. в теле конструктора нельзя инициализировать объекты, не имеющие конструктора по умолчанию, либо константные поля / ссылочные типы 2. фигурная инициализация, в отличие от инициализации круглыми скобками, всегда вызовет конструктор от initializer_list (если существует подходящее преобразование), если таковой имеется

это не все отличия

1. в теле конструктора нельзя инициализировать объекты, не имеющие конструктора по умолчанию, либо константные поля / ссылочные типы 2. фигурная инициализация, в отличие от инициализации круглыми скобками, всегда вызовет конструктор от initializer_list (если существует подходящее преобразование), если таковой имеется

Насколько я помню, конструктора по умолчанию у класса не будет, если а) ты создал конструктор с параметрами, но не создал конструктор без параметров б) удалил конструктор Test() = delete; Верно?

ага

Спасибо

ну либо этот конструктор недоступен из за инкапсуляции

ага, требование такое

блин, фиг знает тогда. По-моему, C++ type deduction не настолько умный, чтобы объявить переменную инкомплит типом и потом его вывести на основе вызова

значит только вариант с костылем-картой

https://wandbox.org/permlink/Z2NNzbB1RPnLIDfh

template <size_t n> struct foo { template <typename T> auto add(T &&e) { if (!storage.has_value()) { storage = std::any(std::vector<T>{}); } std::vector<T> &v = std::any_cast<std::vector<T> &>(storage); v.emplace_back(std::forward<T>(e)); if (v.size() == n) { auto r = std::optional<std::vector<T>>(std::move(v)); storage.reset(); return r; } return std::optional<std::vector<T>>(); } std::any storage; }; TEST(misc, foo) { auto f1 = foo<2>(); auto f2 = foo<2>(); ASSERT_EQ(std::optional<std::vector<int>>(), f1.add(1)); ASSERT_EQ(std::optional<std::vector<int>>(), f2.add(2)); ASSERT_EQ(std::optional<std::vector<int>>({1, 3}), f1.add(3)); ASSERT_EQ(std::optional<std::vector<int>>({2, 4}), f2.add(4)); }

да, похоже это единственный вариант, только жалко лишнюю аллокацию тратить на any

спасибо

да, похоже это единственный вариант, только жалко лишнюю аллокацию тратить на any

ну, если не std::any, тогда придется выделять буфер и играться с placement new ... char storage[1024]; // capacity must be much enough to hold vector };

а в стандарте случаем нету каких-нибудь гарантий, для классов какого размера std::any применит SBO?

если только объединить первый вызов generateFunctor с добавлением первого элемента, тогда можно так: https://wandbox.org/permlink/SUIeXx0rPLA4ONcP

оу, можно было return {} вместо портянки std::optional<std::vector<T>>()

оу, можно было return {} вместо портянки std::optional<std::vector<T>>()

для auto? возможно, не проверял

да, я в своем примере выше заменил, сработало

ой, не, не для авто

когда тип возврата известен

когда тип возврата известен

ну, в этом случае, да

если только объединить первый вызов generateFunctor с добавлением первого элемента, тогда можно так: https://wandbox.org/permlink/SUIeXx0rPLA4ONcP

спасибо

http://coliru.stacked-crooked.com/a/698533b264538fb5

классно, только wrap(wrap()) не сработает, немного криво пишете

http://coliru.stacked-crooked.com/a/698533b264538fb5

а, еще х3 как это работает, вы параметр форвардите криво

а, еще х3 как это работает, вы параметр форвардите криво

Форвардю идеально, учись бро, это серебрянная пуля. Считай, что это такая идиома. Если тебе надо протащить параметр с forwarding reference в глубины твоих шаблонов, то заради меньшей писанины можно везде его передавать (как актуальный параметр фунции) как lvalue reference. Параллельно ты всё равно передаёшь его тип явным образом (как актуальный параметр шаблона), который применяешь в самом конце в std::forward. Это просто экономия писанины. Вот отличный пример https://github.com/tomilov/variant/blob/master/include/versatile/visit.hpp#L61 . Если бы я передавал везде все параметры как std::forward< ... >(), то это бы привело к лишней писанине, но дало бы в итоге эквивалентный код.

классно, только wrap(wrap()) не сработает, немного криво пишете

ну это легко исправить http://coliru.stacked-crooked.com/a/78486037eaadb94b . L l; поле будет иметь тип значения для rvalue переданного в функцию wrap и перемещённое значение в качестве значения и lvalue-reference для lvalue-reference переданного во wrap.

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

Ботов можно создавать хоть на брейнфаке. Надо только уметь отправить HTTP-запрос

Ботов можно создавать хоть на брейнфаке. Надо только уметь отправить HTTP-запрос

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

Вопрос по архитектуре, у меня есть три шаблонных класса так что следующий класс использует предыдущий (если такой существует), но использую я только финальный класс. Как лучше всего инкапсулировать два других класса? И если можно то без определения этих двух классов внутри финального.

Как именно используются?

Наследование, параметризация, агрегация?

Нет, все ще проще

Есть алгоритм который строит главную хеш-таблицу, что имеет свои свойства, вторую хеш-таблицу, что отличается от главной хеш-таблицы и класс списка

Список используется в дополнительной хеш-таблице Дополнительная хеш-таблица в основной

Доступ должен быть только к основной хеш-таблице и без доступа к классу простой хеш-таблицы и к классу списка

Ммм, да Агрегация

Народ

Форвардю идеально, учись бро, это серебрянная пуля. Считай, что это такая идиома. Если тебе надо протащить параметр с forwarding reference в глубины твоих шаблонов, то заради меньшей писанины можно везде его передавать (как актуальный параметр фунции) как lvalue reference. Параллельно ты всё равно передаёшь его тип явным образом (как актуальный параметр шаблона), который применяешь в самом конце в std::forward. Это просто экономия писанины. Вот отличный пример https://github.com/tomilov/variant/blob/master/include/versatile/visit.hpp#L61 . Если бы я передавал везде все параметры как std::forward< ... >(), то это бы привело к лишней писанине, но дало бы в итоге эквивалентный код.

Угу, гениальная идиома std::unique_ptr<int> supasmart_function(std::unique_ptr<int> & ptr) { return std::move(ptr); }

есть ли статический анализатор, который может детектить непроверенный shared_ptr?

Подскажите плиз почему base64encode на C и base64.StdEncoding.EncodeToString на Go дают разные результаты?

Реализованы по разному.

Это пример как раз то, что вы делаете

wrapper получает параметр по ссылке и мувает его

Подскажите плиз почему base64encode на C и base64.StdEncoding.EncodeToString на Go дают разные результаты?

И какой именно base64encode? Их 100500

Хз, какой там у тебя.

Подскажите плиз почему base64encode на C и base64.StdEncoding.EncodeToString на Go дают разные результаты?

Кодировки входных строк разные могут быть. Наверное. Ещё перед вызовом данные могут подготавливаться по-разному.

https://ideone.com/99LsBL

ой чета оно убнуло

есть ли статический анализатор, который может детектить непроверенный shared_ptr?

какова рода непроверенность shared_ptr ?

какова рода непроверенность shared_ptr ?

тема, ну давай паруски

тема, ну давай паруски

не ну а чо он

shared_ptr и в динамке вроде не проверить на коректность, не говоря уж про статики

shared_ptr и в динамке вроде не проверить на коректность, не говоря уж про статики

мне не проверить надо. Мне надо, чтобы анализатор сказал, что вы НЕ проверили шаред перед использованием, как с обычным поинтором. Просто у нас есть один разработчик, который опять уронил наш сервис из-за своего говнокода

Вангую какой PVStudio проверяет это

какова рода непроверенность shared_ptr ?

int *huitka = new int[679]; shared_ptr sp1(huitka); shared_ptr sp2(huitka); // бабах в конце жизни

int *huitka = new int[679]; shared_ptr sp1(huitka); shared_ptr sp2(huitka); // бабах в конце жизни

дада но такое разве провериш, тут нужна фулл муви симентикс