Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.std.c++ > #748

Re: Macro replacement interpretation

Show all headers | View raw

On 3/30/2015 7:21 PM, Edward Diener wrote:

> My problem with the diagnostic message is that the message rarely says what
> is the C++ standard syntax as opposed to the alternate syntax that is being
> allowed as a compiler extension. Therefore the alternate syntax becomes the
> C++ standard syntax for many programmers. But I understand that this is a
> problem that is outside the realm of the C++ standard itself. Once the C++
> standard "allowed" non-standard syntax with diagnostics to still be
> standard conforming then it is up to the compilers what the diagnostic
> message entails.
>
>
>
But the C++ Standard says no such thing. What it requires is that the
implementation tell the programmer if it finds something that is contrary
to the Standard (except in the cases where it explicitly says 'no
diagnostic required'). After an implementation has done that the source
code is no longer conforming C++ and so the Standard can say nothing about
it and make no requirements. How could it say anything else? It has
determined that the code is not C++, that is it. If an implementer then
decides that they are willing to continue that is their decision but it has
nothing to do with Standard C++.

All the Standard can say is that a conforming implementation may not
silently accept non-conforming source code.

You may not like this and think it may lead to poor understanding amongst
progranners but it is not the job of either the Standard or an
implementation to educate programmers.

Now what maybe a problem is that the actual requirement is that an
implementation shall emit at least one diagnostic message for any TU that
contains any non-conforming source code. It does not require that it
identify the problematic code, nor does it require that it be the first
instance of a problem. It could, IIUC, accept the whole TU, emit object
code and finally emit a diagnostic such as 'This TU contains at least one
instance of non-conforming code which this implementation has chosen a to
accept.'  It is only QoI that makes such a diagnostic purely academic.

Finally consider:

extern "myC++" {
// whatever I want
}

I think that as long as the implementer has documented the meaning of
'extern "myC++" ' they do not have to even issue a diagnostic for any
extensions they elect to support. Now that is nasty and fortunately no
implementer has gone down that route.

Francis


-- 
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Back to comp.std.c++ | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Macro replacement interpretation Edward Diener <eldiener@tropicsoft.invalid> - 2015-03-26 12:09 -0600
  Re: Macro replacement interpretation James Kuyper <jameskuyper@verizon.net> - 2015-03-27 14:07 -0600
  Re: Macro replacement interpretation Jakob Bohm <jb-usenet@wisemo.com> - 2015-03-29 03:01 -0600
    Re: Macro replacement interpretation Francis Glassborow <francis.glassborow@btinternet.com> - 2015-03-30 12:20 -0600
    Re: Macro replacement interpretation Edward Diener <eldiener@tropicsoft.invalid> - 2015-03-30 12:21 -0600
      Re: Macro replacement interpretation Francis Glassborow <francis.glassborow@btinternet.com> - 2015-03-31 15:39 -0600
        Re: Macro replacement interpretation James Kuyper <jameskuyper@verizon.net> - 2015-04-01 16:39 -0600
      Re: Macro replacement interpretation James Kuyper <jameskuyper@verizon.net> - 2015-03-31 15:38 -0600
        Re: Macro replacement interpretation Jakob Bohm <jb-usenet@wisemo.com> - 2015-04-01 16:38 -0600
          Re: Macro replacement interpretation James Kuyper <jameskuyper@verizon.net> - 2015-04-02 13:24 -0600
            Re: Macro replacement interpretation Francis Glassborow <francis.glassborow@btinternet.com> - 2015-04-03 14:30 -0600
        Re: Macro replacement interpretation Edward Diener <eldiener@tropicsoft.invalid> - 2015-04-03 14:30 -0600
          Re: Macro replacement interpretation James Kuyper <jameskuyper@verizon.net> - 2015-04-04 15:50 -0600

csiph-web