Если вы про мобильный UI, то, я подозреваю, стиль бын бездумно слизан всеми у Apple ещё несколько лет назад.
Telegram хочет привязку к номеру телефона, что не подходит мне по ряду причин.
С моей т.з. у std::optional один небольшой недостаток. Нет поддержки sentinel value, т.е. когда какое-то значение исходного типа считается nothing. Это позволило бы, к примеру, паковать указатели или сырые хендлы из сторонних библиотек без дополнительного флага, а следовательно совместимо по бинарному представлению с исходным типом. Как следствие — можно было бы делать красивый интерфейс для низкоуровневых библиотек без доп. перепаковки памяти.
Было что-то по теме несколько лет назад, экспериментальная ось-гипервизор, где каждая программа крутится как независимый клиент.
У МС тоже был эксперимент с виртуализацией всего винапи на базе чуть меньше чем 300 системных вызовов.
Увы, для обоих случаев подробностей не помню и ссылки дать не могу.
Проблема старой как навоз мамонта системы безопасности КМК. Давно уже напрашивается система, при которой каждая аппликуха сидит в своей виртуализированной песочнице, думая, что она единственная и неповторимая на всём ПК.
Если вы про owned/notnull — они дают какую-то семантику только в паре со статическим чекером, который их понимает. Последний раз такой чекер был только в Visual Studio. Т.е. его работоспособность даже в VS Build Tools под вопросом. В целом же, как я вижу, С++ всё больше требуется отдельный независимый от компилятора DSL для описания статических проверок :)
В каждой шутке есть доля шутки. Указатели позволяют слишком много. Ссылки обрезаны по самое небалуйся. reference_wrapper имеет почти нужную семантику, но, как ни смешно, слишком длинное имя. А optional из стандарта не имеет sentinel value оптимизации, из-за чего проигрывает голым указателям и по размеру, и по совместимости. К тому же слишком "легко" превращается в голое значение. В общем не хватает чего-то вроде optional<ref<T>>, имеющего почти нулевой оверхед по сравнению с указателем (за вычетом ассёртов в отладочном режиме).
К сожалению, я так и не понял, чем две иерархии (иерархия модулей и иерархия компонентов модуля) лучше, чем просто иерархия модулей. Либо, модули здесь являются единицами дистрибуции. В таком случае это уже пакеты, в б/м общепринятой терминологии.
Вот мне немного отвлечённо интересно. LM, как я понял, не имеет ссейчас даже прототипа. Такими темпами можно и двигатель Алькубьерре запатентовать, благо рендеров в интернете завались.
Я вижу здесь проблему обнаружения символов между отдельными TU. Либо мы вводим "магическую видимость" как в Golang, либо скатываемся обратно к заголовкам, либо вводим по факту ту же полу-иерархию, как в предложении ATOM, только сбоку и своими словами. Не проще ли тогда взять одну концепцию, которая покрывает все эти случаи без дополнительных "танцев с бубном"?
Единственное, что пока выглядит неясным для простой иерархии — как будет выглядеть поиск по иерархии "пакета", без возможности обойти её и влезть в кишки.
// mod1.cpp
export double foo(int)
{
...
}
// mod2.cpp
export import "mod1.cpp";
// ... some other exports...
// main.cpp
import "mod2.cpp"; // you get both mod1.cpp and mod2.cpp exports
int main(int, char**)
{
...
}
Таким образом мы получаем более естественную и понятную структуру модулей, возможность сборки из одного файла, а также позволяем компилятору самому решать, что и как в процессе кешировать.
Я много раз пытался выяснить, в чём недостаток вышеуказанного подхода по сравнению с multi-TU modules. Но ответа, увы, так и не получил.
Ещё один возникший у меня вопрос — никак не покрывается экспортирование только отдельных членов структур и классов. Т.е. некий аналог C# internal.
antoshkka Может вы подскажете, где почитать, почему в текущем состоянии модулей 1 модуль может занимать несколько TU? В Another take on modules для взаимосвязи этих кусочков даже завели отдельную сущность, партишены. Не проще ли 1 модуль = 1 TU, с возможностью вложенности и реэкспорта?
Спасибо большое. А есть где-то более человеческое описание, с рассмотрением основных юз-кейзов?
И, к сожалению, вопрос с обсуждением остаётся открытым.
К слову, а модули не померли вообще? В соответствующей гугл группе мёртвая тишина уже с полгода как. Мои попытки спросить в общей группе isocpp привели к "иди в группу модулей". На заявку вступления в гугл-группу модулей я ответа так и не получил. Или там открытое обсуждение не приветствуется?
fixed
От "нововведений" за последние года 2-3 возникает стойкое ощущение WTF.
Если вы про мобильный UI, то, я подозреваю, стиль бын бездумно слизан всеми у Apple ещё несколько лет назад.
Telegram хочет привязку к номеру телефона, что не подходит мне по ряду причин.
Пусть сначала вернут отправку сообщений по Ctrl+Enter и нормальный вид UI. Интересно, какой кретин решил, что мобильный UI подходит для десктопа.
Диковатая мысль в голове — трансляция в WebAssembly. И тогда PHP начнёт просачиваться в браузеры :)
С моей т.з. у
std::optionalодин небольшой недостаток. Нет поддержки sentinel value, т.е. когда какое-то значение исходного типа считается nothing. Это позволило бы, к примеру, паковать указатели или сырые хендлы из сторонних библиотек без дополнительного флага, а следовательно совместимо по бинарному представлению с исходным типом. Как следствие — можно было бы делать красивый интерфейс для низкоуровневых библиотек без доп. перепаковки памяти.У МС тоже был эксперимент с виртуализацией всего винапи на базе чуть меньше чем 300 системных вызовов.
Увы, для обоих случаев подробностей не помню и ссылки дать не могу.
Это всё хорошо, но не описывает borrowed pointers и not-null pointers независимо от компилятора.
Если вы про owned/notnull — они дают какую-то семантику только в паре со статическим чекером, который их понимает. Последний раз такой чекер был только в Visual Studio. Т.е. его работоспособность даже в VS Build Tools под вопросом. В целом же, как я вижу, С++ всё больше требуется отдельный независимый от компилятора DSL для описания статических проверок :)
В каждой шутке есть доля шутки. Указатели позволяют слишком много. Ссылки обрезаны по самое небалуйся. reference_wrapper имеет почти нужную семантику, но, как ни смешно, слишком длинное имя. А optional из стандарта не имеет sentinel value оптимизации, из-за чего проигрывает голым указателям и по размеру, и по совместимости. К тому же слишком "легко" превращается в голое значение. В общем не хватает чего-то вроде
optional<ref<T>>, имеющего почти нулевой оверхед по сравнению с указателем (за вычетом ассёртов в отладочном режиме).К сожалению, я так и не понял, чем две иерархии (иерархия модулей и иерархия компонентов модуля) лучше, чем просто иерархия модулей. Либо, модули здесь являются единицами дистрибуции. В таком случае это уже пакеты, в б/м общепринятой терминологии.
О! А ссылочку можно? У меня в моём маленьком тулбоксе как раз есть такой велосипед!
Я вижу здесь проблему обнаружения символов между отдельными TU. Либо мы вводим "магическую видимость" как в Golang, либо скатываемся обратно к заголовкам, либо вводим по факту ту же полу-иерархию, как в предложении ATOM, только сбоку и своими словами. Не проще ли тогда взять одну концепцию, которая покрывает все эти случаи без дополнительных "танцев с бубном"?
Единственное, что пока выглядит неясным для простой иерархии — как будет выглядеть поиск по иерархии "пакета", без возможности обойти её и влезть в кишки.
Эмм… а почему не позволить иерархию модулей?
Таким образом мы получаем более естественную и понятную структуру модулей, возможность сборки из одного файла, а также позволяем компилятору самому решать, что и как в процессе кешировать.
Я много раз пытался выяснить, в чём недостаток вышеуказанного подхода по сравнению с multi-TU modules. Но ответа, увы, так и не получил.
Ещё один возникший у меня вопрос — никак не покрывается экспортирование только отдельных членов структур и классов. Т.е. некий аналог C# internal.
antoshkka Может вы подскажете, где почитать, почему в текущем состоянии модулей 1 модуль может занимать несколько TU? В Another take on modules для взаимосвязи этих кусочков даже завели отдельную сущность, партишены. Не проще ли 1 модуль = 1 TU, с возможностью вложенности и реэкспорта?
Спасибо большое. А есть где-то более человеческое описание, с рассмотрением основных юз-кейзов?
И, к сожалению, вопрос с обсуждением остаётся открытым.
К слову, а модули не померли вообще? В соответствующей гугл группе мёртвая тишина уже с полгода как. Мои попытки спросить в общей группе isocpp привели к "иди в группу модулей". На заявку вступления в гугл-группу модулей я ответа так и не получил. Или там открытое обсуждение не приветствуется?