Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #68291 > unrolled thread

On stateful allocators and GCC

Back to article view | Back to comp.lang.c++

Contents

  On stateful allocators and GCC Daniel <danielaparker@gmail.com> - 2019-09-09 20:54 -0700
    Re: On stateful allocators and GCC Melzzzzz <Melzzzzz@zzzzz.com> - 2019-09-10 04:00 +0000
      Re: On stateful allocators and GCC James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-09-10 08:56 -0400
    Re: On stateful allocators and GCC Öö Tiib <ootiib@hot.ee> - 2019-09-10 00:25 -0700
      Re: On stateful allocators and GCC Öö Tiib <ootiib@hot.ee> - 2019-09-10 01:04 -0700
        Re: On stateful allocators and GCC Daniel <danielaparker@gmail.com> - 2019-09-10 04:51 -0700
      Re: On stateful allocators and GCC Daniel <danielaparker@gmail.com> - 2019-09-11 04:39 -0700
    Re: On stateful allocators and GCC Juha Nieminen <nospam@thanks.invalid> - 2019-09-11 09:04 +0000
      Re: On stateful allocators and GCC Daniel <danielaparker@gmail.com> - 2019-09-11 04:32 -0700
        Re: On stateful allocators and GCC Manfred <noname@add.invalid> - 2019-09-11 15:02 +0200
          Re: On stateful allocators and GCC Daniel <danielaparker@gmail.com> - 2019-09-11 06:33 -0700

#68291 — On stateful allocators and GCC

Has anyone attempted to use stateful allocators with GCC basic_string?

My attempts with versions up to 9 result in a compile time error

/usr/include/c++/9/bits/basic_string.tcc:596:30: error: no matching function for call to ‘my_alloc::my_alloc()’
  596 |       if (__n == 0 && __a == _Alloc())

My example allocator my_alloc doesn't have a default constructor, which I don't think you would ever want on a stateful allocator. So why would GCC
want to compare the passed allocator __a with the default constructed
allocator _Alloc()?

I have no issues with vs or clang.

Thanks,
Daniel

[toc] | [next] | [standalone]

#68292

On 2019-09-10, Daniel <danielaparker@gmail.com> wrote:
> Has anyone attempted to use stateful allocators with GCC basic_string?
>
> My attempts with versions up to 9 result in a compile time error
>
> /usr/include/c++/9/bits/basic_string.tcc:596:30: error: no matching function for call to ‘my_alloc::my_alloc()’
>   596 |       if (__n == 0 && __a == _Alloc())
>
> My example allocator my_alloc doesn't have a default constructor, which I don't think you would ever want on a stateful allocator. So why would GCC
> want to compare the passed allocator __a with the default constructed
> allocator _Alloc()?

Don't know about allocator requirements, but if default constructor is
not one of them it is a bug in gcc...
>
> I have no issues with vs or clang.
>
> Thanks,
> Daniel
>
>
>


-- 
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi 
bili naoruzani. -- Mladen Gogala

[toc] | [prev] | [next] | [standalone]

#68297

On 9/10/19 12:00 AM, Melzzzzz wrote:
> On 2019-09-10, Daniel <danielaparker@gmail.com> wrote:
>> Has anyone attempted to use stateful allocators with GCC basic_string?
>>
>> My attempts with versions up to 9 result in a compile time error
>>
>> /usr/include/c++/9/bits/basic_string.tcc:596:30: error: no matching function for call to ‘my_alloc::my_alloc()’
>>   596 |       if (__n == 0 && __a == _Alloc())
>>
>> My example allocator my_alloc doesn't have a default constructor, which I don't think you would ever want on a stateful allocator. So why would GCC
>> want to compare the passed allocator __a with the default constructed
>> allocator _Alloc()?
> 
> Don't know about allocator requirements, but if default constructor is
> not one of them it is a bug in gcc...

I couldn't find any such requirement.

[toc] | [prev] | [next] | [standalone]

#68294

On Tuesday, 10 September 2019 06:54:37 UTC+3, Daniel  wrote:
> Has anyone attempted to use stateful allocators with GCC basic_string?
> 
> My attempts with versions up to 9 result in a compile time error
> 
> /usr/include/c++/9/bits/basic_string.tcc:596:30: error: no matching function for call to ‘my_alloc::my_alloc()’
>   596 |       if (__n == 0 && __a == _Alloc())
> 
> My example allocator my_alloc doesn't have a default constructor, which I don't think you would ever want on a stateful allocator. So why would GCC
> want to compare the passed allocator __a with the default constructed
> allocator _Alloc()?
> 
> I have no issues with vs or clang.

