Typical C++, but Why? - Björn Fahller - C++ on Sea 2023
Vložit
- čas přidán 29. 08. 2023
- cpponsea.uk/
---
Typical C++, but Why? - Björn Fahller - C++ on Sea 2023
The C++ type system is both very weak and very strong. In this presentation I will show you how using the strengths of the type system makes your code better. I will show you how types...
- prevents incorrect code from compiling
- improves readability of code
- reduces the risks when changing code
and I will show you how very simple changes to your code will take you far in the desired direction.
---
Slides: github.com/philsquared/cppons...
Sponsored By think-cell: www.think-cell.com/en/
---
Björn Fahller
Björn Fahller is a senior developer at Net Insight, where he is currently coordinating the technical work of teams developing electronics, FPGA, embedded software, distributed control systems and web applications. He is keen on improving the skills of the teams he works in, by learning, and by sharing knowledge. Björn has worked full time with software development since 1994, mostly for networking products, and primarily in C++. He has also created the popular open source C++ libraries, Trompeloeil for mocking, and strong_type for type safety.
---
C++ on Sea is an annual C++ and coding conference, in Folkestone, in the UK.
- Annual C++ on Sea, C++ conference: cpponsea.uk/
- 2023 Program: cpponsea.uk/2023/schedule/
- Twitter: / cpponsea
---
CZcams Videos Filmed, Edited & Optimised by Digital Medium: events.digital-medium.co.uk
#cpp #cpponsea #programming - Věda a technologie
What a great explanation of simple, understandable techniques for increasing readability and maintainability. We need more of these!
I recently had a problem like the "a load of bool" section. I solved it using bit flags and or-ing them together. It's easier to read in my opinion, since you easily see which flags are being set, and those that aren't just don't appear
Nice talk!
these are some really nice tips!
Re "Too many default" 29:25 for C++ earlier than C++20 you may use a lambda that gets immediately evaluated. Optimizations work AFAIK.
Example:
auto server_socket([](){
server_socket::config conf;
conf.port = 1666;
conf.address = "127.0.0.1";
conf.nonblocking = false;
return conf;
}());
Looks like C++ going javascript....
26:00 That point about not using span directly needs some justification. I don't see how you could shoot yourself in the foot with span. Just use a span of const T for read only buffers. I don't see anything dangerous in there.
Congratulations! You just reinvented Ada! ;-)
It is funny that it took C++ standardisation 10 years to realise that named initialiser lists, introduced in C with C99, are better than constructors for structs, at least occasionally, so they should be there as an option.
Just use Haskell (or any other language with a strict and expressive type system with a solid theoretical basis so type inference is feasible).
I have been away from c++ for a while, I thought constructors should NOT throw. referring to timestamp 10:00
constructors should throw to signal failed object creation. Destructors should not throw.
It makes me a bit uneasy, thinking about these good type-system properties and then thinking of half the world using JavaScript with zero type-system.
@13:20 I prefix all my enum class typenames with E. So it'd be ETrim, EPad, and ELineFeed.
What an excellent advertisement for the Rust programming language
LOLZ
Or you could maybe do something like:
enum class format { truncate, pad_center, pad_left, pad_right, line_feed };
void print( std::string_view, std::vector );
print( "Corn Holio!", { format::truncate, format::line_feed } );
Alternatively, if you have a lot of booleans, you could wrap it all up into a bitset and have them be flags.
But I think that unless you need to store/pass the conditions as a set, enums are cleaner. The vector would involve searching it for the conditions, you're forced to allocate memory, and nothing stops you from passing { truncate, truncate, truncate, truncate... }
print("But the implementation will require an unnecessary loop, and some serious thought as to how inputs like this (which are totally valid to the type system) are handled", {format::truncate, format::line_feed, format::pad_left, format::pad_left, format::line_feed, format::pad_center, format::truncate, format::pad_right, format::pad_center, format::line_feed});
Some alternative to your approach is to use flag enums
enum class format : int {
none = 0,
pad_left = 1
"There are other means to get a CVE" Hahahahah!
Wrong argument: I don't like this tip tbh. I don't want to read code a see 50 different types which I need to cross reference to know what they mean.
Just write units tests for your logic, and easy logic mistakes will be captured easily (and you test on much more than simple type correctness).
Thats also why I limit the use of "auto" for readibility where it really makes things less complicated.