> Documentation is about 80% done
And yet there is not standard library documentation. :(
101–110 of 141 posts
> Documentation is about 80% done
And yet there is not standard library documentation. :(
Earlier quoted context omitted.
What you mean is that C++ doesn't have a way to (easily) let you check whether a given reference is null or not. int* a = NULL; int& b = *a; compiles and runs just fine.
> compiles and runs just fine. For fairly low values of those. Creating a null reference is UB, your program is not legal at all.
Earlier quoted context omitted.
Because your cpu has a base ISA, plus extensions. The compiler doesn't know if you're going to only run this binary on your machine, or distribute it to others that may share your base ISA but possibly not your extensions, so it takes the conservative approach and doesn't use them unless signaled to do so via those compiler flags. Also, I think -march implies -mtune.
In Zig the default target is native, which turns on all the applicable CPU features. If you want to target something other than the native machine you can use --target-os --target-arch parameters. I haven't exposed extra CPU options for cross compiling yet.
Earlier quoted context omitted.
It is entirely possible that even if Windows 10 was perfect software according to the "it gives you the correct output for every input in the input domain" definition, it would still not open the start menu every time you clicked on the icon.
Of course we can redefine bugs as features, but to present that as an argument is a “red herring”: I can assure you, the Windows 10 start menu is not i tended to fail or delay opening instantly upon click or system button press.
There's a certain irony that the presenter quickly dismisses exception-based error handling, and then the first example handles an error by printing a message and exiting -- exactly what an unhandled exception does. This is more than a small piece of irony with a somewhat artificial example. Often, there simply isn't very much you can do with an error. In a SaaS world, you might not be able to tell the user what wron…
That would indeed be ironic if that case was the only thing exception-based error handling entails. That is, if every program just let all exceptions go uncaught. Which is nowhere near why exception handling was invented, or how it's used in practice.
Earlier quoted context omitted.
I made this argument in the talk: the only problem with exception-based handling is the lack of explicitness. It's too easy to call functions without being aware of the set of possible errors. Many c++ projects disable exceptions entirely. Writing "exception safe" code is tricky and non-obvious. Functions which should be guaranteed to never fail often can throw std::bad_alloc. Try-catch syntax forces incorrect nestin…
> the only problem with exception-based handling is the lack of explicitness - It's too easy to call functions without being aware of the set of possible errors. i.e. checked-exceptions?
Then it's "checked" but catching is optional.
Earlier quoted context omitted.
What you mean is that C++ doesn't have a way to (easily) let you check whether a given reference is null or not. int* a = NULL; int& b = *a; compiles and runs just fine.
No the gp is correct, references in c++ can't be null. Your code invoked undefined behavior before you did anything with a reference, namely *a which is a null pointer dereference.
Since nobody stopped you, the problem is still there.
Earlier quoted context omitted.
What you mean is that C++ doesn't have a way to (easily) let you check whether a given reference is null or not. int* a = NULL; int& b = *a; compiles and runs just fine.
> compiles and runs just fine. For fairly low values of those. Creating a null reference is UB, your program is not legal at all.
The whole point is to NOT have it be accepted.
Earlier quoted context omitted.
> the only problem with exception-based handling is the lack of explicitness - It's too easy to call functions without being aware of the set of possible errors. i.e. checked-exceptions?
Or just a compiler / IDE warning saying "X, and Y exceptions could be thrown here but are unhandled". Then it's "checked" but catching is optional.
F# is a language this is a lot like this, and I've recently been unable to get the editor with these features working in Linux, and it makes it rather horrible. If you had to remote in to a server and use vim, it could be rather horrible, and so on.
If we can get something like the language server idea working, really well, on all platforms and supported by all editors, then designing languages around certain IDE assumptions would more often be a good idea I guess.