C# FAQ: general

[1.1] Is C# a practical language?
[1.2] Is C# a perfect language?
[1.3] What's the big deal with OO?
[1.4] What's the big deal with generic programming?
[1.5] Is C# better than C++, Java, VB, etc?
[1.6] Who uses C#?
[1.7] How long does it take to learn OO/C#?
[1.8] What are some features of C# from a business perspective?
[1.9] Are virtual functions (dynamic binding) central to OO/C#?
[1.10] Can you give me a simple reason why virtual functions (dynamic binding) make a big difference?
[1.11] Is C# backward compatible with ANSI/ISO C++?
[1.12] Is C# standardized?
[1.13] Where can I get a copy of the ANSI/ISO C# standard?
[1.14] What are some "interview questions" I could ask that would let me know if candidates really know their stuff?
[1.15] What does the FAQ mean by "such and such is evil"?
[1.16] Will I sometimes use any so-called "evil" constructs?
[1.17] Is it important to know the technical definition of "good OO"? Of "good class design"?
[1.18] What should I tell people who complain that the word "FAQ" is misleading, that it emphasizes the questions rather than the answers, and that we should all start using a different acronym?

Some interesting things I read

A video clip downloading blog:
http://geekbrief.podshow.com/

Robert Scoble:
http://scobleizer.wordpress.com/

Here is a quote from Robert's blog:

"....BMW. It has a jack to plug in a cell phone or an iPod. Now, it's a rich-man's toy, right? But what that tells me is that there's a huge growth in the distribution channel for podcasts coming. Why? Cause what the rich man can buy today you'll be able to buy tomorrow..."

A review on image segmentation

1. Definition

To partition an image into several regions. There are 2 versions:

1. Get desired patterns from the image with undifferentiated background;
2. Partition an image into several regions.

The first 1 can be viewed as a special case of 2.

2. Models for image patterns

There is no universal model for patterns on the image. Some theories assume the patterns follow Gaussian distribution, some assume the patterns have unique texture, etc. For the images obtained from the the real world, they are all projections of one or several objects on the background, which have specific geometric boundary to separate themselves from other objects.

In the image acquisition, the image background may not be uniform either because the acquisition device introdues the distortion, or the illumination, or the nature of background. The uneven background makes the segmentation more difficult. On the other hand, all images are digital, the digitization may create artifacts, which blur the object boundary or texture. For nonuniform background compensation, 2 main approaches are available: estimate the background nonuniformity from the image directly, or estimate it in the segmentation. In the first approach, spatial filtering is a simple method but it may create artifacts, a robust method is called N3 (nonparametric, non-uniform normalization), which is based on the assumption that INU blurs the PDF of image (estimated by image histogram).

There're many methods to segment the images. 2 popular schools of methods are thresholding and edge based method. Based on those 2 types of methods, there are region based segmentation, classification based method, and clustering based methods. What's more, deformable models also have been successfully used in image segmentation, which includes parametric deformable models, geometric deformable models, and etc.

3. Thresholding
The main topic of thresholding is to find an appropriate threshold value to separate the image in different regions according to their intensity or other features. The first technique used widely is based on histogram shape. In the 2 peaks case, the local minimum between 2 peaks is the optimal threshold. Some other methods includes optimal thresholding to minimize some of the objective functions, such as inter-region contrast, mean square error, EM algorithm, k-mean clustering, fuzzy c-mean, entropy, etc.

4. Edge based method
There are many edge detectors, such as Sobel, SUSAN, Canny, Laplacian of Gaussian, etc. Also, morphological method can be used to find the skeletons of the image.

To look for a global edge trace, many methods are proposed. One school of the method is based on template matching, Hough transform can be used to find parametric curves, such as lin, cycle, eclipse, etc. Border tracing to look for the border of an object on the image. Graph searching uses methods such as A*, dynamic programming to find the optimal trace.

5. Region based method
There are many methods available, to name a few, region growing ( which is used to get spot in Mcc), region merging and splitting (used to get spot and cluster in Mcc), connected component labeling.

