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

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

Wading through template instantiation errors for allocator

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

Contents

  Wading through template instantiation errors for allocator Frederick Gotham <cauldwell.thomas@gmail.com> - 2020-01-03 07:04 -0800
    Re: Wading through template instantiation errors for allocator Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-03 16:57 +0000
    Re: Wading through template instantiation errors for allocator Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-03 21:32 +0200
      Re: Wading through template instantiation errors for allocator Frederick Gotham <cauldwell.thomas@gmail.com> - 2020-01-04 06:12 -0800
        Re: Wading through template instantiation errors for allocator Bo Persson <bo@bo-persson.se> - 2020-01-04 15:53 +0100
          Re: Wading through template instantiation errors for allocator Frederick Gotham <cauldwell.thomas@gmail.com> - 2020-01-04 14:34 -0800
            Re: Wading through template instantiation errors for allocator Manfred <noname@add.invalid> - 2020-01-05 22:31 +0100
    Re: Wading through template instantiation errors for allocator Frederick Gotham <cauldwell.thomas@gmail.com> - 2020-01-06 02:12 -0800
      Re: Wading through template instantiation errors for allocator Frederick Gotham <cauldwell.thomas@gmail.com> - 2020-01-06 23:52 -0800
    Re: Wading through template instantiation errors for allocator Ian Collins <ian-news@hotmail.com> - 2020-01-07 21:15 +1300
      Re: Wading through template instantiation errors for allocator Frederick Gotham <cauldwell.thomas@gmail.com> - 2020-01-07 01:01 -0800
        Re: Wading through template instantiation errors for allocator Ian Collins <ian-news@hotmail.com> - 2020-01-08 07:31 +1300
          Re: Wading through template instantiation errors for allocator Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-07 19:50 +0100
          Re: Wading through template instantiation errors for allocator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 07:06 -0800
            Re: Wading through template instantiation errors for allocator Frederick Gotham <cauldwell.thomas@gmail.com> - 2020-01-14 02:25 -0800
      Re: Wading through template instantiation errors for allocator Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-07 09:20 +0000
      Re: Wading through template instantiation errors for allocator boltar@nowhere.org - 2020-01-08 10:12 +0000
      Re: Wading through template instantiation errors for allocator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-08 09:22 -0800
        Re: Wading through template instantiation errors for allocator Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-08 17:44 +0000
        Re: Wading through template instantiation errors for allocator "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2020-01-08 23:00 +0100
      Re: Wading through template instantiation errors for allocator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 06:48 -0800
    Re: Wading through template instantiation errors for allocator Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-07 09:20 +0000
      Re: Wading through template instantiation errors for allocator Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-07 09:35 +0000
        Re: Wading through template instantiation errors for allocator Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-07 09:43 +0000
          Re: Wading through template instantiation errors for allocator Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-07 10:47 +0100
            Re: Wading through template instantiation errors for allocator Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-07 10:59 +0100
              Re: Wading through template instantiation errors for allocator Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-07 10:15 +0000
                Re: Wading through template instantiation errors for allocator Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-07 11:21 +0100
                  Re: Wading through template instantiation errors for allocator Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-07 10:25 +0000
            Re: Wading through template instantiation errors for allocator Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-07 10:02 +0000
            Re: Wading through template instantiation errors for allocator Bo Persson <bo@bo-persson.se> - 2020-01-07 15:27 +0100
    Re: Wading through template instantiation errors for allocator Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-07 10:36 +0100
      Re: Wading through template instantiation errors for allocator Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-07 10:42 +0100

Page 1 of 2  [1] 2  Next page →

#71021 — Wading through template instantiation errors for allocator

My GNU C++ compiler version 7.4.0 for Ubuntu won't compile the following code and I don't know why.

If I remove the second template parameter, i.e. "size_t capacity", then it works fine.

I wonder if another compiler will compile it?

This code is for a new kind of allocator that uses global (i.e. static duration) memory.

#include <cstddef>  /* size_t */
#include <new>  /* Only for bad_alloc */ 

