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.

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

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

Есть вопрос к ненавистникам 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*

ой

Параметром чего? Конструктора?) Я от этого и избавляюсь

инициализовать после конструктора, например

в make_derived_2

Вооот, от этого я и пришёл. Контекст требуется уже внутри конструктора Derived, поэтому после - не получится

хм...

в любом случае меня учили в книжках, что агрегация уменьшает связность

а зачем вообще нужен второй конструктор?

он же может быть использован только в make_derived_2

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

В идеале нужно удалить конструктор Derived, который использует void*

Ну его сейчас можно удалить и юзать вторую фабрику. Собственно вопрос в том, законно ли это