This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch] libstdc++/21244


Paolo Carlini <pcarlini@suse.de> writes:

| Gabriel Dos Reis wrote:
| 
| >Well, I do not believe in them, but that does not matter for this patch :-)
| >Unnamed enumerations or class types should be treated as if given
| >unique names in the program (just like unnamed namespaces).  But, that
| >is something to be taken to the committee.
| >  
| >
| I see. But we have a real issue here:

I was not talking of imagniray issue.  Use of unnamed enumerations or
types are pervasive and I believe it needs appropriate handling.  And,
I said, the outcome of the discussion in the committee does not really
matter for this patch.

| due to the issue discussed in
| c++/19404 in my opinion we should basically avoid any use of anonymous
| nums. At least this is my understanding. If you can figure out a safer
| strategy for this issue, please share it... ;)

Avoiding any use of unamed enumeration is too drastic a cure for this
specific issue in the library.  For example, the following is
perfectly fine

   template<class>
      struct is_integer { enum { value = 0 }; };

  template<class>
      struct is_floatiing_point { enum { value = 0 }; };

  template<class T>
     struct is_arithemtic { 
        enum { 
           value = is_integer<T>::value || is_floatiing_point<T>::value
        };
     };

   template<bool>
      struct Bazzit { ... };

   Bazzit<is_arithmetic<Gee>::value> baz;

I don't think we need to switch to hyper-panic mode.

-- Gaby

         


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]