NDC{TechTown} : Typical C++, but Why?

Typical C++, But Why? – NDC{TechTown} 2022 © Björn Fahller @bjorn_fahller 1/124
Typical C++, But Why?
Björn Fahller
https://puzzlemontage.crevado.com/

View Slide


View Slide

Björn Fahller

View Slide

C++ type system in a nutshell
●
C++ has a small standard set of jigsaw puzzle
piece shapes, which often fit in the wrong
places

View Slide

●
places
●
C++ allows you to create your own shapes and
make them as generic or specific as you want

View Slide

●
places
●
●
Developers usually create pieces that make up
the structure of the program, but rarely for the
information passed between the pieces

View Slide

●
places
●
●

View Slide

●
places
●
●
I intend to make you change this
by showing a number of examples
and how they can be improved.

View Slide

Wrong argument

View Slide

std::string read_user_input();
std::string sanitize_input(const std::string&);
std::string query_user_data(const std::string&);
void process_result(const std::string&);
class illegal_query { … };
void react_to_user_input() {
auto input = read_user_input();
auto sanitized_input = sanitize_input(input);
log("input user data=", sanitized_input)
auto result = query_user_data(input);
process_result(result);
}
Wrong argument

View Slide

}
Wrong argument

View Slide

}
Wrong argument
https://xkcd.com/327/

View Slide

}
Wrong argument
Oops!
But what to
do?

View Slide

Wrong argument
sanitized_string sanitize_input(const std::string&);
std::string query_user_data(const sanitized_string&);
}

View Slide

Wrong argument
}

View Slide

Wrong argument
} struct sanitized_string {
std::string value;
};

View Slide

Wrong argument
}
error: invalid initialization of reference of type 'const sanitized_string&'
from expression of type 'std::__cxx11::basic_string'
| auto result = query_user_data(input);
| ^~~~~
~~~~~~~~~~~~~~~~~~~~~~
struct sanitized_string {
std::string value;
};

View Slide

Wrong argument
auto result = query_user_data(sanitized_input);
}
class sanitized_string {
public:
// \throws illegal_query
explicit sanitized_string(std::string);
explicit operator const std::string&() const;
private:
std::string value;
};

View Slide

Wrong argument
}
public:
private:
std::string value;
};

View Slide

Wrong argument
}
public:
private:
std::string value;
};
void work(int);
class C {
public:
operator int() const;
};
void f(C c)
{
work(c);
}

View Slide

Wrong argument
}
public:
private:
std::string value;
};
void work(int);
class C {
public:
};
void f(C c)
{
work(c);
}
work() accepts an int,
but c is not an int. The
conversion operator is
called to get an int.

View Slide

Wrong argument
}
public:
private:
std::string value;
};
void work(int);
class C {
public:
};
void f(C c)
{
work(c);
}
work() accepts an int,
but c is not an int. The
conversion operator is
called to get an int.
Conversion to int. You
almost always want such
an operator to be const.

View Slide

Wrong argument
}
public:
private:
std::string value;
};
void work(int);
class C {
public:
};
void f(C c)
{
work(c);
}
void work(int);
class C {
public:
explicit operator int() const;
};
void f(C c)
{
work(static_cast(c));
}

View Slide

Wrong argument
}
public:
private:
std::string value;
};
void work(int);
class C {
public:
};
void f(C c)
{
work(c);
}
void work(int);
class C {
public:
};
void f(C c)
{
}
Making the conversion
operator explicit
eliminates the risk for
accidental conversions.

View Slide

Wrong argument
}
public:
private:
std::string value;
};
void work(int);
class C {
public:
};
void f(C c)
{
work(c);
}
void work(int);
class C {
public:
};
void f(C c)
{
}
Making the conversion
operator explicit
eliminates the risk for
accidental conversions.
You have to say you
want a conversion.

View Slide

Wrong argument
auto sanitized_input = sanitized_string{input};
}
public:
private:
std::string value;
};

View Slide

Wrong argument
}
public:
private:
std::string value;
};
Private, so cannot
accidentally modify
the underlying value

View Slide

Wrong argument
}
public:
private:
std::string value;
};
Private, so cannot
accidentally modify
Explicit effort needed to
get the string representation

View Slide

Wrong argument
}
public:
private:
std::string value;
};
Private, so cannot
accidentally modify
Explicit effort needed to
get the string representation
Very difficult to have an invalid
sanitized_string object.

View Slide

Wrong argument
} Code is:
●
Very clean
●
Very easy to read
●
Very correct