6. Classification and clustering based method

• K-mean clustering
• fuzzy c-mean clustering
• K-nearest neighboring
• Adapative fuzzy c-mean
• Decision tree
• ANN

7. Deformable models
Parametric deformable model

Geometric deformable model

dynamic_cast vs static_cast in managed c++

Pointer casting managed c++

static_cast is used for all conversions that are well-defined. These include “safe” conversions that the compiler would allow you to do without a cast and less-safe conversions that are nonetheless welldefined. The types of conversions covered by static_cast include typical castless conversions, narrowing (information-losing) conversions, forcing a conversion from a void*, implicit type conversions, and static navigation of class hierarchies.

C++ provides a special explicit cast (introduced in Chapter 3) called dynamic_cast that is a type-safe downcast operation. When you use dynamic_cast to try to cast down to a particular type, the return
value will be a pointer to the desired type only if the cast is proper and successful, otherwise it will return zero to indicate that this was not the correct type.

It is extremely important for the garbage collector to track all pointers into the common language runtime heap during program execution. This leads to the following constraint on __gc pointer casts. Constraint A __gc pointer shall not be cast to a __nogc pointer. Example // __gc_pointer10.cpp // compile with: /clr #using <mscorlib.dll> __gc struct G { int i; }; int main() { G *pG = new G; int *pi; pi = &pG->i; // C2440 pi = (int*)&pG->i; // C2440 } It is possible to convert a __gc pointer to a __nogc pointer via pinning. The Managed Extensions maintain the usual meanings of the various styles of C++ casts, limiting them somewhat to preserve the integrity of the common language runtime garbage collector. The following sections describe the impact on the Managed Extensions for each style of cast.

Pinning Pointers An object or sub-object of a managed class can be pinned, in which case the common language runtime will not move it during garbage collection. The principal use of this is to pass a pointer to managed data as an actual parameter of an unmanaged function call. A local variable called a pinning pointer can be declared whose top-level pointer type is qualified by the __pin keyword. During a collection cycle, the runtime will inspect the metadata created for the pinning pointer and will not move the item it points to. Example // __gc_pointer16.cpp // compile with: /clr /EHsc #using <mscorlib.dll> #include <iostream> __gc class G { public: int i; G() { i = 0; }; }; class H { public: void incr(int * i) { // unmanaged function (*i)++; std::cout << *i << std::endl; }; }; int main() { G __pin * pG = new G; // pG is a pinning pointer H * h = new H; h->incr(& pG -> i); // pointer to managed data passed as actual // parameter of unmanaged function call } Output 1 A pinned object is pinned only while a pinning pointer points to it. It is no longer pinned when its pinning pointer goes out of scope, or is set to 0 in the program. After that, any unmanaged pointers that remain pointing to that object must not be dereferenced. An unpinned item can be moved in the heap by the garbage collector. Any __nogc pointers that still point to it will not be updated, and dereferencing one of them could raise an unrecoverable exception. Example // __gc_pointer17.cpp // compile with: /clr /LD #using <mscorlib.dll> __gc class G { public: int i; }; void f(G * pG) { G __pin* ppG = pG; // the object pointed to by pG is pinned until the pinning // variable ppG goes out of scope, ppG = 0; // or is set to 0 } A pinning pointer is volatile by default. It is redundant but not an error if the user declares a pinning pointer to be volatile. This prevents the optimizer from deleting an assignment of 0 to a pinning pointer in the source code, even though the assignment appears to be dead code. Pinning a sub-object defined in a managed object has the effect of pinning the entire object. For example, if any element of an array is pinned, then the whole array is also pinned. There are no extensions to the language for declaring a pinned array. To pin an array, declare a pinning pointer to its element type, and pin one of its elements. Example // __gc_pointer18.cpp // compile with: /clr #using <mscorlib.dll> #include <stdio.h> using namespace System; int main() { Byte arr[] = new Byte[4]; // arr is a managed array arr[0] = 'C'; arr[1] = '+'; arr[2] = '+'; arr[3] = '0'; Byte __pin * p = &arr[1]; // entire array is now pinned unsigned char * cp = p; printf("%s\n", cp); // bytes pointed at by cp will not move during call } Output ++0 Characteristics A pinning pointer can be implicitly converted to a __nogc pointer. This is the only mechanism provided for passing addresses in the common language runtime heap to functions expecting __nogc pointers. The primary use for this is passing such addresses to unmanaged functions in external DLLs. Constraints A pinning variable shall be a nonstatic local variable. Except for its pinning properties, a pinning pointer is identical to a __gc pointer. Two function overloads shall not differ only by the use of pin and __gc pointer types. A pinning pointer type shall not be used in a cast expression. It can only be used to declare a variable. Example // __gc_pointer19.cpp // compile with: /clr #using <mscorlib.dll> using namespace System; __gc struct G { int i; }; int main() { Object *o = new G; if ( G __pin *pG = dynamic_cast<G __pin *>(o) ) { // C3834 pG->i = 10; } } A pinning pointer can be implicitly converted to a __gc pointer. Example // __gc_pointer20.cpp // compile with: /clr /LD #using <mscorlib.dll> __gc class G { public: int i; }; void f(G * pG) { G __pin * ppG = pG; G * pG2 = ppG; // ok }; A __nogc pointer can be converted to a pinning pointer only if the pinning pointer is an interior __gc pointer. Example // __gc_pointer21.cpp // compile with: /clr #using <mscorlib.dll> struct G { int i; }; __gc struct H { int j; }; int main() { G * g = new G; // g is a __nogc whole object pointer H * h = new H; int __pin * k = & h -> j; // k is a pinning interior __gc pointer int * l = & g -> i; // l is a __nogc pointer k = l; // ok };

