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
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; }());
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.
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.
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});
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.
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!
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....
Congratulations! You just reinvented Ada! ;-)
these are some really nice tips!
Just use Haskell (or any other language with a strict and expressive type system with a solid theoretical basis so type inference is feasible).
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.
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.
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
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.
"There are other means to get a CVE" Hahahahah!