standards

Following a question asked here earlier today and multitudes of similary themed questions, I'm here to ask about this problem from stadard's viewpoint. struct Base { int member; }; struct Derived : Base { int another_member; }; int main() { Base* p = new Derived[10]; // (1) p[1].member = 42; // (2) delete[] p; // (3) } According to standard (1) is well-formed, because Dervied* (which is the result of new-expression ) can be implicitly converted to Base* (C++11 draft, §4.10/3): A prvalue of type “pointer to cv D”, where D is a class type, can be converted to a prvalue of type “pointer to cv B”,

Size of char , signed char and unsigned char is defined to be 1 byte, by the C++ Standard itself. I'm wondering why it didn't define the sizeof(bool) also? C++03 Standard $5.3.3/1 says, sizeof(char), sizeof(signed char) and sizeof(unsigned char) are 1; the result of sizeof applied to any other fundamental type (3.9.1) is implementation-defined. [Note: in particular,sizeof(bool) and sizeof(wchar_t) are implementation-defined .69) I understand the rationale that sizeof(bool) cannot be less than one byte . But is there any rationale why it should be greater than 1 byte either? I'm not saying that

C++ standard does not mention anything about the stack or the heap, they are implementation specific , which is true. Even though they are not part of the C++ standard, we end up using them anyway, so much that it's like they are part of the language itself and have to be taken into consideration for memory or performance purpose. Hence my question are there implementations of C++ that doesn't use stacks and heaps? Others have already given good answers about the heap, so I'll leave that alone. Some implementations (e.g., on IBM mainframes) don't use a stack as most people would think of it,

int main() { char c = 0xff; bool b = 0xff == c; // Under most C/C++ compilers' default options, b is FALSE!!! } Neither the C or C++ standard specify char as signed or unsigned, it is implementation-defined. Why does the C/C++ standard not explicitly define char as signed or unsigned for avoiding dangerous misuses like the above code? Historical reasons, mostly. Expressions of type char are promoted to int in most contexts (because a lot of CPUs don't have 8-bit arithmetic operations). On some systems, sign extension is the most efficient way to do this, which argues for making plain char

I'm stuck deciding which to use as both seem to work. Should I be placing links <a> inside of <h2> elements? Or the other way around? What is the correct standard? You can only place <h2> elements within <a> elements if you're working with HTML5, which allows any other elements within <a> elements . Previous specifications (or current ones however you want to look at them) never allowed this. The usual way of doing this is to place <a> within <h2> . This works, has always worked, and has been the only valid way to do it before HTML5, for heading links, as the link refers to the text in that