$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: williamkempf_at_[hidden]
Date: 2001-07-05 09:25:19
--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> 
> ----- Original Message -----
> From: "Toon Knapen" <toon_at_s...>
> 
> > So my point is starting class-names with uppercase does no harm 
(is even
> > usefull) while synching with the STL concerning memberfunctions 
is still
> > a good idea.
> 
> I don't care all that muchn (my personal standard has always been 
MixedCase
> for type names until I started working here, where much code will 
probably
> be boostified), but I do think it makes the transition into the 
standard
> more difficult. For example, NumericTraits<int> or 
Numeric_traits<int> looks
> weird next to iterator_traits<char*>. Also, in template 
metaprogramming it
> is sometimes useful to blur the line between types, values, and 
functions. I
> am not sure it is worth the costs, however.
> 
> In any case, we would have to rewrite lots of boost code and break 
lots of
> users' code to change this convention now. I think that's probably 
the best
> argument for keeping it as is.
I actually think the conflicts are rare enough that this is a non-
issue.  When the conflicts do arise you simply must choose a 
different name for one of the conflicting entities.  The suggestion 
to change the type to *_t is one choice, the other would be to pick a 
synonym or use the get_* wart for this one case in the function 
name.  Since the C++ standard has settled on this as their guidelines 
we should follow suit.  Existing Boost code is also a strong 
argument.  So let's leave well enough alone ;).
> > > > 7.1):Use ``//'' to delimit comments in lieu of ``/*...*/''
> > > >
> > > > We and many other projects use for instance doxygen for 
generating
> > > > documentation. Doxygen (and other similar tools) needs the 
java-style
> of
> > > > commenting using /** ... */. So could we also allow this in 
the
> > > > guidelines ? I know, it's a bit awkward to change rules to the
> protocol
> > > > of some tools but this type of comment has also become quit 
standard.
> > >
> > > Doxygen also responds to ///...
> > > Are /** ... */ really needed for anything?
> >
> > Yep, but this is for one-liners AFAIK. I'll have to check if this 
gives
> > the same results as /** ... */
> 
> I think it works if the ///s are on consecutive lines, but I could 
be wrong.
You aren't wrong.
Bill Kempf