Ну в мейкфайлах на самом деле не надо файлы вручную перечислять

Ну в мейкфайлах на самом деле не надо файлы вручную перечислять

Да я просто видел, что генерится студией их, когда багу одну отлавливал. Страшно стало. Там баш-скрипт gcc отдается строк на 200 что-ли, если в pastebin копирнуть

нет не можем

Стоп мы же можем сейчас кажись превращать констекспр поды в типы по методу Антона Полухина?

Если да то мы можем "передавать" поды в качестве шаблонных параметров распаковывая и запаковывая их автоматически

Если да то мы можем "передавать" поды в качестве шаблонных параметров распаковывая и запаковывая их автоматически

Это очешуенная идея!

я пытаюсь

но нужен С++17

В "методе Полухина" на С++14 есть reinterpret_cast, который нельзя в constexpr

да впень с++14

там трабла в том что чтоб это сделать нормально мы уже должны это уметь

template <template <auto...> class Callback, class Value, size_t... I> constexpr auto decompose_to_subtypes_impl(Value v, std::index_sequence<I...>) noexcept { return Callback<get<I>(v)...>{}; }

это работает?

не проверял)

не должно вроде

Ну, постараюсь на этой неделе проверить и довести до ума

ошибка: decomposition declaration cannot be declared «constexpr»

О_О

вот это облом

и вот еще

constexpr auto test_constexpr(int a) noexcept { return integral_constant<int, a>{}; }

не работает

потомучто a не constexpr

тооочно

короче бесполезно

надо тупо вводить constexpr параметры или чтото такое

constexpr test t{3, 'c'}; struct bar { const test value = t; }; cout << foo<bar>() << endl; вот такое есть только

можно обмазаться макросами

можно обмазаться макросами

через месяц после этого: "такс, такс, что это у нас тут, о, макрос _FUNC_, давно его не видел"

рекурсия на ембеддеде довольно плохая идея

радуйся что не попал к таким дауничам

А в бусте есть интрузивные контейнеры, например.

если узлов миллион то можно трейдануть скорость за память и пройти по списку миллион раз, но затратить на это 0 памяти )

можно затратить тысячу памяти и пройтись чуть поменьше

но покажите мне эмбеддед с миллионом стека - такого даже не линуксе без доп. опций не добиться

Смотря как список реализован. Xor если, то херня вопрос и без оверхэда

Смотря как список реализован. Xor если, то херня вопрос и без оверхэда

справедливо!

"а если коллега идиот"?

#book #algorthms

Вопрос стандартный, если идешь в эмбедед. У тебя память и все остальные ресурсы ограничены. Тебе нужен кольцевой встраиваемый список, там даже маллок не нужен. потому что не во все контроллеры он влезет.

да это обычный. встраиваемый это тот который явл-ся частью полезных данных.

лучше использовать сразу двухсвязный. там все стандартные операции O(1)

Я ответил на твой вопрос? Это вопрос больше про Си. да да тот самый старенький Си.

если это С, то это не скомпилируется

если список не одноноправленный, вообще проблем нет, просто идешь назад, но даже если список одноноправленный и не стоит ограничение на модификацию списка можно попробовать его инвертировать. Те если мы упираемся только в память и можно жертвовать временем.

Да не нужно ничего инвертировать, он кольцевой. Ему даже маллок не нужно при модификации. Памяти в эмбедед очень мало. Но предельные случаи известны. по этому выделяется массив или даже секция по средствам линковщика. Но это массив. а с данными удобнее работать в динамике (но динамике с точки зрения выделения памяти нет, вот бл просто нет маллока и фри) По этому крутые дяди придумали так называемые встраиваемые контэйнеры.

вот пример из ядра линуха: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/list.h?h=v4.13-rc2

это как раз двухсвязный. односвязные используются чуть реже. могу дать ссылку на мою реализацию если надо. Таким же макаром реализуют деревья, красночерное можно глянуть в том же ядре.

мы даем такой вопрос, но запрещаем рекурсией пользоваться и запрещаем так же new

Да не нужно ничего инвертировать, он кольцевой. Ему даже маллок не нужно при модификации. Памяти в эмбедед очень мало. Но предельные случаи известны. по этому выделяется массив или даже секция по средствам линковщика. Но это массив. а с данными удобнее работать в динамике (но динамике с точки зрения выделения памяти нет, вот бл просто нет маллока и фри) По этому крутые дяди придумали так называемые встраиваемые контэйнеры.

Я так понял у него однонаправленный список и вывести требуется в обратном направлении. и проблемма не только в выделении памяти но еще и в том что заранее не известен предыдущий элемент. Поправте меня пожалуйста если не прав

что за хрень вообще стеком пользоваться для реверса односвязного списка?

мы даем такой вопрос, но запрещаем рекурсией пользоваться и запрещаем так же new

А где новые ноды создаёте?

мы заставляем реверсировать этот же список

А вставка?

при реверсе вставка.

?

Да прост xor список и всего делов, ну...

Никаких лишних аллокаций, ничего.

Не, без реверса. Пуш бэк

Просто итерируешься назад с конца и всё.

я пишу про реверс

А ок, ну да new не нужен

Ну просто обычно прежде чем список развернуть, его надо написать)))

Ну, я так смотрю, многие найдут это задание интересным

дерзайте

Пройдёт доконца, узнает размер)))

1. Пройтись до конца. 2. Хранить длину отдельно.

Неее, нельзя хранить. Чистый список. Только из нод))

Ноды в эмбедед создаются уже под задачу, читай выше. ПРимер: нам известно что будут приходить данные из разных источников, мы их транслируем. скажем некие покеты по SPI или модбас там.. нам оговорили что в очереди 500 пакетов. мы делаем массив на максимум. далее обьявляем кол-во голов списков согласно кол-ва входных дырок. далее идут данные. с разных дурок с разной скоростью мы берем из общего пула ноду пихаем в свою голову, после отрабоки возврощаем. если в пуле нод нет, превышен заложенный макимум на 500. как то так.

Неее, нельзя хранить. Чистый список. Только из нод))

Тогда дуй с начала до конца, чо.)

Так и делают

Ну, конечно, лучше хранить размер))

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

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

Вообще список медленнее обходить, чем вектор тот же