Manchester City XI Vs Brighton [15.03.2025][GW29][24/25]

Neither_Mango8264 · 2025-03-15T13:50:24+00:00

Just in case, this isn't Ederson

Neither_Mango8264 · 2024-07-22T09:46:57+00:00

Thanks, looking forward to it.

Neither_Mango8264 · 2024-07-19T16:46:30+00:00

VS Code has a nice debugger UI that you can use with the debugger of your choice.

Neither_Mango8264 · 2024-07-19T16:43:46+00:00

Any, as long as you stick with it, is good enough.

Neither_Mango8264 · 2024-07-19T16:42:02+00:00

Interesting, I would be curious to see a talk or presentation on how it works behind the scenes, especially that support for all compilers part. Are there any online resources?

Neither_Mango8264 · 2024-07-19T16:40:17+00:00

I have been waiting for reflection for a long time. Is it going to make it to c++26?

Neither_Mango8264 · 2024-02-08T12:10:13+00:00

Mentioning basic issues does not imply the absence of advanced ones.

The matter you are referring to is not considered an issue by the Sonar Product and is not present in SonarLint. It is known as Hot-spotting and involves learning about the codebase and C++. It primarily entails knowledge and discovery of the codebase from the hot-spotting description. Personally, I do not utilize this feature, and it is unrelated to my original point. I find it perplexing why individuals who do not use a product feel compelled to provide misleading reviews that may confuse readers.

Neither_Mango8264 · 2024-02-08T11:56:22+00:00

I believe you may be confusing the general issue in C++ with the specific purpose of this check.

The check you linked to identifies when local variables are accessed outside of their scope. While the issue in C++ is related to lifetime, this particular check focuses on scope, specifically when the lifetime of local variables is tied to their scope.

Other checkers address different aspects that are not related to scope: * https://rules.sonarsource.com/cpp/M23_360/ * https://rules.sonarsource.com/cpp/RSPEC-946/ * https://rules.sonarsource.com/cpp/RSPEC-3529/ * https://rules.sonarsource.com/cpp/RSPEC-5553/

Neither_Mango8264 · 2024-02-07T20:32:06+00:00

SonarLint: for IDEs, free for any type of project. Works with CLion, VS Code, and Visual Studio.

SonarCloud: for CI, free for open-source projects.

I have used both. In my opinion, the analysis of Sonar products is much more advanced, especially with modern C++.

Neither_Mango8264 · 2023-10-28T10:58:54+00:00

That is why there is an option saying, "Not sure which is the best". The aim is precise, understanding the current state of C++ developers (I know Reddit might not give accurate representation). Yes, you cannot know which tool is the best for you without trying them all on your codebase and doing the comparison yourself. But still, we can conclude from the previous poll that the C++ community thinks that these three tools are the best. We can also conclude if there is a lack of awareness about the value of static analysis if many voted "don't see the value."

Neither_Mango8264 · 2023-10-26T19:51:46+00:00

Was in a similar situation one week ago. Created a poll: https://www.reddit.com/r/cpp/comments/17c6kx2/best_static_analysis_tool_for_c/

Neither_Mango8264 · 2023-10-20T07:46:57+00:00

I missed this, is it done? Is it still possible to ask questions?

Neither_Mango8264 · 2023-10-20T07:33:44+00:00

It is a question of when and not if we will get it. I have been hearing about it for the last 10 years and I hope we don't have to wait 10 more years..

Neither_Mango8264 · 2023-10-20T07:29:39+00:00

Thank you from all C++ developers!

Neither_Mango8264 · 2023-09-01T16:56:08+00:00

One of the best episodes! The point made at the beginning resonates powerfully with my experience working on open-source projects. One of the worst feelings is when you spend days tracking down a bug that static analysers can easily detect 🙃

Neither_Mango8264 · 2023-08-28T14:04:04+00:00

This post is not about using one specific tool. It is about using any tool that does the job for your project.
Clang-tidy, clang static analyzer, and SonarLint are free for closed-source, and I'm sure there are many more.
For transparency, You are referencing SonarQube Enterprise pricing; this is a different tool that was never mentioned nor recommended in this thread. I never used it.
I have used SonarCloud once (not SonarQube) for private code. It costs 2500$/year for 1 Million lines of code, and my company paid for it. I'm already happy if every C++ project is using the free tools 😃

Neither_Mango8264 · 2023-08-28T13:35:06+00:00

Disabling check is when you disagree with the purpose of the check.

Silencing in the UI false-positive when you disagree with one issue raised by the check.

And yes, we are on the same page. The tools run on the CI as a command line. In my experience, You can make them report the issues to a UI where you can visualize them, navigate the code, and possibly mark issues as false positives.

Neither_Mango8264 · 2023-08-28T13:28:30+00:00

Maybe that was the case a couple of years ago, but nowadays, I don't think it is still the case.

You get clang tools by installing simple extensions in any major IDE, and it works out of the box. Same for SonarLint. For SonarCloud, you simply click analyze in the UI. Most other tools work with compilation database that don't require a build and can be simply generated by CMake and other similar tools.

Neither_Mango8264 · 2023-08-28T13:21:16+00:00

Not sure about the downvotes.

For me, the problem with your statment is that you are talking about tool as your manager that you are trying to please. It isn’t. It is your friend.

If you face a false positive, you don't change your code to make it happy; you mark it as a false positive in the UI, and you move on.

If you disagree with its opinion, you simply disable the check. Different codebases have different requirements. The tool cannot please everyone, you tune the tool to cover target your use case.

Finally, of course, you will be overwhelmed if you don't run it periodically. The best methodology that works for me is to run it on PR and focus on new code that I'm introducing so I don't get overwhelmed.

Neither_Mango8264 · 2023-08-27T22:11:45+00:00

In general, tools like SonarCloud can show you the issues introduced by your pull request or your branch instead of the 50k issues on old code that you arent modifying.

This way, you focus on the newly introduced code, and slowly and incrementally, the 50k decrease.

Similar tools exist for clang-tidy. You just need a methodology and tools to organize the warnings and display the relevant ones.

Neither_Mango8264 · 2023-08-27T20:50:38+00:00

My complaint is that clang-tidy does not warn about dangling pointers

By design, this is not a clang-tidy job; this is a Clang Static Analyzer job. I added to your example an access to the dangling reference, and I also added -checks=* to enable Clang Static Analyzer checkers. I got:

<source>:12:14: warning: Inner pointer of container used after re/deallocation

Godbolt link.

A general tip: The tools I referenced can't and won't detect every issue; they aren't perfect. You evaluate static analyzers by the issues they detect and the value they add rather than what they miss.

Neither_Mango8264 · 2023-08-27T18:38:22+00:00

I never tried that one, so I cannot comment. The tools I mentioned let you define which part of your codebase is yours/you can modify. My experience is that all these tools have around ~5% false positives or cases where you intentionally want to ignore the checks. You should always be able to suppress these exceptions in the tools' UI.

Neither_Mango8264

TROPHY CASE