[cmake-developers] Coding style questions

Brad King brad.king at kitware.com
Fri Feb 24 15:04:04 EST 2012


On 2/24/2012 2:32 PM, Yury G. Kudryashov wrote:
> 1. Some classes/methods have doxygen comments, others haven't. Will you
> accept patches that add such comments?

Sure, as long as they are accurate :)

We started that way back in the beginning but haven't really
maintained it.  As more contributors come in to the project
though documentation of the internals is more important.

> 2. The same about 'const' qualifiers on methods.

I'm all for them.  Some day I'd like things to be refactored
enough that the entire generation step can take place with
only 'const' access to the results of the configuration step.
Historically there has been lots of internal refactoring
(and some hacking) which has required 'const' to be added or
removed in places that are not so clean.

> 3. When do you use std::string vs char *?

We don't really have a convention for that.  We won't reject
a patch over this unless there is a bug caused by the choice.

We tend to use char* when we know that the referenced string
isn't going anywhere.  Historically there were also cases
that non-conforming compilers required the choice of one or
the other.  If you prefer "std::string const&" where it will
not create large copies, that's fine with me.

> 3a. What is the difference between std::string and cmStdString?

The latter was introduced long ago when C++ compilers were
not so good at mangling symbol names for code like

   std::map<std::string, std::string>

which if expanded out with default template arguments and
unwrapping the std::string typedef is actually a *really*
long name.  At one time we had problems with toolchains that
made the mangled names so long that their linker had trouble.
Today compilers tend to use a short mangling for std::string
as a special case.

Use std::string unless you're dealing with an existing API that
requires cmStdString.

-Brad



More information about the cmake-developers mailing list