Bugzilla say it is RESOLVED FIXED for gcc 5 ages ago. 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56437
Is it regression so someone had added the _Alloc() back,
or are you using very old gcc?

[toc] | [prev] | [next] | [standalone]

#68295

On Tuesday, 10 September 2019 10:25:40 UTC+3, Öö Tiib  wrote:
> On Tuesday, 10 September 2019 06:54:37 UTC+3, Daniel  wrote:
> > Has anyone attempted to use stateful allocators with GCC basic_string?
> > 
> > My attempts with versions up to 9 result in a compile time error
> > 
> > /usr/include/c++/9/bits/basic_string.tcc:596:30: error: no matching function for call to ‘my_alloc::my_alloc()’
> >   596 |       if (__n == 0 && __a == _Alloc())
> > 
> > My example allocator my_alloc doesn't have a default constructor, which I don't think you would ever want on a stateful allocator. So why would GCC
> > want to compare the passed allocator __a with the default constructed
> > allocator _Alloc()?
> > 
> > I have no issues with vs or clang.
> 
> Bugzilla say it is RESOLVED FIXED for gcc 5 ages ago. 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56437
> Is it regression so someone had added the _Alloc() back,
> or are you using very old gcc?

Demo: http://coliru.stacked-crooked.com/a/823d838b73d969b4

[toc] | [prev] | [next] | [standalone]

#68296

On Tuesday, September 10, 2019 at 4:04:36 AM UTC-4, Öö Tiib wrote:
> > 
> > Bugzilla say it is RESOLVED FIXED for gcc 5 ages ago. 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56437
> > Is it regression so someone had added the _Alloc() back,
> > or are you using very old gcc?
> 

Sounds plausible, but I'm at a loss to understand how. The builds are being 
done under travis, and the entries in .travis.yml look like, e.g.

    - os: linux
      addons:
        apt:
          sources:
            - ubuntu-toolchain-r-test
          packages:
            - g++-8
      env: COMPILER=gcc VERSION=8 CXXFLAGS="-std=c++17
 
> Demo: http://coliru.stacked-crooked.com/a/823d838b73d969b4

But will double check.

[toc] | [prev] | [next] | [standalone]

#68313

On Tuesday, September 10, 2019 at 3:25:40 AM UTC-4, Öö Tiib wrote:

> Is it regression so someone had added the _Alloc() back,
> or are you using very old gcc?

I believe I'm using the correct versions of gcc in the travis builds, but I 
think what's happening is that I'm picking up a version of the library that is
#if'ed compiled for gcc's old reference counting strings, viz

#if _GLIBCXX_FULLY_DYNAMIC_STRING == 0
	if (__beg == __end && __a == _Alloc())
	  return _S_empty_rep()._M_refdata();
#endif

[toc] | [prev] | [next] | [standalone]

#68306

Daniel <danielaparker@gmail.com> wrote:
> I have no issues with vs or clang.

I tried this with clang, and it gives an error. (If the constructor is
commented out, it compiles and works ok.) Am I missing something obvious?

//-----------------------------------------------------
#include <iostream>
#include <string>

struct MyAlloc
{
    using value_type = char;
    MyAlloc(int) {}
    char* allocate(std::size_t n) { return new char[n]; };
    char* allocate(std::size_t n, const void*) { return new char[n]; };
    void deallocate(char* ptr, std::size_t) { delete[] ptr; }
    bool operator==(const MyAlloc&) const { return true; }
    bool operator!=(const MyAlloc&) const { return false; }
};

int main(int argc, char** argv)
{
    std::basic_string<char, std::char_traits<char>, MyAlloc> str("hello");
    std::cout << str << "\n";
}
//-----------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#68312

On Wednesday, September 11, 2019 at 5:04:43 AM UTC-4, Juha Nieminen wrote:
> Daniel wrote:
> > I have no issues with vs or clang.
> 
> I tried this with clang, and it gives an error. (If the constructor is
> commented out, it compiles and works ok.) Am I missing something obvious?
> 
> //-----------------------------------------------------
> #include <iostream>
> #include <string>
> 
> struct MyAlloc
> {
>     using value_type = char;
>     MyAlloc(int) {}
>     char* allocate(std::size_t n) { return new char[n]; };
>     char* allocate(std::size_t n, const void*) { return new char[n]; };
>     void deallocate(char* ptr, std::size_t) { delete[] ptr; }
>     bool operator==(const MyAlloc&) const { return true; }
>     bool operator!=(const MyAlloc&) const { return false; }
> };
> 
> int main(int argc, char** argv)
> {
>     std::basic_string<char, std::char_traits<char>, MyAlloc> str("hello");
>     std::cout << str << "\n";
> }
> //-----------------------------------------------------

