vector must have the same value as its allocator

Question

This MCVE compiles/runs with gcc 7.3:
Please note, this MCVE has been dramatically reduced keeping the error reproduce able, so the code in the Allocator template doesn't make sense but it doesn't affect the constallation!

#include <regex>
#include <string>
#include <iostream>

namespace FaF
{
    template <typename T>
    class Allocator
    {
        public:
            typedef T value_type;

            Allocator() throw() {}
            template <typename U> Allocator (const Allocator<U>&) throw() {}
            ~Allocator() throw() {}

            T* allocate (std::size_t num, const void* hint = 0)
            {
                (void) hint; (void) num;
                return  new ( T );
            }

            void deallocate (T* p, std::size_t num) { (void) num; (void) p; }
    };

    using string = std::basic_string<char, std::char_traits<char>, Allocator<char>>;
    using smatch = std::match_results<FaF::string::const_iterator, Allocator<FaF::string::const_iterator>>;
}

int main()
{
    FaF::smatch results {};
    std::cout << "OK\n";
}

where Allocator is my own allocator.

We are now using gcc 8.2 and get this error

    FaF::smatch results {};
    ^--- vector must have the same value as its allocator

When I change FaF::smatch to the default std::smatch then it compiles/runs with gcc 8.2.

My question:

What is the reason and why this code doesn't compile with gcc 8.2 even it did with gcc 7.3 with C++17 setting - nothing else changed. This is what confuses me. Somewhere changed something which doesn't have apparently to do anything with C++.

See it live - clang 6.0 accepts the version with FaF::smatch as well.

Compiler flags:
-O3 -std=c++17 -Werror -Wextra -Wold-style-cast -Wall

`match_results` wants an allocator for `std::sub_match`, where `It` is its first template argument. — Igor Tandetnik, Aug 19 '18 at 17:47
Probably a bug in gcc 7.3, fixed in 8.2. The standard requires that an allocator-aware container's `value_type` be the same as the allocator's `value_type` — Igor Tandetnik, Aug 19 '18 at 17:53
The standard says it's undefined to use the wrong allocator type, so it's not a bug for GCC 7.3 to compile it without a diagnostic. But I did make GCC 8 stricter for `-std=c++NN` modes so now it diagnoses the problem (the code will still be accepted for `-std=gnu++NN` modes, as an extension). — Jonathan Wakely, Aug 20 '18 at 10:08
Yes, I was adding the extra info for the benefit of Igor and others reading here who might not click through to GCC's bugzilla. Your answer is correct, but stackoverflow's (somewhat silly) policy is to provide all the info here, not just link to another site that gives the answer. — Jonathan Wakely, Aug 20 '18 at 10:12
Well, OK, not a bug but a compiler extension. Either way, the original code is not valid C++. — Igor Tandetnik, Aug 20 '18 at 12:36

Peter VARGA · Accepted Answer · 2018-08-20T22:15:43.950

I filed this case in the gnu gcc bug database and the solution is this:

using smatch = std::match_results<FaF::string::const_iterator, 
      Allocator<std::sub_match<FaF::string::const_iterator>>>;
                ^^^^^^^^^^^^^^^

Here the answer from the gnu bug database link:

The value type of match_result<Iter> is sub_match<Iter>, 
  so you need to use Allocator<sub_match<Iter>> not Allocator<Iter>.

> Changing it to std::smatch then it compiles.


Because that uses the correct allocator type.

> Compiler options:
> -O3 -std=c++17 -Werror -Wextra -Wold-style-cast -Wall


If you use -std=gnu++17 then your code will be accepted,
  but is not portable and is not valid C++.

I want to thank the gnu team for the very fast reply which helps also the SO community!

vector must have the same value as its allocator

1 Answers1