template<typename T, std::size_t capacity>
class StaticAllocator { 
public: 
	typedef T value_type; 

protected: 

	static T buf[capacity]; 

public: 

	T *allocate(std::size_t const n) 
	{ 
		if (n > capacity) 
			throw std::bad_alloc(); 

		return buf;
	} 

	void deallocate(T *, std::size_t) 
	{ 
		/* Do Nothing */ 
	} 
}; 

template<typename T, std::size_t capacity>
T StaticAllocator<T,capacity>::buf[capacity]; 

using std::size_t;

#include <vector>
using std::vector;

#include <iostream> 
using std::cout; 
using std::endl; 

auto main(void) -> int 
{
	vector< char, StaticAllocator<char, 4> > v; 

	v.push_back('a'); 
	v.push_back('b'); 
	v.push_back('c'); 
	v.push_back('d'); 

	for (auto const &elem : v) 
		cout << elem << endl;
		
	vector< char, StaticAllocator<char, 4> > v2; 

	v2.push_back('x'); 
	v2.push_back('y'); 
	v2.push_back('z');

	for (auto const &elem : v2)
		cout << elem << endl;
		
	// Now try the first vector again
	
	for (auto const &elem : v) 
		cout << elem << endl;
}

[toc] | [next] | [standalone]

#71034

On 2020-01-03, Frederick Gotham <cauldwell.thomas@gmail.com> wrote:
>
> My GNU C++ compiler version 7.4.0 for Ubuntu won't compile the following code and I don't know why.
>
> If I remove the second template parameter, i.e. "size_t capacity", then it works fine.
>
> I wonder if another compiler will compile it?
>
> This code is for a new kind of allocator that uses global (i.e. static duration) memory.
>
> #include <cstddef>  /* size_t */
> #include <new>  /* Only for bad_alloc */ 
>
> template<typename T, std::size_t capacity>
> class StaticAllocator { 
> public: 
> 	typedef T value_type; 
>
> protected: 
>
> 	static T buf[capacity]; 
>
> public: 
>
> 	T *allocate(std::size_t const n) 
> 	{ 
> 		if (n > capacity) 
> 			throw std::bad_alloc(); 
>
> 		return buf;
> 	} 
>
> 	void deallocate(T *, std::size_t) 
> 	{ 
> 		/* Do Nothing */ 
> 	} 
> }; 
>
> template<typename T, std::size_t capacity>
> T StaticAllocator<T,capacity>::buf[capacity]; 

can't check but this is missing initializer?
just say buf and it will compile.

>
> using std::size_t;
>
> #include <vector>
> using std::vector;
>
> #include <iostream> 
> using std::cout; 
> using std::endl; 
>
> auto main(void) -> int 
> {
> 	vector< char, StaticAllocator<char, 4> > v; 
>
> 	v.push_back('a'); 
> 	v.push_back('b'); 
> 	v.push_back('c'); 
> 	v.push_back('d'); 
>
> 	for (auto const &elem : v) 
> 		cout << elem << endl;
> 		
> 	vector< char, StaticAllocator<char, 4> > v2; 
>
> 	v2.push_back('x'); 
> 	v2.push_back('y'); 
> 	v2.push_back('z');
>
> 	for (auto const &elem : v2)
> 		cout << elem << endl;
> 		
> 	// Now try the first vector again
> 	
> 	for (auto const &elem : v) 
> 		cout << elem << endl;
> }
>
>
What's the purpose of allocator when you can allocate only one
vector with it?

-- 
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi --  Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi 
bili naoruzani. -- Mladen Gogala

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

#71049