View Slide

Wrong argument
●
Even a very simple struct eliminates a whole
class of errors
●
Private data and throwing constructor makes
the right thing easy and the wrong thing hard
●
Almost always use explicit for constructors
and conversion operators

View Slide

A load of bool

View Slide

A load of bool
void print(std::string_view, bool truncate, bool pad, bool line_feed);
int main()
{
print("foo", false, false, true);
}

View Slide

A load of bool
int main()
{
}
Looks alright here

View Slide

A load of bool
int main()
{
}
Looks alright here
But completely
incomprehensible here.
And even if you use named
variables, there’s no way to
know if you have them in the
right order.

View Slide

A load of bool
enum class truncate { off, on };
enum class pad { off, on };
enum class line_feed { off, on };
void print(std::string_view, truncate truncate_, pad pad_, line_feed lf_);
int main()
{
print("foo", truncate::off, pad::off, line_feed::on);
}

View Slide

A load of bool
int main()
{
}
Enum class to
the rescue!

View Slide

A load of bool
int main()
{
}
Enum class to
the rescue!
Very readable
And each is a unique
type, so reordering is a
compilation error

View Slide

A load of bool
int main()
{
}
Enum class to
the rescue!
Very readable
And each is a unique
type, so reordering is a
compilation error
Although admittedly
names of the
parameters can be a bit
hard on the eye

View Slide

A load of bool
●
You almost never want bool parameters, and
especially not several
●
enum class adds the good kind of verbosity
that enhances readability

View Slide

Dangerous defaults

View Slide

Dangerous defaults
void
print(std::string_view, bool trunc, bool pad, bool lf=true);
int main()
{
}
Same as before, but
now we want line feed
to be the default

View Slide

Dangerous defaults
void
int main()
{
}

View Slide

Dangerous defaults
void
int main()
{
}
After some time we
want to make the field
size a parameter.

View Slide

Dangerous defaults
void
print(std::string_view, size_t field, bool trunc, bool pad, bool lf=true);
int main()
{
}
After some time we
size a parameter.

View Slide

Dangerous defaults
void
print(std::string_view, size_t field, bool trunc, bool pad, bool lf=true);
int main()
{
}
After some time we
size a parameter.
⚠️ Still compiles, with
field size == 0!!!

View Slide

Dangerous defaults
void
print(std::string_view,
size_t field,
truncate trunc_,
pad pad_,
line_feed lf_ = line_feed::on);
int main()
{
}

View Slide

Dangerous defaults
void
print(std::string_view,
size_t field,
truncate trunc_,
pad pad_,
line_feed lf_ = line_feed::on);
int main()
{
}
note: initializing argument 2 of 'void print(std::string_view, size_t,
truncate, pad, line_feed)'
| void print(std::string_view, size_t field, truncate trunc_, pad pad_, line_feed lf_);
| ~~~~~~~^~~~~
~~~~~~~~~~~~~

View Slide

Dangerous defaults
●
Default parameters are extremely dangerous
over time if the parameter types are
interchangeable
●
Unique and non-convertible types catch this
problem

View Slide

Coupled parameters

View Slide

Coupled parameters
size_t parse_header(const uint8_t* buffer, size_t buffer_length);
void copy_payload(const uint8_t* begin, size_t payload_length);
void received_packet(const uint8_t* buffer, size_t buffer_length)
{
auto header_len = parse_header(buffer, buffer_length);
copy_payload(buffer + header_len, buffer_length);
}

View Slide

Coupled parameters
{
}

View Slide

Coupled parameters
{
}
Oops! Do I get
a CVE now?
But what to do?

View Slide

Coupled parameters
{
}
These parameters describe one
thing, a contiguous range of
memory that can be inspected.
Let’s represent that in one type.

View Slide

Coupled parameters
{
}

View Slide

Coupled parameters
struct buffer_view {
const uint8_t* const begin;
const size_t length;
buffer_view prefix(size_t len) const {
return { begin, std::min(len, length)};
}
buffer_view suffix_after(size_t pos) const {
auto adjusted_pos = std::min(pos, length);
return { begin + adjusted_pos, length - adjusted_pos };
}
};
{
}

View Slide

Coupled parameters
}
}
};
{
}
const public data

View Slide

Coupled parameters
}
}
};
{
}
Return new views
Return new views

View Slide

Coupled parameters
}
}
};
{
}
Truncate if necessary

View Slide

