From: demarcus_at_hotmail_com@tellus.orb.dotsrc.org   
      
   >> Hi,   
   >>   
   >> If you read this code, what do you think it does?   
   >>   
   >> CameraMan cm( nullptr );   
   >>   
   >> It could mean anything, right?   
   >   
   > It could, but it should be something easily guessed like   
   > "nonexistent", "missing", "not available" or "not applicable".   
   > Fundamentally, it's no different from   
   >   
   >       CameraMan cm( someptr );   
   >   
   > because you need to know what the CameraMan constructor does and   
   > what parameters it takes to understand what's going on here anyway.   
   > What a null pointer argument means should be part of the contract, but   
   > it should be straightforward once you understand the bigger picture.   
   > (Yes, I was apparently repeating myself from the previous thread. :))   
   >   
      
   I claim there is a subtle difference. If you read   
      
   CameraMan cm( nullptr );   
      
   you have to check the documentation of the constructor but if you read   
      
   CameraMan cm( angleptr );   
      
   then you instantly see that it's at least an angle there and it also   
   gives you the information that the existence of the angle is decided at   
   run-time. With   
      
   CamerMan cm( ANGLE_MISSING );   
      
   you see that the angle is missing already at compile time. So I would   
   say yes, for readability, anything is better than   
      
   CameraMan cm( nullptr );   
      
   (given it can be interpreted as "missing", "N/A", etc. as you say)   
      
   >> Even if this could be solved I realize that it's quite a lot of   
   >> boilerplate code just to prevent the explicit nullptr, so I'm about   
   >> to abandon that strategy. I still think though, that the explicit   
   >> nullptr is troublesome so I want at least to come up with some   
   >> coding guideline.   
   >   
   > I don't see the point of preventing an explicit nullptr argument.   
   >   
   >       int* anglep = nullptr;   
   >       CameraMan cm( anglep );   
   >   
   > This will still compile and the constructor should be prepared for   
   > this, anyway.   
   >   
      
   Yes, but it allows me to directly see that it's something that can   
   change in run-time. Above is perfectly fine because anglep gives me all   
   the information I need; it's a pointer to an angle, and it could be   
   missing. With   
      
   CameraMan cm( nullptr );   
      
   I don't even know /what/ is missing.   
      
   >> My question is; would you all agree that nullptr is a magic number   
   >> that always should be replaced with a label like the following?   
   >> const std::nullptr_t BAD_ANGLE = nullptr;   
   >   
   > I don't agree; I believe common constants such as 0, 1, 2, false, true,   
   > nullptr, etc. are acceptable as unnamed constants. 'time(NO_STORE)'   
   > or 'execl(..., END_OF_ARGS)' only makes the code verbose without   
   > facilitating the understanding any further.   
   >   
      
   My idea is to come up with a coding guideline that removes all those   
   split seconds you spend on trying to understand what's going on. It's   
   just a split second, yes, but summed up they might make you annoyed   
   reading code, when it could be the opposite; enjoying.   
      
   I haven't checked up on execl but never mind. My theory goes like this.   
   If execl would work perfectly with just providing the args, like   
   execl( arg1, arg2, arg3 );   
   then END_OF_ARGS will distract you for a split second and should be removed.   
      
   However, if the arg list must be terminated with 0 or the like, then   
   END_OF_ARGS is way better than 0 or NULL since otherwise you must check   
   the documentation of execl to understand what the last value actually   
   means. Checking the documentation is more than a split second and summed   
   up it will annoy you.   
      
   > (I often go further and use 24 [hours in a day] or 86400 [seconds in   
   > a day] as unnamed constants without any confusion, though if I were   
   > writing so for someone else, it might not get through code review...)   
   >   
      
   This was a nice example. Here 24 is so rooted into peoples minds so the   
   following function   
      
   clock.setHours( 24 );   
      
   is much better than   
      
   clock.setHours( ONE_DAY );   
      
   since you for a split second will start to wonder if the programmer   
   meant only the day and not the night. Writing   
      
   clock.setSeconds( 86400 );   
      
   without a comment would probably not get through a code review as you say.   
      
   > The fact that a null pointer means a bad angle and not something else   
   > bad in the particular context should be made clear from the fact that   
   > the function takes an angle parameter.   
   >   
      
   True, I stumbled on my own guidelines. BAD_ANGLE should be changed to   
   MISSING_ANGLE. The nullptr, and possible symbolic constants set to   
   nullptr, should always be easy interpretable as "nonexistent",   
   "missing", "not available" or "not applicable", as you said.   
      
      
   Regards,   
   Daniel   
      
      
   --   
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)