[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Yet another newbie

From: Daniel L. Rall <dlr_at_finemaltcoding.com>
Date: 2000-08-07 23:04:30 CEST

Karl Fogel wrote:
> [snip]
> > 1) The HACKING file says:
> >
> > * Signify internal variables by two underscores after the prefix.
> > That is, when a symbol must (for technical reasons) reside in the
> > global namespace despite not being part of a published interface,
> > then use two underscores following the module prefix. For
> > example:
> >
> > svn_fs_get_ver_prop () /* Part of published API. */
> > svn_fs__parse_props () /* For internal use only. */
> >
> > That's fine iff we can guarantee that no symbol containing two consecutive
> > underscores will ever be seen by a C++ compiler, a guarantee I think we
> > can't safely make. Quoting from the C++ standard, sec 7.4.3.1.2 para 1:
> >
> > -- Each name that contains a double underscore (__) or
> > begins with an underscore followed by an uppercase
> > letter (2.11) is reserved to the implementation for any
> > use.
> >
> > IMHO we should find some other way to name private symbols. Perhaps a
> > different prefix (e.g., svnp_) would be better for that purpose.
>
> The two underscores are not about preventing name conflicts, they're
> about reminding humans that a given object is not part of the
> published interface, despite its appearance in a public place.

According to this snippet from the C++ spec., it's *possible* that names
with double underscores may conflict with symbols that are part of a C++
compiler's implementation. Different syntactic sugar should probably be
adopted for distinguishing between the SVN internal and external API to
avoid the possibility of this compiler symbol name conflict.

-- 
Daniel Rall <dlr@finemaltcoding.com>
Received on Sat Oct 21 14:36:06 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.