C++ : Multiple Access Specifiers in a Class

On May 27th, Ramshankar in one of the C++ communities at Orkut, asked what seemed like a pretty innocuous question:

class TUid
{
public:
IMPORT_C TInt operator==(const TUid& aUid) const;
static inline TUid Null();
public:
TInt32 iUid;
};


What is the purpose of defining "public" section again? Is it for allowing:

TUid myType = { 0x01232423 };

Multiple public/protected/private sections are very much allowed in C++. In fact, they are seen in MFC wizard generated code. But, the real problem lay in not whether it was allowed, but why has this been allowed? As the C++ standard states that:

12. Nonstatic data members of a (non-union) class declared without an intervening access-specifier are allocated so that later members have higher addresses within a class object. The order of allocation of nonstatic data members separated by an access-specifier is unspecified (_class.access.spec_).

So, to find accurate (reliable) answer I had to email Bjarne, and this was his reply:

Consider

struct S {
public:
int a;
private:
int b;
public:
int c;
private:
int d;
};

Is the compiler allowed to allocate the private members next to each other? (the answer is yes).

The reason for the rule was early ideas of separating private data from public data for some implementations to be able to alleviate code evolution problems when the data layout changed.

For example if you allocated public before private, then adding a private member could be done without affecting the public intercase (after creation). As far as I know, no compiler has ever done that.

However, some compilers do use rearrangement to create more compact layouts. For example:

struct SS {
char a;
public:
int b;
public:
char c;
public:
int d;
public:
char e;
};

If members are allocated in declaration order, the size will be 5 words, but you can (legally) reorder to get 3 words (assuming a 4-byte word).

Personally, I have never found this useful.

I'll leave as an exercise how to reorder to get 3 words . <(^_^)>

But, a mystery still remains as André asked:

Can you write any piece of strictly conforming code for which 9p12 (the above stated standard snippet) makes ANY difference for a non-POD (Plain Old Data) type?

Put another way (this is a different formulation of the same question):
Can you write any piece of code that uses 9p12 (the fact that the order is specified) for a non-POD type, without invoking undefined behaviour?

Can you?!

C++ : 'this' pointer representation

How is the 'this' pointer represented? The C++ standard states:

9.3.2/1

In the body of a nonstatic (9.3) member function, the keyword this is a non-lvalue expression whose value is the address of the object for which the function is called. The type of this in a member function of a class X is X*. If the member function is declared const, the type of this is const X*, if the member function is declared volatile, the type of this is volatile X*, and if the member function is declared const volatile, the type of this is const volatile X*.

But, in many texts I have read that the 'this' pointer is considered a constant. So, I did what I usually do when faced with extreme difficulty, shoot a mail to Mr Stroustrup. Here's a part of conversation that followed:

Dear Mr Stroustrup,

I am sorry if I am disturbing you.
In the C++ standard following is stated for the 'this' pointer.

-----------
9.3.2/1

In the body of a nonstatic (9.3) member function, the keyword this is a non-lvalue expression whose value is the address of the object for which the function is called. The type of this in a member function of a class X is X*. If the member function is declared const, the type of this is const X*, if the member function is declared volatile, the type of this is volatile X*, and if the member function is declared const volatile, the type of this is const volatile X*.
----------

While reading 'Inside the C++ Object model', by Mr Stanley Lippman, I came through 'this' being a constant pointer: myclass *const this, and const myclass *const this. And he writes that this technique was used in 'cfront'.

My point is, I always considered 'this' to being a constant pointer so that we can validate it being a non-LValue as the standard requires it to be. But if we stick to the standard then what Mr Lippman writes turns out to be non-standard. What should I assume? In the C++ community at Orkut, I replied with the following

and it must be

void zaman::shout (const zaman *const this, .....) const {}

and

void zaman::shout(zaman *const this, .....) {}


Waiting anxiously for reply

----------------------------

His reply:

The committee decided (to simplify overloading rules, I think) to express the fact that you cannot change the value of "this" as it being a non-lvalue. I originally expressed its immutability by saying that it was a *const. Undoubtedly, you can find some example where that difference matter, but you'll have to look hard and the likelihood of such an example appearing in real come must be minimal.

-------------------------------

So, it's not a constant pointer. -- Answer

C++ : Are NULL and C++ standard library part of the C++ language?

NO, C++ standard library is not a part of the C++ language but provides support.

The question was raised in an Orkut forum, and who better to ask than Bjarne. This is what his reply to my email was:

Zaman Bakshi wrote:
> Dear Mr Stroustrup,
>
> I hope this email finds you in good health. Sir, can we say that the
> standard C and C++ libraries are a part of the C++ 'language'? Or
> should they be considered as a support for the language and not a part
> of it? This point was raised in the C/C++ programmers' community (that
> I am moderating) with reference to NULL. I cited your TC++PL and wrote
> const int NULL = 0; to be the correct implementation of NULL in C++,
> if it has to be defined. We know that 0 should be used instead of
> NULL, but what if NULL has to be defined. A null pointer is defined in
> the 'C++ standard' but NULL is used with reference to the C libraries.
> My answer was that NULL is not a part of the language but part of the
> C standard libraries referred in the C++ standard.

