Re[8]: Почему CLion и VS не предупреждают?
От: Shmj Ниоткуда  
Дата: 03.05.23 14:04
Оценка: :)))
Здравствуйте, rg45, Вы писали:

R>Вот именно, использование new там было вообще не в тему — даже в контесте его вопроса. Это лишь линший раз демонстрирует в какую кучу свалены мухи и котлеты в его голове. И сам он эту кучу разгребать не хочет, а тащит ее нам, чтоб мы разбирались в лабиринтах его сложного Квалиа.


У меня как раз вопрос присваивания стековой памяти, которая освобождается при выходе из функции.

R>Полностью согласен. Я и сам проходил по маршруту C++ -> C#. И знаю многих людей, которые преодолели этот путь без особого труда и в кратчайшие сроки. А вот в обратную сторону... что-то ни одного не припоминаю. Сплошные стоны и сопли.


Я, дело в том что, вынужден "марать руки" в С++ — никуда от этого не деться. Хотя проект то не на С++ у нас. Просто внешние библиотеки нужно чуток править.

И понял что это все-равно кому-то нужно будет делать и никто не хочет — все боятся. И чем дальше — тем все меньше в живых и при памяти остается людей, кто может это делать.
Re[8]: Почему CLion и VS не предупреждают?
От: DiPaolo Россия  
Дата: 03.05.23 14:07
Оценка:
S>Нужно было уточнить как раз — меня больше интересовал вопрос присваивания стековой памяти, которая освобождается при выходе из фукнции, переменной которая в куче.



Кажется, у тебя есть какие-то пробелы в понимании указателей и работы с памятью. Вот тут почитай https://www.learncpp.com/cpp-tutorial/dynamic-memory-allocation-with-new-and-delete/. Там есть про стек и про хип (кучу, heap).
Патриот здравого смысла
Re[9]: Почему CLion и VS не предупреждают?
От: Shmj Ниоткуда  
Дата: 03.05.23 14:18
Оценка:
Здравствуйте, DiPaolo, Вы писали:

DP>Кажется, у тебя есть какие-то пробелы в понимании указателей и работы с памятью. Вот тут почитай https://www.learncpp.com/cpp-tutorial/dynamic-memory-allocation-with-new-and-delete/. Там есть про стек и про хип (кучу, heap).


Вы хотите сказать в этом программа корректна? Она же мусор выводит на экран при сборке в VS, к примеру.
Re[10]: Почему CLion и VS не предупреждают?
От: DiPaolo Россия  
Дата: 03.05.23 14:23
Оценка: +1
S>Вы хотите сказать в этом программа корректна? Она же мусор выводит на экран при сборке в VS, к примеру.

Я уже запутался. Ты смешал в кучу два или три разных топика. Изначально речь шла про ворсинки статического анализа. Я показал, какой ворнинг выдает clang-analyzer.

Далее твой вопрос про освобождение стековой памяти. На что я посоветовал почитать про стыковую память и память в куче, потому что налицо пробел в понимании работы памяти в плюсах.

Выше есть мои коменты в коде. Там вроде все понятно.
Патриот здравого смысла
Re[9]: Почему CLion и VS не предупреждают?
От: reversecode google
Дата: 03.05.23 14:24
Оценка:
пробелы это слабые знание или знания выборочно
а у него пустота

он не хочет читать книги и вообще изучать
ему проще онлайн-троллинг на форуме где ему будут все рассказывать, рассжевывать
и замечу
все бесплатно!
Re[11]: Почему CLion и VS не предупреждают?
От: Shmj Ниоткуда  
Дата: 03.05.23 14:30
Оценка:
Здравствуйте, DiPaolo, Вы писали:

DP>Я уже запутался. Ты смешал в кучу два или три разных топика. Изначально речь шла про ворсинки статического анализа. Я показал, какой ворнинг выдает clang-analyzer.


Больше интересовал вопрос варнинга именно при присвоении стековой памяти.

DP>Далее твой вопрос про освобождение стековой памяти. На что я посоветовал почитать про стыковую память и память в куче, потому что налицо пробел в понимании работы памяти в плюсах.


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

DP>Выше есть мои коменты в коде. Там вроде все понятно.


Вы, похоже, тоже не заметили этой проблемы — увидели только что память не освобождена — а проблему присвоения стековой памяти — не заметили?
Re[12]: Почему CLion и VS не предупреждают?
От: DiPaolo Россия  
Дата: 03.05.23 14:35
Оценка:
S>Вы, похоже, тоже не заметили этой проблемы — увидели только что память не освобождена — а проблему присвоения стековой памяти — не заметили?

Не заметил. Я просто скопипастил то, что выдал статик аналайзер, о чем и был изначальный вопрос. Почему статический анализатор в моем случае не показывает ворнинг там — хз.
Патриот здравого смысла
Re[2]: Почему CLion и VS не предупреждают?
От: Shmj Ниоткуда  
Дата: 03.05.23 14:35
Оценка:
Здравствуйте, DiPaolo, Вы писали:

