Modern C and What We Can Learn from It [video]
1–10 of 132 posts
Re: Modern C and What We Can Learn from It [video]
#2Association of C and C++ Users (ACCU)
They should really just call themselves the ACU, they are wildly pro C++. It's progress that there is even a C talk at all at their conference but even looking at the title it's pitching itself at "No really, C isn't completely worthless"
One day such language wars might seem quaint. While everyone has their livelihoods tied to their chosen technologies it probably won't. C++ is fine imho fwiw. It's just not anything like "always and everywhere a better choice that C which should be treated as a virus."
The Scala folk are worst at it around here that I've seen but my experience may not be yours. People used to say similar of the LISP people on newsgroups. Perl was the first I saw where Larry and co. spent a lot of resource trying to make that not happen in the community. Python did a decent job following from what I've seen. C++ has always been pretty brutal in silly ways. I hope for it to calm down. Having one purely C talk at the conference of the Association of C and C++ users might be considered in some spheres to be "progress of a sort."
edit: disclosure. I am a member of the ACCU.
Re: Modern C and What We Can Learn from It [video]
#3The presenter has discovered the Result / Either monad at 00:24:16, but their proposed C implementation sounds like a really bad idea:
- The flag needs to be manually inlined into every type, thus bloating the type even after the value has been successfully created. ie every instance of `file_contents_t` in your program has become the equivalent of `Result` and you have to check it for validity every time you use it, not just when you create it.
- The flag is easy to forget to check. `std::optional` has that problem too with its `*` and `->` operators, but at least you have to write them, as well as the type "std::optional", explicitly. You can't accidentally use a `std::optional` as a `file_contents_t`, but you can accidentally use a `file_contents_t` with `.valid = false` where one with `.valid = true` was expected.
- The `img = crop_to_cat(img); img = add_bow_tie(img); ...` example looks great when you just call the functions in sequence and expect each function to be a no-op for invalid inputs. But this breaks down when you have loops or logging or sleeps or other side effects that you genuinely want to skip. At that point you will have to start checking `if (img.valid)` manually again anyway. And if there are enough of these scattered around multiple scopes, you'll end up wanting `goto error` again.
The callback-based example with `std::optional` as well as the Rust example with early returns don't have these problems. (Incidentally the Rust version uses an explicit `match` and manual return of the error for some reason, even though that particular usage pattern is exactly what the `?` operator is for.)
Re: Modern C and What We Can Learn from It [video]
#4The presenter has discovered the Result / Either monad at 00:24:16, but their proposed C implementation sounds like a really bad idea: - The flag needs to be manually inlined into every type, thus bloating the type even after the value has been successfully created. ie every instance of `file_contents_t` in your program has become the equivalent of `Result ` and you have to check it for validity every time you use it…
Having used the “local errno” solution, I feel you’re overstating the downsides a great deal.
Re: Modern C and What We Can Learn from It [video]
#5The presenter has discovered the Result / Either monad at 00:24:16, but their proposed C implementation sounds like a really bad idea: - The flag needs to be manually inlined into every type, thus bloating the type even after the value has been successfully created. ie every instance of `file_contents_t` in your program has become the equivalent of `Result ` and you have to check it for validity every time you use it…
I agree. `crop_to_cat(img)` now has to be concerned with handling a possibly invalid image even though this method doesn't make sense for an invalid image.
It muddies the type signature of the method and instead of `Image -> Image` (or possibly `Image -> Either Image Error`) it has to read `Either Image Error -> Either Image Error`.
What if I want to apply that method to a valid image? I either need to wrap the image or provide different overloads of the method which can get quite tedious if the number of possibly "fallible" parameters grows. A macro for unwrapping and early return would be nicer.
Re: Modern C and What We Can Learn from It [video]
#6It is to be noted that designated struct initializers will be/are in C++20 (of course it has all the features, it's C++).
See it here: https://en.cppreference.com/w/cpp/language/aggregate_initial...
Re: Modern C and What We Can Learn from It [video]
#7It is to be noted that designated struct initializers will be/are in C++20 (of course it has all the features, it's C++). See it here: https://en.cppreference.com/w/cpp/language/aggregate_initial...
The C++ version is much worse. "Note: out-of-order designated initialization, nested designated initialization, mixing of designated initializers and regular initializers, and designated initialization of arrays are all supported in the C programming language, but are not allowed in C++.”
Arrays designed to be indexed by an enum is a pattern I use all the time in C and designated initializers make it a whole lot safer and reduce the likelihood of a bug when refactoring.
Re: Modern C and What We Can Learn from It [video]
#8The presenter has discovered the Result / Either monad at 00:24:16, but their proposed C implementation sounds like a really bad idea: - The flag needs to be manually inlined into every type, thus bloating the type even after the value has been successfully created. ie every instance of `file_contents_t` in your program has become the equivalent of `Result ` and you have to check it for validity every time you use it…
I agree. `crop_to_cat(img)` now has to be concerned with handling a possibly invalid image even though this method doesn't make sense for an invalid image. It muddies the type signature of the method and instead of `Image -> Image` (or possibly `Image -> Either Image Error`) it has to read `Either Image Error -> Either Image Error`. What if I want to apply that method to a valid image? I either need to wrap the image…
Not to mention that you also lose the error context. That boolean "is_valid" flag is not really informative of what happened.
For example, if the image to load doesn't exist, you may want to print/log such path.
The goto looks like a better approach.
Re: Modern C and What We Can Learn from It [video]
#9Association of C and C++ Users (ACCU) They should really just call themselves the ACU, they are wildly pro C++. It's progress that there is even a C talk at all at their conference but even looking at the title it's pitching itself at "No really, C isn't completely worthless" One day such language wars might seem quaint. While everyone has their livelihoods tied to their chosen technologies it probably won't. C++ is…
In my experience, I have to qualify I program "ANSI C", otherwise people assume that I am really talking about C++.
I list ANSI C and no C++ in my professional experience and yet I have had a bunch of people call me to seriously talk about me helping in their C++ project. Maybe I shouldn't fault recruiters too much, though they should probably understand what language they are hiring for. But some of these guys were technical managers.
It kinda seems to me a lot of technical world assumes C died and C++ is newer and better version of it, which obviously is wrong way to look at it. These are separate languages that for unfortunate historical reasons share a lot of tooling and language syntax.
Re: Modern C and What We Can Learn from It [video]
#10Association of C and C++ Users (ACCU) They should really just call themselves the ACU, they are wildly pro C++. It's progress that there is even a C talk at all at their conference but even looking at the title it's pitching itself at "No really, C isn't completely worthless" One day such language wars might seem quaint. While everyone has their livelihoods tied to their chosen technologies it probably won't. C++ is…
In my experience, I have to qualify I program "ANSI C", otherwise people assume that I am really talking about C++. I list ANSI C and no C++ in my professional experience and yet I have had a bunch of people call me to seriously talk about me helping in their C++ project. Maybe I shouldn't fault recruiters too much, though they should probably understand what language they are hiring for. But some of these guys were…
If you can program C well, C++ isn't going to be too much of a problem for you. The reverse is not necessarily true. If I were hiring on a C++ project I'd definitely want to talk to someone who is genuinely good at C - they may not want to talk of course.