On 7/12/16 12:58 AM, dandl wrote:
Try to write a fully standard compliant standard library without using any
of
the reserved namespace!!!
This is the key point that has been missed so far. The C/C++ standards do
not provide a mechanism by which the supplier of a library can reserve or
sequester some range of identifiers, for both historic and possible future
use, and at the same time be guaranteed to conflict with neither the
provider of an implementation nor the user of the library. Therefore a
choice has to be made.
The fact that the ISO committee didn't provide/mandate a system doesn't
mean that some system can't be adopted, outside the standard. The C
standard is designed to be supplemented by auxiliary standards, and
enforcing such a rule would be outside the scope the standard wanted to
take (and when the standard first was developed, domains weren't as
expected).
Intruding on the implementation space in violation of the standard is not
the best solution to the problem.
The safest solution (and one widely adopted) is to choose a prefix of
sufficient length and starting with a letter. It should be one that is
highly likely to be unique to the enterprise and then be applied to all
visible identifiers. The ownership of that prefix could be backed up by
ownership of a matching domain, trademark, registered company name, etc.
[The Java domain thing is just plain silly, and widely breached.]
Yes, using a domain you own is a good ad-hock unique prefix. If you do
something like that, at least when you get a conflict, you can point to
the other party and ask them why they are using something they don't own
(There might be some codes gotten this way that might have other
possible meanings). Trademarks and registered names may not be the best
as often the reservation is somewhat limited in scope, and may be
confused with an ordinary word (like Coke).
In fact Sqlite has done an excellent job of exactly that, with one
exception: they chose to add an unnecessary underscore before the guard
prefix and thereby became non-compliant. It should simply be removed (or
have been removed -- perhaps it's now too late).
--
Richard Damon
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