DP>Что использовать:

DP>- PVS
DP>- cppcheck

Ни один не показал проблему в коде


Если неиспользуемая переменая — то cppcheck дает варнинг. А тут его все устраивает

Сорри, чего-то PVS глюканул на CLion. На VS — норм.

Вопрос снимается.
Отредактировано 03.05.2023 17:13 Shmj . Предыдущая версия .
Re[9]: Почему CLion и VS не предупреждают?
От: rg45 СССР  
Дата: 03.05.23 14:51
Оценка: +1
Здравствуйте, Shmj, Вы писали:

R>>Вот именно, использование new там было вообще не в тему — даже в контесте его вопроса. Это лишь линший раз демонстрирует в какую кучу свалены мухи и котлеты в его голове. И сам он эту кучу разгребать не хочет, а тащит ее нам, чтоб мы разбирались в лабиринтах его сложного Квалиа.


S>У меня как раз вопрос присваивания стековой памяти, которая освобождается при выходе из функции.


Усыпить, чтоб не мучился



Ты правда ни хера не понял в моих словах? Скажи, что ты просто прикидываешься, ну пожалуйста!
--
Отредактировано 03.05.2023 14:55 rg45 . Предыдущая версия .
Re[3]: Почему CLion и VS не предупреждают?
От: pilgrim_ Россия  
Дата: 03.05.23 14:51
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Ни один не показал проблему в коде



GCC с -Wall -O2 (без оптимизации почему-то не показывает варнинг) и PVS предупреждают об использовании локального адреса за пределами функции.

https://gcc.godbolt.org/z/dfo861h1M

  GCC
<source>: In function 'int main()':
<source>:24:27: warning: using a dangling pointer to 't' [-Wdangling-pointer=]
   24 |     std::cout << t->V1 << "\n";
      |                           ^~~~
<source>:11:10: note: 't' declared here
   11 |     char t[2];
      |          ^
<source>:24:27: warning: 't' may be used uninitialized [-Wmaybe-uninitialized]
   24 |     std::cout << t->V1 << "\n";
      |                           ^~~~
In file included from /opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/iostream:41,
                 from <source>:1:
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/ostream:662:5: note: by argument 2 of type 'const char*' to 'std::basic_ostream<char, _Traits>& std::operator<<(basic_ostream<char, _Traits>&, const char*) [with _Traits = char_traits<char>]' declared here
  662 |     operator<<(basic_ostream<char, _Traits>& __out, const char* __s)
      |     ^~~~~~~~
<source>:11:10: note: 't' declared here
   11 |     char t[2];
      |          ^


  PVS, более человеческое предупреждение
<source>:16:1: warning: V507 Pointer to local array 't' is stored outside the scope of this array. Such a pointer will become invalid.


Но оба не предупреждают об утечке C1*.
Re[10]: Почему CLion и VS не предупреждают?
От: Shmj Ниоткуда  
Дата: 03.05.23 14:52
Оценка: :))
Здравствуйте, rg45, Вы писали:

S>>У меня как раз вопрос присваивания стековой памяти, которая освобождается при выходе из функции.


R>

Усыпить, чтоб не мучился


Давай по теме. Как я вижу, не все тут поняли где именно проблема.
Re[3]: Почему CLion и VS не предупреждают?
От: B0FEE664  
Дата: 03.05.23 15:08
Оценка:
Здравствуйте, T4r4sB, Вы писали:

TB>Ну перепишешь ты этот код на std::array и ссылки. Лучше станет? Нет

Станет лучше или нет — это смотря кому, но по крайней мере будет работать:

#include <array>
#include <iostream>
#include <memory>
#include <string>


class C1
{
public:
    std::shared_ptr<const std::array<char, 2>> V1;
};

std::shared_ptr<C1> fun2()
{
    std::shared_ptr<std::array<char, 2>> t = std::make_shared<std::array<char, 2>>();
    std::array<char, 2>& ref = *t;
    ref[0] = 't';
    ref[1] = '\0';

    std::shared_ptr<C1> c = std::make_shared<C1>();
    c->V1 = t;

    return c;
}

int main()
{
    auto t = fun2();
    std::cout << t->V1->data() << "\n";
}



#include <iostream>
#include <memory>
#include <string>

struct C1
{
    C1(const std::string& str) :  V1{str}{}
    const std::string V1;
};

std::shared_ptr<C1> fun2()
{
    std::string t = "t\0";
    std::shared_ptr<C1> c = std::make_shared<C1>(t);
    return c;
}

int main()
{
    auto t = fun2();
    std::cout << t->V1 << "\n";
}
И каждый день — без права на ошибку...
Re[4]: Почему CLion и VS не предупреждают?
От: so5team https://stiffstream.com
Дата: 03.05.23 15:22
Оценка:
Здравствуйте, pilgrim_, Вы писали:

_>PVS, более человеческое предупреждение

_><source>:16:1: warning: V507 Pointer to local array 't' is stored outside the scope of this array. Such a pointer will become invalid.