dynamic_cast The use of dynamic_cast is prevalent in managed code. The common language runtime base class library uses the root Object* as the parameter type of many of its APIs and collections classes, which in turn requires clients to commonly convert from Object* to their intended class type. The semantics of dynamic_cast on a __gc pointer is the same as for __nogc pointers, except that pointer to void is not allowed. If the cast is successful, the result is a pointer to the derived class object; otherwise the result is the value 0. Example // __gc_pointer11.cpp // compile with: /clr #using <mscorlib.dll> using namespace System; __gc struct G { int i; }; int main() { Object *o = new G; if ( G *pG = dynamic_cast<G*>(o) ) { pG->i = 10; } } Constraint dynamic_cast shall not be used on value type pointers, including pointers of type Void *.

__try_cast The Managed Extensions provide a new dynamically checked cast, similar to dynamic_cast, that throws an exception when the cast is unsuccessful: __try_cast < type-id > ( expression ) If a __try_cast fails at runtime, it will throw System::InvalidCastException. Example // __gc_pointer13.cpp // compile with: /clr #using <mscorlib.dll> __gc struct Base {}; __gc struct Derived : Base {}; __gc struct MoreDerived : Derived {}; int main() { Base*bp = new Derived; try { MoreDerived *mdp = __try_cast<MoreDerived*>(bp); } catch(System::InvalidCastException*) { System::Console::WriteLine("Could not cast 'bp' to MoreDerived*"); } } Output Could not cast 'bp' to MoreDerived* Constraint __try_cast shall not be used on value type pointers including pointers of type Void *.

static_cast In addition to performing ordinary arithmetic casts, the C++ static_cast is also used to convert a base class __gc pointer to a derived class __gc pointer without a runtime check. Note Unchecked pointer casts can break the type safety of __gc pointers, and cause the garbage collector to fail. Static_cast between pointers should only be used for performance-critical code when you are absolutely certain that the types are right. static_cast is commonly used in conjunction with collection classes that require casting all elements to Object* before adding them to the collection. If you only put certain types of objects into the collection, it is relatively safe to retrieve them using static_cast. Even so, use of __try_cast is recommend in test builds, with a switch to static_cast only for release builds. Constraint Static_cast does not work on a pointer-to an object of a value class except for Void *.

