On 15/06/2013 10:59 p.m., Eric Niebler wrote:
On 13-06-15 03:40 PM, Agustín K-ballo Bergé wrote:
On 15/06/2013 03:43 a.m., Agustín K-ballo Bergé wrote:
On 14/06/2013 11:06 p.m., Eric Niebler wrote:
- Some specific uses of Proto actions in constant expressions fail. GCC
reports an ambiguity with ref-qualifiers in the following scenario:

     struct foo
     {
         int& bar() &
         { return _bar; }
         //~ int&& bar() &&
         //~ { return static_cast<int&&>(_bar); }
         constexpr int const& bar() const &
         { return _bar; }
         constexpr int const&& bar() const &&
         { return static_cast<int const&&>(_bar); }

         int _bar;
     };

     foo().bar();

   For that to work correctly, the 4 overloads need to be provided.

Huh. According to the standard, or according to gcc? I won't work around
a bug in a compiler without filing it first.

I do not know, this little experiment has got me re-reading the standard back and forth, but I am not that fluent in standardeese. I'm still researching this and a few other of the issues.

This,
in turn, means that non-const rvalues (?) cannot be used in constant
expressions since constexpr implies const (in C++11, not anymore in
C++14). Anyway, this is more than I can digest at the moment.

(*) the bit failing to compile is a use of Proto actions as a constant
expression [the `omg` case at everywhere.cpp], due to the issue with
ref-qualifier overloads.

I see you included all of these fixes in your one pull request. I'll
need to go through this carefully and file compiler bugs where
necessary.

I did not, or if I did it was unintentional. I only wanted to submit the first change I did, the one that fixes the duplicated constexprs. That's the single one I'm confident enough that has to be applied. Alas, the last change I did silences a GCC warning, so that one is another good candidate (after refactoring to your coding style). The others probably won't fit your coding style anyways, plus some are even incorrect and further reverted/fixed. They are only intended to be a guide of what has to be changed to please GCC.

I also want to use BOOST_WORKAROUND if we actually include
any temporary workarounds in the code. I say "temporary" because I have
every intention of ripping out all workarounds once the bugs actually
get fixed. I intend to keep this code as clean as possible.


I would appreciate if we could discuss (off-list if appropriate) all these changes I've done as you go through them, whenever you have the time. I am particularly interested in determining whether the code is standard conforming, or whether they are the result of bugs in either GCC or Clang.

A million thanks for your work. It's a huge help.


My pleasure. This has been a productive learning experience for me (one that has not yet ended I hope).

Regards,
--
Agustín K-ballo Bergé.-
http://talesofcpp.fusionfenix.com
_______________________________________________
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Reply via email to