Почему слабочитаемо? Всего-то добавлен один-единственный параметр шаблона, который должен иметь функцию exec(). Родной шаблон тоже не пострадал, всего лишь получил одного дополнительного предка. С точки зрения результирующего кода - ничего не изменилось абсолютно. С точки зрения интерфейса, предоставляемого OS::process - тоже полная идентичность.
Единственное, что изменилось - добавился альтернативный способ создания процессов в оси. Имхо, сплошной профит

Не понимаю, чем оно мешает в том виде, как предлагается сейчас?

Да мне ничем. Главный идеолог против...

А может мои пламенные речи уже переубедили его?

Так это вполне обычная практика в C++ - передавать в шаблон базового класса свой же тип:
http://en.cppreference.com/w/cpp/memory/en...hared_from_this
Пример оттуда:

Ни разу не так. Помещено туда определение шаблона process, а exec просто объявлена внутри process, и её определение вполне без проблем может быть сделано где угодно.


А я и не говорю, что оно здесь есть. Я его и предлагаю взамен наследования на котором вы настаиваете, хотя в наследовании тут смысла вообще почти нет: из-за того, что exeс статическая, никакое наследование не позволит иметь нормальный объект с инкапсулированными данными внутри - это будет просто пространство имён с "регулировкой" уровня доступа, не более.




+1.


Да, всяко не очень красиво получается. А главное - ради чего?


Вот это было бы лучше всего. Расширения для того и предназначены, чтобы расширять. Там можно что угодно делать - желающие пусть юзают.


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

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


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

В общем, ждём результатов обкатки в железе предложенного варианта (process : public custom_process<...>).

Проверил.
Предложенный вариант даёт полностью, до байта совпадающий бинарный файл прошивки. Но я его на всякий случай прогнал в железе. Работает!
Вот исправленный OS_Kernel.h:  OS_Kernel.h.zip ( 4.47 килобайт ) Кол-во скачиваний: 160

OS_Kernel.cpp остаётся родной. Прошу попробовать с другими портами, у кого есть время.

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


А этого (регулировки уровня доступа) мало?
Все процессы существуют в единственном экземпляре, поэтому статическая exec() не пугает.

Этот вот TSlon::exec() перестал быть функцией процесса. Потерял доступ к protected в TBaseProcess. Их там (пока) и немного, но тут уже «страдает чувство прекрасного» у меня.

По поводу сущностей: «предоставлять функцию процесса» -- это задача базового класса процесса. И если про что-то в системе я думаю «это -- процесс», то мне естественно думать «занчит, оно должно біть потомком базового класса процесса».
Ну так вот сижу я и думаю
«так, мне нужен процесс обслуживания индикации»
«другие будут дергать этот процесс такой-то функцией, которая будет помещать запросы в очередь»
«ага, у процесса должна быть очередь»
Но в результате делаю класс процесса, о котором думал (class TSlon) и класс процесса процесса (typedef OS::process<…> TSlonProc).


Ну :-) Вдруг эти байты только с виду одинаковые :-D

Ой, если не замотаюсь, завтра на работе (оно там в реальной винде живет) проверю с IAR, но только методом file compare. И мне кажется, что тоже разницы должно быть 0.00, и платы все равно нет под рукой.
gcc/avr не вижу смысла проверять, front-end тот же.

Это совершенно неверно. Согласно стандарту языка С++, специализация шаблонной функции должно быть выполнено только в том пространстве имён где был объявлен шаблон. То, что некоторые компиляторы допускают иную трактовку, является их ошибкой.
Вот выдержка из стандарта (14.7.3/1):


В любом случае компиляторы подтянуться к стандарту, код перестанет компилироваться и придётся писать

Через параметр конструктора предка? Но тогда надо переопределять и terminate(), который тоже использует адрес exec.

Молодец!


Конечно мало. Тут речь про инкапсуляцию ведут, а оная подразумевает наличие законченного целостного объекта. Но на деле никакого объекта и в помине нет, а есть сборная солянка из статических членов, засунутых в общее пространство имён. Т.е. ни абстракции, ни отделения интерфейса от реализации (т.к. и интерфейса-то никакого нет) - ничего этого нет. За что боремся?


Пугать-то не пугает, но и ничего этот подход не даёт.


