Re: [proto] Proto v5

[Agustín K-ballo Bergé]

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:


(Sorry for the top-posting. I'm away from my computer.)

The repository *is* compilable, if your compiler is clang built from
trunk. I suspect there are bugs in Proto, gcc, and clang, and sorting
it all out will be fun.

Thanks for your patch. I'll apply it as soon as I can.

Eric


That's the green light I was expecting to start picking Proto v5 at GCC.
I just got the first test compiling and passing successfully
(action.cpp). I have pushed all the changes to my fork of the
repository, so if you are interested keep an eye on it.

Even after disabling the substitution_failure machinery (to get the full
instantiation spew), going through the compiler output is mind
bending... My respects to you, sir!





The fork of Proto v5 at https://github.com/K-ballo/proto-0x correctly 
compiles and passes (almost*) all test cases and examples with GCC 
4.8.1. There are two caveats:


- GCC does not allow the use of `this` within noexcept specifications, 
so those are disabled. This is a bug in GCC (reported by Dave Abrahams 
here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52869)


- 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_castint(_bar); }
constexpr int const bar() const 
{ return _bar; }
constexpr int const bar() const 
{ return static_castint const(_bar); }

int _bar;
};

foo().bar();

  For that to work correctly, the 4 overloads need to be provided. 
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.


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

Re: [proto] Proto v5

[Agustín K-ballo Bergé]

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_castint(_bar); }
 constexpr int const bar() const 
 { return _bar; }
 constexpr int const bar() const 
 { return static_castint 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