при этом /EHsc является основной практической настройкой

в данном примере такое ощущение, будто компилятор опасается выброшенного исключения при {} - инициализации структуры с size_t

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

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

Да, там Саттер прорабатывает более общее решение, но оно весьма противоречивое

на объекты бы повесить те же штуки что и на функции

в общем, категорически рекомендую добавлять /EHsc при проверке тех или иных решений для msvc

потому что может приводить к полному сбою всей оптимизации

на объекты бы повесить те же штуки что и на функции

хотяб для инициализации

хотяб для инициализации

а хотя не уг какоето

слишком жирно

на объекты бы повесить те же штуки что и на функции

Тогда можно получить javascript с вечной проблемой утекающей в непонятном месте памяти

тогда сломается void foo(string_view sw); foo(string{"Hello word!"}); // OK, right now

а почему надо держаться за этот кейс?

да ну его

го писать на го - тупо же звучит, поэтому и не пишет :D

ага, да и к тому же я ж уже так шутил)

а почему надо держаться за этот кейс?

это популярный и нормальный кейс В Boost его попробовали убрать, и поломался весь пользовательский код

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

а почему надо держаться за этот кейс?

В более вменяемом виде он выглядит как void foo(string_view sw); string bar(); foo(bar()); // OK, right now

ok

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

я плохо понимаю, зачем

нужно просто нормально написать для всяких std::vector::operator [] ref-quailifier

ну вон там стрингвью

@antoshkka так, а прострел ноги в том, что ...? ну, передали в std::string_view временный объект, который будет жить до конца полного выражения. ну передали в функцию. функция же не дура сохранить где-то std::string_view и использовать после.

в string_view нужно запретить вообще временные объекты передавать)

просто какбы у stringview семантика ссылки неявная

и вроде хранить можно изза этого

я бы сказал, что в C++ есть чудесная проблема преобразования && в const&

в string_view нужно запретить вообще временные объекты передавать)

выше пример

даже 2 или 3

а почему просто не написать: operator string_view() const noexcept & ;

потому что && можно в const& преобразовать

const& сигнатура аналогична const

operator string_view() noexcept & должно быть

string_view это принципиально & тип, насколько я понимаю, он не может захватить владение

operator string_view() noexcept & должно быть

Это всё равно не 100% гарантия string_view sw; { string s{"hello word. hello word. hello word. hello word. hello word. "}; sw = s; } std::cout << sw; // Oops!

Это всё равно не 100% гарантия string_view sw; { string s{"hello word. hello word. hello word. hello word. hello word. "}; sw = s; } std::cout << sw; // Oops!

По моему текущего мнению все хорошо, если считать 1. Объект & живет минимум scope выше чем оператор, и только с него можно снимать view 2. Объект && живет оператор

Т.е. если я создаю или присваиваю view-объект с нарушением правил жизни, я сам буратино

Хотя я предпочел бы иметь view-объекты немутабельными

Как &

Enter Rust

По моему текущего мнению все хорошо, если считать 1. Объект & живет минимум scope выше чем оператор, и только с него можно снимать view 2. Объект && живет оператор

Вроде как в этих правилах все хорошо, если view объект создается из объекта &, потому что переданный объект гарантированно живет в scope, в котором объявлен view-объект

Это всё равно не 100% гарантия string_view sw; { string s{"hello word. hello word. hello word. hello word. hello word. "}; sw = s; } std::cout << sw; // Oops!

я поэтому и сказал что это костыль

ну там не нужна гарантия

давайте оставим как есть

По моему текущего мнению все хорошо, если считать 1. Объект & живет минимум scope выше чем оператор, и только с него можно снимать view 2. Объект && живет оператор

Из этого вытекает правило при возврате & использовать & как ref qualifier и все еще все хорошо

Ну кроме того, что && конвертируемо языком в const& и это все ломает

я поэтому и сказал что это костыль

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

ну раст +- говорят чекает хотя я не проверял

на явных штуках наверное

да раст небось заставит тебя доказывать что объект не сдохнет

да раст небось заставит тебя доказывать что объект не сдохнет

меня нет, а вот тебя заставит

меня нет, а вот тебя заставит

?

удобно вот так хейтить то сразу, да?

удобно вот так хейтить то сразу, да?

речь же про пример когда это утверждение неверно)

я предполагаю ошибку вроде "I'm not sure this reference is not dead, gimme the prove"

я предполагаю ошибку вроде "I'm not sure this reference is not dead, gimme the prove"

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

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

там выше пример Антона, string_view присваивается с нарушением scope

ну в расте если функция консьюмит этот стринг вью, то bar(foo()) валиден - bar заберет ownership себе и спокойно внутри себя похоронит

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

а, ну собсно borrow будет на время вызова, а потом дропнется

ну в расте если функция консьюмит этот стринг вью, то bar(foo()) валиден - bar заберет ownership себе и спокойно внутри себя похоронит

а как это реализовано? тут же с точки зрения плюсов шаблонная функция bar() должна быть, либо она должна значение получать

если ты передаешь значение то оно консьюмится

let a = "foo"; g(&a); // g сжирает &a f(a); // f сжирает а h(a); // хуюшки

примерно так

let a = "foo"; g(&a); // g сжирает &a f(a); // f сжирает а h(a); // хуюшки

ну это по сути плюсовая модель с точность до проверки, что после std::move() нельзя объект использовать

т.е. g() по сигнатуре получает & и обязана не делать side effect f(), h() по сигнатуре получает значение и его перемещают правильно?

ERROR: S client not available

близко, но не совсем, в с++ нету lifetime annotations

{}

(под side effect подразумеваю что функция не имеет права присваивать ссылку кому-либо, кроме локальных переменных и возвращаемого view-значения)

близко, но не совсем, в с++ нету lifetime annotations

у меня сейчас конвенция на это есть)))

в конвенции нет бороу чекера, так что это баловство в целом

компиль-тайм чекера нет, да

рантайм чекает в дебажке

ну хоть так

ну там в случае передачи ссылки с сохранением враппер передается

т.е. типа 0. По умолчанию ты не имеешь права считать, что ссылка живет дольше вызываемой функции (вызывающий гарантирует последнее) 1. Если 0 нарушается возвратом view-объекта, ты сам делаешь враппер и обзываешь функцию _view 2. Если 1 нарушается, то принимается сразу враппер

1 как нарушается?

Например, мне нужно передать std::function с биндом

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

Или есть кнопки, которые хотят, чтобы был инициализирован глобальный TooltipController

void f(const T t) { g(std::move(t)); } Это же UB?

void f(const T t) { g(std::move(t)); } Это же UB?

плохо понимаю, почему

плохо понимаю, почему

в общем-то потому что нет

в общем-то потому что нет

ну move вернет const&&

Господа

А clang и gcc обучены ли PLD использовать на ARM-ах?

https://lwn.net/Articles/444336/ Вот вам. Тут любят такое.

> An additional complication comes from the fact that virtual memory systems can have more than one mapping for a given range of memory, and caching is a feature of the mapping, not the memory itself. So one might well wonder what happens if different mappings have different caching attributes. On recent ARM processor designs, what happens is officially undefined; in practice, it can mean problems like corrupted memory, machine checks, or simple hangs.

Ребят, всем привет) кто свободен и может помочь мне?

Ребят, всем привет) кто свободен и может помочь мне?

Фиктивный брак?

ахахх

нет

комп практикум в универ не могу сделать

массив у меня хватило ума сгенерировать

а сортировку не знаю как

@supapro

?