On 3.01.2020 17:04, Frederick Gotham wrote:
>
> My GNU C++ compiler version 7.4.0 for Ubuntu won't compile the following code and I don't know why.
>
> If I remove the second template parameter, i.e. "size_t capacity", then it works fine.
>
> I wonder if another compiler will compile it?
>
> This code is for a new kind of allocator that uses global (i.e. static duration) memory.
>
> #include <cstddef>  /* size_t */
> #include <new>  /* Only for bad_alloc */
>
> template<typename T, std::size_t capacity>
> class StaticAllocator {


By deriving your allocator from std::allocator<T> it started to compile, 
at least with my compiler and settings.

Theoretically this derivation should not be needed, but then it would 
probably need to define some extra stuff. The allocator requirements 
have been in great flux in the recent standards, I'm not sure what it is 
missing exactly.

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

#71110

On Friday, January 3, 2020 at 7:33:08 PM UTC, Paavo Helde wrote:

> By deriving your allocator from std::allocator<T> it started to compile, 
> at least with my compiler and settings.
> 
> Theoretically this derivation should not be needed, but then it would 
> probably need to define some extra stuff. The allocator requirements 
> have been in great flux in the recent standards, I'm not sure what it is 
> missing exactly.



I've tried this on three compilers: GNU, Microsoft, Clang

The original code which has two template parameters, "typename T, std::size_t capacity", only compiles on the Clang compiler.

The second version with only one template parameter, "typename T", compiles on all three compilers.

Since the second version works on all three compilers, I don't think that this problem is anything to do with how allocators are implemented in the respective standard libraries for these three compilers. Making the change from two parameters to one parameter shouldn't cause compilation to fail.

Here's the code for the second version which works on all three compilers (I've just commented out the 2nd parameter):

#include <cstddef>  /* size_t */ 
#include <new>  /* Only for bad_alloc */ 

std::size_t constexpr capacity = 4;  /* This is instead of a template parameter */

template<typename T /*, std::size_t capacity*/ > 
class StaticAllocator { 
public: 
        typedef T value_type; 

protected: 

        static T buf[capacity]; 

public: 

        T *allocate(std::size_t const n) 
        { 
                if (n > capacity) 
                        throw std::bad_alloc(); 

                return buf; 
        } 

        void deallocate(T *, std::size_t) 
        { 
                /* Do Nothing */ 
        } 
}; 

template<typename T /*, std::size_t capacity*/ > 
T StaticAllocator<T /*,capacity*/ >::buf[capacity]; 

using std::size_t; 

#include <vector> 
using std::vector; 

#include <iostream> 
using std::cout; 
using std::endl; 

auto main(void) -> int 
{ 
        vector< char, StaticAllocator<char /*, 4*/ > > v; 

        v.push_back('a'); 
        v.push_back('b'); 
        v.push_back('c'); 
        v.push_back('d'); 

        for (auto const &elem : v) 
                cout << elem << endl; 
                 
        vector< char, StaticAllocator<char /*, 4 */> > v2; 

        v2.push_back('x'); 
        v2.push_back('y'); 
        v2.push_back('z'); 

        for (auto const &elem : v2) 
                cout << elem << endl; 
                 
        // Now try the first vector again 
         
        for (auto const &elem : v) 
                cout << elem << endl; 
}

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

#71113

