[SG10] Example for __cpp_lib_byte

Bjarne Stroustrup bjarne at stroustrup.com
Sun Oct 22 12:25:08 CEST 2017



On 10/22/2017 1:52 PM, Nicolai Josuttis wrote:
> Oops,
> sorry, but I STRONGLY disagree here.
>
> Please correct me if I am wrong.
> Especially if you know better HOW to solve the problem
> feature macros solve, instead.

Keep your shirt on. I'm not a little inexperience middle manager that 
can be intimidated by your superior reputation or by liberal use of 
CAPITAL LETTERS.

We need a serious discussion.

>
> Am 22.10.2017 um 04:28 schrieb Bjarne Stroustrup:
>> I see the utility of feature macros for library implementers, especially
>> for supporting old compilers. I hear the argument that they allow faster
>> use of new and experimental features, but I don't think that argument
>> has been sufficiently well articulated and weighed against the damage
>> done to the majority uses of the language and the evolution of the
>> language and its tools infrastructure.
>>
> We use a real problem here.
> We have a problem that ONLY can be solved by preprocessor abilities.
> The whole PURPOSE of the preprocessor including macros is to deal with
> implementation details.
>
> It is a fact that implementation only partially support things
> and don't give any portable hint what they support.
> (Microsoft even doesn't handle __cplusplus is a useful fashion.)
> This will not change.

I said that I understood the advantage to library writers, but I also 
asked for a better articulation of the problem. I obviously cannot offer 
an improved solution to a weakly articulated problem. I cannot even 
decide whether the problem is among those that it is important to solve 
in the standard given our limited time and resources. Furthermore, for 
every every new feature we should considered not just the problems it 
solves, but also what problems it might introduce and what existing 
problems it might make worse. I feel this is lacking in this case.

Also, "The whole PURPOSE of the preprocessor including macros is to deal 
with implementation details" is not historically accurate, and even if 
it was that would not imply that it was a good solution to the 
implementation problems that it is used to mitigate.

>
>> I fear the utility of feature macros to define dialects: "if (feature I
>> don't like) static_assert(false, "don't use this; it's bad for you)."
>> Fortunately this is (for me) mainly hypothetical, but over the years I
>> have had *many* hopeful questions along the lines of "is there a
>> standard way of disabling X?". I strongly prefer to leave such potential
>> major damage for local gain to non-standard hacks.
>>
> How can a feature macro be used to disable a feature???

Simple. As I said above:

	static_assert(false, "don't use this; it's bad for you");

Place this in a header and require it for corporate use and you are done.

I hope I'm not giving you new bad ideas. As I said, the equivalent has been frequently suggested to me over the years.

>
>
>> Worse: the more macros, the harder it is to develop new tools for C++.
>> Marcos is a major reason C++ is tool poor compared to more modern
>> alternatives.
>>
> So, the only other option we have is to use platform specific "feature
> macros". That is a lot worse because the resulting code is hard to write
> and hard to maintain.
> And the tool problem, you have in mind, Bjarne, will be a lot worse with
> that.
> So NOT having feature macros does not solve any problem you describe,
> but makes things significantly worse.

So you say. My guess is that you are flat wrong. Use of macros is at the 
root of most of our tool problems. I think the best you could argue is 
that adding a few dozen more standard macros won't make it worse (even 
though that set is open-ended). I won't say that the burden of proof is 
on proposers of more macros, but I will say that we need to consider 
this problem before adding many more macros to the standard. The work to 
start that discussion fairly falls on the proposers.

Theoretically, localizing the use of macros could alleviate the problem, 
but I have not seen a proposal  for that (unless you count my old 
macroscope proposal).

>
>> Worse still: Over the last few weeks, I have been traveling, talking
>> with *many* senior developers from a variety of major C++ users. They
>> are excited about the promise of modules. In particular, many see it as
>> an opportunity to finally cleaning up their code to get it more hygienic
>> by getting rid of most macros, undisciplined aliases, and forward
>> declarations. Adding macros to the standard could reduce the internal
>> representation(s) of modules to token soup, and give us "modules" that
>> do not offer real modularity.
>>
> Can you give a concrete example, please?

