[Bug c++/65890] [C++03]sizeof(qualified-id) accepted when the operand denotes a non-static member

2015-05-19 Thread frankhb1989 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65890

--- Comment #7 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #6)
 (In reply to frankhb1989 from comment #5)
  Mainly for testing of the conformance.
 
 I don't understand what this means. Testing what? G++? G++ does not exist
 for you to test its conformance to a standard. Most users don't care about
 slavish conformance to a defective specification, they want a useful
 compiler.


Ok, since there is no strictly conforming program concept in ISO C++ as it in
ISO C, I'd better to clarify, the direct point is portability of the legacy
user code. Checking and ensuring the code (carefully kept undefined behavior or
no diagnostics required away) to be standard-compliant is one aspect of
usefulness of the compiler which provides standard modes. How can I do if
'g++ -std=c++03 -pedantic-errors' behaves different than other C++03-conforming
compilers compiling the ill-formed C++03 code, besides to drop the code away? 

  Although it is treated a defect of
  the design and has been changed later, the old rules are still well-defined
  and the published standard itself is consistent. So if I did not get wrong
  about the purpose of '-std=', this should be a bug. Whether it is worth
  being fixed is another problem.
 
 You are wrong about how -std options work. We incorporate dozens of DRs into
 all modes, instead of making them only apply to later standard modes.
 

The manual says nothing about this. It tells me to obtain all the diagnostics
required by the standard, you should also specify -pedantic (or
-pedantic-errors if you want them to be errors rather than warnings). I
thought the standard here is one of the published ones. And there seems to be
no separate options to control the features in individual DRs. If the compiler
frontend does right (by design) as you said, this is a documentation issue,
since I am really confused about what g++ are allowed to do.
Now it seems I'd better simply not rely on these -std options of g++ for these
works.

  On the other hand, I'd debate the resolution of this CWG issue is not pure
  improvement. There could be a trick to distinguish static and non-static
  data members through SFINAE on expressions like 'sizeof((C::x))'. It is
  broken now.
 
 SFINAE in C++03 was not nearly as useful, and doesn't work for private
 members. The language is more useful now, there is no reason to hobble it
 with a foolish consistency to a defective design.

Yes, it is obviously not so useful as C++11/14/1z. But can we just get rid of
C++98/03 totally for this reason? For this issue, the (current) result is, 'g++
-std=c++03 -pedantic-errors' actually implements a dialect of C++03 with some
subtle patches in the standard, which is difficult in many aspects even to
experienced users. And even this is a resolved defect, the design of these
related features in the language is still arguably more or less defective. The
latter is nothing to do with g++ directly, though.


[Bug c++/65890] [C++03]sizeof(qualified-id) accepted when the operand denotes a non-static member

2015-05-19 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65890

--- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org ---
The purpose of G++ is not a validation tool for finding non-portable code. As I
said, it's to be a useful compiler.

It has always been the policy of G++ (and other compilers!) to incorporate DRs
into past standard modes, and that is clearly documented in the manual:


  c++98
  c++03
The 1998 ISO C++ standard plus the 2003 technical corrigendum
and some additional defect reports.
^^^

So this is not a bug and there is no documentation issue.


[Bug c++/65890] [C++03]sizeof(qualified-id) accepted when the operand denotes a non-static member

2015-05-18 Thread frankhb1989 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65890

--- Comment #5 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #3)
 This was changed by
 http://open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#613
 
 It was a defect in the original standard. What possible advantage is there
 in rejecting it in C++03 mode but accepting it in C++11 mode? i.e. why do
 you consider this a bug?

Mainly for testing of the conformance. Although it is treated a defect of the
design and has been changed later, the old rules are still well-defined and the
published standard itself is consistent. So if I did not get wrong about the
purpose of '-std=', this should be a bug. Whether it is worth being fixed is
another problem.

On the other hand, I'd debate the resolution of this CWG issue is not pure
improvement. There could be a trick to distinguish static and non-static data
members through SFINAE on expressions like 'sizeof((C::x))'. It is broken now.


[Bug c++/65890] [C++03]sizeof(qualified-id) accepted when the operand denotes a non-static member

2015-05-18 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65890

--- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to frankhb1989 from comment #5)
 Mainly for testing of the conformance.

I don't understand what this means. Testing what? G++? G++ does not exist for
you to test its conformance to a standard. Most users don't care about slavish
conformance to a defective specification, they want a useful compiler.

 Although it is treated a defect of
 the design and has been changed later, the old rules are still well-defined
 and the published standard itself is consistent. So if I did not get wrong
 about the purpose of '-std=', this should be a bug. Whether it is worth
 being fixed is another problem.

You are wrong about how -std options work. We incorporate dozens of DRs into
all modes, instead of making them only apply to later standard modes.

 On the other hand, I'd debate the resolution of this CWG issue is not pure
 improvement. There could be a trick to distinguish static and non-static
 data members through SFINAE on expressions like 'sizeof((C::x))'. It is
 broken now.

SFINAE in C++03 was not nearly as useful, and doesn't work for private members.
The language is more useful now, there is no reason to hobble it with a foolish
consistency to a defective design.

Not a bug.


[Bug c++/65890] [C++03]sizeof(qualified-id) accepted when the operand denotes a non-static member

2015-04-26 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65890

--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
This was changed by
http://open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#613

It was a defect in the original standard. What possible advantage is there in
rejecting it in C++03 mode but accepting it in C++11 mode? i.e. why do you
consider this a bug?


[Bug c++/65890] [C++03]sizeof(qualified-id) accepted when the operand denotes a non-static member

2015-04-26 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65890

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org ---
Implemented by https://gcc.gnu.org/r145375 which applies to all language modes,
which I'm sure is what was intended.


[Bug c++/65890] [C++03]sizeof(qualified-id) accepted when the operand denotes a non-static member

2015-04-25 Thread frankhb1989 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65890

--- Comment #2 from frankhb1989 at gmail dot com ---
Tested here: http://melpon.org/wandbox/, both G++ 5.1 and 6.0 accepted the
invalid code.


[Bug c++/65890] [C++03]sizeof(qualified-id) accepted when the operand denotes a non-static member

2015-04-25 Thread frankhb1989 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65890

--- Comment #1 from frankhb1989 at gmail dot com ---
Oops, wrong version of case pasted ... I once wanted to use this minimal one:

sizeof(Tag::m);

Nevertheless, the conclusion is the same for this issue.

(There are other mess, e.g. Clang++ 3.6 wrongly interpret 'decltype((Tag::m))'
as pointer to member but I think G++ is right here).