Здравствуйте, AeroSun, Вы писали:
AS>Вот к примеру из моего недавнего: делаю крипто библиотеку, нужен контейнер (вектор/дек/строка) который ведёт себя полностью как стандартный. Необходимое условие — при умирании объекта он обязан затереть свою память.
AS>Так вот в текущих плюсах с текущей стандартной библиотекой эта задача не решаема без костылей.
1. Кастомный аллокатор, который затирает память, которую высвобождает.
2. Кастомный delete/placement delete для самих объектов, который затирает память, которую высвобождает.

Здравствуйте, AeroSun, Вы писали:
AS>Перефразирую вопрос: где кроме embeded нужен SSO?
SSO — это не только память, но и отсутствие обращения к куче. А доступ к ней синхронный из разных потоков. Больше обращений — меньше параллелизма.

Здравствуйте, AeroSun, Вы писали:

AS>Вот к примеру из моего недавнего: делаю крипто библиотеку, нужен контейнер (вектор/дек/строка) который ведёт себя полностью как стандартный. Необходимое условие — при умирании объекта он обязан затереть свою память.

Каждый элемент контейнера должен в деструкторе затирать свою память. Да, писанины много, но секьюрный байт и просто байт — это два разных типа.

ЗЫ А если включить режим паранойи, то вообще никакие данные не должны находится в памяти в расшифрованном виде — у каждого байта должен быть метод выдающий своё нешифрованное значение...

Здравствуйте, AeroSun, Вы писали:

skip

AS>Вот к примеру из моего недавнего: делаю крипто библиотеку, нужен контейнер (вектор/дек/строка) который ведёт себя полностью как стандартный. Необходимое условие — при умирании объекта он обязан затереть свою память.

skip

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

Здравствуйте, Marty, Вы писали:

M>Здравствуйте!

M>Хочу вот сделать свой класс строк, который предоставляет всё то, что даёт std::basic_string. Вот буквально пару методов добавить, при том, что всё новое будет работать через методы std::basic_string'а.

M>Отнаследоваться от std::basic_string'а, или сделать его членом класса, и написать/скопировать простыню делегирования?

M>В чем подводные камни?

Вообще конечно было бы неплохо узнать, что это за пара методов. Но как по мне, так однозначно надо делать пару свободных функций. Можешь засунуть их в какой-нибудь "namespace my_string_utils".

Почему не стоит делать свой класс строки. Просто потому что мы всё это лет 15 назад проходили. Когда-то каждый программист считал, что он просто обязан написать свою лучшую в мире реализацию строки. Мало того тогда еще все бибилиотеки и фреймворки имели свою реализацию строки. Помните AnsiString, CString, QString и др. Всех их вообще было довольно просто преобразовать друг в друга, но все равно приходилось очень много трахаться чтобы интегрировать разные части кода.
Потом вроде наконец то все стали использовать стандартный std::string или const char* (сейчас правда еще string_view появился, зоопарк растет), и все более менее довольны. Но многим по прежнему хочится написать свою новую молодежную реализацию класса строки. Главный подводный камень, что никому твой класс строки будет не нужен, и если кто-то будет юзать твой код, первое что он сделает, это попытается преобразовать твою строку во что-то стандартное, с чем он знает как работать. Даже если твоя строка будет всего лишь оберткой над стандартной, тебе все равно придется передавать ее в свои функции, чтоб использовасть новый функционал, то есть ты полностью привяжешь свой код к новой строке, либо ты весь код должен сделать шаблоном, что то еще удовольствие.

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

Здравствуйте, ksandro, Вы писали:

K>Вообще конечно было бы неплохо узнать, что это за пара методов.

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


K>Но как по мне, так однозначно надо делать пару свободных функций. Можешь засунуть их в какой-нибудь "namespace my_string_utils".

Свобоных функций и так масса понаделана, но самые употребимые хочется запихать в строку


K>Почему не стоит делать свой класс строки. Просто потому что мы всё это лет 15 назад проходили. Когда-то каждый программист считал, что он просто обязан написать свою лучшую в мире реализацию строки. Мало того тогда еще все бибилиотеки и фреймворки имели свою реализацию строки. Помните AnsiString, CString, QString и др. Всех их вообще было довольно просто преобразовать друг в друга, но все равно приходилось очень много трахаться чтобы интегрировать разные части кода.

Дело не в преобразовании, а в том, что все эти AnsiString, CString, QString — они отличаются интерфейсом от std::string. Вот сейчас QString вроде бы привели к более или менее совместимому с std::string виду, и получается обычно писать код, который работает и с std::string и с QString, но, сцуко, они не сделали метод empty(), есть только isEmpty.


K>Потом вроде наконец то все стали использовать стандартный std::string или const char* (сейчас правда еще string_view появился, зоопарк растет), и все более менее довольны. Но многим по прежнему хочится написать свою новую молодежную реализацию класса строки. Главный подводный камень, что никому твой класс строки будет не нужен, и если кто-то будет юзать твой код, первое что он сделает, это попытается преобразовать твою строку во что-то стандартное, с чем он знает как работать. Даже если твоя строка будет всего лишь оберткой над стандартной, тебе все равно придется передавать ее в свои функции, чтоб использовасть новый функционал, то есть ты полностью привяжешь свой код к новой строке

Для своего кода — это не проблема


K>либо ты весь код должен сделать шаблоном, что то еще удовольствие.

А какие проблемы? У меня большая часть кода — шаблонная


K>Мой тебе совет, не знанимайся фигней, сделай просто пару свободных функций, иначе потом будешь очень долго мучиться.

У меня этих свободных функций уже 100500, и я уже долго мучаюсь