What are Plain Old Data (POD) Objects? A POD (plain old data) object has one of these data types--a fundamental type, pointer, union, struct, array, or class--with no constructor. Conversely, a non-POD object is one for which a constructor exists. A POD object begins its lifetime when it obtains storage with the proper size for its type and its lifetime ends when the storage for the object is either reused or deallocated. so basically, a pod struct is something you can create with malloc a pod struct doesn't need new, or inplace new a[b] == *(a+b) == *(b+a) == b[a] structures and classes are identical except for default access control class foobar; // class name declaration = forward declaration (16:41:33) MartianLobster: is there a way to prevent the compiler from creating a default constructor for a class? I don't think there is. The only thing I could think of to simulate this behavior is to define the default destructor, and have it throw an exception on the first line. (16:41:48) kenws left the room (quit: "!"). (16:41:48) Bklyn: MartianLobster: declare one in the private/protected section (16:41:52) Bklyn: MartianLobster: but don't define it (16:41:58) loufoque: MartianLobster: make the constructor private (16:42:10) Bklyn: MartianLobster: alternately, provide some other public ctor (16:42:54) MartianLobster: ok thanks, I guess that is better, because it detects the error at run time, rather than hitting you during debugging (16:42:54) unreal [n=unreal@unaffiliated/unreal] entered the room. (16:43:02) Bklyn: compile time (16:43:12) MartianLobster: oops ye lol if and elses should be alligned ow: int SomeFunction(x) { if (x) > 0 if (x > 100) return 100; else return x; return 0; } Is impossible to read. SomeFunction(-1) returns 0 contrary to implication. !threading (16:49:23) nolyc: threading in C++ is a waste, don't do it (16:49:27) loufoque: !multithreading (16:49:31) loufoque: !factoids (16:49:33) nolyc: factoids is http://www.projectiwear.org/~plasmahh/cpp/factoids.sh (16:49:50) loufoque: there is no other factoids about threads (16:54:54) MartianLobster: is there any reason why static variables are "depricated"? does the ansi commitee just want to force everyone to use the anonymous namespace? (16:54:59) glen_quagmire left the room (quit: Client Quit). (16:55:40) black_13 [n=black_13@ppp-70-245-143-126.dsl.rcsntx.swbell.net] entered the room. (16:56:02) vulture: deprecated - yes, they are deprecated in favour of anonymous namespaces. (well non-member statics are. Static class members aren't deprecated) const Foo& f = Foo(); An instance of Foo is indeed created. It may seem that the instance does not exist for very long because the Foo() syntax appears to create a temporary. However, the temporary is guaranteed to exist for the scope of the reference variable f (ANSI/ISO C++ Standard 12.2/5). with if else clauses, the else binds to the closest if The array bound must be a constant expression when defining a static or automatic array. A dynamic array, as shown, can use a non-constant expression. Stroustrup 6.2 c++ standard 5.5.3 how to call pointers to member functions: void (someclass:pointer) (int); someclase * someobject; (someobject->*pointer)(2) --------------------------- Which one of the following statements accurately expresses the disadvantages of making a function inline? This question illustrates the drawbacks of inlining. Although inlining allows the compiler to perform more aggressive optimizations, there is a reason programmers only make short functions inline. Choice 1 Inline functions always make the program bigger. This is incorrect. Inlining a function may make the program smaller if the size of the function (in terms of machine instructions) is smaller than the function call overhead. Choice 2 Inline functions always make the program slower. This is incorrect. In fact, inline functions tend to be faster than the equivalent non-inline functions since function call overhead is eliminated. When the function is inline, it may be possible for the compiler to completely eliminate calls to it. Choice 3 Inline functions always make the program bigger and slower. This is incorrect. Inline functions may make the program bigger (although it may make it smaller as well). However, it will very seldom make it slower. in fact, inline functions were introduced to eliminate function-call overhead, thus encouraging programmers to write many small functions rather than fewer large, hard-to-maintain functions. In any case, it is definitely incorrect to state that inline functions will always make programs bigger and slower. Choice 4 It is not possible to take the address of an inline function. This is incorrect. If the address of an inline function is taken, the compiler will generate an out-of-line copy of the function and will provide the address of that copy. Choice 5 Correct (selected) It increases compile-time dependencies. This is the correct answer. Since the body of an inline function must be made visible to all translation units that see its declaration, any changes to the body of the inline function forces a recompilation of all those translation units. References ANSI/ISO C++ Standard 7.1.2/4; Stroustrup 7.1.1 ------------------- throwing from a dtor, during a stack unwind caused by an exception terminate() is invoked. This is the correct choice. It is a serious programming error to throw from a destructor if an exception is already causing stack unwinding (C++ Standard 15.2/3). Throwing from a constructor is usually discouraged, but if it is to be done, then uncaught_exception() should be checked first (C++ Standard 15.5.3/1). ---------------------- dynamic binding ~ polymorphism Dynamic binding This is the correct answer. The virtual keyword allows derived classes to override the run-time behavior of parent classes. Thus, the exact behavior of a class is determined by its type at run-time, as opposed to the type of the referring reference or pointer at compile-time. Since the behavior is not known until run-time, this is known as dynamic binding (as opposed to static binding, which happens at compile time). -------------- instantiation ~ object abstraction ~ PersonnelRecord represents an instantiation of some class. This is incorrect. See other comments. An "instantiation" is the run-time representation of a class instance. Choice 5 Correct (not selected) PersonnelRecord represents an abstraction. This is the correct answer. While the C++ language also does not define the word "abstraction," in object oriented terminology, it is a concept that is implemented in part through the grouping of variables that represent the state of an object into a single type to represent that object. ___________________--- An "is a" relationship between classes This is the correct choice. This answer is considered canonical; memorize it; believe it. See Stroustrup 24.3.4. ________________________ Which one of the following statements is true when a derivation inherits both a virtual and a non-virtual instance of a base class? This question shows that a base class must be virtual throughout the inheritance path in order to be consolidated in the object layout. Each derived class object has a base object from the virtual instance and a base object from non-virtual instance. This is correct. The existence of a virtual base does not imply the use of virtual in the base class list where it is not specified (C++ Standard 10.1/6). ------------- 10.1 - assumed double ----------- overriding -- virtual functions overloading -- normal functions, different arg list ------------------- Iterators from an std::list cannot be used with std::sort(). This is the correct answer. std::sort() requires random access iterators, and std::list supplies bi-directional iterators. Note that some implementations do provide a version of the std::sort() algorithm, which works with bi-directional iterators, but this is not required by the standard. ------------------- What happens if a function contains an exception specification and it directly or indirectly throws an exception NOT listed in the specification? This question demonstrates one of the potential consequences of using an exception specification. The exception will result in a call to std::unexpected (). This is correct. Only the exceptions listed in the exception specification may be thrown (C++ Standard 15.4/8). Throwing any others results in a call to std::unexpected() (C++ Standard 15.5.2/1). ------------------ a b !a !b !a && !b !(!a && !b) 1 1 0 0 0 1 1 0 0 1 0 1 0 1 1 0 0 1 0 0 1 1 1 0 ---------------- It invokes undefined behavior. This is correct. When deleting an array, the dynamic and the static type of the object must be the same, or the behavior is undefined (C++ Standard 5.3.5/3).