reinterpret_cast In C++, reinterpret_cast is used to cast between unrelated pointer types, and between pointers and integral types without a runtime check. Use of reinterpret_cast on __gc pointers is extremely discouraged, and should be limited to casting between pointers to simple class types that contain no embedded __gc pointers. Note Since unchecked pointer casts can break the type safety of __gc pointers, reinterpret_cast between pointers should only be used when absolutely necessary. Using reinterpret_cast is the only way to cast between pointers to value types other than Void *. This cast must be used when casting between pointers and value types. There is no runtime type information associated with these pointers. Example // __gc_pointer14.cpp // compile with: /clr #using <mscorlib.dll> using namespace System; public __value struct I { int i; }; public __value struct R { float f; }; int main() { R r = {2.17828f}; System::Void* pV = &r; // implicit conversion from R * to Void * I *pI = reinterpret_cast<I*>(pV); System::Console::WriteLine(pI->i); } Output 1074489585 Constraint Even reinterpret_cast must meet the constraint for __gc pointers. reinterpret_cast shall not be used to remove the __gc-ness of a __gc pointer, including conversion to integral types.

const_cast const_cast is supported for __gc pointers, and has the usual C++ semantics.

C-Style Casts In C++, a C-style cast can be used to perform the same conversions as static_cast, reinterpret_cast, and const_cast. Unfortunately, they make unsafe pointer casting difficult to detect using editing tools or manual scanning of source code. It is common for a C-style cast to silently result in a reinterpret_cast, when the user actually would have preferred a static_cast. Unsafe C-style casts are restricted as follows. Characteristics C-style casts between unmanaged types are the same as in C++. A C-style cast that performs a base-class-to-derived-class pointer conversion will cause a level-1 warning, and the compiler will emit a __try_cast in its place, meaning the cast will cause a runtime exception if the cast-to-derived fails. This will expose unsafe casts at their origin, instead of causing the garbage collector to crash unpredictably. Constraint A C-style cast shall not be used as a substitute for reinterpret_cast involving __gc pointers.

C# Design Pattern: Singleton

In the Singleton Pattern we have at any given instance a single instance of the Singleton Class active. All instantiation of the Singleton Class references the same instance of the Class. The pattern also provides a global point of access to the sole instance of the class.

Class Diagram

Sequence Diagram

Implementation

Steps for implementing the Singleton Pattern:

Step1:
Create a project of type Console Application. Name it SingletonTest.

Step2:
Add a Class File named Singleton and add the following code

/// /// Summary description for Singleton. /// public class Singleton { //Fields private static Singleton instance; /// /// Standard default Constructor /// protected Singleton() {} /// /// Static method for creating the single instance /// of the Constructor /// /// public static Singleton Instance() { // initialize if not already done if( instance == null ) instance = new Singleton(); // return the initialized instance of the Singleton Class return instance; } }

Step 3:
Create a Client class that would access the Singleton Class as follows :

/// /// Summary description for Client. /// class Client { /// /// The main entry point for the application. /// [STAThread] static void Main(string[] args) { // Constructor is protected -- cannot use new Singleton s1 = Singleton.Instance(); Singleton s2 = Singleton.Instance(); if( s1 == s2 ) Console.WriteLine( "The same instance" ); Console.ReadLine(); } }

Step 4:
Run the Application it would display the following output:

Conclusion

Thus we have implemented the Singleton Design Pattern using the .Net framework.Like any Concepts/Theory Singleton Pattern also has its pros and cons.

Benefits of Singleton Pattern:

1. Instance control: Singleton prevents other objects from instantiating their own copies of the Singleton object, ensuring that all objects access the single instance.

2. Flexibility: Because the class controls the instantiation process, the class has the flexibility to change the instantiation process.

Drawbacks of Singleton Pattern:

1. Overhead. Although the amount is minuscule, there is some overhead involved in checking whether an instance of the class already exists every time an object requests a reference. This problem can be overcome by using static initialization

2. Possible development confusion. When using a singleton object (especially one defined in a class library), developers must remember that they cannot use the new keyword to instantiate the object. Because application developers may not have access to the library source code, they may be surprised to find that they cannot instantiate this class directly.

