так нельзя писать же

ну например auto f = [](int(y)){}

это разрешенный сейчас синтаксис

ничеси

зачем

auto f = [](int){}

это разрешенный сейчас синтаксис

+, так в боте сделал в олнгм месте

auto f = [](x(y)){} и неявное auto

ну тут вроде явно написано что x это тип

этож объявление

auto f = [](int(y(int))) {};

ну тип

Ты же на этапе вызова лямбды можешь только узнать кто с кем ее вызвал, собственно а auto это compile time

или ошибка

там речь о том чтоб не писать auto

auto f = [](auto y(int)) {}; мне сейчас вижак скомпилил

да это функция же нет?

ну смотри, x(y) кто тип?

или никто?

выражение auto y(int) означает переменную y

это тип

это тип потомучто нет возвращаемого значения у фукнции

у тебя не тип auto

а тип функция

а у функции должно быть возвращаемое значние

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

да если подразумевается тип

Немного не в тему вопрос) Насколько жесткий диск влияет на скорость компиляции? Если компилировать на ссд, будет ли это заметно быстрее?

да

в смысле, если выражение _похоже_ на объявление переменной?

в рам компилируй

ну по факту тут тип - функция же это явно видно никак иначе не растолковать

тоесть тип задан уже

/

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

я говорю подставлять авто только если тип не задан

auto f = [](auto&(x)) {}; опять же, компилируется

да таместь баги с struct x{} [](x){}

здесь как раз легко, известно, что x тип

чисто синтаксически неизвестно

?

x тип объявлен как тип, с этого момента это тип

вроде весь парсер выражений плюсов ломается, если заранее неясно какие идентификаторы - имена типов

спасибо за подвохи

.

там лулзный был. Про ит в целом

ссылку можно?

ссылку можно?

позже скину

int g(int); std::string h(int); auto f = [](auto x(int)) { return x(0); }; f(&g); f(&h); как это вообще работает?

как функтор с шаблоном думаю

что такое f?

функтор

класс или переменная или что?

объект анонимного класса

у него стремный тип

лучше его не знать

а, я понял, у этого объекта же просто шаблонный operator()

понял, втупил

В supapro молчат

Как в CMake подключить BLAS?

На Linux

Пытаюсь так find_package(BLAS REQUIRED) include_directories( ${BLAS_INCLUDE_DIRS}) target_link_libraries( EVM_M ${BLAS_LIBRARY})

пишет CMake Error at CMakeLists.txt:8 (target_link_libraries): Cannot specify link libraries for target "EVM_M" which is not built by this project.

ERROR: S client not available

target EVM_M должен быть определен либо через add_executable, либо через add_library

а уже после слинкован с библиотекой посредством target_link_libraries

Всем привет

Помогите написать код

По блок-схеме

чего-то тут не хватает

а вообще, такие вопросы - в чат для новичков

#supapro

Чат supapro.cxx: https://telegram.me/joinchat/BYlFbD3eN3JMaG34hyh96w

Да, инфы в блоках нет.

Сказали же, иди в #supapro

в ультрамегапро

https://t.me/joinchat/AAAAAEH2f4R62LrebHWd7g

Есть вопрос к ненавистникам UB: http://cpp.sh/2rbzm внутри main()

Можно вопрос от новичка (прошу простить), можно же Base(void* c=nullptr) : context(c) {} - он и конструктор по умолчанию и с параметром - сразу двух зайцев не?

Можно вопрос от новичка (прошу простить), можно же Base(void* c=nullptr) : context(c) {} - он и конструктор по умолчанию и с параметром - сразу двух зайцев не?

Не об этом вопрос. Base можно как угодно менять, задача упростить Derived

Derived(double a) : Derived (a, nullptr) {// используем context, a } Это не подходит почему? еще раз простите.

Потому что контекст будет nullptr, если попытаться его использовать

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

Фабрика и Base будут интерфейсом либы, а вот Derived создаёт пользователь. И не круто каждый раз пилить конструктор очередного Derived с дополнительным аргументом void*. Для этого я придумал вторую фабрику и спрашиваю - насколько правильно её использовать

Есть вопрос к ненавистникам UB: http://cpp.sh/2rbzm внутри main()

забавно, но не очевидно: почему это не сугубо теоретический вопрос?

забавно, но не очевидно: почему это не сугубо теоретический вопрос?

Встала задача сделать интерфейс, удобный для пользователя

почему нельзя отказаться от наследования?

почему нельзя отказаться от наследования?

Потому что в Base лежит много логики (пример упрощён)

Derived используется по указателю, разве не сработает агрегация с перегрузкой -> ?

Derived используется по указателю, разве не сработает агрегация с перегрузкой -> ?

Сделать Base членом Derived? Тогда всё равно потребуется его явно инициализировать context'ом. Опять неудобство для пользователя

вроде нет, можно же теперь просто протолкать параметром бывший Base*

ой