- 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
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
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
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
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
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]
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,
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
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
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
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
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
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
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
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
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.
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
17 matches
Mail list logo