А можно подробнее про эти транзакции? Это транзакции на запись или запросы только на чтение тоже включены сюда? Если это все вместе, каково примерно соотношение записи и чтения?
Все правильно, все справедливо. Список односвязный, как и показано на первой картинке.
В C++ можно передать кастомный аллокатор, если нет желания использовать дефолтный.
Это можно сделать штатно в Rust, но в разбираемых примерах штатный механизм работы с памятью вообще не задействован. В рамках такого подхода невозможного мало, за исключением:
Вместо этой строки должен быть растовый аналог std::aligned_storageT, а в методе push — perfect forwarding аргументов.
Пробросить параметры конструктора и собрать объект по нужному месту — нет, так нельзя. Даже в кучу поместить, гарантированно минуя стек, можно только в "ночной версии". В ряде случаев компилятор соптимизирует Box::new::(), конечно.
Собственно, как я говорил, если рассматривать Rust как "замену", то это скорее "замена" языка C, чем C++.
Задача была в следующем, мы должны спроектировать нотификейшн систем, который отправлял бы нотификейшены, когда его об этом будут просить сторонние сервисы.
Можно более подробно про условия задачи? Также не очень понятны требования:
Это хороший подход — договориться про определения.
Нестабильный код (или unstable feature) требует особой версии компилятора — альфа, ночная и прочая. Стабильной версией (release, production) нестабильный код компилироваться не должен. Вкратце эти тезисы излагал тут.
Такого нет, конечно — в плюсах отсутсвует явный механизм индикации нестабильности чего-то и явное разделение на стабильный-ночной версии компилятора. Только нестабильные штуки из реализации std от этого не пропадают,
Вообще, это означает, что "нестабильных штук" там нет, т.е. можно взять компилятор и скомпилировать к нему библиотеку.
Есть "нестандартные штуки", т.е. другим компилятором эта библиотека может не скопилироваться.
Вот, например, если я знаю, что последний элемент типа T это массив, то могу ли я добавить в malloc некоторое количество элементов для него?
Можно глянуть на код для С?
Мощь Rust я понимаю больше как гарантию отсутствия race conditions в сложном многопоточном коде.
Что насчет автоматического освобождения ресурсов, обобщенных типов, контроля за явной инициализацией всех полей структур, решения проблемы висячих ссылок? Еще есть такая приятная мелочь как "каждое значение имеет одного и только одного владельца-переменную".
КМК и вне рамок многопоточности тут много "плюшек".
В таких вопросах очень полезны базовые познания как в ассемблере так и в технологиях получения этого ассемблера из исходников.
Сибираюсь "черкнуть" пару статей про обобщенные типы в Go, там этот вопрос будет рассматриваться.
Добавил разделители для удобства. Хотя это уже "подделка данных".
Интересно, а почему не использовать терминологию Microsoft?
Очень интересно! А каков профиль нагрузки в плане соотношения чтение/запись и сколько/какого "железа" под эту нагрузку выделено?
Выходит, 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++.
Пока рассматриваем стабильный из С.
Пример по ссылке компилируется.
Нестабильный компилироваться не должен.