What a bout adding : Avoid macro name collision by prefixing all the macros with a prefix

[viboes]

Macros a global and don't have scope, so the C naming rules should apply.

I would add a rule, avoid macro name collision by prefixing all the macros with a prefix MYLIB_, MYAPP_.

This is in conflict with Expected and Ensures.

[gdr-at-ms]

A good point about macro naming rules in general.

However, the focus on the implementation detail of Expects() and Ensures() appears to be incommensurable to the intended semantics. If we get contracts, it wouldn't matter.
If a compiler implements something like http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4417.pdf then clearly these two helpers can be implemented as functions, therefore the focus on their being prefixed would not be justified.

[viboes]

I believe the issue with Expects and Ensures is independent of whether they are macros or functions. A library must not introduce global symbols that can clash with other libraries or application code. I don't expect the C++ standard library to add global macros nor global functions.

If we want these global symbols, we need them as keywords of the C++ standard (as e.g. static_cast) and the user could not use them. This will of course be a breaking change and need enough attention. Does the C++ Core guidelines want to add specific keywords to the c++ language?

I' would add a rule: "Libraries must not add global symbols" . If absolutely needed they must follow the C prefix mylib_ or MYLIB_ idiom, to avoid possible clashes with other libraries and applications.

I agree that prefixing is not nice, but at least it doesn't break user code.
If you add them as functions in the namespace gsl::expects/ensures (as suggested already in a GSL issue). The final user can always define its own global function if she considers it helps to make the code clearer, but a library and I even less the GSL library should do it.

A library (in particular GSL) could provide these user only global functions in a specific file (with a BIG comment) as far as it doesn't use them at all. It is the responsibility of the final user to include these files.

If the C++ Core guidelines are for C++17/20 and we know already that Ensures and Expects would be keywords of this C++17/20 standard then and only then I could consider as acceptable that a library could introduce these global symbols with the same semantics (I would say that the library is providing the future feature). The problem is that we don't know if we will have these as keywords in the future released, or do we?

[gdr-at-ms]

We don't know at this point what WG21 will decide. An attribute syntax was suggested; others want keywords. I suspect the particular emphasis on Ensures() and Expects() is out of proportion.

Anyway, regarding symbols: what is the practical difference between a keyword, an operator (which effectively is a global symbol), or an alphabetic function (e.g. swap) that happens to be effectively an operator spelled differently?

Also note that GSL isn't just any ordinary library. GSL assumes C++14.

Regarding "breaking user code", we are interested and attentive to actual user codes that are broken.

Maybe this issue is conflating too many things in one?

[mcvsama]

What about a guideline about naming include-sentinels in header files? Many files use double underscored names for defines, some often use just header name like #include FILENAME_H, which in case of bigger project might conflict. Maybe suggest a guideline to use library name, then module name, and then path?

#ifndef SI__DIR1__DIR2__FILENAME_H__INCLUDED
#define …

Or do you think that such guildeline belong to a code-style book of a project?

[os12]

@mcvsama, there is a better way to control preprocessor inclusions:

#pragma once

[mcvsama]

@os12 Is it part of a standard?

[os12]

I am not sure whether this has been standardized. It works in VC++/GCC/Clang...

[mcvsama]

http://stackoverflow.com/a/23699893 says it's not standarized because of problems with reliability. What a pity. Thanks for sharing that, anyway.

[gdr-at-ms]

#pragma once isn't standard, even if implemented by popular compilers.
Most compilers know how to "optimize" include guard patterns into #pragma once, if they support it.

[AndrewPardoe]

Editors discussed on 11/16/2015.