3. Object lifetime. Singleton does not address the issue of deleting the single object. In languages that provide memory management (for example, languages based on the .NET Framework), only the Singleton class could cause the instance to be deallocated because it holds a private reference to the instance. In languages, such as C++, other classes could delete the object instance, but doing so would lead to a dangling reference inside the Singleton class.

Design pattern in C#: Introduction

Most programming involves usage of Design Patterns in one form or other. There are around 23 Design Patterns that are available. They are categorized as given below:

[I] Creational Patterns

1. Singleton
2. Factory
3. Abstract Factory
4. Builder
5. Prototype

[II] Structural Patterns

1. Adapter
2. Bridge
3. Composite
4. Decorator
5. Facade
6. Flyweight
7. Proxy

[III] Behavioral Pattern

1. Chain Of Responsibility
2. Command
3. Interpreter
4. Iterator
5. Mediator
6. Memento
7. Observer
8. State
9. Strategy
10. Template Method
11. Visitor

Design patterns are commonly defined as time-tested solutions to recurring design problems.

The most striking benefits of Design Patterns are as follows:

• They provide you with a way to solve issues related to software development using a proven solution. The solution facilitates the development of highly cohesive modules with minimal coupling. They isolate the variability that may exist in the system requirements, making the overall system easier to understand and maintain.
• Design patterns make communication between designers more efficient. Software professionals can immediately picture the high-level design in their thoughts immediately the name of the pattern used to solve a particular issue when discussing system design

Software Architecture (3)

Some useful links to Software Architecture:

Software Architectural Styles: http://hebb.cis.uoguelph.ca/~dave/27320/new/architec.html
A class website: http://courses.cs.tamu.edu/cpsc689/hohin/fall00/


Chapter 4 Shared Information System


4.1 Shared Information System

• Separate programs for separate subtasks;
• Multiple individual steps is composed to larger tasks by passing data in a known format; (not flexible, not interactive)
• Shared data store; (data stores with different representation)
• Shared information system evolution pattern.

4.2 Database integration

2 strategies to handle data diversity: unified schema and multidatabases.

4.2.1 Batch sequential

• Transaction (commit(), rollback())

4.2.2 Simple repository

• interactive tech provides the opportunity and demand for online update adn query.
• Increasing transaction and modification.

4.2.3 Virtual repository

• Use schemas to provide a logic view of the multiple distributed databases.

4.2.4. Hierarchical layers

4.2.5. Evolution of shared information system in business data processing

• Batch processing
• Interactive processing
• unified schemas
• Multidatabase (layered hierarchy with client server interaction).

4.3. Integration in software development environment

• Batch sequential
• Repository
• Hierarchical layer

4.4. Building design

• Repository
• Intelligent control

4.5 Architectural structures for SIS

Teamwork, team structure, and motivations

From chapter 11, 12, 13 of "Rapid Development" by Steve McConnell.

1. Motivation

Developers are more introvertious than the general population. Achievement, possibility for growth, work itself, and technical supervision opportunity are among the top five factors motivating them. On the contrary, managers are more excited by the responsibility, and recognition.

For the long term, reward is important. However, sometimes the reward itself may undermine the quality of work, since the passion for the work itself is more important. Therefore, the rewards should be presented as a gesture of appreciation rather than an incentive. The more external the reward is, the less interested the work will be.

The Hawthorne effect is gold to project managers. Run every software project as an experiment, as a pilot project. Try something new, and make sure every team member knows it. If get some conclusive result, use it for the later projects, otherwise you get the better productivity at least. Note that: don't manipulate.

Performance review. The effect can be negative or positive. a 2 blades sword.

Morale

2. Teamwork

The characterisitics of a productive team:

