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

[Patrick Schluter]

On Friday, 2 November 2018 at 12:00:05 UTC, Atila Neves wrote:
> 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?

We were talking C here. An array access to offset -1 only goes to 
the memory befor the array. If the array is on the stack it's 
another variable or the return address of the function. It it's 
in the heap, it's generally some overhead structure of the 
allocator or another buffer if the chunk of memory is from a slab 
allocator. Only when using tools like efence or valgrind that 
will allocate a memory page for every allocated block will it be 
possible to crash with a a[-1] access.

>
>> 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.

True. Only 2 billion happens before 4 billion.

>
>> 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.

I didn't say laziness (pereza), but sloppiness (descuidado) it's 
not the same thing.

>
> 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.

Yeah, 16 bit Borland C was the horror if you had to work on far 
and huge memory model. The fun part was that size_t wouldn't have 
helped as it was only a unsigned int (if ever people wanted an 
example of a platform where sizeof(size_t ) < sizeof(long) real 
mode x86 is it).