I’m currently in my final preparations for this year’s Akademy.
For people unaware of this conference,
it is the annual conference of KDE contributors.
We tend to have a few dozen of high quality talks
on various topics ranging from art and community building,
to hard-core Qt and C++ talks.
I’m going to have two talks.
One on (obviously :) ) functional programming in C++,
and one on C++17 and 20.
The later one will be a bit self-serving because I’d like
us to raise the compiler requirements for our software
so that we could enjoy working in KDE even more.
The only thing more important
than talks is the period after
where the different teams within KDE
meet-up to discuss the future plans.
While we do it all the time on IRC
and on the mailing lists,
having face-to-face meetings is irreplaceable.
If you are near Almeria,
the conference is free for attendance!
I guess this is public now –
Sergey invited me to give the keynote at C++ Siberia 2017
which will be held in Tomsk in August (25th and 26th).
@ivan_cukic will give a keynote at C++ Siberia 2017
https://t.co/B5oWqhjRuk #cpp #cppsiberia
— C++ User Group, RF (@cpp_russia) July 11, 2017
This will require some serious mental and physical preparation.
I’ve never had a talk two hours long. :)
If you are in area,
and you speak Russian
(My keynote will be in English since, despite having a Russian-sounding name, I don’t speak Russian),
come and join us –
the tickets are available at the conference website.
Sometimes, we need to create wrapper types.
types like unique_ptr, shared_ptr, optional and similar.
these types have an accessor member function called .get
but they also provide the operator-> to support
direct access to the contained value
similarly to what ordinary pointers do.
The problem is that sometimes we have a few of these types
nested into each other.
This means that we need to call .get multiple times,
or to have a lot of dereference operators
until we reach the value.
Something like this:
This can be a bit ugly.
If we can replace one .get() with an arrow,
it would be nice if we could replace the second .get() as well.
For this, the C++98 introduced a long arrow operator.
What if we have another layer of wrapping?
Just make a longer arrow.
With a special implementation of wrap,
this compiles and works without many problems.
Now, before we continue,
you should realize that this post is not a serious one.
And that this should never be used in a serious project,
just like the left arrow operator <--
and the WTF operator ??!??! (which no longer works in C++17 BTW).
One of my pet peeves with teaching FP in C++
is that if we want to have efficient code,
we need to catch functions and other callable objects
as template arguments.
Because of this,
we do not have function signatures that are self-documenting.
Consider a function that outputs items that satisfy a predicate
to the standard output:
We see that the template parameter is named Predicate,
so we can imply that it needs to return a bool (or something convertible to bool),
and we can deduce from the function name
and the type of the first argument
that it should be a function that takes an int.
This is a lot of reasoning just to be able
to tell what we can pass to the function.
For this reason,
Bartosz uses std::function in his blog posts
it tells us exactly which functions we can pass in.
But std::function is slow.
So, we either need to have a bad API or a slow API.
the things will change.
We will be able to define a really short (and a bit dirty) concept
that will check whether the functions we get are
of the right signature:
Edit: Changed the concept name to Callable to fit the naming in the standard [func.def] since it supports any callable, not just function objects
We will be able to call foo with any callable that looks like a int-to-int function.
And we will get an error ‘constraint Callable<int(int)> is not satisfied’
for those that do not have the matching signature.
An alternative approach is to use std::is_invocable type trait
(thanks Agustín Bergé for writing the original proposal and pointing me to it).
It will provide us with a cleaner definition for the concept,
though the usage syntax will have to be a bit different
if we want to keep the concept definition short and succulent.
When we get concepts (C++20, hopefully),
we will have the best of both worlds
we will have an optimal way to accept callable objects as function arguments,
and not sacrificing the API to do it.
Today, Functional Programming in C++ is again the Deal of the Day –
you get half off if you use the code dotd032317au at cukic.co/to/manning-dotd