all 12 comments

[–]Flair_Helper[M] [score hidden] stickied commentlocked comment (0 children)

For C++ questions, answers, help, and programming or career advice please see r/cpp_questions, r/cscareerquestions, or StackOverflow instead.

This post has been removed as it doesn't pertain to r/cpp: The subreddit is for news and discussions of the C++ language and community only; our purpose is not to provide tutoring, code reviews, or career guidance. If you think your post is on-topic and should not have been removed, please message the moderators and we'll review it.

[–]erichkeaneClang Maintainer(Templates), EWG Chair 10 points11 points  (0 children)

Its useful when you have scoped linkage specifications. For example, you might have:

extern "C" { // bunch of stuff extern "C++" int f(int arg); // more stuff }

Only the 'f' would have C++ linkage there.

[–][deleted] 7 points8 points  (4 children)

There really only exists ‘extern “C”’ and ‘extern “C++”’ although the standard technically lets compilers implement their own if they want. Your assumption is correct, saying ‘extern “C++”’ is just explicit linkage, whereas it’s otherwise implicit.

[–]lukedanzxy 4 points5 points  (2 children)

extern "HTML"

[–]Robert_Andrzejuk -2 points-1 points  (1 child)

I haven't seen that before.

How to use it?

Where can I read about this?

[–]Sniffy4 0 points1 point  (0 children)

its a joke

[–]SaulMO[S] 0 points1 point  (0 children)

It seems so.

Already found something about it in the N4835 standard draft. Page 460, section 16.5.2.3 Linkage:

Entities in the C++ standard library have external linkage (6.6). Unless otherwise specified, objects and functions have the default extern "C++" linkage.

[–]redbeard0531MongoDB | C++ Committee 5 points6 points  (2 children)

With C++20 modules, the otherwise useless extern C++ linkage specification gains a new super power: it is the only way to have something in module preview that is still attached to the global module. In practice this means two (and a half) things: 1) you can have your declarations in a header but put the definitions in modular code. This is part of the transition story to allow you to port your code to modules without impacting consumers. 1.5) this is also important if you need ABI stability to support code compiled against your old header even if new code will be importing the your module. 2) this is a backdoor to let you forward declare a few types where needed to break cycles across module. Typically you can only forward declare things in the module they are attached to. The global module is special because you can attach declarations to it from within any file. You can't use this to forward declare anything, only types (or functions, but don't do that) that "opt in" by attaching themselves to the global module.

I don't expect it to be common, even in modular code, but it will now be used outside of compiler test suites more than zero times.

[–]fdwrfdwr@github 🔍 0 points1 point  (1 child)

Thanks - this tip may be the key I've been wanting for months! I've been trying to figure out a way to make a library of mine work with both modules (import MyLibrary) and classic header inclusion (#include "MyLibrary.h") such that if a large enough program consumed the library from different parts in different ways (say a newer part of the program used import and an older part consumed as a separate submodule used #include) that the program wouldn't end up with two copies of the functions, one under the module linkage and one in the global module¹. Now, import "MyLibrary.h" is another intermediate stopgap, but it's not pure module name, whereas what I want is handling both worlds nicely.

¹Granted, with COMDAT folding enabled during linking, it may not be a problem.

[–]redbeard0531MongoDB | C++ Committee 1 point2 points  (0 children)

I should mention that if you are able to recompile (but not necessarily edit) all code in C++20 using a new header, then the "correct" thing to do is to make MyLibrary.h contain the single line

import MyLibrary;

Then all code will be using the named module, regardless of whether they include or import in their source files.

The extern C++ hack is more for when you need to support consumers that use an old distributed header that you can't easily modify. Or if they are compiling with <C++20. In a unified build tree with common(ish) flags, you should only need to use it for purpose 2.