Чем заменить указатель

Чем заменить можно указатель в данном примере. Что бы можно было использовать p как объект без операции разыменования?
Добавлено через 6 минут
подозреваю, что использовать указатель в данном случае оптимальное и единственное решение, можно было бы использовать ссылку Container & если бы не было функции члена Reset

0

Сообщение от _stanislav подозреваю, что использовать указатель в данном случае оптимальное и единственное решение, можно было бы использовать ссылку Container & если бы не было функции члена Reset

Правильно подозреваешь, так и есть.
А смысла заменять на что-то - нет. Единственное, что можно придумать (ну, кроме удаления, std::unique_ptr, который здесь не нужен), это переопределённый оператор -> который будет вызывать исключение, в случае nullptr. Но я бы не стал так делать.

0

Сообщение от _stanislav Чем заменить можно указатель в данном примере. Что бы можно было использовать p как объект

Только рукописной оболочной над указателем, которая переимплементирует все до единого методы Container (т.е. объявляет все эти методы и делегирует их в указатель). Получится что-то вроде узкоспециализированного std::reference_wrapper.

Неясно только, зачем такая фигня понадобилась.

0

Сообщение от TheCalligrapher Неясно только, зачем такая фигня понадобилась.

фигня в смысле функция член Reset? или заменять указатель.

Добавлено через 7 минут
SomeСlass принимает буфер по ссылке что бы не перемещать и не копировать, он еще его чистит, и принимает следующую порцию данных при вызове Reset.

Добавлено через 11 минут

Сообщение от oleg-m1973 Правильно подозреваешь, так и есть. А смысла заменять на что-то - нет.

Сообщение от TheCalligrapher Только рукописной оболочной над указателем

Спасибо за ответ.

0

Сообщение от _stanislav фигня в смысле функция член Reset? или заменять указатель.

Фигня в смысле: зачем нужно работать как будто напрямую с обычным объектом? Почему бы не работать как с указателем, т.е. через ->?

0

Сообщение от TheCalligrapher зачем нужно работать как будто напрямую с обычным объектом? Почему бы не работать как с указателем

не нужно, дошло до меня.

Добавлено через 1 минуту
Я слегка поддался гипнозу, что сырые указатели это плохо.

0

Сообщение от _stanislav можно было бы использовать ссылку Container & если бы не было функции члена Reset

Ну так убери ф-цию Reset ...

0

Сообщение от Avazart Ну так убери ф-цию Reset

а как тогда указатель переназначить?

0

Сообщение от _stanislav подозреваю, что использовать указатель в данном случае оптимальное и единственное решение,

да. единственное и оптимальное.

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

конструктор:

Сообщение от _stanislav SomeСlass() : p{nullptr} {}

намекнёт проницательному читателю,
что ресурса может и не быть.

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

Сообщение от _stanislav а как тогда указатель переназначить?

если нужно перенацеливать - значит нужен указатель.
ссылку нельзя перенацелить.

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

вкратце суть:
объект, который был рожден константным не должен быть изменен.
модификация такого объекта - UB.

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

рассмотрим класс:

компилятор может реализовать член-данных, как указатель:

обрати внимание: константный указатель.
правила языка запрещают перенацеливать ссылку.
поэтому, ассоциированный с нею указатель неизменяемый.


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

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

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

0

_stanislav,
Скажу что конструктор который принимает ссылку и берет адрес исходного объекта не очень хорошо выглядит в плане архитектуры потому что такой подход заставляет больше напрягаться при разработке и вот почему:

работа с экземпляром класса SomeСlass всегда подразумевает то, что всегда нужно держать в голове время жизни объекта типа Container от которого зависит SomeСlass.

Так же напрягает что можно сделать так: SomeСlass obj(container) и как бы не глядя в исходники не совсем понятно насколько объекты типа SomeСlass и container независимы друг от друга в плане lifetime. Если производительность не критична и нужен именно такой подход (агрегация) то предлагаю заменить обычный указатель на shared_ptr или weak_ptr в зависимости от того что нужно в конечном счете. Если будет shared_ptr, то пока экземпляр SomeСlass еще не протух, container-ом можно будет пользоваться внутри SomeСlass. Если же это будет weak_ptr, то его всегда можно проверить на предмет "а не протух ли объект, на который мы ссылаемся?" и если протух, то например бросить эксепшен. Так будет безопаснее.

Не знаю конечно что за задача, но все же решил сказать об этом т.к это может пригодится.

0

_stanislav, я может что-то не понял, а без указателя нельзя реализовать?
Ну и проверять size очереди при необходимости.

0

n1b1ru,
тогда будет срабатывать оператор присваивания копированием (к чему лишние копии?)
вот тут p = r;

Добавлено через 6 минут
а тут конструктор копирования для Container... SomeClass(Container& r) : p{r}

0

