Здравствуйте, sergii.p, Вы писали:
SP>по-моему стало ещё более запутанней.
Да.
SP>Для тривиального случая да, компилятор может гарантировать.
Более того, вроде как стандарт определяет совсем немного случаев когда он может этот неявный lifetime начать. + несколько функций из stdlib, применение которых так же начинает implicit lifetime (malloc). + стандарт отдает на откуп производителям компиляторов аналогичные объявления для нестандартных функций вроде VirtualAlloc-а в Win32.
Но не дает возможности программисту самому обозначить функцию как начинающую implicit lifetime.
Т.е. так норм:
X * p = malloc(sizeof(X));
А так уже нет:
X * p = my_custom_alloc(sizeof(X));
SP>
SP>alignas(int) unsigned char buffer[64];
SP>const std::size_t offset = get_some_offset(); // значение неизвестно на этапе компиляции
SP>int* ptr = reinterpret_cast<int*>(buffer + offset);
SP>*ptr = 42;
SP>
SP>Формально UB. Но если offset % alignof(int) == 0 то вполне корректное поведение, но гарантировать это в compile time невозможно.
Как я понимаю, специально для таких случаев в C++23 добавили start_lifetime_as
Здравствуйте, sergii.p, Вы писали:
s> ·>Так в данном случае это только С/С++ с приветом. В остальных ЯП всё в порядке с return. s> в rust return вообще можно не ставить и оно скомпилируется
Так ведь не просто скомпилируется, но и будет работать. В отличие от.
Здравствуйте, Marty, Вы писали:
A>>То есть не более одной ошибки на страницу. И тогда это было нормально. Это не вызывало усилий и получалось само. A>>Без этого человек считался неграмотным, и его в ВУЗ просто не брали. Ну потому что учить дурака бесполезно. A>>Современные люди с высшим образованием такого даже представить себе такого не могут.
M>Какой у тебя огромный...
Ты начал что-то понимать...
M>>>Что за чудо? Никогда такого не видел. Покажешь?
A>>
A>>FILE * my_fopen( char *filename, char *flags )
A>>{
A>> return fopen( filename,flags );
A>>}
A>>FILE *fr = my_fopen( "my_file", "r" ); // <--- вот тут будут два совершенно бессмысленных варнинга
A>>
M>Тут очень даже осмысленные варнинги. Внутри твоего my_fopen может происходить запись по переданном указателям, а ты передаёшь литералы. Эти литералы лежат в сегменте инициализированных данных, и туда писать нельзя. Вот тебе компилятор и говорит, что ты хрень творишь
Не надо говорить, что "может", когда "нету".
Внутри моего my_fopen запись не происходит. Это значит, что не может быть. Оно не происходит.
Вообще, похоже, что умение пользоваться глазами — это такой же уходящий скилл, как умение читать.
Есть три ситуации — когда "есть", когда "нету", и когда "может быть".
Так вот первые два варианта исключают третий.
Да, это уже не про программирование. Это про логику. Про обычную человеческую логику.
Здравствуйте, alpha21264, Вы писали:
A>Не надо говорить, что "может", когда "нету". A>Внутри моего my_fopen запись не происходит. Это значит, что не может быть. Оно не происходит. A>Вообще, похоже, что умение пользоваться глазами — это такой же уходящий скилл, как умение читать. A>Есть три ситуации — когда "есть", когда "нету", и когда "может быть". A>Так вот первые два варианта исключают третий.
A>Да, это уже не про программирование. Это про логику. Про обычную человеческую логику.
У тебя все функции inline? Когда ты наводишь мышку в IDE на вызов неизвестной тебе функции, тебе там показывают не только прототип, но и всё её тело, чтобы ты мог убедиться, что неконстантные параметры в ней не меняются?
Умение слышать, что тебе говорят, равно как и умение думать — похоже тоже уходящий скил, и не смотря на всю твою длину, он у тебя короткий
A>FILE * my_fopen( char *filename, char *flags )
A>{
A> return fopen( filename,flags );
A>}
A>FILE *fr = my_fopen( "my_file", "r" ); // <--- вот тут будут два совершенно бессмысленных варнинга
A>
А если в каком-то месте программы фактические параметры не будут прибиты гвоздями как строковые литералы, а придут в виде указателей типа const char*, то вместо "бессмысленных" предупреждений, у тебя будет просто ошибка компиляции. Интересно даже, кто будет виноватым у тебя в этом случае.
--
Справедливость выше закона. А человечность выше справедливости.
