public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "frankhb1989 at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/65890] [C++03]sizeof(qualified-id) accepted when the operand denotes a non-static member
Date: Tue, 19 May 2015 07:55:00 -0000	[thread overview]
Message-ID: <bug-65890-4-flz9EGphE8@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-65890-4@http.gcc.gnu.org/bugzilla/>

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.


  parent reply	other threads:[~2015-05-19  7:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-65890-4@http.gcc.gnu.org/bugzilla/>
2015-04-25 18:09 ` frankhb1989 at gmail dot com
2015-04-26 12:56 ` redi at gcc dot gnu.org
2015-04-26 13:02 ` redi at gcc dot gnu.org
2015-05-18 22:57 ` redi at gcc dot gnu.org
2015-05-19  7:55 ` frankhb1989 at gmail dot com [this message]
2015-05-19  9:45 ` redi at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-65890-4-flz9EGphE8@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).