From: the.beez.speaks@gmail.com   
      
   On 10-03-2024 10:56, Paul Rubin wrote:   
   > anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:   
   > 2+2=5 is obviously wrong and Java doesn't go quite that far.  Java   
   > instead insists that you can add two positive integers and get a   
   > negative one.  That's wrong the same way that 2+2=5 is.  It just doesn't   
   > mess up actual programs as often, because the numbers involved are   
   > bigger.   
      
   Any number representation has its problems - since there is no way to   
   properly represent infinite precision. If you tried to get an arbitrary   
   precision system let represent PI properly, it would blow that system -   
   no matter how much hardware you threw at it. And yes, exceeding that   
   precision will have side effects. Deal with it. The current binary   
   representation was designed for raw speed - and it shows. That's how   
   things are. Exclamations like "BUT IT'S WRONG" may be correct, but   
   without a true alternative it's not gonna change much.   
      
   > That is, C and other such languages have null pointers because they   
   > corresponded so conveniently to machine operations that the language   
   > designers couldn't resist including them.  Java-style wraparound   
   > arithmetic is more of the same.  A bug magnet, but irresistibly   
   > convenient for the implementers because of its isomorphism to machine   
   > arithmetic.   
      
   That's exactly the attitude that some people have down here. Just squat   
   the problem without properly thinking it through. "Yeah, lets limit   
   cells to 16 bits". "Yeah, lets LOOP 'fall through' and examine every   
   single integer possible before stopping", "Yeah, lets introduce ?DO.   
   It's not gonna solve much, but it looks good", "Yeah, lets set 1 CHARS   
   to a single address unit", "Yeah, lets abuse the weird behavior of MOVE   
   when it overlaps and make it into a feature, because it's so neat".   
      
   It's the kind of design decision making that is sold as "pragmatic", but   
   actually is lazy and sloppy.   
      
   In 4tH, I originally started off with "0" as a NULL pointer. I quickly   
   found out that 80000000h (on the 32bit machine) had special properties,   
   which didn't make it suitable for a lot of operations. So, this became   
   the "error" value. As a signed number, it isn't a valid pointer anyway.   
   So that slowly, but surely became 4tHs error value. I haven't regretted   
   that since it works out a lot better than a number like "0".   
      
   > Java also has null pointers, another possible mistake.  Ada doesn't have   
   > them, nor does Python etc.  C++ has them because of its C heritage and   
   > the need to support legacy code, but I believe that in "modern" C++   
   > style you're supposed to use references instead of pointers, so you   
   > can't have a null or uninitialized one.   
      
   It depends a lot on how error checking is handled. You could return it   
   like "errno" or perror(). You could throw an exception. You could return   
   some special value - like a NULL pointer.   
      
   Personally, I think it's kind of an overkill to throw an exception when   
   your substring isn't found (like in INSTR()) - but it's an interesting   
   thought. And what about RAII? Yeah, we hide our NULL pointer in a   
   boolean, so we can throw an exception anyway (sic!). Talking about   
   "sloppy design":   
      
     std::ofstream file("example.txt");   
      if (!file.is_open()) {   
        throw std::runtime_error("unable to open file");   
      }   
      
   The point is - every solution has advantages and disadvantages. Sure,   
   you must inform developers of the disadvantages of a chosen solution.   
   But you must also have the courage to fix things, gravitating to the   
   best solution possible. gets() is a good example. I mean, NULL is   
   already a macro, it shouldn't be difficult to gravitate to a better   
   value. When programming properly, it shouldn't even break much code -   
   unless you thought:   
      
   if (!fopen("myfile.txt", "r")) { .. }   
      
   was a great idea.   
      
   Hans Bezemer   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)