Слушайте, а виртуальные деструкторы медленнее обычных? В плане стоит ли любой абсолютно класс делать с вирт деструктором?..

Медленее из-за возможного сброса кэша и невозможности отследить indirect call в предсказателе переходов

Кто разбирается в системном программировании помогите, хочу понять что происходит при передаче исполнения от одного процесса к другом, что происходит с контекстом ? Где она сохраняется ?

в ядре

Кто разбирается в системном программировании помогите, хочу понять что происходит при передаче исполнения от одного процесса к другом, что происходит с контекстом ? Где она сохраняется ?

в Linux - в process control block

в Windows в структурах ETHREAD/KTHREAD/EPROCESS/KPROCESS

что происходит — ну, ядро сохраняет контекст, вычисляет, кому выполняться следующим и засовывает соотетствующий instruction counter в cpu

обзорно — https://github.com/torvalds/linux/blob/master/include/linux/sched.h .

ну что происходит на Windows - это нужно что-нибудь типа Windows Internals почитать, чтобы понять

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

В какой стек ?

стек един.

на x86, как минимум.

Стек непобедим(

Стек у процесса один

в cpu есть регистр, в котором находится указатель на голову стека

Я запутался

Стек у процесса один

зависит от системы.

Пользовательский контекст состоит из кода и данных в которую и входит стек, bss и прочее

Как я знаю

Стек у процесса один

есть инструкции push/pop. Процесс вообще один только может выполняться на одном ядре. Этот процесс — как правило — ядро, которое может внутри себя запускать какие-то внешние инструкции.

Пользовательский контекст состоит из кода и данных в которую и входит стек, bss и прочее

ну, да. Образ программы, загруженный в память.

в начале выполнения сохраняется указатель на текущую голову стека — за неё процесс изнутри выйти не может (в общем случае, если нет уязвимостей)

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

обращение к данным в нём — это в общем случае загрузка из RAM, если, конечно, её нет в кеше.

Как ты понимаешь контекстный уровень ?

в ядре есть список структур task_struct (точнее, двусвязный список), в task_struct находится вся информация о контексте конекретной таски: выделенная память, занятые дескрипторы, указать на текущую инструкцию, и всякие вспомогательные данные.

Как ты понимаешь контекстный уровень ?

я вообще не понимаю о чём ты.

судя по ссылкам из гугла, это как раз и есть task_struct в linux.

посмотри на struct task_struct в https://github.com/torvalds/linux/blob/master/include/linux/sched.h .

Все я понял

Ядро имеет свой стек где хранит информацию о функциях и системных вызовах

Ядро имеет свой стек где хранит информацию о функциях и системных вызовах

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

Понятно, спасибо

Кто разбирается в системном программировании помогите, хочу понять что происходит при передаче исполнения от одного процесса к другом, что происходит с контекстом ? Где она сохраняется ?

У каждого процесса свой контекст., Внутри процесса у каждого потока свой стек и свой набор переменных в thread local storage

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

В "больших" операционных системах процессы уровня пользователей не участвуеют в обработке прерываний вообще.

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

Вот примерно так было во времена DOS...

В "больших" операционных системах процессы уровня пользователей не участвуеют в обработке прерываний вообще.

На уровне ядра

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

Нет, у кого процесса стек свой. Даже у каждого потока процесса

Процесс имеет два стека, при исполнении в режиме ядра и в режиме задачи

На уровне ядра

На уровне ядра чего? Не всегда у ОС и ядро то есть...

Процесс имеет два стека, при исполнении в режиме ядра и в режиме задачи

Нет. Один

Операционная система без ядра это что то новое

Для меня

Нет, у кого процесса стек свой. Даже у каждого потока процесса

Свой стековый фрейм, выделенный ядром. Процессор когда делает push вообще ничего не знает про процессы и треды

Ну, о сколько нам открытий чудных...

Операционная система без ядра это что то новое

baremetal ?

Как можно представить Linux без ядра ?

Свой стековый фрейм, выделенный ядром. Процессор когда делает push вообще ничего не знает про процессы и треды

Это да, правильно

Как можно представить Linux без ядра ?

Ядро -это элемент архитектуры конкретной операционной системы.

Так это оболочка + дополнения

Нет, у кого процесса стек свой. Даже у каждого потока процесса

Так и представляю себе решение проблемы синхронизации стековых операций.

Как запустить машину без мотора ?

Как можно представить Linux без ядра ?

Можно представить всю ту же фигню с другим мотором)

А почему машину? А если у тебя не машина, а танк, и там турбина?

Интерфейс не подойдёт ))

Все разное...

На танк колесо от мерседеса ?

На уровне ядра чего? Не всегда у ОС и ядро то есть...

