А можно подробнее про эти транзакции? Это транзакции на запись или запросы только на чтение тоже включены сюда? Если это все вместе, каково примерно соотношение записи и чтения?
Все правильно, все справедливо. Список односвязный, как и показано на первой картинке.
В C++ можно передать кастомный аллокатор, если нет желания использовать дефолтный.
Это можно сделать штатно в Rust, но в разбираемых примерах штатный механизм работы с памятью вообще не задействован. В рамках такого подхода невозможного мало, за исключением:
Вместо этой строки должен быть растовый аналог std::aligned_storageT, а в методе push — perfect forwarding аргументов.
Пробросить параметры конструктора и собрать объект по нужному месту — нет, так нельзя. Даже в кучу поместить, гарантированно минуя стек, можно только в "ночной версии". В ряде случаев компилятор соптимизирует Box::new::(), конечно.
Собственно, как я говорил, если рассматривать Rust как "замену", то это скорее "замена" языка C, чем C++.
Задача была в следующем, мы должны спроектировать нотификейшн систем, который отправлял бы нотификейшены, когда его об этом будут просить сторонние сервисы.
Можно более подробно про условия задачи? Также не очень понятны требования:
Это хороший подход — договориться про определения.
Нестабильный код (или unstable feature) требует особой версии компилятора — альфа, ночная и прочая. Стабильной версией (release, production) нестабильный код компилироваться не должен. Вкратце эти тезисы излагал тут.
Такого нет, конечно — в плюсах отсутсвует явный механизм индикации нестабильности чего-то и явное разделение на стабильный-ночной версии компилятора. Только нестабильные штуки из реализации std от этого не пропадают,
Вообще, это означает, что "нестабильных штук" там нет, т.е. можно взять компилятор и скомпилировать к нему библиотеку.
Есть "нестандартные штуки", т.е. другим компилятором эта библиотека может не скопилироваться.
Вот, например, если я знаю, что последний элемент типа T это массив, то могу ли я добавить в malloc некоторое количество элементов для него?
Можно глянуть на код для С?
Мощь Rust я понимаю больше как гарантию отсутствия race conditions в сложном многопоточном коде.
Что насчет автоматического освобождения ресурсов, обобщенных типов, контроля за явной инициализацией всех полей структур, решения проблемы висячих ссылок? Еще есть такая приятная мелочь как "каждое значение имеет одного и только одного владельца-переменную".
КМК и вне рамок многопоточности тут много "плюшек".
Гм, а как вы в таком случае доверяете функциям выделения памяти в других языках?
Приходится именно что доверять, "гарантий" компилятора же нет. Понятно, что даже в случае наличия таковых встает вопрос о доверии самому компилятору, но тем не менее...
Вижу там агрегацию нескольких malloc в один, вижу там двусвязныё двусвязные циклические списки, где элемент может и не знать, в каком он контейнере расположен, или можно сказать, что он сам по себе контейнер.
Работу с памятью можно практически не менять, malloc — нет проблем.
res = libc::malloc(std::mem::size_of::<T>()) as *mut T;
И понимаю, что это надо переписывать как-то совершенно по-другому.
Чтобы задействовать всю мощь Rust надо, действительно, писать несколько иначе. Но можно оставаться и во вполне "сишных" рамках, почему нет. Бонусом будет кросс-компиляция "из-коробки", для embedded скорее всего надо будет побороться с размером исполняемого модуля, недавно была статья по этой теме.
Выходит, 10 операций в секунду на ядро?
А можно подробнее про эти транзакции? Это транзакции на запись или запросы только на чтение тоже включены сюда? Если это все вместе, каково примерно соотношение записи и чтения?
Пример с деструктурирующим присваиванием я бы переписал в таком песочницо-компилируемом виде:
Не уловил, что изменилось — было два смежных ДЦ, оба загорелись, а теперь ситуация какова?
Как быть с тем, что на море эта иллюзия наблюдается тоже, хотя домов в поле зрения нет?
Не понял, почему наблюдатель для угла D находится ближе к Солнцу, чем для D'?
Все правильно, все справедливо. Список односвязный, как и показано на первой картинке.
Это можно сделать штатно в Rust, но в разбираемых примерах штатный механизм работы с памятью вообще не задействован. В рамках такого подхода невозможного мало, за исключением:
Пробросить параметры конструктора и собрать объект по нужному месту — нет, так нельзя. Даже в кучу поместить, гарантированно минуя стек, можно только в "ночной версии". В ряде случаев компилятор соптимизирует
Box::new::()
, конечно.Собственно, как я говорил, если рассматривать Rust как "замену", то это скорее "замена" языка C, чем C++.
Можно более подробно про условия задачи? Также не очень понятны требования:
Я разве написал, что он должен заработать? В цитате этого нет. В цитате есть "Попробуем".
Тут странно. Я вижу такое:
И это работает, по крайней мере, тут.
Давайте так поступим — процитируйте какое-либо мое утверждение из статьи и далее я поясню его, если это нужно.
Это хороший подход — договориться про определения.
Нестабильный код (или unstable feature) требует особой версии компилятора — альфа, ночная и прочая. Стабильной версией (release, production) нестабильный код компилироваться не должен. Вкратце эти тезисы излагал тут.
Вообще, это означает, что "нестабильных штук" там нет, т.е. можно взять компилятор и скомпилировать к нему библиотеку.
Есть "нестандартные штуки", т.е. другим компилятором эта библиотека может не скопилироваться.
typedef signed int __int32_t;
? — Нет.Это все компилируется стабильным компилятором
https://godbolt.org/z/8qEezhbch
Меня интересуют примеры, когда для компиляции стандартной библиотеки надо включить "ночную" опцию у компилятора.
Это разве был интересующий пример нестабильного C++ в стандартной библиотеке C++?
Чем же лучше версия на Rust:
?
Можно глянуть на код для С?
Что насчет автоматического освобождения ресурсов, обобщенных типов, контроля за явной инициализацией всех полей структур, решения проблемы висячих ссылок? Еще есть такая приятная мелочь как "каждое значение имеет одного и только одного владельца-переменную".
КМК и вне рамок многопоточности тут много "плюшек".
Вот это взорвется? https://www.onlinegdb.com/vmdoJZFgL
Поясните, из-за чего?
Вообще меня интересовали примеры нестабильного C++ в стандартной библиотеке C++.
Пока рассматриваем стабильный из С.
Пример по ссылке компилируется.
Нестабильный компилироваться не должен.
В целом мотивация упрятать нестабильный box внутрь Box понятна, тут вопросов нет.
Нет возражений также считать код Box "надёжным", в том смысле, в каком "надёжен" код на любом ЯП — не меньше, но и не больше.
PS. Для саморазвития — можно глянуть на примеры нестабильного C++ в стд C++?
Приходится именно что доверять, "гарантий" компилятора же нет. Понятно, что даже в случае наличия таковых встает вопрос о доверии самому компилятору, но тем не менее...
На картинке скорее односвязный список с локальными "побегами" одиночной длины.
Как могут гарантии стабильного компилятора распространяться на то, что не компилируется?
Работу с памятью можно практически не менять, malloc — нет проблем.
Чтобы задействовать всю мощь Rust надо, действительно, писать несколько иначе. Но можно оставаться и во вполне "сишных" рамках, почему нет. Бонусом будет кросс-компиляция "из-коробки", для embedded скорее всего надо будет побороться с размером исполняемого модуля, недавно была статья по этой теме.