Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: False positives...  (Read 1617 times)

0 Members and 3 Guests are viewing this topic.

Bluesummers

  • Newbie
  • *
  • Posts: 2
    • View Profile
False positives...
« on: July 29, 2013, 08:03:19 pm »
of Valgrind, when working with SFML, are quite annoying. So I was wondering if somebody would be willing to share a suppression file with me. Since making one is quite a boring task, I figured I'd ask first before making my own.

Sorry if this has already been posted, but the search doesn't work for some reason, and what I've found via Google is unrelated.

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 11032
    • View Profile
    • development blog
    • Email
Re: False positives...
« Reply #1 on: July 29, 2013, 09:13:25 pm »
I don't get why people try to hunt memory leaks. If you use RAII and not use new/delete pairs, the possibility of creating a memory leak is very small. Don't try to fight the symptoms, fight the causer. ;)

From my knowledge, nobody has ever posted such a file here. I just know that one has to use Valgrind correctly to remove a few of the false positives.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Bluesummers

  • Newbie
  • *
  • Posts: 2
    • View Profile
Re: False positives...
« Reply #2 on: July 29, 2013, 09:51:08 pm »
I have just five raw pointers (because of forward declarations. as far as I know, the standard demands the template arguments to be a complete type); the rest are unique pointers. A few shared pointers here and there.

It shouldn't leak. I'm just being my paranoid self. :P

I'll make the file in a few days, then. Maybe there's someone as paranoid as myself I can help. :D

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
Re: False positives...
« Reply #3 on: July 30, 2013, 04:13:50 pm »
as far as I know, the standard demands the template arguments to be a complete type
The C++ standard explicitly mentions an exception for unique pointers:
Quote from: n3337 §20.7.1/5
[...] The template parameter T of unique_ptr may be an incomplete type.

But you have to define an empty destructor in the .cpp file, since the compiler requires a complete type when destroying the object. To avoid raw pointers even in cases where you need value semantics and copied ownership, my aurora::CopiedPtr might be interesting (it doesn't require the definition of destructor, copy constructor and copy assignment operator)...

No need to spend effort for the Valgrind file, people should rather learn to use RAII ;)
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

 

anything