Coupled parameters
buffer_view parse_header(buffer_view packet);
void copy_payload(buffer_view payload);
void received_packet(buffer_view packet)
{
auto header = parse_header(packet);
copy_payload(packet.suffix_after(header.length));
}
}
}
};

View Slide

Clearer intent and
reduced risk of error
Coupled parameters
{
}
}
}
};

View Slide

Clearer intent and
reduced risk of error
Coupled parameters
{
}
}
}
};
But immutable
members can
be problematic

View Slide

Coupled parameters
class buffer_view {
const uint8_t* start;
size_t length;
public:
buffer_view(const uint8_t* buff, size_t len)
: start(buff), length(len) {}
const uint8_t* begin() const { return start; }
const uint8_t* end() const { return start + length; }
size_t size() const { return length;}
buffer_view prefix(size_t len) const;
buffer_view suffix_after(size_t pos) const;
};

View Slide

Coupled parameters
class buffer_view {
size_t length;
public:
};
mutable private data

View Slide

Coupled parameters
class buffer_view {
size_t length;
public:
};
Access functions that
play nicely with range-for

View Slide

Coupled parameters
class buffer_view {
size_t length;
public:
};
Resist the
temptation to
add too much!

View Slide

Coupled parameters
class buffer_view {
size_t length;
public:
};
Resist the
temptation to
add too much!
Go back and
add stuff later
if needed

View Slide

Coupled parameters
●
When several parameters together describe
one thing, model that one thing as a type
●
C++20 has std::span<> to model the
start+length view into a buffer.

View Slide

Too many defaults

View Slide

Too many defaults
class server_socket {
public:
server_socket(uint16_t port,
bool tcp = true,
std::string_view address="0.0.0.0",
std::optional multicast = std::nullopt,
bool nonblocking = true);
…
};
What if I want all the
defaults, but
nonblocking = false?

View Slide

Too many defaults
public:
struct config {
uint16_t port;
bool tcp = true;
std::string_view address = "0.0.0.0";
std::optional multicast = std::nullopt;
bool nonblocking = true;
};
server_socket(config);
…
};

View Slide

Too many defaults
public:
struct config {
uint16_t port;
bool tcp = true;
};
…
};
Use member initializers
for the defaults

View Slide

Too many defaults
public:
struct config {
uint16_t port;
bool tcp = true;
};
…
};
int main()
{
server_socket socket({.port = 1666,
.address = "127.0.0.1",
.nonblocking = false});
…
}

View Slide

Too many defaults
public:
struct config {
uint16_t port;
bool tcp = true;
};
…
};
int main()
{
.address = "127.0.0.1",
…
}
C++20 designated
initializer list for explicit
named values

View Slide

Too many defaults
public:
struct config {
uint16_t port;
bool tcp = true;
};
…
};
int main()
{
.address = "127.0.0.1",
…
}
C++20 designated
named values
server_socket::config conf;
conf.port = 1666;
conf.address = "127.0.0.1";
conf.nonblocking = false;
server_socket socket(conf);
Before C++20

View Slide

Too many defaults
public:
struct config {
uint16_t port;
bool tcp = true;
};
…
};
int main()
{
.address = "127.0.0.1",
…
}
C++20 designated
named values
server_socket::config conf;
conf.port = 1666;
conf.address = "127.0.0.1";
conf.nonblocking = false;
server_socket socket(conf);
Before C++20
⚠️ Omitting .port
is not an error!

View Slide

Too many defaults
public:
struct config {
uint16_t port;
bool tcp = true;
};
…
};
int main()
{
.address = "127.0.0.1",
…
}
template
class must_init {
public:
must_init(T t) : value(std::move(t)) {}
operator T&() { return value; }
operator const T&() const { return value; }
private:
T value;
};

View Slide

Too many defaults
public:
struct config {
uint16_t port;
bool tcp = true;
};
…
};
int main()
{
.address = "127.0.0.1",
…
}
template
class must_init {
public:
private:
T value;
};
No default constructor!

View Slide

Too many defaults
public:
struct config {
uint16_t port;
bool tcp = true;
};
…
};
int main()
{
.address = "127.0.0.1",
…
}
template
class must_init {
public:
private:
T value;
};
Access underlying value

View Slide

Too many defaults
int main()
{
.address = "127.0.0.1",
…
}
public:
struct config {
must_init port;
bool tcp = true;
};
…
};
template
class must_init {
public:
private:
T value;
};

View Slide

