Why do private member variables behaved like protected in the same module when creating deriving class?

[Atila Neves]

On Thursday, 1 November 2018 at 18:46:37 UTC, Patrick Schluter 
wrote:
> On Thursday, 1 November 2018 at 14:28:27 UTC, Atila Neves wrote:
>> On Tuesday, 30 October 2018 at 08:18:57 UTC, Bastiaan Veelo 
>> wrote:
>>> On Tuesday, 30 October 2018 at 00:01:18 UTC, 
>>> unprotected-entity wrote:
>>>> On Monday, 29 October 2018 at 22:24:22 UTC, Bastiaan Veelo 
>>>> wrote:

>> Friends don't let friends use unsigned types for counting.
>
> My experience is exactly the opposite. I inherited a code base 
> of ~200K lines of C written over 3 decades by several 
> developers of varying skills. You can not imagine how many bugs 
> I found thanks to replacing int and long by size_t and 
> uint32_t/uint64_t.
>
> int i = 0;
> ints[--i];  // look ma, no errors or warnings! indeed
>
> with size_t i at least you get segfault or a bus error.

I'm interested in knowing how you don't get a segfault with a 
signed integer. I'm guessing a big block of pre-allocated memory?

> The worst offense is using int on 64 bit machines when working 
> on big datasets, overflows are really more common than people 
> expect.

The problem there is using `int`, not the fact that `int` is 
signed.

> When using unsigned, it requires indeed to be careful when 
> interacting with other variable, but since when is sloppiness a 
> virtue?

In programming? Laziness is always a virtue. If I wanted to be 
careful when I write code, I wouldn't be on this forum.

Besides, even if *I'm* careful, my colleagues might not be, and 
it'll be me paying the gdb price.

> The thing is, all the code that used int as a default was code 
> that was not thought through concerning the range of values and 
> limits of the used variables.

I learned C using 16-bit Borland, which meant `int` was the same 
as `short`. Every time I wrote a for loop back then I had to 
consider if I needed `long` instead.