I distinguish between the C++ language and the C++ standard library.
They are both part of the C++ standard, though, and shipped with every
implementation. Some people (slightly incorrect I think, but
understandably) refer to all that is in "The C++ language standard" as
"the C++ language".

>
> So, are NULL and the libraries part of the 'C++ language'?

I would say no. Even though you can use NULL after #including that
appropriate standard library header, you don't have to.

In C++0x, we'll get nullptr as a keyword indicating the null pointer.

C++ : Free-store versus Heap

What's the difference between the heap and the free-store? The C++ Programming Language keeps on referring them interchangeably. There was as huge cry over this issue in C/C++ programmer's community in Orkut. I had to shoot a mail to Dr. Bjarne Stroustrup. Here's our conversation:

My Mail:

Dear Mr Stroustrup,

Sorry to disturb you again. You have mentioned several times in the TC++PL that 'new' allocates memory from the 'free store (or heap)'. There has been a huge cry on the C++ community at Orkut (that I am moderating) as to whether free-store is the same as heap. The argument given against is that Mr Herb Sutter has mentioned that the free-store is different from the heap:

http://www.gotw.ca/gotw/009.htm

and that global 'new' has nothing to do with the heap.

So, if so, why has TC++PL used 'free store (or heap)' instead of mentioning the use of 'heap' separately.

Waiting anxiously for the response.

Regards,
Zaman Bakshi

His Reply:

Note that Herb says: "Note about Heap vs. Free Store: We distinguish between "heap" and "free store" because the draft deliberately leaves unspecified the question of whether these two areas are related. For example, when memory is deallocated via operator delete, 18.4.1.1 states:"

In other word, the "free store" vs "heap" distinction is Herb's attempt to distinguish malloc() allocation from new allocation.

>
> So, if so, why has TC++PL used 'free store (or heap)' instead of
> mentioning the use of 'heap' separately.

Because even though it is undefined from where new and malloc() get their memory, they typically get them from exactly the same place. It is common for new and malloc() to allocate and free storage from the same part of the computer's memory. In that case, "free store" and "heap" are synonyms. I consistently use "free store" and "heap" is not a defined term in the C++ standard (outside the heap standard library algorithms, which are unrelated to new and malloc()). In relation to new, "heap" is simply a word someone uses (typically as a synonym to "free store") - usually because they come from a different language background.


My Reply:

Thank you Mr. Stroustrup, I had inferred the same thing (about using free store as general -- or better, synonym -- term) and had explained the community. But, I had been requested to reconfirm.

With warm regards,
Zaman Bakshi

C++ : Indeterminate Value

The C language standard clearly 'defines' what an indeterminate value is in C. But the C++ standard is missing this definition. Naturally, we can't adopt the definition in C standard to C++. I wanted to know, and who could have been more reliable than Mr. Bjarne Stroustrup to clear this cloud of uncertainty. So, I dashed an email to him. Here's the conversation that followed:

----------------------------------

Dear Mr Stroustrup,

I am reading D&E, and let me congratulate you for writing such a great book. It has been of a lot of help. Mr. Stroustrup, I am moderating a C++ community on Orkut and there has been a very big issue over what 'indeterminate value' means for the C++ standard. The C standard clearly states what 'indeterminate value' means, but the C++ standard though using (indeterminate value) many times doesn't specify its definition. Should we regard 'indeterminate value' in C++ as being undefined, or should we stick to the C standard's definition (for 'indeterminate value')?

Anxiously waiting for the response.

Regards,
Zaman Bakshi.

----------------------------------

Thanks.

I never used "indeterminate value" and hadn't noticed that it had "snug
into" the C++ standard. I have raised an issue and "indeterminate value"
will be defined in C++0x. You can't "stick to C's definition" because
that definition has never been approved for C++ (was introduced into C
relatively lately, I believe). "indeterminate" simple means that you
don't know what that value is (if could be absolutely any bit pattern
that fits in the object). I believe the C++ standard is specific about
which operations requires a properly initialized object.

Does this address the issues raised in your discussion? If not, please
ask again.

----------------------------------

Dear Mr Stroustrup,

Thank you for replying to my e-mail. Yes, it does answer my issue. This is exactly what I had inferred, but as you know, developers like me can't argue over the standard, so had to clear the doubt. I, like others, are anxiously waiting for C++0x to be out with the standard. Good luck with it. And I thank you again for your response.

Regards,
Zaman Bakshi

----------------------------------

Thanks. I'm working hard for C++0x to become C++09. Doing that requires
a complete feature freeze and complete WP by the end of 2007.