On 2020-01-04 at 15:12, Frederick Gotham wrote:
> On Friday, January 3, 2020 at 7:33:08 PM UTC, Paavo Helde wrote:
> 
>> By deriving your allocator from std::allocator<T> it started to compile,
>> at least with my compiler and settings.
>>
>> Theoretically this derivation should not be needed, but then it would
>> probably need to define some extra stuff. The allocator requirements
>> have been in great flux in the recent standards, I'm not sure what it is
>> missing exactly.
> 
> 
> 
> I've tried this on three compilers: GNU, Microsoft, Clang
> 
> The original code which has two template parameters, "typename T, std::size_t capacity", only compiles on the Clang compiler.
> 
> The second version with only one template parameter, "typename T", compiles on all three compilers.
> 
> Since the second version works on all three compilers, I don't think that this problem is anything to do with how allocators are implemented in the respective standard libraries for these three compilers. Making the change from two parameters to one parameter shouldn't cause compilation to fail.
> 
> Here's the code for the second version which works on all three compilers (I've just commented out the 2nd parameter):
> 
> #include <cstddef>  /* size_t */
> #include <new>  /* Only for bad_alloc */
> 
> std::size_t constexpr capacity = 4;  /* This is instead of a template parameter */
> 
> template<typename T /*, std::size_t capacity*/ >
> class StaticAllocator {
> public:
>          typedef T value_type;
> 
> protected:
> 
>          static T buf[capacity];
> 
> public:
> 
>          T *allocate(std::size_t const n)
>          {
>                  if (n > capacity)
>                          throw std::bad_alloc();
> 
>                  return buf;
>          }
> 
>          void deallocate(T *, std::size_t)
>          {
>                  /* Do Nothing */
>          }
> };
> 
> template<typename T /*, std::size_t capacity*/ >
> T StaticAllocator<T /*,capacity*/ >::buf[capacity];
> 
> using std::size_t;
> 
> #include <vector>
> using std::vector;
> 
> #include <iostream>
> using std::cout;
> using std::endl;
> 
> auto main(void) -> int
> {
>          vector< char, StaticAllocator<char /*, 4*/ > > v;
> 
>          v.push_back('a');
>          v.push_back('b');
>          v.push_back('c');
>          v.push_back('d');
> 
>          for (auto const &elem : v)
>                  cout << elem << endl;
>                   
>          vector< char, StaticAllocator<char /*, 4 */> > v2;
> 
>          v2.push_back('x');
>          v2.push_back('y');
>          v2.push_back('z');
> 
>          for (auto const &elem : v2)
>                  cout << elem << endl;
>                   
>          // Now try the first vector again
>           
>          for (auto const &elem : v)
>                  cout << elem << endl;
> }
> 

Seems like the culprit is the rebind member template from the allocator 
requirements. MSVC uses that to make sure that the allocator used for 
vector<T> really allocates T's:

using _Rebind_alloc_t =
  typename allocator_traits<_Alloc>::template rebind_alloc<_Value_type>;


The allocator table says:

A::template rebind<U>::other (optional)[1]

with the very important note:

"Notes:

rebind is only optional (provided by std::allocator_traits) if this 
allocator is a template of the form SomeAllocator<T, Args>, where Args 
is zero or more additional template type parameters."

https://en.cppreference.com/w/cpp/named_req/Allocator#cite_note-1


As your second template parameter is a non-type template parameter (the 
value 4), it doesn't *fully* comply with these requirements and so a 
compiler doesn't have to accept it.


Apparently, some compilers might work if the allocator is *almost* 
correct, but they don't have to.


     Bo Persson

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

#71119

Bo wrote:

> rebind is only optional (provided by std::allocator_traits) if this 
> allocator is a template of the form SomeAllocator<T, Args>, where Args 
> is zero or more additional template type parameters."


Well spotted. Here's my workaround:


#include <cstddef>  /* size_t */
#include <new> /* Only for bad_alloc */

template <std::size_t capacity>
class Outer {

template<typename T>
class StaticAllocator {
public:
        typedef T value_type;

protected:

        static T buf[capacity];

public:

        T *allocate(std::size_t const n)
        {
                if (n > capacity)
                        throw std::bad_alloc();

                return buf;
        }

        void deallocate(T *, std::size_t)
        {
                /* Do Nothing */
        }
};

};

template<std::size_t capacity>
template<typename T>
T Outer<capacity>::StaticAllocator<T>::buf[capacity];

using std::size_t;

#include <vector>
using std::vector;

#include <iostream>
using std::cout;
using std::endl;

auto main(void) -> int
{
        vector< char, Outer<4>::StaticAllocator<char> > v;

        v.push_back('a');
        v.push_back('b');
        v.push_back('c');
        v.push_back('d');

        for (auto const &elem : v)
                cout << elem << endl;
            
        vector< char, Outer<4>::StaticAllocator<char> > v2;

        v2.push_back('x');
        v2.push_back('y');
        v2.push_back('z');

        for (auto const &elem : v2)
                cout << elem << endl;
                
        // Now try the first vector again
        
        for (auto const &elem : v)
                cout << elem << endl;
}