1. A shared, elevating vision or goal;
2. A sense of team identity;
3. A results-driven structure(roles must be cleared and accountable, an effective communication system, monitoring individual performance, decision made on facts);
4. Competent team members (specific tech skills, desire to contribute, collaboration skills, mixed roles);
5. A commitment to the team;
6. Mutual trust (honesty, openness, consistency, and respect);
7. Interdependence among team members;
8. Effective communications;
9. A sense of autonomy;
10. A sense of empowerment;
11. Small team size;
12. A high level of enjoyment.

Why teams fail?

The contrary of any one of above.

To point out one thing: who first, then what. To keep a unqualified person on the bus hurts the team most. If someone is not qualified, the firing decision has to be made as early as possible before it hurts the project.

Long term team building: don't dismiss the team because of short peroid of idleness. The cost of rebuilding a good team is way much more than the pay of idleness. The risk is increasing as well.

A summary of teamwork:

1. for team leaders

1. Avoid compromising team goals with political issues;
2. Exhibit personal commitment to the team's goal;
3. Not to give too many priorities;
4. Be fair and impartial to the members;
5. Confront the inadequency of any team member;
6. Open to new ideas and information from the member.

2. for team member

1. Demonstrate a realistic understanding of my role and accountability;
2. Demonstrate objective and fact based judgement;
3. Collaborate effectively with other members;
4. Make the team goal at higher priority;
5. Demonstrate a willingness to devote whatever effort to achieve team success;
6. Be willing to share and feedback appropriately;
7. Provide help;
8. Demonstrate high standards of excellence;
9. Support team decision;
10. Demonstrate courage of conviction by directly confronting important issues;
11. Demonstrate leadership in ways that contribute to the team success;
12. Respond constructively to feedbacks.

3. Team structure

Organize the team according to the objectives:

1. Problem resolution---trust;
2. Creativity---autonomy;
3. Tactical execution--clarity.

Team models:

1. business team: expert lead + equal members, the most common model;
2. chief-programmer team(surgical team): surgen+backup programmer+administrator+toolsmith,e tc; but rare programmers have the expertise to serve as surgen;
3. skunkworks team: a group of talents, black-box to the outsider;
4. Feature team;
5. Search-and-rescue team;
6. SWAT team: a group of experts, each are good at one tool;
7. Professional athletic team;
8. Theater team;
9. Large team;

Managers and tech leaders

Customer oriented development

Notes from chapter 10 of "Rapid development" by Steve McConnell

1. Customers' importance to rapid development

Top 3 reasons of delayed projects:

1. Lack of user input;
2. Incomplete requirements specifications;
3. Changing requirements and specifications.

2 main reasons that pay attention to customer relations:

1. Good relations with customers improve the development speed;
1. Improved efficiency
2. Less rework
3. Reduced risk
4. Lack friction
2. Good releations with customers improve preceived development speed.

2. Customer-oriented practices

1. Planning
1. Select an appropriate lifecycle model, keep the customer with steady, tangible progress update.
2. Identify the real customer.
3. Establish an efficient method for interacting with the customer (single point of contact).
4. Create a win-win project.
5. Manage risks.
2. Requirement analysis
1. The challenge is to collect the real requirements;
2. sometimes real requirements conflict with collected requirments;
3. More often, they are simply missing;
4. Customer tends to interpret the requirement broadly, and the developers is opposite.
5. Case: **visual c++ (lower the switch cost to c++) against borland c++(expert c++)
3. Design
1. Lack of design flexibility was the weakness of the design
2. Employ design practices that allow customers to change their minds occasionally.
4. Construction
1. Write maintenable and modifiable code in order to responed to user's change;
2. Progress monitoring practices;
3. Select a lifecycle model allow customers with steady, tangible progress update.

3. Managing customer expectations

Many problems in software development, especially speed, arise from unstated, unrealistic expections.

1. Customers assumes that the development is as easy as they preceive, such as drag and drop documents from one application to the other on win 3.1, it is easy to them, what about the implementation?
2. Customers assumes that you understand all of their requirements without having to explain to you.
3. One important task is to educate the customers during the development.
4. With inflated expectation, developers look like losers even when they do a good job. Who inflate expectations damage their credibilit, undermine their working relationships with customers.

Further reading:

Naomi Karten, Managing expectations