Groups | Search | Server Info | Keyboard shortcuts | Login | Register
| 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 |
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 | Next — Previous in thread | Next in thread | Find similar
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