Now I can get back to testing my new allocator.

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

#71158

On 1/4/2020 11:34 PM, Frederick Gotham wrote:
> Bo wrote:
> 
>> rebind is only optional (provided by std::allocator_traits) if this
>> allocator is a template of the form SomeAllocator<T, Args>, where Args
>> is zero or more additional template type parameters."
> 
> 
> Well spotted. Here's my workaround:
> 
> 
> #include <cstddef>  /* size_t */
> #include <new> /* Only for bad_alloc */
> 
> template <std::size_t capacity>
> class Outer {
> 
> template<typename T>
> class StaticAllocator {
> public:
>          typedef T value_type;
> 
> protected:
> 
>          static T buf[capacity];
> 
> public:
> 
>          T *allocate(std::size_t const n)
>          {
>                  if (n > capacity)
>                          throw std::bad_alloc();
> 
>                  return buf;
>          }
> 
>          void deallocate(T *, std::size_t)
>          {
>                  /* Do Nothing */
>          }
> };
> 
> };
> 
> template<std::size_t capacity>
> template<typename T>
> T Outer<capacity>::StaticAllocator<T>::buf[capacity];
> 
> using std::size_t;
> 
> #include <vector>
> using std::vector;
> 
> #include <iostream>
> using std::cout;
> using std::endl;
> 
> auto main(void) -> int
> {
>          vector< char, Outer<4>::StaticAllocator<char> > v;
> 
>          v.push_back('a');
>          v.push_back('b');
>          v.push_back('c');
>          v.push_back('d');
> 
>          for (auto const &elem : v)
>                  cout << elem << endl;
>              
>          vector< char, Outer<4>::StaticAllocator<char> > v2;
> 
>          v2.push_back('x');
>          v2.push_back('y');
>          v2.push_back('z');
> 
>          for (auto const &elem : v2)
>                  cout << elem << endl;
>                  
>          // Now try the first vector again
>          
>          for (auto const &elem : v)
>                  cout << elem << endl;
> }
> 
> 
> Now I can get back to testing my new allocator.
> 

The following satisfies the rebind requirement, although I do not know 
how this may play in a more elaborate context:

template<typename T, std::size_t capacity>
class StaticAllocator {
   public:
     typedef T value_type;

   protected:

     static T buf[capacity];

   public:

     template<typename U>
       struct rebind
       {
         typedef StaticAllocator<U, capacity> other;
       };

     T *allocate(std::size_t const n)
     {
       if (n > capacity)
         throw std::bad_alloc();

       return buf;
     }

     void deallocate(T *, std::size_t)
     {
       /* Do Nothing */
     }
};

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

#71174

Taking in Bo and Manfred's changes, here's my latest rendition:

#include <cstddef>  /* size_t */
#include <new>  /* Only for bad_alloc */ 

static int const thisfile = 0;  /* This serves the same purpose as __FILE__ */

template<typename T, std::size_t t_capacity, std::size_t t_counter, int const *t_file>
class StaticAllocator { 
protected: 

	static T buf[t_capacity];

public:

	typedef T value_type;
	
	template<typename U> 
	struct rebind { 
		typedef StaticAllocator<U, t_capacity, t_counter, t_file> other; 
	};

	T *allocate(std::size_t const n) 
	{ 
		if (n > t_capacity) 
			throw std::bad_alloc(); 

		return buf;
	} 

	void deallocate(T *, std::size_t) 
	{ 
		/* Do Nothing */ 
	} 
}; 

template<typename T, std::size_t t_capacity, std::size_t t_counter, int const *t_file>
T StaticAllocator<T, t_capacity, t_counter, t_file>::buf[t_capacity]; 

using std::size_t;

#include <vector>
using std::vector;

