Anonymous
we did bench marks on our code and we found that pthread was faster then std::thread for our application
Anonymous
also thread does not have semaphores
Anonymous
and we needed semaphores
Anonymous
to tell us when all the cameras triggered
Anonymous
how much faster
not by much
Anonymous
like maybe 5 milliseconds
Anonymous
so does it matter
Anonymous
but we are on a jetson tx2
Anonymous
for us it does
Anonymous
the order matters
Anonymous
Anonymous
alright
Anonymous
just the fact that 8 get triggered
Anonymous
my bad 12 now
Anonymous
we have 12 cameras on that system now
Anonymous
like maybe 5 milliseconds
that's a lot!
Anonymous
yep which is why we stuck with pthread instead of std::thread
Anonymous
it has still static lifetieme duration where the sentence above applies
static lifetime for a file is the global lifetime
olli
static lifetime for a file is the global lifetime
do you mean something like source.cpp static Type t; int main() { return 0; } ??
Anonymous
but not quite
Anonymous
main() is in a different file
Anonymous
these cases those statics wait till the end of the whole program to get destroyed
Anonymous
you use static to hide that variable from other files
Anonymous
to prevent people like me from doing weird stuff like extern
Anonymous
and calling those variables
olli
Still, static lifetime
olli
destructor called at the end
Anonymous
Still, static lifetime
however static lifetime is the same as the global lifetime
Anonymous
even in a function
olli
Stillt no leak occures, that's the only thing I wanted to say
Anonymous
and now i do vect.resize(1000000);
Anonymous
now is there a leak?
olli
in the same file?
Anonymous
if i forget about that in my code
olli
show the code please
Anonymous
inside one function
Anonymous
static std::vector<int> vect; int foo() { vect.resize(100000000); }
Anonymous
and we call foo once in the main function
olli
v.cpp #include <vector> static std::vector<int> v; void foo() { v.resize(10000000); } m.cpp extern void foo(); int main() { foo(); } valgrind reports ==29== All heap blocks were freed -- no leaks are possible ==29== ==29== For counts of detected and suppressed errors, rerun with: -v ==29== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Anonymous
but i know this causes memory leaks
Anonymous
now have a while loop in there
Anonymous
for infinity
Anonymous
so while (1); in the main cpp file
Anonymous
and monitor that heap usage for a few days
Anonymous
it will still stay the same
Mihail
well why would you consider that a memory leak?
Mihail
like that's what you told it to do
Mihail
so it does it
Anonymous
well why would you consider that a memory leak?
because i worked with some developers who made stupid fucking mistakes like that
Anonymous
and it ended up having the robot go off the rails
Anonymous
and all because they forgot that they did 1 line of code
Anonymous
without thinking
Mihail
ok but like what do you expect to happen?
Anonymous
ok but like what do you expect to happen?
i except a memory leak to happen and not being able to use that much heap space as needed
Mihail
you want the vector to automatically shrink itself? that just sounds stupid
Anonymous
you want the vector to automatically shrink itself? that just sounds stupid
no however i am saying this is how we can have memory leaks
Anonymous
if we have bigger and bigger codes
Anonymous
no programming langauge by itself causes memory leaks but some make it easier to make these memory leaks then others
Anonymous
it is practically impossible to make a memory leak in asm
Anonymous
it is practically impossible to make a memory leak in asm
it is so possible to mess everything up
Anonymous
how (apart from cyclic references?)
the only way is cyclic references
olli
the only way is cyclic references
yes, but then again always prefer std::unique_ptr
Anonymous
i still prefer handling the pointers
Anonymous
#include <stdio.h> #include <memory> using namespace std; class C { public: C() {printf("Constructor for C: this=%p\n", this);} ~C() {printf("Destructor for C: this=%p\n", this);} void setSharedPointer(shared_ptr<C> p) {pC = p;} private: shared_ptr<C> pC; }; int main(int argc, char ** argv) { shared_ptr<C> pC(new C); shared_ptr<C> pD(new C); pC->setSharedPointer(pD); pD->setSharedPointer(pC); return 0; }
Anonymous
raw pointers? why?
because she is like me
Anonymous
we like to ensure we do not have memory leaks ourselves
Anonymous
keeps us on our toes
Anonymous
raw pointers? why?
because i've used pointer in my classes only, I test and review them.
Anonymous
is my code gonna crash?
Anonymous
not only
olli
because she is like me
that's no argument. I partially agree, but using std::unique_ptr is a good way for ownership