Look at any representation for representing a module (the IPR 
http://www.stroustrup.com/gdr-bs-macis09.pdf ) would be an example. Each 
time you have a macro, you need to represent the alternatives. These 
alternatives need not maintain scope or grammar rules, so the 
representation of cannot be a proper AST, but reduces to "token soup". A 
lot of such token soup defeats the aims of modules, i.e. modularity. For 
example:

int f (int
#ifdef FOO
, int
#else
, double
#endif
);

#ifdef BAR
do_something {
#endif

....

#ifdef BAR
}
#endif

I have seen these and far worse in production code, and I assume that so 
have you. I'm sure that we can get many more examples if we start looking.

>
>> In haste: I am still traveling. I recommend treading very carefully
>> here. I am not a fan of macros, not even feature macros.
>>
> Obviously ;-)
> But you don't want to deprecate #define, don't you? ;-)
> (I am a bit honest here, there is a good reason we have it, for cases
>   that can't be solved by core language features).

I don't think there are good reasons except compatibility and the 
management of language evolution. In principle, we can do without 
#define . My long-term aim is to eliminate #define. By long-term, I do 
not mean next year or C++20. To be responsible stewards of C++'s 
evolution, we must think in decades, and try not to make problems worse 
by short-term fixes.

>
> IMO, we have a useful feature that solves a significant problem.
Which problem exactly? (you repeat yourself, so I do too)
> It does NOT introduce the problem Bjarne fears (because it can't).
I disagree (see above).

> Not having it is a lot worse.

You repeat yourself again, presupposing your conclusion.

> So what's the problem?
That the problem to be solved has not (to my knowledge) been carefully 
articulated and its side effects (incl. long-term effects) have not been 
carefully explored.

Note that I do not assume that a principled solution to your problem is 
impossible. However, a good solution may not be more macro hacking. For 
example, note that I strongly opposed the original compile-time if 
because it had the problems with tooling and ASTs that I mentioned 
above, but I accepted the current compile-time if because it does not 
have those problems.

>
>
>> On 10/21/2017 9:03 AM, Herb Sutter wrote:
>>>>> Furthermore, since we usually are in the business of standardizing
>>>>> things that users otherwise have to write many times themselves: Has
>>>>> SG10 considered actively defining a <std-forward-compat> header
>>>>> library that does the above for all the things it can, the idea being
>>>>> that users who have to target multiple implementations at various
>>>>> stages of conformance can include <std-forward-compat> after all their
>>>>> standard library's own headers and write their code more closely
>>>>> against the actual latest IS's std:: library,
>>>>> without having to reinvent the above by hand (incompatibly on
>>>>> different systems), as a transition tool to help encourage people to
>>>>> adopt the latest standard?
>>>> That's a very interesting idea, but might it make more sense for it
>>>> to be
>>> done
>>>> by LWG, as opposed to SG10?
>>> Whoever owns the feature tests should own how to use and adopt them so I
>>> would think the <std-forward-compat> header would fall under that. After
>>> all, it should be kept in sync with the feature tests.
>>>
>>> So initially to get the ball rolling, since we have a set of tests
>>> already
>>> that are maintained by SG10, wouldn't it be expected that the initial
>>> header
>>> to be created by SG10 too -- again, just to get the ball rolling?
>>>
>>> Going forward, if we standardize feature tests, then we will presumably
>>> expect each proposal author to suggest a feature test (where appropriate)
>>> and a <std-forward-compat> mechanism (if appropriate).
>>>
>>> Is that reasonable?
>>>
>>>
>>> _______________________________________________
>>> Features mailing list
>>> Features at isocpp.open-std.org
>>> http://www.open-std.org/mailman/listinfo/features
>>



More information about the Features mailing list