vb.net 128 barcode generator PARAMETERIZED FUNCTIONS AND TYPES in C#.NET

Generation PDF417 in C#.NET PARAMETERIZED FUNCTIONS AND TYPES

property ListNode<T>^ Current { ListNode<T>^ get() { if (theList->changed) throw gcnew InvalidOperationException(); return current; } } virtual bool MoveNext() { if (theList->changed) throw gcnew InvalidOperationException(); beginning = false; if (current != nullptr) { current = current->next; } else current = theList->First; if (current != nullptr) return true; else return false; } virtual void Reset() { theList->changed = false; current = theList->First; } ~ListEnumerator() {} }; // end of ListEnumerator }; // end of MyList int main() { MyList<int>^ int_list = gcnew MyList<int>(); int_list->Add(10); int_list->Add(100); int_list->Add(1000); int_list->Add(100000);

int_list->Add(500); int_list->Remove(10); int_list->Remove(1000); int_list->Remove(500); int_list->Add(50); // Iterate through the list using the for each statement, // displaying each member of the list at the console. for each (ListNode<int>^ node in int_list) { Console::WriteLine(node->item); // int_list->Remove(50); // danger: modifying the collection } } The output of Listing 11-8 is as follows: 100 100000 50 There are a few points to notice about Listing 11-8. Recall the IEnumerable implementation on a deck of cards in 9 (Listing 9-15). In that example, we chose to implement the nongeneric IEnumerable. Implementing the generic IEnumerable<T> adds an additional layer of complexity because IEnumerable<T> also inherits from IEnumerable. That means MyList must implement two different versions of GetEnumerator: one for the generic IEnumerable and one for the nongeneric interface. This is done via explicit interface implementation. In fact, just as in Listing 9-15, we make the interface implementation methods private and define a public method that for each actually uses and that the private interface implementation functions call. This helps improve performance since the enumeration does not require a virtual function call. Note also that we had to add a destructor to the ListEnumerator class. Without the destructor, the compiler complains that we did not implement IDisposable::Dispose. This is because IEnumerator<T> also inherits from IDisposable (the nongeneric IEnumerator does not). A C++/CLI destructor on a managed type is emitted as the Dispose method, as discussed in 6. Finally, we have added a Boolean field in MyList that detects whether MyList is changed during the enumeration. As you may recall, in Listing 9-15, we made a copy of the card deck and used it in the enumerator class. With this version, you avoid the copy, which could be expensive for a large list, and instead generate an exception when the list is modified. To demonstrate the exception, try uncommenting the line calling the Remove method during the iteration. If we permitted the item to be successfully removed during the iteration, the collection would be considered corrupted, and the enumeration would produce undefined results. The behavior of for each would not be as expected and would be very confusing for consumers of the type. Unless you create a working copy of the collection, you should always implement some code that checks that the type has not been modified.

The restriction noted previously on the use of methods, properties, and other constructs on a type parameter would severely limit the usefulness of generic types, were it not for the ability to get around the restriction by using constraints. Constraints are specific requirements put on a type parameter that limit, or constrain, the types that may be used as type arguments. Essentially, the constraints limit the possible type arguments to a subset of all possible types. By imposing constraints, you may write generic code that uses the methods, properties, and other constructs supported by the constrained subset of types. There are several types of constraints: interface constraints, class constraints, the gcnew constraint, and constraints that limit the type arguments to either reference types or value types.

Interface constraints indicate that the type parameter must implement the specified interface or interfaces. When an interface constraint is applied to the type parameter, you may use methods of that interface in your generic type definition (see Listing 11-9). Listing 11-9. Specifying Interface Constraints // interface_constraint.cpp interface class I { void f(); }; // The constraint is introduced with the where keyword // and requires that T inherit from I. generic <typename T> where T : I ref class R { T t; public: R(T t_in) : t(t_in) { // Call the method on I. // This code would not compile without // the constraint. t->f(); } };