standards

class D: A { B obj; C obj2; } What order of construction here is guaranteed ? I know that D will be constructed after A, B and C, but what I really want to know is whether A is guaranteed to be constructed before B or C, or even whether B is guaranteed to be constructed before C. I know you can have an explicit initialiser list: D(): A(), B(), C() {} but does that initialiser list determine the order of initialisation? Also, does whether or not any of the components do or don't have a default constructor? From the C++03 standard ISO/IEC 14882:2003(E) §12.6.2/5 [class.base.init]: Initialization

I came across an interesting comment in php.net about serialize data in order to save it into the DB. It says the following: Please! please! please! DO NOT serialize data and place it into your database. Serialize can be used that way, but that's missing the point of a relational database and the datatypes inherent in your database engine. Doing this makes data in your database non-portable, difficult to read, and can complicate queries. If you want your application to be portable to other languages, like let's say you find that you want to use Java for some portion of your app that it makes

Most C programmers are familiar with the strdup function. Many of them will take it for granted, yet it is not part of the C Standard (neither C89, C99 nor C11). It is part of POSIX and may not be available on all environments. Indeed Microsoft insisted on renaming it _strdup , adding to confusion. It is rather easy to define it this way (in C): #include <string.h> char *strdup(const char *s) { size_t size = strlen(s) + 1; char *p = malloc(size); if (p) { memcpy(p, s, size); } return p; } But even savvy programmers can easily get it wrong. Furthermore, redefining the function only on systems

Today at work I had an interesting discussion with one of my coworkers. He was surprised when he had the following happen to him: assert(-1 % 10 == -1) //Expecting 9 So when he came to ask me about it, I told him "well, that makes sense. When you divide -1 by 10, you get 0 with -1 remaining. His argument however was that the modulus operator is supposed to hold true to the "always positive" model. I did a little research and found that the modulus he was referring to looks like this: Let q be the integer quotient of a and n. Let r be the remainder. Then: a = n * q + r The definition I was

With normal functions, one can write extern "C" int Frotz(int); // in a header int Frotz(int x) { return x; } With function pointers, however, this appears to have been implemented inconsistently between compilers. extern "C" int Klutz(int (*)(int), int); int Klutz(int (*fptr)(int), int x) { return (*fptr)(x); } In the declaration, the argument is also extern "C" . In the definition, most compilers appear to match these functions and make Klutz an extern "C" function. The Sun and Cray compilers, however, interpret these functions as being different, producing an overloaded int Klutz(int (*fptr

What is the defined behavior in C for UINT_MAX + 1u ? How safe is to assume it is zero? From the standard (C11, 6.2.5/9, emphasis mine): [...] A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type . If UINT_MAX is 10 : (10 + 1) % (10 + 1) == 0 So, yes, it's safe to assume it's zero. paulsm4 It's worth emphasizing that while unsigned behavior is well-defined, signed integer overflow isn't:

I'm bit confused regarding iterator invalidation in deque. (In the context of this question) Following is the excerpts from -- The C++ Standard Library: A Tutorial and Reference, By Nicolai M. Josuttis Any insertion or deletion of elements other than at the beginning or end invalidates all pointers, references, and iterators that refer to elements of the deque. Following is the excerpts from SGI site: The semantics of iterator invalidation for deque is as follows. Insert (including push_front and push_back ) invalidates all iterators that refer to a deque. Erase in the middle of a deque

Does the numbering of clauses, sections, subsections, paragraphs, etc., differ between the C++11 standard ISO/IEC 14882:2011 and the later, gratis-downloadable draft N3337? To be clear: my question is not whether it is advisable to use N3337 in place of the official standard, for that question has already been well answered on Stackoverflow; but only whether the numbering differs. For reference, here is the most nearly relevant non-Stackoverflow answer I find (if you follow the link, refer specifically to the item dated "Sun Mar 18, 12 06:41 PM"). Also for reference, @Nemo draws attention to a