#include <iostream> 
using std::cout; 
using std::endl; 

auto main(void) -> int 
{
	vector< char, StaticAllocator< char, 4, __COUNTER__, &thisfile > > v;

	v.push_back('a'); 
	v.push_back('b'); 
	v.push_back('c'); 
	v.push_back('d'); 

	for (auto const &elem : v) 
		cout << elem << endl;
		
	vector< char, StaticAllocator< char, 4, __COUNTER__, &thisfile > > v2;

	v2.push_back('x'); 
	v2.push_back('y'); 
	v2.push_back('z');

	for (auto const &elem : v2)
		cout << elem << endl;
		
	// Now try the first vector again
	
	for (auto const &elem : v) 
		cout << elem << endl;
}


This compiles and works as intended on GNU and Clang, however it fails to compile on Microsoft with the following error:

        template parameter 't_file': 'thisfile':
        an expression involving objects with internal linkage cannot
        be used as a non-type argument

Anyone got any more ideas? I'm hoping to submit this to Boost soon.

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

#71190

I have cleaned it up again a little. This time I'm using a default template parameter.

#include <cstddef>  /* size_t */
#include <new>  /* Only for bad_alloc */ 

static int this_translation_unit;  /* This serves the same purpose as __FILE__ */

template<typename T, std::size_t t_capacity, std::size_t t_counter, int *t_file = &this_translation_unit>
class StaticAllocator { 
protected: 

	static T buf[t_capacity];

public:

	typedef T value_type;
	
	template<typename U> 
	struct rebind { 
		typedef StaticAllocator<U, t_capacity, t_counter, t_file> other; 
	};

	T *allocate(std::size_t const n) 
	{ 
		if (n > t_capacity) 
			throw std::bad_alloc(); 

		return buf;
	} 

	void deallocate(T *, std::size_t) 
	{ 
		/* Do Nothing */ 
	} 
}; 

template<typename T, std::size_t t_capacity, std::size_t t_counter, int *t_file>
T StaticAllocator<T, t_capacity, t_counter, t_file>::buf[t_capacity]; 

using std::size_t;

#include <vector>
using std::vector;

#include <iostream> 
using std::cout; 
using std::endl; 

auto main(void) -> int 
{
	vector< char, StaticAllocator< char, 4, __COUNTER__ > > v;

	v.push_back('a'); 
	v.push_back('b'); 
	v.push_back('c'); 
	v.push_back('d'); 

	for (auto const &elem : v) 
		cout << elem << endl;
		
	vector< char, StaticAllocator< char, 4, __COUNTER__ > > v2;

	v2.push_back('x'); 
	v2.push_back('y'); 
	v2.push_back('z');

	for (auto const &elem : v2)
		cout << elem << endl;
		
	// Now try the first vector again
	
	for (auto const &elem : v) 
		cout << elem << endl;
}

I'm submitting this to the Boost development mailing list today.

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

#71191

On 04/01/2020 04:04, Frederick Gotham wrote:

> 
> auto main(void) -> int

What kind of an abomination is this?

-- 
Ian.

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

#71192

On Tuesday, January 7, 2020 at 8:15:43 AM UTC, Ian Collins wrote:

> > auto main(void) -> int
> 
> What kind of an abomination is this?


It fails to compile on older C++ compilers, before C++11.

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

#71207

On 07/01/2020 22:01, Frederick Gotham wrote:
> On Tuesday, January 7, 2020 at 8:15:43 AM UTC, Ian Collins wrote:
> 
>>> auto main(void) -> int
>>
>> What kind of an abomination is this?
> 
> 
> It fails to compile on older C++ compilers, before C++11
It should fail to compile with compilers that enforce good taste.

-- 
Ian.

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

#71208

>> It fails to compile on older C++ compilers, before C++11

> It should fail to compile with compilers that enforce good taste.

auto isn't good taste except when necessary.

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

#71258

Ian Collins <ian-news@hotmail.com> writes:

