I wish compilers would come with more of these features out of the box. I'd imagine that at least some static analyses features are relatively easy to implement. This could already be a big help.
you can't have improvement without continuos challenges, we need challenges to improve, what you said is not actually the best way to get better and smarter, what's the point to live a life if not to experience and improve your own mindset...
Really should rename "Data Oriented Programming" as it can be confused with "Data oriented design" or its less used synonym "Data oriented programming" (which name matches exactly). Data oriented programming/design is a superior idea over Object oriented programming - yes, the video is about a completely different subject, but naming is important.
Good to have extra checking capabilities but not sure what this adds to MS debug CRT. That already reports many of presented stuff such as boundary overruns and memory leaks. Using modern C++ would already prevent many of the issues.
9:22, if you can build it into the IDE then you can add it to all compilers you can submit code for, no excuses, it should be made a compile time error, also should add a option to toggle checking for values that have not been 0'd out by the function exit, if there's no sign they're being passed to something outside of the function's scope then they should be cleared by the time it ends, even if it's not compiled into the final byte code, this type of requirement will at least remind the dev that the variable exists and they should make sure it is safely cleaned up. In my case I make liberal use of goto to ensure safe cleanup, here's an example: int foo(...) { int ret = -1; // Default to an unknown error void *mem = calloc( 1, BUFSIZ ); /* Compiler should assume this succeeds and use a non-0 number to track when it's cleaned up, an instance of mem = NULL; should be found shortly before return */ ... if ( /* catch error */ ) goto free_pointer; ... ret = 0; free_pointer: free(mem); mem = NULL; return ret; }
42:29, a simpler solution is to just store the thread id in the lock, start it off as -1 (or 0 if that's always invalid) and when a lock is obtained set that id and increment a reference count, every lock attempt there after from that would then increase that count and the same number of releases would then be required to clear the the thread id let another thread take the lock, it's the solution I came up with for my custom mutex that utilises a system mutex under the hood for the initial lock, 1st thread to acquire the lock, set the thread id and release the lock takes the custom mutex, the other thread/s upon acquiring the lock will check again if the thread id is still empty and return to waiting on it if not.
Funny they run it on GCC to show memory errors, but not on MSVC or any other MS tech (apart from vague IoT) itself. Sadge. Goes to show they are ready to poo poo on other projects but not their own. MS has always been this way Good video though! Really interesting tech!
:D I think you mistook that specific moment in a wrong manner. He did tell that those errors came from an old GCC compiler version and newer one didn't have any of those memory errors.
Dynamic analysis is an improvement but it's not sufficient, for dynamic analysis to work you'd need to be able to run all of the code paths ahead of time, which is rare. The way forward is to actually ship the analysis to prod, and at that point you might as well use a better language.
Bullshit... Dynamic analysis is a must. Most applications depends on runtime decisions. Shipping application with tools for dynamic analysis is good, but language doesn't matter here.
I wish compilers would come with more of these features out of the box. I'd imagine that at least some static analyses features are relatively easy to implement. This could already be a big help.
you can't have improvement without continuos challenges, we need challenges to improve, what you said is not actually the best way to get better and smarter, what's the point to live a life if not to experience and improve your own mindset...
Really should rename "Data Oriented Programming" as it can be confused with "Data oriented design" or its less used synonym "Data oriented programming" (which name matches exactly).
Data oriented programming/design is a superior idea over Object oriented programming - yes, the video is about a completely different subject, but naming is important.
Good to have extra checking capabilities but not sure what this adds to MS debug CRT. That already reports many of presented stuff such as boundary overruns and memory leaks. Using modern C++ would already prevent many of the issues.
SAL was useful in a codebase I worked on years ago but it was so so so poorly documented!
Fascinating talk, thanks.
40 years ago, some dudes creates Ada...
Interesting talk of some fantastic technology.
Was somewhat put off by the parts that very much come across as a sales pitch though.
Valgrind dev (d)hat on, very interesting. Continuation sounds good. Is there no way to hook the loader so that asan is active during program load?
At 46:24 , does it make the A[-1] write to what would have been there if the metadata wasn’t (in the process of “taking the hit”)?
9:22, if you can build it into the IDE then you can add it to all compilers you can submit code for, no excuses, it should be made a compile time error, also should add a option to toggle checking for values that have not been 0'd out by the function exit, if there's no sign they're being passed to something outside of the function's scope then they should be cleared by the time it ends, even if it's not compiled into the final byte code, this type of requirement will at least remind the dev that the variable exists and they should make sure it is safely cleaned up. In my case I make liberal use of goto to ensure safe cleanup, here's an example:
int foo(...)
{
int ret = -1; // Default to an unknown error
void *mem = calloc( 1, BUFSIZ ); /* Compiler should assume this succeeds and use a non-0 number to track when it's cleaned up, an instance of mem = NULL; should be found shortly before return */
...
if ( /* catch error */ )
goto free_pointer;
...
ret = 0;
free_pointer:
free(mem);
mem = NULL;
return ret;
}
42:29, a simpler solution is to just store the thread id in the lock, start it off as -1 (or 0 if that's always invalid) and when a lock is obtained set that id and increment a reference count, every lock attempt there after from that would then increase that count and the same number of releases would then be required to clear the the thread id let another thread take the lock, it's the solution I came up with for my custom mutex that utilises a system mutex under the hood for the initial lock, 1st thread to acquire the lock, set the thread id and release the lock takes the custom mutex, the other thread/s upon acquiring the lock will check again if the thread id is still empty and return to waiting on it if not.
Thats called a reentrant/recursive lock, it already exists :)
@@Ch40zz yep, called std::recursive_mutex and std::recursive_timed_mutex in case you need one with time limits
Watching this scares me as hell because I know too much what this means, and it's so ugly !
Funny they run it on GCC to show memory errors, but not on MSVC or any other MS tech (apart from vague IoT) itself. Sadge. Goes to show they are ready to poo poo on other projects but not their own. MS has always been this way
Good video though! Really interesting tech!
:D I think you mistook that specific moment in a wrong manner. He did tell that those errors came from an old GCC compiler version and newer one didn't have any of those memory errors.
Wait till Rust comment arrives xDDD
Yes particularly after his comment at 1:00:40!!!
Seems to me you have not understood the content of what has been explained. Rust won't help.
48:31, you can, change the font size, I don't even use windows anymore and I still remember that
Dynamic analysis is an improvement but it's not sufficient, for dynamic analysis to work you'd need to be able to run all of the code paths ahead of time, which is rare. The way forward is to actually ship the analysis to prod, and at that point you might as well use a better language.
If you don’t run your code before shipping. How do you know if it even works?
that is why you use fuzzing to try to hit all code paths. Though it is obviously not thorough.
Bullshit...
Dynamic analysis is a must. Most applications depends on runtime decisions.
Shipping application with tools for dynamic analysis is good, but language doesn't matter here.
@@azarashikamen4098 "Bullshit..." If the code is detected as faulty just don't let it compile, and you need specific features to do that
rust is coming....
@@manrico736 if C++ get the same ownership rules and compiler rules C++ will replace rust