Failure to init is now
a compilation error!
Too many defaults
int main()
{
.address = "127.0.0.1",
…
}
public:
struct config {
must_init port;
bool tcp = true;
};
…
};
template
class must_init {
public:
private:
T value;
};

View Slide

Too many defaults
●
Creating structs with parameters is especially
helpful when many of them have reasonable
defaults
●
The technique is extra useful since C++20
thanks to the designated initializer syntax

View Slide

Wrong key

View Slide

Wrong key
using client_id = int;
using server_id = int;
class control
{
std::map m_client_session;
std::map m_server_session;
public:
void close_server(server_id id) {
m_client_session.erase(id);
}
void close_client(client_id id);
};

View Slide

Wrong key
class control
{
public:
}
};

View Slide

Wrong key
class control
{
public:
}
};
Oops!
But what to
do?

View Slide

Wrong key
class control
{
public:
}
};
A type alias is
little more than
a comment!

View Slide

Wrong key
enum class client_id : int {};
enum class server_id : int {};
class control
{
public:
}
};

View Slide

Wrong key
class control
{
public:
}
};
Creates new unique
types and works for
any integer type

View Slide

Wrong key
class control
{
public:
}
};
Creates new unique
types and works for
any integer type
C++17 and
later

View Slide

Wrong key
class control
{
public:
}
};
error: no matching function for call to 'std::map::erase(server_id&)'
~~~~~~~~~~~~~~~~~~~~~~~~~~

View Slide

Wrong key
class control
{
public:
m_server_session.erase(id);
}
};

View Slide

Wrong key
class control
{
public:
}
};

View Slide

Wrong key
class control
{
public:
}
};
Redundant information
in the name. The type
carries the intent.

View Slide

Wrong key
class control
{
public:
void close_session(server_id id) {
}
void close_session(client_id id);
};

View Slide

Wrong key
class control
{
public:
}
};
We can overload
functions on
different parameter
types

View Slide

Wrong key
class control
{
public:
}
};

View Slide

Wrong key
class control
{
public:
}
};
auto x = client_id{3};
auto y = x;
int v = static_cast(y);
bool b = x < y;

View Slide

Wrong key
class control
{
public:
}
};
auto y = x;
bool b = x < y;
Create from underlying type

View Slide

Wrong key
class control
{
public:
}
};
auto y = x;
bool b = x < y;
Get value from underlying type

View Slide

Wrong key
class control
{
public:
}
};
auto y = x;
bool b = x < y;
equality and ordering
comparisons

View Slide

Wrong key
class control
{
public:
}
};
What if the
keys aren’t of
integer types?

View Slide

Wrong key
class control
{
public:
}
};
What if the
keys aren’t of
integer types?
Can’t use std::string as
underlying type for an enum

View Slide

Wrong key
class control
{
public:
}
};
#include
#include
class server_id {
std::string value;
public:
explicit server_id(std::string id) : value(std::move(id)) {}
explicit operator std::string_view() const { return value; }
auto operator<=>(const server_id&) const = default;
};

View Slide

Wrong key
class control
{
public:
}
};
#include
#include
class server_id {
std::string value;
public:
};
Always use an explicit constructor

View Slide

Wrong key
class control
{
public:
}
};
#include
#include
class server_id {
std::string value;
public:
};
and an explicit conversion operator

View Slide

Wrong key
class control
{
public:
}
};
#include
#include
class server_id {
std::string value;
public:
};
C++20 magic comparison operators

View Slide

Wrong key
●
enum class is great for creating new integer
types
●
C++20 operator<=>() saves a lot of work

View Slide

Types
●
Reduce the risk of calling functions with the wrong values
●
Reduce the risk that dependent values diverge
●
Makes it easier to manage defaults
●
Can help prevent uninitialized data
●
Are more convenient to write and use since C++20
●
Make your APIs more expressive
●
Are typically discovered as the code evolves
●
Just don’t forget to incorporate the improvements

View Slide

Furthermore...
The amazing art work used in this presentation
https://youtu.be/iLpt23V2vQE
Theory and details to think
about when designing types
The benefits and
traps when making
types for containers
https://youtu.be/0cTOqwrvq94
Premiers on Sept 18!

View Slide

[email protected]
@bjorn_fahller
@rollbear
Björn Fahller

View Slide

NDC{TechTown} : Typical C++, but Why?

NDC{TechTown} : Typical C++, but Why?

Björn Fahller

More Decks by Björn Fahller

Other Decks in Programming

Featured

Transcript