> On 07/01/2020 22:01, Frederick Gotham wrote:
>
>> On Tuesday, January 7, 2020 at 8:15:43 AM UTC, Ian Collins wrote:
>>
>>>> auto main(void) -> int
>>>
>>> What kind of an abomination is this?
>>
>> It fails to compile on older C++ compilers, before C++11
>
> It should fail to compile with compilers that enforce good taste.

So, not on any currently conforming C++ compiler, you mean?

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

#71334

On Friday, January 10, 2020 at 3:06:23 PM UTC, Tim Rentsch wrote:

> > It should fail to compile with compilers that enforce good taste.
> 
> So, not on any currently conforming C++ compiler, you mean?


I, too, tried logic on this argument here on this newsgroup. I found that logic failed. I might try rationale next.

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

#71194

On 2020-01-07, Ian Collins <ian-news@hotmail.com> wrote:
> On 04/01/2020 04:04, Frederick Gotham wrote:
>
>> 
>> auto main(void) -> int
>
> What kind of an abomination is this?

People write some other language that is not C++ ;)
>


-- 
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi --  Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi 
bili naoruzani. -- Mladen Gogala

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

#71216

On Tue, 7 Jan 2020 21:15:32 +1300
Ian Collins <ian-news@hotmail.com> wrote:
>On 04/01/2020 04:04, Frederick Gotham wrote:
>
>> 
>> auto main(void) -> int
>
>What kind of an abomination is this?

Its for developers who like to show off: "Look at me, I'm using unnecessarily
complex syntax for no good reason - I must truly be l33t!"

Anyone who wrote that sort of crap in an interview test for me would have their
CV shown the bin the minute they left.

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

#71226

Ian Collins <ian-news@hotmail.com> writes:
> On 04/01/2020 04:04, Frederick Gotham wrote:
>> auto main(void) -> int
>
> What kind of an abomination is this?

There are some advantages to trailing return types (introduced in
C++11) particularly for function templates where the return type
depends on the argument types.

If C++ were being designed from scratch today, I suspect that they
would be the only syntax accepted, with the leading "auto" omitted.
Other than historical baggage, there's no good reason to have two
different syntax for return types.

Some have argued that we should use trailing return types
consistently in new code.  Others would argue that we shouldn't
use them in cases where they offer no specific advantages, simply
because they're unfamiliar.  I tend to fall into the latter camp,
but I can imagine changing my mind eventually.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    [Note updated email address]
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

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

#71228

On 2020-01-08, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>> On 04/01/2020 04:04, Frederick Gotham wrote:
>>> auto main(void) -> int
>>
>> What kind of an abomination is this?
>
> There are some advantages to trailing return types (introduced in
> C++11) particularly for function templates where the return type
> depends on the argument types.
>
> If C++ were being designed from scratch today, I suspect that they
> would be the only syntax accepted, with the leading "auto" omitted.

Or fun fn func etc...

-- 
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi --  Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi 
bili naoruzani. -- Mladen Gogala

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

#71230

On 08.01.2020 18:22, Keith Thompson wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>> On 04/01/2020 04:04, Frederick Gotham wrote:
>>> auto main(void) -> int
>>
>> What kind of an abomination is this?
> 
> There are some advantages to trailing return types (introduced in
> C++11) particularly for function templates where the return type
> depends on the argument types.
> 
> If C++ were being designed from scratch today, I suspect that they
> would be the only syntax accepted, with the leading "auto" omitted.

"Implicit auto" for the win!

Then, in an even later version of C++ that will be deprecated and one 
will be required to spell out Unicode `ℱ` (capital script F).


> Other than historical baggage, there's no good reason to have two
> different syntax for return types.
> 
> Some have argued that we should use trailing return types
> consistently in new code.  Others would argue that we shouldn't
> use them in cases where they offer no specific advantages, simply
> because they're unfamiliar.  I tend to fall into the latter camp,
> but I can imagine changing my mind eventually.
> 

- Alf

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web