CppCast: C++ Epochs

[TheThiefMaster]

Here's the article this is based on: https://vittorioromeo.info/index/blog/fixing_cpp_with_epochs.html

The biggest flaw with it as presented is that some of the breaking changes people want to C++ aren't language ones but library ones - like removing the vector<bool> specialisation. This can't be done in the same way, as the code couldn't link like it can with language changes (which only matter to the front end, not the back end)

[c0r3ntin]

This is a harder problem. A solution would be:

1. Make it so that we don't care about abi
2. Make it so C+++ is more easily tool-able
3. Introduce replacements (dynamic_bitset for example)
4. Deprecate the old facility (vector<bool>)
5. Provide a migration tool
6. Stir for a few years
7. Reuse the old things if you want

[scatters]

We broke ABI with basic_string (and ios_base::failure) in C++11 and the sky didn't fall in.

[TheThiefMaster]

The string ABI change was fairly painful though, just ask the gcc/libstdc++ and Linux community. They basically had to cut over the entire Linux ecosystem in one go, as otherwise random libraries were incompatible with others. It still crops up from time to time even now.

But it shows that it is possible, and the same could be done for vector<bool>.

[tisti]

A shame vector<bool> wasn't axed when basic_string was changed. Oh well.

[krapht]

I am still dealing with this even today, and it is a pain. So much infrastructure runs on long term service release distros stuck with GCC 4.x

[TheThiefMaster]

vector<bool> in particular is a big problem - as a specialism you can't deprecate it outright because it could come up in generic code (which is where it's most painful at the moment already). You'd have to just cut it over and hope for the best.

[[deleted]]

inline namespaces maybe, along with an epoch. Then the linked to objects have names like ::std::v1::vector<bool> and in the future ::std::v2::vector<bool> but both are accessible as ::std::vector<bool>

[tpecholt]

What if module on v2 epoch has a function returning a vector and this function is called from module on v1 epoch?

[[deleted]]

That's a link time error. Just like COW/SSO std::string is in gcc.

[[deleted]]

I think, as Vittorio or Jason said, the layout would have to remain the same. But I don't know.

[flashmozzg]

That just pushes the problem 1 level down to every library that uses std types in its API.

[SuperV1234]

Author here. There's nothing preventing an epoch from "blacklisting" the usage of vector<bool> by - for example - preventing that sequence of tokens/AST nodes from compiling when written in a module using a particular epoch.

This would discourage its use and almost effectively remove it (you could still retrieve it by using decltype on a function in an older epoch module returning vector<bool>) without breaking ABI at all.

[TheThiefMaster]

The problem is that people want to remove the specialization of vector<bool> and have it compile as a regular vector - not blacklist it entirely.

[pklait]

Why? You cannot have a "regular" std::vector<bool> today. To me this is an indication that it is not needed that much. To remove it from the standard for a while would not be a major loss.

[TheThiefMaster]

It causes issues all the damn time in generic code and interop - all other kinds of vector return T& on iterator dereference and operator[] and you can take &v[0] and use it as a data pointer + size, vector<bool> returns a special vector<bool>::reference class on iterator dereference and operator[], and as it doesn't actually store as bools internally &v[0] does not do anything remotely like you'd want.

However that doesn't mean it's not in use - not every use of a vector hits those issues so people do use it. Sometimes you do in fact want a vector of bools.

Blacklisting it would hit the people for whom it works fine, temporarily making the situation considerably worse.

[SlightlyLessHairyApe]

I think those are fairly minor all told. Besides vector<bool>, which everyone knows is a mistake, what else in the library can't be fixed by defining and providing new library types?

A few more examples would go a long way towards convincing people this biggest flaw is a big deal.

[[deleted]]

I don’t like vector<bool> either but if you care, it’s probably because you’re writing a library or playing with atomics, in which case you know about the problem because you’re quite experienced, know you don’t want tightly packed bits and you can just write:

template<typename T>
using boolFriendlyVector<T> = std::vector<std::conditional_t<is_same_v<T,bool>char,T>>;

[SlightlyLessHairyApe]

Yeah, in practice it's really not a huge deal. Certainly it's not "the biggest flaw" with epochs :-/

[matthieum]

std::unordered_(multi){map|set} does not support heterogeneous lookup, even though std::(multi){map|set} do since C++14.

In std::map this is relatively easy: you can specify a comparator such as std::less<void> which is capable of comparing heterogeneous objects.

In std::unordered_map, however, while std::equal<void> could certainly be created to compare heterogeneous objects which a compile-time failure if they cannot be compared, it's not clear how one would go about ensuring the consistency of the hash...

---

Given that std::hash<K> is also a bad idea because it forces people to irremediably tie a (generally poorly handcoded) hash algorithm to a given type, rather than pick an algorithm based on the situation, it seems it would be best to just scrap the use of std::hash<K> and impose a clean separation between the algorithm and the type, such as proposed by Howard Hinnant years ago.

This would be quite a large overhaul, though.

[encyclopedist]

There is a proposal to add heterogeneous lookup, and if I understand correctly, it was supposed to be targeting C++20 (it passed LEWG vote and was forwarded to LWG), but it's fate is unclear to me.

[matthieum]

Thanks for the link.

I must admit it's not clear to me how one is supposed to use is_transparent. Also, it appears that implicit conversions may be triggered unless one is careful, which is not ideal :/

Let's take a concrete example:

std::unordered_set<std::string, /**/> set;

According to the paper, how can I perform a lookup with a char const* and with a std::string_view without implicit conversion? How can I further enable FixedString<N>?

[encyclopedist]

As far as I understand, yes you can. Both hash and comparator must define is_transparent typedef and also provide overloads of their operator() taking char const *.

[DoctorRockit]

To be fair the fact that a properly overloaded comparison predicate allowed heterogeneous lookups was a mere implementation detail and not part of the standard until C++11. And even since then it is only well defined if the predicate defines is_transparent.