Тут cons это функция - реализация законна «соединение» монады. И где - то на уровне языка есть реализация получения результата. По этому на прямую с такими списками работать нельзя (большую часть времени их вообще нет, только описание как их получить)

В лиспе все не список, а скорее объект. Все Список там только на синтаксическом уровне.

Ну как раз наоборот, в с++ список более высокоуровневый чем в лиспе.

Ну и про монады ты имхо загнул, они тут ни при чем.
В лиспе монад вообще нет.

Да ладно, при чем тут монады ?

Я не могу писать незнакомым )

Потому, что так делают списки в некоторых языках (ну и можно доказать выполнение монадических законов для списков в lisp). И это единственное различие списка типа лисповского и списка типа си-шного. Определяется оно сущностями, которыми может оперировать язык.

Монаду List в C++ сделать не сложно, но пользоваться ей будет очень не удобно - по этому так не делают.

/s@SupaproBot

@ODN_VLC_molchun Ваш вопрос перемещён в чат @supapro . Там Вам с радостью помогут с Вашей проблемой :)

Дорогой, перенаправляю тебя в чат "программирование", ибо оффтопик

Твои вопросы тут @pro_prog

Хорошо, спасибо )

В общем: вот как это получается. Список - это (всегда) структура данных. В императивном программирование программист говорит: «хочу список». Среда исполнения выделяет кусок памяти и дает то, что программист просит. В функциональном программирование с ленивым вычислением программист говорит - пусть эти штуки образуют список и среда выполнения возвращает ему функцию, которая (когда выполнится на самом деле) сделает список. Если все что есть у рантайма, это функция связывания двух элементов, то для того, чтобы получился список нужно сначала исходную функцию с кучей аргументов привести к функциям связывания. Потом, в какой то момент функция выполнится и появится структура данных. Следующий логический шаг - идите лесом со своим исполнением, нам и так хорошо. Можно просто пройти по всей цепочке, взять левый аргумент каждой такой функции, и сделать новую цепочку, где будет все то же самое, только вместо данных будут вызовы функций от данных), но это уже другая история - тут важно, что изначальный список может вообще не существовать (в понимание C). C++ не то чтобы сильно ФП, но есть замыкания, а функция (еще со времен C) объект первого порядка и теперь есть относительно сносный автоматический вывод типов. А вот никакого синтаксического сахара для работы с монадами нет. Зато есть удобная stl где список это структура данных с удобными итераторами и очень легко работать с памятью.

Может ли на устройстве с встроенной графикой(SoC), которая использует часть оперативной памяти в качестве видеопамяти фреймбуфер находится в kernel space, если предполагается zero-copy? Т.е а получаю указатель на некую область памяти через определённые API, а дальше напрямую пишу данные в неё и видео отображает это безобразие. Или всё-таки выделяется память в userspace, а сам VideoCore напрямую её дёргает? Просто я не могу понять как я умудрился выполняя memcpy не просто словить UB, а ещё и привести систему всю в неработоспособное состояние

Здравствуйте, скажите, пожалуйста, почему не линкуются библиотеки?
Я получаю ошибку компоновщика:

LINK : fatal error LNK1104: не удается открыть файл "sublibrary_c.lib"

Все файлы лежат в одной папке:

CMakeLists.txt
main.cpp
sublibrary_c.lib
sublibrary_cpp.lib
sub_c.h
sub_cpp.hpp

Содержимое CMakeLists.txt:

project(sub_main)
add_executable(sub_main main.cpp)
target_link_libraries(sub_main sublibrary_c sublibrary_cpp)

Просто пытаюсь использовать заранее собранные библиотеки. Без исходников. Только с заголовочными файлами.

помогите, пожалуйста, разобраться с ошибками во время компиляции (хотя бы в какую сторону копать): https://pastebin.com/gvxjTeVz

Исправил файл на следующее:

cmake_minimum_required(VERSION 3.19)
project(sub_main)
add_library(sublibrary_c STATIC IMPORTED)
add_library(sublibrary_cpp STATIC IMPORTED)
set_property(TARGET sublibrary_c sublibrary_cpp PROPERTY
             IMPORTED_LOCATION "C:/Users/ilya8/Desktop/lesson_5_1/main")
add_executable(sub_main main.cpp)
target_link_libraries(sub_main sublibrary_c sublibrary_cpp)

теперь вообще не понятно
LINK : fatal error LNK1104: не удается открыть файл "..\.obj"
🤕

я понял, ушел к новичкам

cmake_minimum_required(VERSION 3.19)
project(sub_main)
add_library(sublibrary_c STATIC IMPORTED)
add_library(sublibrary_cpp STATIC IMPORTED)
set_property(TARGET sublibrary_c sublibrary_cpp PROPERTY
             IMPORTED_LOCATION "C:/Users/ilya8/Desktop/lesson_5_1/main")
add_executable(sub_main main.cpp)
target_link_libraries(sub_main sublibrary_c sublibrary_cpp)

IMPORTED_LOCATION должен на саму либу указывать.