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 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers