Groups | Search | Server Info | Keyboard shortcuts | Login | Register


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

Re: Macro replacement interpretation

Message-ID <mffpre$6s4$1@dont-email.me> (permalink)
Newsgroups comp.std.c++
From James Kuyper <jameskuyper@verizon.net>
Subject Re: Macro replacement interpretation
Organization A noiseless patient Spider
References <meiemi$vtj$1@dont-email.me> <RdednfuKHuOQRonInZ2dnUVZ8kednZ2d@giganews.com> <mf8vtn$bp4$1@dont-email.me> <mfc3lg$cqr$1@dont-email.me>
Date 2015-04-01 16:39 -0600

Show all headers | View raw


On 03/31/2015 05:39 PM, Francis Glassborow wrote:
...
> 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.

I don't think so - that already matches the current syntax for language
linkage.
7.5p1 says "Some of the properties associated with an entity with
language linkage are specific to each implementation and are not
described here." but other properties of language linkage are discussed
in the standard, so an implementation's freedom to implement extensions
by use of that syntax is extremely limited.
7.5p2 says "Use of a string-literal other than "C" or "C++" is
conditionally supported, with implementation-defined semantics. [ Note:
Therefore, a linkage-specification with a string literal that is unknown
to the implementation requires a diagnostic. =E2=80=94end note ]"
Note that it is only the semantics that are implementation-defined; that
clause does not permit a supported language linkage to redefine the
syntax rules.

--
James Kuyper


[ 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 | NextPrevious 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