Моежет это про "режим ядра"?

На танк колесо от мерседеса ?

добро пожаловать в мир POSIX

Есть и примитивные однопользовательские системы

Моежет это про "режим ядра"?

+

Так ядро и представляет интерфейс, как можно запустить программу в виндовс на линуксе не изменив системные вызовы ?

К ядру ?

При компиляции через сколько уровней проходит код программы ?

А как по вашему EFI приложения работают?

А как по вашему EFI приложения работают?

Это другая тема для обсуждения

Прошивка

Ладно, главное не это, а то что к языку С++ (и С) это все не имеет никакого отношения

Компилятор и Линекер. Все, 2

Короч такой вопрос. Хочу я, чтобы enum'ы были раскиданы по своим неймспейсам. Допустим есть у меня класс Powerup. И есть enum powerupType { ... } Я хочу перенести его под класс, чтобы было enum Powerup::Type, поскольку оно логически относится только к этому классу. Но это приведет к тому, что везде в других модулях, где используется это перечисление, мне придется инклудить заголовочник powerup.hpp Делать это ради одного перечисления мне кажется неправильным, потому что на ровном месте появляется лишняя связность Допустимо ли вынести такие перечисления в отдельный заголовочник? Там будет несколько разных перечислений, относящихся к разным классам, типа Input::Direction

Насколько это плохой тон - держать отдельно от файлов класса код, относящийся к классу

Насколько это плохой тон - держать отдельно от файлов класса код, относящийся к классу

Вложенные в классы имена в С++ содержат огромадный дефект - они не могут быть declared без definition класса, так что если определение класса надо развязывать, у вас и выбора нет, и вопроса нет

Не понял про "развязывать", что имеется в виду? На данный момент решение уже принято - убрать все enum'ы в отдельный файл config.hpp, тот же где все настройки и константы проекта хранятся, и без привязки к классам. Получается убрать сопряжения между классами напрямую. Решил, что это важнее чем держать перечисления внутри подходящих классов.

Не понял про "развязывать", что имеется в виду? На данный момент решение уже принято - убрать все enum'ы в отдельный файл config.hpp, тот же где все настройки и константы проекта хранятся, и без привязки к классам. Получается убрать сопряжения между классами напрямую. Решил, что это важнее чем держать перечисления внутри подходящих классов.

Значит, что если вы различаете работу с declaration и definition некоторого класса, то у вас автоматически все публичные вложенные типы должны уйти наружу класса

в каком-то конвенционном виде, вроде namespace some { enum class special_enum {}; } class some_type { public: //some::special_enum это что-то мое на самом деле };

а как только они перестали быть внутри класса, вопроса больше нет - вы с ними как с (А зависит от Б) можете работать

(например, вас же не смущает предка некоторого класса убирать в другой файл)

в каком-то конвенционном виде, вроде namespace some { enum class special_enum {}; } class some_type { public: //some::special_enum это что-то мое на самом деле };

уперся это вот, не хватает уровня понять, что это все значит

спрошу лучше, как в этот вид переделать то, что у меня есть

уперся это вот, не хватает уровня понять, что это все значит

это конвенция, когда имена типов грубо говоря пишутся some_type, а для всего вспомогательно есть namespace some рядом

Можно практический пример? я с трудом понимаю)) Или на моём примере как переделать

https://github.com/narical/asciidunge/blob/libtcod/include/config.hpp

https://github.com/narical/asciidunge/blob/libtcod/src/input.cpp

этот класс использует enum direction { ... } из config.hpp

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

этот класс использует enum direction { ... } из config.hpp

ну все-таки enum вместо enum class писать в С++11 моветон

ох, надеюсь где-нить на хабре есть на эту тему почитайка

нет конечно, я совершенно внутреннюю вещь рассказываю сейчас

т.е. ваша проблема закрывается определенной конвенцией именования типов

в каком-то конвенционном виде, вроде namespace some { enum class special_enum {}; } class some_type { public: //some::special_enum это что-то мое на самом деле };

аналогично этому, но менее абстрактный пример можно?

аналогично этому, но менее абстрактный пример можно?

я совершенно не понимаю, что вы хотели сказать классом powerup, но если предположить, что это тип-значение, то enum class powerup_enum { health, mana, damage }; class powerup_type { explicit powerup_type(powerup_enum type) : type_(type) { } private: powerup_enum type_ /*m_type, etc...*/; };

вообще ваш Powerup выглядит, будто это std::variant

у меня там большая часть кода заглушечная

теоретически она когда-то должна развиться в нечто совершенно другое, практически же - всё будет переписано с нуля с другим подходом совершенно

Это мой первый проект, который я начал решив выучить плюсы