For a stateful allocator, you need to pass an instance of the constructor
to the object. But MyAlloc also isn't right, it needs to be a template class,
and have a constructor that supports rebinding. As a minimal example, try 

#include <iostream> 
#include <string>
#include <memory>

template <class T>
struct MyAlloc
{
    using value_type = T;
    using size_type = std::size_t;
    using propagate_on_container_move_assignment = std::true_type;

    MyAlloc(int) {}

    template< class U >
    MyAlloc(const MyAlloc<U>&) noexcept {}

    T* allocate(size_type n)
    {
        return static_cast<T*>(::operator new(n * sizeof(T)));
    }

    void deallocate(T* ptr, size_type) noexcept
    {
        ::operator delete(ptr);
    }

    bool operator==(const MyAlloc&) const { return true; }
    bool operator!=(const MyAlloc&) const { return false; }
};

int main()
{
    std::basic_string<char, std::char_traits<char>, MyAlloc<char>> str("hello", MyAlloc<char>(1));
    std::cout << str << "\n";
}

[toc] | [prev] | [next] | [standalone]

#68317

On 9/11/2019 1:32 PM, Daniel wrote:
> On Wednesday, September 11, 2019 at 5:04:43 AM UTC-4, Juha Nieminen wrote:
>> Daniel wrote:
>>> I have no issues with vs or clang.
>>
>> I tried this with clang, and it gives an error. (If the constructor is
>> commented out, it compiles and works ok.) Am I missing something obvious?
>>
>> //-----------------------------------------------------
>> #include <iostream>
>> #include <string>
>>
>> struct MyAlloc
>> {
>>      using value_type = char;
>>      MyAlloc(int) {}
>>      char* allocate(std::size_t n) { return new char[n]; };
>>      char* allocate(std::size_t n, const void*) { return new char[n]; };
>>      void deallocate(char* ptr, std::size_t) { delete[] ptr; }
>>      bool operator==(const MyAlloc&) const { return true; }
>>      bool operator!=(const MyAlloc&) const { return false; }
>> };
>>
>> int main(int argc, char** argv)
>> {
>>      std::basic_string<char, std::char_traits<char>, MyAlloc> str("hello");
>>      std::cout << str << "\n";
>> }
>> //-----------------------------------------------------
> 
> For a stateful allocator, you need to pass an instance of the constructor
> to the object.
You probably meant to pass an instance of the allocator.
In C++ an instance of the constructor is ungood.

  But MyAlloc also isn't right, it needs to be a template class,
> and have a constructor that supports rebinding. As a minimal example, try
> 
> #include <iostream>
> #include <string>
> #include <memory>
> 
> template <class T>
> struct MyAlloc
> {
>      using value_type = T;
>      using size_type = std::size_t;
>      using propagate_on_container_move_assignment = std::true_type;
> 
>      MyAlloc(int) {}
> 
>      template< class U >
>      MyAlloc(const MyAlloc<U>&) noexcept {}
> 
>      T* allocate(size_type n)
>      {
>          return static_cast<T*>(::operator new(n * sizeof(T)));
>      }
> 
>      void deallocate(T* ptr, size_type) noexcept
>      {
>          ::operator delete(ptr);
>      }
> 
>      bool operator==(const MyAlloc&) const { return true; }
>      bool operator!=(const MyAlloc&) const { return false; }
> };
> 
> int main()
> {
>      std::basic_string<char, std::char_traits<char>, MyAlloc<char>> str("hello", MyAlloc<char>(1));
>      std::cout << str << "\n";
> }
> 
> 

[toc] | [prev] | [next] | [standalone]

#68318

On Wednesday, September 11, 2019 at 9:02:23 AM UTC-4, Manfred wrote:
> On 9/11/2019 1:32 PM, Daniel wrote:
> > 
> > For a stateful allocator, you need to pass an instance of the constructor
> > to the object.
> You probably meant to pass an instance of the allocator.
> In C++ an instance of the constructor is ungood.
> 
Indeed :-)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web