search

microsoft / STL

MSVC's implementation of the C++ Standard Library.
Other
10.23k stars 1.51k forks source link

Documentation for implementation-defined behaviors #5149

Open FrankHB opened 3 days ago

FrankHB commented 3 days ago

Documentataion for implementation-defined beahviors are part of conformance to ISO C++. The standard requires them to be defined in the documentation of the implementation. Where are they maintained?

Currently, nothing about them are in docs, which can be a surprise, e.g. compared to libc++.

I find no entry about them on learn.microsoft.com. There was a bug but closed as "not a bug" in favor of the language reference.

Despite the status of the core language documentation (irrelavant here) and the fact of lacking a list of implementation-defined behavior as the index of the standard, I find some are too insufficient to be usable at all. For example, list::iterator is an alias of some implementation-defined type, and the document just renders it "implementation-defined", but where is the definition? Although libstdc++ effectively undermines this as unspecified and libc++ is simply missing such entries (hence buggy), copying the text of "implementation-defined" as-is from the standard should not be complete.

For the sake of maintability, the documentation of the library can be better maintained in this repository. If this is out of the scope, clarification and pointing to the right place in README.md should improve the status a bit.

frederick-vs-ja commented 3 days ago

For example, list::iterator is an alias of some implementation-defined type, and the document just renders it "implementation-defined", but where is the definition?

Oops, perhaps we should ask LWG what should be documented for iterator types of containers. It seems that implementations tend to treat them as "unspecified" implementation details together with expostion-only iterator types.

CaseyCarter commented 3 days ago

Oops, perhaps we should ask LWG what should be documented for iterator types of containers. It seems that implementations tend to treat them as "unspecified" implementation details together with expostion-only iterator types.

While not a comment on other uses of "implementation-defined", I think using iterator = implementation-defined; has passed its era of usefulness in the standard. There aren't useful properties of an iterator type that users can't observe directly in the language / library. It might be less work to file an LWG issue to change some implementation-defined items to unspecified than to figure out what to document.