Сообщение от Undisputed Скажу что конструктор который принимает ссылку и берет адрес исходного объекта не очень хорошо выглядит в плане архитектуры потому что такой подход заставляет больше напрягаться при разработке и вот почему:

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

Сообщение от Undisputed предлагаю заменить обычный указатель на shared_ptr

глупое предложение.

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

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

0

hoggy,
По поводу string_view думаю что все таки это плюсы, и очень часто стандартные фичи не обвязаны какими то дополнительными проверками, что бы не было оверхеда.

По поводу shared_ptr: в данном случае явно видно что объект на который есть ссылка внутри SomeClass может быть использован и за пределами SomeClass и SomeClass не контролирует его lifetime. В таком случае это как раз тот случай когда мы share-им обьект между принципиально двумя разными контекстами... То есть в данном случае используется агрегация.

В целом как уже говорил я не знаю что за задача. То о чем я говорю просто более безопасный вариант (смысл этой безопасности описывал выше)

0

Сообщение от Undisputed По поводу string_view думаю что все таки это плюсы, и очень часто стандартные фичи не обвязаны какими то дополнительными проверками, что бы не было оверхеда.

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

дело не в "дополнительных проверках".
ты можешь реализовывать какие угодно проверки.

дело в здравом смысле.

Сообщение от Undisputed По поводу shared_ptr: в данном случае явно видно что объект на который есть ссылка внутри SomeClass может быть использован и за пределами SomeClass.

ты передаешь объект по ссылке.
итак понятно, что он может быть использован за пределами SomeClass

Сообщение от Undisputed В таком случае это как раз тот случай когда мы share-им обьект между принципиально двумя разными контекстами...

нефига подобного.


любая с++ архитектура в конечном счете даёт ответы на два фундаментальных вопроса:
1. кто о ком знает?
2. кто кем владеет?

ну так вот.
есть класс, который принимает объект по ссылке (указателю).
тобишь, он не владеет ресурсом, но хочет им пользоваться.

и вот здесь у тебя есть только два варианта:

1.
ты считаешь нормальной ситуацию,
когда к моменту эксплуатации ресурса, выясняется, что ресурс протух.

например: пришел запрос от юзера. смотрим:
если сессия протухла, тогда заново просим его авторизоваццо.
иначе - работаем с уже имеющейся сессией.

в этом случае ты используешь связку shared/weak

2.
ресурс априори должны быть валидным.
ситуация, когда он нужен, а он внезапно протух - это программная ошибка.
в этом случае weak тебя не спасет.

Сообщение от Undisputed В целом как уже говорил я не знаю что за задача.

но ты знаешь, что человек изначально не использовал shared/weak.
из чего не сложно сделать вывод: шаринг ему без надобности.
из чего не сложно сделать вывод: у него 2й вариант.
из чего не сложно сделать вывод: weak ему не нужен.

Добавлено через 3 минуты

Сообщение от Undisputed То о чем я говорю просто более безопасный вариант

допустим ты поюзал weak.
и узнал что ресурс протух.
этого не должно было быть.
у тебя баг в коде.

и куда смотрела твоя служба безопасности?

0

Да не особо понятно как SomeСlass, Container ведут/используются после создания/задания так что о shared_pointer рано судить.

Добавлено через 2 минуты

Сообщение от _stanislav а как тогда указатель переназначить?

Никак. Создать новый SomeСlass для нового Container-ра.

0

hoggy,
Да, проверки есть но нужно так же признать что они есть не везде. Где то они (проверки) могли бы добавить безопасности, но отсутствуют (в этом смысле имею ввиду). Например в std::stack:op не делается проверка на то что есть ли элемент в стеке или нет. Это как бы оставляют на конечного пользователя тем самым не создают оверхед но при этом оставляют конечному пользователю возможность сделать эту проверку самому хотя они могли бы например возвращать bool как результат операции удаления типа удалилось или нет и не вводить UB если контейнер окажется пустым (вот что я имел ввиду когда говорил про оверхед при навязывании безопасного обращения с объектами).

Что касается того что "ресурс всегда должен быть валидным когда он нужен и если его нет то это программная ошибка и weak_ptr не поможет" то тут я не согласен. Мы ведь может вызвать use_count для weak_ptr при уничтоженном объекте на который был нацелен соответствующий shared и это не будет UB и никаких программных ошибок не будет. Если use_count == 0, можем бросить эксепшен.

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

0

Сообщение от Undisputed Где то они (проверки) могли бы добавить безопасности, но отсутствуют (в этом смысле имею ввиду).

Безопасность как бы ценой производительности не С++ - путь. Но вообще все зависит задачи.

0

Undisputed, если указатель не nullptr то он валидный, остается только перед использованием проверить
queue::empty

0

Avazart,
Да, вот именно это я и имел ввиду про безопасность, что в С++ этим особо не балуются в угоду производительности

_stanislav,
тогда норм, значит то о чем я говорил это не твой случай

0