Re: [cmake-developers] Questions about coding conventions

2016-06-14 Thread clinton
- On Jun 14, 2016, at 8:09 AM, Daniel Pfeifer dan...@pfeifer-mail.de wrote: > On Tue, Jun 14, 2016 at 3:14 PM, Brad King wrote: >> On 06/13/2016 10:16 AM, Brad King wrote: Can't `std::ifstream` and `std::ofstream` be used directly? It seams that kwsys does

Re: [cmake-developers] Questions about coding conventions

2016-06-14 Thread Daniel Pfeifer
On Tue, Jun 14, 2016 at 3:14 PM, Brad King wrote: > On 06/13/2016 10:16 AM, Brad King wrote: >>> Can't `std::ifstream` and `std::ofstream` be used directly? It seams >>> that kwsys does some workarounds >> >> Yes, std::{o,f}stream can be used directly. > > On second

Re: [cmake-developers] Questions about coding conventions

2016-06-14 Thread Brad King
On 06/13/2016 10:16 AM, Brad King wrote: >> Can't `std::ifstream` and `std::ofstream` be used directly? It seams >> that kwsys does some workarounds > > Yes, std::{o,f}stream can be used directly. On second thought, std::{i,o}fstream should not be used to open files. The cmsys::{i,o}fstream

Re: [cmake-developers] Questions about coding conventions

2016-06-13 Thread Ben Boeckel
On Mon, Jun 13, 2016 at 16:14:51 +0200, Daniel Pfeifer wrote: > On Mon, Jun 13, 2016 at 2:09 PM, Ben Boeckel wrote: > > Usually NULL means "unset". See properties, > > variable values, etc. As an output, any place which doesn't care should > > already be using

Re: [cmake-developers] Questions about coding conventions

2016-06-13 Thread Brad King
On 06/10/2016 05:43 PM, Daniel Pfeifer wrote: >> Please look at documenting this in CONTRIBUTING.rst once we resolve >> this discussion. > > ok. +1 to Steve's suggestion of putting it in cmake-developer(7). >>> So far it is pretty consistent. But how to name free functions and >>> macros? I

Re: [cmake-developers] Questions about coding conventions

2016-06-13 Thread Daniel Pfeifer
On Mon, Jun 13, 2016 at 2:09 PM, Ben Boeckel wrote: > On Mon, Jun 13, 2016 at 00:03:29 +0200, Daniel Pfeifer wrote: >> Can you show an example? To be clear: We are looking for a function, >> that has a code path for `str == NULL` and a *different* codepath for >> `str[0]

Re: [cmake-developers] Questions about coding conventions

2016-06-13 Thread Ben Boeckel
On Mon, Jun 13, 2016 at 00:03:29 +0200, Daniel Pfeifer wrote: > Can you show an example? To be clear: We are looking for a function, > that has a code path for `str == NULL` and a *different* codepath for > `str[0] = '\0'`. As input to functions? Usually NULL means "unset". See properties,

Re: [cmake-developers] Questions about coding conventions

2016-06-12 Thread Daniel Pfeifer
On Sun, Jun 12, 2016 at 4:26 PM, Ben Boeckel wrote: > On Fri, Jun 10, 2016 at 15:30:05 +0200, Daniel Pfeifer wrote: >> Passing and returning strings: We have `const char*`, `std::string`, >> and `std::string const&`. Unifying this can affect performance. >> Storing `const

Re: [cmake-developers] Questions about coding conventions

2016-06-12 Thread Ben Boeckel
On Fri, Jun 10, 2016 at 15:30:05 +0200, Daniel Pfeifer wrote: > Passing and returning strings: We have `const char*`, `std::string`, > and `std::string const&`. Unifying this can affect performance. > Storing `const char*` in a `std::string` creates a (potentially > unneded) copy (assuming it is

Re: [cmake-developers] Questions about coding conventions

2016-06-10 Thread Daniel Pfeifer
On Fri, Jun 10, 2016 at 3:43 PM, Brad King wrote: > On 06/10/2016 09:30 AM, Daniel Pfeifer wrote: >> By looking at the CMake source code, there are some inconsistencies >> regarding coding conventions. This is not a big problem and fixing >> them probably does not have a

Re: [cmake-developers] Questions about coding conventions

2016-06-10 Thread Daniel Pfeifer
On Fri, Jun 10, 2016 at 5:19 PM, Tobias Hunger wrote: > On Fr, 2016-06-10 at 16:34 +0200, Daniel Pfeifer wrote: >> If used consistently, it indicates that you are dealing with a member. >> I personally prefer `this->` over `m_`. With semantic syntax >> highlighting you

Re: [cmake-developers] Questions about coding conventions

2016-06-10 Thread Tobias Hunger
On Fr, 2016-06-10 at 16:34 +0200, Daniel Pfeifer wrote: > If used consistently, it indicates that you are dealing with a member. > I personally prefer `this->` over `m_`. With semantic syntax > highlighting you probably don't need either of them. But then again, > you often look at code that does

Re: [cmake-developers] Questions about coding conventions

2016-06-10 Thread Brad King
On 06/10/2016 10:34 AM, Daniel Pfeifer wrote: >> May I asked why "this->" is used so often? > > If used consistently, it indicates that you are dealing with a member. > I personally prefer `this->` over `m_`. ... > you often look at code that does not have semantic highlighting (eg. > inside

Re: [cmake-developers] Questions about coding conventions

2016-06-10 Thread Daniel Pfeifer
On Fri, Jun 10, 2016 at 4:16 PM, Tobias Hunger wrote: > On Fr, 2016-06-10 at 15:30 +0200, Daniel Pfeifer wrote: >> Naming conventions: Classes are named cmLikeThis. Member functions >> and member variables are named LikeThis. Local variables are named >> likeThis. Members

Re: [cmake-developers] Questions about coding conventions

2016-06-10 Thread Tobias Hunger
On Fr, 2016-06-10 at 15:30 +0200, Daniel Pfeifer wrote: > Naming conventions: Classes are named  cmLikeThis. Member functions > and member variables are named LikeThis. Local variables are named > likeThis. Members are always accessed with `this->`. So far it is > pretty consistent. But how to

Re: [cmake-developers] Questions about coding conventions

2016-06-10 Thread Brad King
On 06/10/2016 09:30 AM, Daniel Pfeifer wrote: > By looking at the CMake source code, there are some inconsistencies > regarding coding conventions. This is not a big problem and fixing > them probably does not have a high priority. > I would like to know what conventions to follow for new code.

[cmake-developers] Questions about coding conventions

2016-06-10 Thread Daniel Pfeifer
Hi, By looking at the CMake source code, there are some inconsistencies regarding coding conventions. This is not a big problem and fixing them probably does not have a high priority. I would like to know what conventions to follow for new code. Formatting: No longer an issue. A .clang-format is