C++ problem

Op 06-Mar-16 om 5:58 PM schreef raimond.dragomir@gmail.com:
>> Using all-caps puts the emphasis and warning about possible mistakes in
>> the wrong place.
>
> I don't use all-caps to warn me about possible mistakes (!?) in my code. I use
> all-caps to clearly show in the source that the thing is not what it seems to be
> (regular variable or function call) but something different (may be just
> a simple constant but may be as well A LOT of code behind). This is what
> I want to know when seeing all-caps, this is what I intend when using all-caps.

A function call can also have LOT of code behind it, so that doesn't 
seem to be a good justification to me.

Wouter "Objects? No thanks!" van Ooijen

duminică, 6 martie 2016, 19:26:17 UTC+2, Wouter van Ooijen a scris:
> Op 06-Mar-16 om 5:58 PM schreef raimond.dragomir@gmail.com:
> >> Using all-caps puts the emphasis and warning about possible mistakes in
> >> the wrong place.
> >
> > I don't use all-caps to warn me about possible mistakes (!?) in my code. I use
> > all-caps to clearly show in the source that the thing is not what it seems to be
> > (regular variable or function call) but something different (may be just
> > a simple constant but may be as well A LOT of code behind). This is what
> > I want to know when seeing all-caps, this is what I intend when using all-caps.
> 
> A function call can also have LOT of code behind it, so that doesn't 
> seem to be a good justification to me.
> 
> Wouter "Objects? No thanks!" van Ooijen

You didn't understand the detail: it's about what it looks like not what it 
really is. And for me a function call and LOT of inline code is different.
Sometimes matters, sometimes not, but I want to see a difference when I look
at it.

Op 06-Mar-16 om 6:35 PM schreef raimond.dragomir@gmail.com:
> duminică, 6 martie 2016, 19:26:17 UTC+2, Wouter van Ooijen a scris:
>> Op 06-Mar-16 om 5:58 PM schreef raimond.dragomir@gmail.com:
>>>> Using all-caps puts the emphasis and warning about possible mistakes in
>>>> the wrong place.
>>>
>>> I don't use all-caps to warn me about possible mistakes (!?) in my code. I use
>>> all-caps to clearly show in the source that the thing is not what it seems to be
>>> (regular variable or function call) but something different (may be just
>>> a simple constant but may be as well A LOT of code behind). This is what
>>> I want to know when seeing all-caps, this is what I intend when using all-caps.
>>
>> A function call can also have LOT of code behind it, so that doesn't
>> seem to be a good justification to me.
>>
>> Wouter "Objects? No thanks!" van Ooijen
>
> You didn't understand the detail: it's about what it looks like not what it
> really is. And for me a function call and LOT of inline code is different.

A function call can BE a lot of inline code, that is up to the compiler 
to decide.

But your 'lot of code' aqrgument doen't match

#define number_of_objects 100

So you'd agree that such a macro should not be SHOUTING? (Apart from 
that is shouldn't be a macro in the first place...)

Wouter "Objects? No thanks!" van Ooijen

On 3/6/16 4:22 AM, Wouter van Ooijen wrote:
> Op 06-Mar-16 om 9:17 AM schreef tim...:
>>
>> "David Brown" <david.brown@hesbynett.no> wrote in message
>> news:nbeu4v$t8s$1@dont-email.me...
>>>
>>> To me, "all caps" is shouting - it is a warning that there is
>>> something odd going on here.
>>
>> but there is something odd going on here
>>
>> there's a textual replacement being undertaken, not a function call.
>> This may result in odd behaviour if the author hasn't defined their
>> macro properly
>
> If something hasn't been designed properly all bets are off.
>
> The point is that a straightforward macro or constant doesn't need
> special attention from the reader. What does warrant special attention
> is something that doesn't behave as a constant or function call. SUCH a
> macro (if used at all!) deserves CAPITALS.
>
> Wouter "object? No thanks!" van Ooijen
>

What I see being worth the warning is that it is a name that isn't 
confined by scope. As such, you need to think much more carefully about 
such names, and making them distinct typographically, you get less 
things that might conflict in usage.