Object-Oriented Programming and Windows Workflow Fundamentals

In exception handling, catching a base class type will catch all derived class exceptions due to polymorphism. This is because a derived class object 'is-a' base class object, so the base class catch block can handle it. This enables handling groups of related exceptions with a single handler.

In UML, association relationships are represented by a line with an arrowhead pointing from the derived class toward the parent or base class. This shows the direction of the relationship. The other options represent different UML concepts - double lines are for implementation, diamond shapes for aggregation/composition.

In C++, if you do not explicitly define an overloaded assignment operator for a class, the compiler automatically generates a default member-wise copy assignment operator.

Peer-to-peer relationship in UML is a type of association where two classes interact as equals, neither containing the other. Unlike aggregation (whole-part) or composition (strong ownership), peer-to-peer represents a collaborative relationship where both classes have comparable status.

Object-oriented programming allows developers to define custom data types using classes and model programs around real-world entities, which makes system conceptualization much easier. Programs cannot automatically teach themselves to resolve runtime errors, meaning the option combining custom types and conceptualization is correct.

In C++, operator new returns a void*, which cannot be implicitly converted to a typed pointer like myObj* without an explicit cast. Additionally, sizeof(foo) allocates space for the pointer size (4 or 8 bytes) rather than the object itself.

If realloc fails, it returns NULL and the original pointer to allocated memory is lost, causing a memory leak. The correct approach is to use a temporary pointer for realloc, check if it succeeded, then assign back. Realloc does not guarantee success, and option C is wrong because realloc does NOT automatically free the original memory on failure.

Encapsulation achieves information hiding by bundling data and methods within a class and controlling access through public interfaces. The other options are benefits of information hiding, not encapsulation itself. Encapsulation is the mechanism that enables information hiding, which in turn reduces interdependencies and supports implementation independence.

Classes using dynamic memory must provide a destructor to free allocated memory and prevent leaks. While copy constructor and assignment operator are also important (Rule of Three), the destructor is essential - it's the only one absolutely required. The question asks 'should be provided' and destructor is the minimum essential.

Encapsulation, inheritance, and polymorphism are widely recognized as the three core foundational pillars of Object-Oriented Programming (OOP). Exception handling is a general runtime control flow feature, and method overloading is a specific implementation of compile-time polymorphism rather than a distinct primary pillar.

Association is a relationship between classes where objects interact but neither owns the other, enabling reusability through collaboration. Inheritance and composition are also reusability mechanisms, but the question seems to focus on association as a form of reusability through inter-class collaboration without ownership.

Workflow code-behind in WF4.0 is not a place where you can write arbitrary C# code. Workflows are XAML-based compositions of activities, and the 'code-behind' is limited to event handlers and specific extension points, not general-purpose C# logic. Custom logic should be encapsulated in custom activities or expressions.

In WF4.0, data can be passed to workflows through multiple mechanisms. InArguments are the primary way to pass input data when starting a workflow or invoking an activity. Bookmark resumption is another mechanism that allows passing data when resuming a paused workflow from a bookmark. Both methods are valid and serve different scenarios.

In the WF4.0 designer, OutArguments are typically accessed by assigning them to variables. The designer binds these arguments to variables that can then be used elsewhere in the workflow. This is the standard pattern for extracting output from activities and workflows. InArguments are for input, not output access.

The ResumeBookmark method requires two parameters: the bookmark name and the value to pass to the resumption point. WorkflowApplication (not WorkflowInvoker) is the correct host type for operations involving bookmarks. The method signature is ResumeBookmark(bookmarkName, value), where value can be null if no data needs passing.

Activity designers in WF4.0 are built using Windows Presentation Foundation (WPF). WPF provides the visual designer surface, the property grid, and all the UI components that make up the workflow designer experience. Silverlight and Windows are not used for WF activity designers.

To associate a custom designer with an activity in WF4.0, you apply the Designer attribute to the activity class. This attribute specifies which designer class should be used to visually represent the activity. The attribute typically points to a class derived from ActivityDesigner. The other options are not valid mechanisms for designer association.

In Windows Workflow Foundation, an Activity Designer is a customized WPF control. It consists of both a XAML file defining the user interface layout and a corresponding code-behind file (like C# or VB.NET) to implement the runtime interaction logic, making the statement false.

In custom activities derived from CodeActivity, the Execute method contains the execution logic. This is where you implement the activity's primary behavior. For NativeActivity, you override Execute differently, and CacheMetadata is for runtime metadata registration, not execution logic. Exec and beginExec are not valid WF4.0 method names.