Ну может быть по этому автор и остановился именно на коротких фрагментах детских сказок? Хотя с другой стороны, текст для контента 18+ не так уж и важен :-)
Мало того, я таки решил сделать прототип первой версии публичной базы знаний. Для этого специально пошел учиться на курсы fullstack-developer. Планирую на диплом реализовать именно прототип этой системы.
Может лучше было начать с того, чтобы изучить уже существующие аналогичные решения??
Смысл в том, чтобы программист думал там, где компьютер (компилятор) не сможет сделать правильно без его участия. Если не нужно шарить ссылку, создавай ссылку без возможности шаринга, и компилятор именно это и будет проверять.
Да, все так. Только для межпотокового взаимодействия требуется не счетчик, а объект синхронизации (если мы говорит об этом). А так да, счетчик является встроенным в механизм управления ссылками и работа с с ним происходит автоматически.
Просто я не могу придумать ситуации, когда есть расшаренный между потоками объект (точнее ссылка), но объект синхронизации доступа отсутствует.
Раз вы не можете вернуть контейнер, значит его нужно передать снаружи, как аргумент при вызове функции. Этот объект-контейнер будет более высокого уровня, а значит сможет (по правилам синтаксиса) содержать сами объекты, а не только слабые ссылки.
return head // или что тут у вас надо написать, *head?
Да, этим вы возвращаете сильную ссылку, а фактически владельца объекта или std::move, если так будет проще.
Но в этом случае вы можете вернуть только объект head, а вот ссылка на tail протухнет, так как владельцем объекта является локальная переменная, которая к моменту возврата из функции уже будет освобождена, так как закончится её область действия.
UPD. Тут скорее всего нужно создавать какой нибудь контейнер для хранения всех листьев списка и возвращать по значению именно его, а не отдельный элемент.
Нет, не стоит, так как это объекты одного уровня и ссылка может быть только слабой.
prev удаляется и получается dangling pointer
Вы возвращаете из функции ссылку на локальную переменную, поэтому это действительно dangling pointer. Вот только для получения данных указателя по правилам синтаксиса вам необходимое его "захватить" (оператор "звездочка"), т.е. превратить weak_ptr в shared_ptr. Поэтому тут у вас ошибка в логике, а при работе с памятью ошибки не будет.
Хотя такие логические ошибки легко выявлять во время анализа AST, так что скорее всего эта ошибка будет выявлена еще на этапе компиляции.
Мощность подключения по любому ограничена (проводка, подвод, мощность подстанции и т.д.).
Они еще и не то могут :-)
Ну может быть по этому автор и остановился именно на коротких фрагментах детских сказок?
Хотя с другой стороны, текст для контента 18+ не так уж и важен :-)
Ну так может тогда и напишите, чем же ваша супер программа для ведения базы знаний лучше, чем все остальные?
В поиске забанили?
https://yandex.ru/search/?text=база+знаний
https://www.google.ru/search?q=база+знаний
Может лучше было начать с того, чтобы изучить уже существующие аналогичные решения??
В другом месте, если я покупаю именно новый диск, то я его сразу верну продавцу.
Сломаются как раз в тот момент, когда бекап действительно будет нужен?
Это же б/у диски после майнинга. Вы уверены, что хороша идея покупать подобные диски?
Могли движок позже взять, как огнелис, например.
Вот так?
Странным для не новичка является путать номер элемента с его индексом (смещением элемента относительно начала массива).
Еще бывает и дробный голос :-)
Смысл в том, чтобы программист думал там, где компьютер (компилятор) не сможет сделать правильно без его участия. Если не нужно шарить ссылку, создавай ссылку без возможности шаринга, и компилятор именно это и будет проверять.
Да, все так. Только для межпотокового взаимодействия требуется не счетчик, а объект синхронизации (если мы говорит об этом). А так да, счетчик является встроенным в механизм управления ссылками и работа с с ним происходит автоматически.
Просто я не могу придумать ситуации, когда есть расшаренный между потоками объект (точнее ссылка), но объект синхронизации доступа отсутствует.
Это как раз самое простое. Самое сложное, это записать нужный алгоритм в семантике языка, а потом искать и исправлять ошибки.
Обязательно! Более того, я хочу сделать полный контроль ссылок, включая автоматическую межпотоковую синхронизацию, поэтому Rust в любом случае не получится :-)
Раз вы не можете вернуть контейнер, значит его нужно передать снаружи, как аргумент при вызове функции. Этот объект-контейнер будет более высокого уровня, а значит сможет (по правилам синтаксиса) содержать сами объекты, а не только слабые ссылки.
Да, этим вы возвращаете сильную ссылку, а фактически владельца объекта или std::move, если так будет проще.
Но в этом случае вы можете вернуть только объект head, а вот ссылка на tail протухнет, так как владельцем объекта является локальная переменная, которая к моменту возврата из функции уже будет освобождена, так как закончится её область действия.
UPD. Тут скорее всего нужно создавать какой нибудь контейнер для хранения всех листьев списка и возвращать по значению именно его, а не отдельный элемент.
Нет, не стоит, так как это объекты одного уровня и ссылка может быть только слабой.
Вы возвращаете из функции ссылку на локальную переменную, поэтому это действительно dangling pointer. Вот только для получения данных указателя по правилам синтаксиса вам необходимое его "захватить" (оператор "звездочка"), т.е. превратить weak_ptr в shared_ptr. Поэтому тут у вас ошибка в логике, а при работе с памятью ошибки не будет.
Хотя такие логические ошибки легко выявлять во время анализа AST, так что скорее всего эта ошибка будет выявлена еще на этапе компиляции.