Seems like an improvement to me.
Two other things that would improve this code for me:
(1) “Not doing no assertions” hurts my brain. I wish we could use “if
(ASSERT_ENABLED)” instead.
(2) ASSERT is easier to understand if it only adds code, and does not remove
code. So, in the “ASSERT else
On Apr 19, 2014, at 13:09, Filip Pizlo fpi...@apple.com wrote:
Hey everyone,
When guarding code with macros that are always defined, such as
ASSERT_DISABLED (it's always either 0 or 1), we have a choice between:
if (!ASSERT_DISABLED) {
// do things
}
and:
On Apr 20, 2014, at 12:18 PM, Geoffrey Garen gga...@apple.com wrote:
Seems like an improvement to me.
Two other things that would improve this code for me:
(1) “Not doing no assertions” hurts my brain. I wish we could use “if
(ASSERT_ENABLED)” instead.
+1
(2) ASSERT is easier to
On Apr 20, 2014, at 12:56 PM, Mark Rowe mr...@apple.com wrote:
On Apr 19, 2014, at 13:09, Filip Pizlo fpi...@apple.com wrote:
Hey everyone,
When guarding code with macros that are always defined, such as
ASSERT_DISABLED (it's always either 0 or 1), we have a choice between:
On Apr 20, 2014, at 13:08, Filip Pizlo fpi...@apple.com wrote:
On Apr 20, 2014, at 12:56 PM, Mark Rowe mr...@apple.com wrote:
On Apr 19, 2014, at 13:09, Filip Pizlo fpi...@apple.com wrote:
Hey everyone,
When guarding code with macros that are always defined, such as
On Apr 19, 2014, at 13:36, Filip Pizlo fpi...@apple.com wrote:
Here are some examples.
Guarding a loop that does assertions:
if (!ASSERT_DISABLED) {
for (unsigned index = 0; index m_generationInfo.size(); ++index) {
GenerationInfo info = m_generationInfo[index];
On Apr 20, 2014, at 13:19, Mark Rowe mr...@apple.com wrote:
On Apr 20, 2014, at 13:08, Filip Pizlo fpi...@apple.com wrote:
On Apr 20, 2014, at 12:56 PM, Mark Rowe mr...@apple.com wrote:
On Apr 19, 2014, at 13:09, Filip Pizlo fpi...@apple.com wrote:
Hey everyone,
When
On Apr 20, 2014, at 1:19 PM, Mark Rowe mr...@apple.com wrote:
On Apr 20, 2014, at 13:08, Filip Pizlo fpi...@apple.com wrote:
On Apr 20, 2014, at 12:56 PM, Mark Rowe mr...@apple.com wrote:
On Apr 19, 2014, at 13:09, Filip Pizlo fpi...@apple.com wrote:
Hey everyone,
When
The #if means that the code being guarded isn't indented. I believe that
indenting control flow is a good idea.
Also, using normal if's whenever it would compile and be semantically
equivalent means that the code being protected would benefit from
syntax/type/semantic checking even in a
On Apr 20, 2014, at 14:02, Filip Pizlo fpi...@apple.com wrote:
The #if means that the code being guarded isn't indented. I believe that
indenting control flow is a good idea.
Also, using normal if's whenever it would compile and be semantically
equivalent means that the code being
On Apr 20, 2014, at 2:43 PM, Mark Rowe mr...@apple.com wrote:
On Apr 20, 2014, at 14:02, Filip Pizlo fpi...@apple.com wrote:
The #if means that the code being guarded isn't indented. I believe that
indenting control flow is a good idea.
Also, using normal if's whenever it would
On Apr 20, 2014, at 14:50, Filip Pizlo fpi...@apple.com wrote:
On Apr 20, 2014, at 2:43 PM, Mark Rowe mr...@apple.com wrote:
On Apr 20, 2014, at 14:02, Filip Pizlo fpi...@apple.com wrote:
The #if means that the code being guarded isn't indented. I believe that
indenting control
On Apr 20, 2014, at 3:09 PM, Mark Rowe mr...@apple.com wrote:
On Apr 20, 2014, at 14:50, Filip Pizlo fpi...@apple.com wrote:
On Apr 20, 2014, at 2:43 PM, Mark Rowe mr...@apple.com wrote:
On Apr 20, 2014, at 14:02, Filip Pizlo fpi...@apple.com wrote:
The #if means that the
13 matches
Mail list logo
