Tsuna <tsuna@warszawa.lrde.epita.fr> writes:
On 2006-09-25, Roland Levillain <roland@lrde.epita.fr> wrote:
Roland Levillain <roland@lrde.epita.fr> writes:
Thierry GERAUD <theo@lrde.epita.fr> writes:
Index: oln/core/abstract/image.hh =================================================================== --- oln/core/abstract/image.hh (revision 526) +++ oln/core/abstract/image.hh (working copy) @@ -29,216 +29,11 @@
[...]
+ /// Typedefs. + typedef oln_type_of(E, topo) topo_t; + typedef oln_type_of(E, psite) psite_t; + typedef oln_type_of(E, rvalue) rvalue_t;
Shouldn't we use type names ending in `_type', rather than `_t', in accordance with
https://olena.lrde.epita.fr/cgi-bin/twiki/view/Olena/CodingStyle
?
We've discussed this point with Théo; he said names ending in `_type' are for public types, while the ones ending in `_t' are for private types. That makes sense to me, so I suggest sticking to this convention.
(BTW, we have to create a new coding style for Olena 1.0 on the Wiki, derived from Olena 0.10's.)
Types ending in _t are reserved by POSIX :P
This rule has been set up by POSIX to avoid namespace pollution, because C has no means to separate standard types from user types. The aforementioned types ending in `_t' are enclosed in a C++ class namespace (which itself belongs to a user namespace). Under these conditions, does this rule still apply? I browsed the Single Unix Specification version 3 (since POSIX isn't freely available), and only found this reference in the « Rationale (Informative) Volume » (XRAT): B.2.12 Data Types The requirement that additional types defined in this section end in "_t" was prompted by the problem of name space pollution. It is difficult to define a type (where that type is not one defined by IEEE Std 1003.1-2001) in one header file and use it in another without adding symbols to the name space of the program. To allow implementors to provide their own types, all conforming applications are required to avoid symbols ending in "_t", which permits the implementor to provide additional types. Because a major use of types is in the definition of structure members, which can (and in many cases must) be added to the structures defined in IEEE Std 1003.1-2001, the need for additional types is compelling. Is this the single reference on that subject in SUSv3?