Прикольно, если переписать исходный пример нормально, с unique_ptr, PVS не выдает предупреждение. А вот GCC 13 -- выдает
https://gcc.godbolt.org/z/d87ohc4dE
Re[5]: Почему CLion и VS не предупреждают?
От: pilgrim_ Россия  
Дата: 03.05.23 15:25
Оценка:
Здравствуйте, so5team, Вы писали:

S>Прикольно, если переписать исходный пример нормально, с unique_ptr, PVS не выдает предупреждение. А вот GCC 13 -- выдает

S>https://gcc.godbolt.org/z/d87ohc4dE

Нет в мире совершенства , да и GCC почему-то только с оптимизацией выдаёт предупреждение.
Re[10]: Почему CLion и VS не предупреждают?
От: Shmj Ниоткуда  
Дата: 03.05.23 16:51
Оценка:
Здравствуйте, rg45, Вы писали:

R>>>Вот именно, использование new там было вообще не в тему — даже в контесте его вопроса. Это лишь линший раз демонстрирует в какую кучу свалены мухи и котлеты в его голове. И сам он эту кучу разгребать не хочет, а тащит ее нам, чтоб мы разбирались в лабиринтах его сложного Квалиа.


R>Ты правда ни хера не понял в моих словах? Скажи, что ты просто прикидываешься, ну пожалуйста!


Я не призываю так писать — мой вопрос лишь в статистическом анализаторе, который такие вещи сможет обнаружить.
Re[11]: Почему CLion и VS не предупреждают?
От: rg45 СССР  
Дата: 03.05.23 17:07
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Я не призываю так писать — мой вопрос лишь в статистическом анализаторе, который такие вещи сможет обнаружить.


Какие "такие"? Ты нахера утечку памяти туда воткнул, когда твой вопрос касался указателей и ссылок на локальные переменные, чье время жизни меньше времени жизни ссылок и указателей? А я скажу нахера — просто в голове у тебя полная каша. И вместо того, чтоб что-то читать и разбираться, ты тащишь всех своих тараканов сюда.
--
Отредактировано 03.05.2023 17:11 rg45 . Предыдущая версия . Еще …
Отредактировано 03.05.2023 17:10 rg45 . Предыдущая версия .
Отредактировано 03.05.2023 17:08 rg45 . Предыдущая версия .
Re[9]: Почему CLion и VS не предупреждают?
От: T4r4sB Россия  
Дата: 03.05.23 17:21
Оценка:
Здравствуйте, Shmj, Вы писали:

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


R>>Вот именно, использование new там было вообще не в тему — даже в контесте его вопроса. Это лишь линший раз демонстрирует в какую кучу свалены мухи и котлеты в его голове. И сам он эту кучу разгребать не хочет, а тащит ее нам, чтоб мы разбирались в лабиринтах его сложного Квалиа.


S>У меня как раз вопрос присваивания стековой памяти, которая освобождается при выходе из функции.


Одно из необходимых умений программиста — это способность составлять МИНИМАЛЬНЫЙ пример, иллюстрирующий проблему.
У тебя же в коде ещё и всякий мусор типа оператора new, кстати нахрена он нужен после 11 года?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[12]: Почему CLion и VS не предупреждают?
От: Shmj Ниоткуда  
Дата: 03.05.23 18:04
Оценка: :))
Здравствуйте, rg45, Вы писали:

S>>Я не призываю так писать — мой вопрос лишь в статистическом анализаторе, который такие вещи сможет обнаружить.


R>Какие "такие"? Ты нахера утечку памяти туда воткнул, когда твой вопрос касался указателей и ссылок на локальные переменные, чье время жизни меньше времени жизни ссылок и указателей?


Утечку памяти воткнул случайно, т.к. еще не отработал привычку очистки. Потом увидел но решил не исправлять — т.к. хороший анализатор должен и это увидеть.
Re[13]: Почему CLion и VS не предупреждают?
От: rg45 СССР  
Дата: 03.05.23 18:12
Оценка: 7 (1) +2
Здравствуйте, Shmj, Вы писали:

S>Утечку памяти воткнул случайно, т.к. еще не отработал привычку очистки. Потом увидел но решил не исправлять — т.к. хороший анализатор должен и это увидеть.


Так вот знай, за "привычку очистки" в приличных конторах бьют линейкой по рукам так же точно, как и за утечку, которую ты "воткнул случайно". А могут и прощальный подсрачник выписать. Я тебе в третий раз даю эту ссылку: RAII. Почитай, это найважнейший принцип, без которого не пишется ни одна современная программа на С++.
--
Отредактировано 03.05.2023 18:17 rg45 . Предыдущая версия .
Re[13]: Почему CLion и VS не предупреждают?
От: T4r4sB Россия  
Дата: 03.05.23 18:19
Оценка: +1
Здравствуйте, Shmj, Вы писали:

S>Утечку памяти воткнул случайно, т.к. еще не отработал привычку очистки.


Нахрена ты вообще туда new впендюрил, если тебе достаточно вернуть объект по значению?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.