А зачем ему этот доступ? Всё, что предназначено для доступа с уровня пользовательской программы, помещено в public секцию, остальное - для внутренних служебных целей. Поэтому разрешение доступа юзеру к этому представлению - это никакое не благо, а дырка в защите. Если там есть что-то, к чему надо дать доступ на уровне прикладного кода, это надо поместить в открытую секцию.


Не базового класса процесса, а собственно процесса. Базовый класс процесса нужен для повышения эффективности и является "технологическим".


Это почему это? Процесс - это транспорт, который выполняет "транспортную" функцию. А уж чем его загрузишь, то он и повезёт. Отождествлять грузовик с перевозимым грузом, является, имхо, не очень удачной идеей.


А если этот процесс не только обслуживает индикацию, но и, например, клавиатуру опрашивает? Что мешает на одном "автобусе" катать и пионеров, и бабушек? По моему опыту, как раз-таки, нередко один процесс обслуживает более, чем одну сущность.



Вы путаете declaration (объявление) и definition (определение). Также вы путате явную (explicit) специализацию и полную (full) специализацию. Приведённый вами пункт стандарта гласит о том, что если используется явная специализация, то она должна быть объявлена в том же простанстве имён. Но где там сказано, что на должна быть определена в этом пространстве имён? У нас там нигде явной специализации не объявляется.


А этот код - это определение полной (а не объявление явной) специализации функции. Т.ч. всё в порядке, ничего компилироваться не перестанет, пусть там копиляторы хоть подтянутся, хоть отожмутся.

Ладно, раз уж у Гарри такая идиосинкразия к этому варианту, то давайте сделаем его расширением. Я попробовал, оказывается это работает точно так же
Вот, приаттачу пока сюда, а на днях выложу в репозиторий (Уж здесь-то, я думаю, возражений не последует?).
 CustomProcess.h.zip ( 634 байт ) Кол-во скачиваний: 152

И ещё попробую сделать вариант с нестатическим exec(). Тоже в виде расширения. Чтоб уж совсем была инкапсуляция

Давайте только определимся -- грузовик или автобус. И если таки грузовик, то для бабушек с пионерами придётся рядом поставить телегу с креслами и на верёвочке к грузовику прицепить.
Хотя нынешний процесс -- скорее шасси, на которое можно пассажирскую газельку навесить, можно бортовую. Предлагается только вариант на шлее тянуть за этим шасси телегу.

Ну да. Только я считаю абсолютно полноправным (равноправным с другими) вариант
И не считаю, что всегда и везде единственно правильно


Может, я наглухо испорчен борландсишным
но мне это не кажется настолько ненормальным, что нельзя это добавить в саму ОС. Другое дело, если бы это ломало все существующие наработки, но оно же прозрачно для старых проектов.
И не у меня последнего такая хотелка, как видим.

Э-э, мы, вроде, договорились, что если реализация не страдает, то принимаем. Т.ч. это можно не расширением, а основным вариантом делать. Клади в trunk, попробуем при случае.


Да, скорее просто платформа для перевозки. Проблема в том, она не очень хорошо переделывается ни в полноценный грузовик, ни в автобус (из-за статика).


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

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


Ну, с методами (виртуальными функциями) в борланде всё понятно - там-то это как правило именно тред - поток управления, который имеет начало и конец - вызвали его, он отработал и кончился. И тут нужна гибкость при вызове, чтобы можно строить элегантные схемы с обработкой - вызывать автоматом нужный в каждом контексте метод. Это не про нас.

Что касается самой схемы передачи типа объекта аргументом шаблона, который участвует в наследовании, то это основа для создания стратегий (Александреску). Это достаточно глубокая вещь. В данном же случае это просто синтаксический выверт, и как ты выражаешься: "страдает моё чувство прекрасного". Но как уже сказал выше, раз с совместимостью и кодогенерацией никаких проблем нет, пусть будет этот вариант, если он кому-то больше нравится (хотя я не вижу, повторяю, в этом особого смысла - инкапсулированного объекта не получается, придётся руками объявлять все поля-данные вне пределов класса и т.д.).

На самом деле на этот пункт стандарта я вышел погуглив сообщение об ошибке. К сожалению, из той цитаты, что я привёл, действительно не ясно насчёт определения ф-ции.
В общем, задал вопрос на RSDN: http://www.rsdn.ru/forum/cpp/4963144.all. Там есть спецы, знающие стандарт наизусть

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