Exceptions in C Sharp

All exceptions are either of type System.Exception or of types derived from System.Exception. The CLR System namespace includes a number of exception types that can be used by your program. These exception types include ArgumentNullException, InvalidCastException, and OverflowException, as well as many others. You can guess their use based on their name. For example, ArgumentNull exception is thrown when an argument to a method is null when that is not an expected (or acceptable) value.

When your program encounters an exceptional circumstance, such as running out of memory, it throws (or raises) an exception. Exceptions must be handled before the program can continue.

The search for an exception handler can unwind the stack. This means that if the currently running function does not handle the exception, the current function terminates and the calling function gets a chance to handle the exception. If none of the calling functions handles it, the exception ultimately is handled by the Common Language Runtime (CLR), which abruptly terminates your program.

If function A calls function B and function B calls function C, these function calls are all placed on the stack. When a programmer talks about "unwinding the stack" what is meant is that you back up from C to B to A.

If you must unwind the stack from C to B to A to handle the exception, when you are done, you are in A; there is no automatic return to C.

If you return all the way to the first method (Main) and no exception handler is found, the default exception handler (provided by the compiler) is invoked. The default exception handler just terminates the program.

18.2

VISUAL STUDIO INTRODUCTION

C SHARP INTRODUCTION

C SHARP OUT LOOK

DOT NET AND C SHARP

C SHARP APPLICATION STRICTURE

OOPS INTRODUCTION

OOPS AND C SHARP

IDE AND C SHARP

INSTANTIATING OBJECTS IN C SHARP

CLASSES AND OBJECTS IN C SHARP

OPERATORS IN C SHARP

SWITCH AND ITERATION IN C SHARP

BRANCHING IN C SHARP

CONSTANTS AND STRING

SOFTWARE SAFETY

Before software was used in sarety critical systems, they were often controlled by conventional (nonprogrammable) mechanical and electronic devices. System safety techniques are designed to cope with random failures in these (nonprogrammable] systems. Human design errors are not considered since it is assumed that all faults caused by human errors can be avoided completely or removed prior to delivery and operation.

When software is used as part of the control, complexity can increase by an order of magnitude or more. Subtle design faults induced by human error—something that can be uncovered and eliminated in hardware-based conventional control—become much more difficult to uncover when software is used.

Software safety is a software quality activity that focuses on the identification and assessment of potential hazards that may affect software negatively and cause an entire system to fail. If hazards can be identified early in the software engineering process, design features can be specified that will either eliminate or control potential hazards.

A modeling and analysis process is conducted as part of software safety. Initially, hazards are identified and categorized by risk. For example, some of the hazards associated with a computer-based cruise control for an automobile might be

• causes uncontrolled acceleration that cannot be stopped

• does not respond to depression of brake pedal (by turning off)

• does not engage when switch is activated

• slowly loses or gains speed

Once these system-level hazards are identified, analysis techniques are used to assign severity and probability of occurrence. To be effective, software must be analyzed in the context of the entire system.

For example, a subtle user input error (people are system components) may be magnified by a software fault to produce control data that improperly positions a mechanical device. If a set of external environmental conditions are met (and only if they are met), the improper position of the mechanical device will cause a disastrous failure.

Anylysis techniques such as fault tree analyse , real-time logic , or petri net models can be used to predict the chain of events that can cause hazards and the probability that each of the events will occur to create the chain.

Once hazards are identified and analyzed, safety-related requirements can be specified for the software. That is, the specification can contain a list of undesirable events and the desired system responses to these events. The role of software in managing undesirable events is then indicated.

Although software reliability and software safety are closely related to one another it is important to understand the subtle difference between them. However, the occurrence of a failure does not necessarily result in a hazard or mishap. Software safety examines the ways in which failures result in conditions that can lead to a mishap. That is, failures are not considered in a vacuum, but are evaluated in the context of an entire computer-based system.

VALIDATION TESTING

SYSTEM TESTING

DEBUGGING AND TESTING

DEFECT AMPLIFICATION AND REMOVAL

ITERATIVE SPIRAL MODEL

STANDARD WATER MODEL

CONFIGURATION MANAGEMENT

CONTROLLED TESTING ENVIRONMENT

RISK ANALYSIS PART ONE

RISK ANALYSIS PART TWO

BACK GROUND ISSUES

SOFTWARE REVIEWS PART ONE

SOFTWARE REVIEWS PART TWO

SOFTWARE RELIABILITY

SAFETY ASPECTS

MISTAKE PROOFING

SCRIPT ENVIRONMENT

V MODEL IN TESTING

SOFTWARE RELIABILITY

There is no doubt that the reliability of a computer program is an important element of its overall quality. If a program repeatedly and frequently fails to perform, it matters little whether other software quality factors are acceptable.

Software reliability, unlike many other factors , can be measured directed and estimated using historical and developmental data. Software reliability is defined in statistical terms as "the probability of failure-free operation of a computer program in a specified environment for a specified time" . To illustrate, program X is estimated to have a reliability of 0.96 over eight elapsed processing hours. In other words, if program X were to be executed 100 times and require eight hours of elapsed processing time (execution time), it is likely to operate correctly (without failure) 96 times out of 100.

Whenever software reliability is discussed, a pivotal question arises: What is meant by the term failure? In the context of any discussion of software quality and reliability, failure is nonconformance to software requirements. Yet, even within this definition, there are gradations. Failures can be only annoying or catastrophic. One failure can be corrected within seconds while another requires weeks or even months to correct. Complicating the issue even further, the correction of one failure may in fact result in the introduction of other errors that ultimately result in other failures.

Measures of Reliability and Availability

Early work in software reliability attempted to extrapolate the mathematics of hardware reliability theory to the prediction of rea;ibility. Most hardware-related reliability models are predicated on failure due to wear rather than failure due to design defects. In hardware, failures due to physical wear (e.g., the effects of temperature, corrosion, shock) are more likely than a design-related failure. Unfortunately, the opposite is true for software. In fact, all software failures can be traced to design or implementation problems; wear does not enter into the picture.

There has been debate over the relationship between key concepts in hardware reliability and their applicability to software . Although an irrefutable link has yet be be established, it is worthwhile to consider a few simple concepts that apply to both system elements.

The Regex Class in C Sharp

The .NET Framework provides an object-oriented approach to regular expression pattern matching and replacement.

The Framework Class Library namespace System.Text.RegularExpressions is the home to all the .NET Framework objects associated with regular expressions. The central class for regular expression support is Regex, which provides methods and properties for working with regular expressions, the most important of which are shown.

Method or property	Explanation
Regex constructor	Overloaded; creates an instance of Regex
Options	Property that returns the options passed in to the constructor
IsMatch()	Method that indicates whether a match is found in the input string
Match	Searches an input string and returns a match for a regular expression
Matches	Searches an input string and returns all successful matches for a regular expression
Replace	Replace all occurrences of a pattern with a replacement string
Split	Splits an input string into an array of substrings based on a regular expression

Example Regular expressions

using System;

using System.Text;

using System.Text.RegularExpressions;



namespace RegularExpressions

{

class Tester

{

   public void Run()

   {

       string s1 =

           "One,Two,Three Liberty Associates, Inc.";

          Regex theRegex = new Regex(" |, |,"); 

       StringBuilder sBuilder = new StringBuilder();

       int id = 1;

 foreach (string subString in theRegex.Split(s1)) 

       {

           sBuilder.AppendFormat(

               "{0}: {1}\n", id++, subString);

       }

       Console.WriteLine("{0}", sBuilder);

   }



   [STAThread]

   static void Main()

   {

      Tester t = new Tester();

      t.Run();

   }

}

}

 Output:

1: One

2: Two

3: Three

4: Liberty

5: Associates

6: Inc.

This can be a bit confusing. In the context of a C# program, which is the regular expression: the text passed in to the constructor or the Regex object itself? It is true that the text string passed to the constructor is a regular expression in the traditional sense of the term. From a C# (i.e., object-oriented) point of view, however, the argument to the constructor is just a string of characters; it is the object called theRegex that is the regular expression object.

STATISTICAL QUALITY ASSURANCE

Software quality can be achieved through competent analysis, design, coding, and testing, as well as through the application of formal technical reviews, a testing strategy, better control of software work products and the changes made to them, and the application of accepted software engineering standards. In addition, quality can be defined in terms of a broad array of quality factors and measured (indirectly) using a variety of indices and metrics.

A syntax and semantics can be defined for every programming language, and work is underway to develop a similarly rigorous approach to the specification of software requirements. If the requirements model (specification) and the programming language can be represented in a rigorous manner, it should be possible to apply mathematic proof of correctness to demonstrate that a program conforms exactly to its specifications.

Steps required to perform statistical SQA :

1. Information about software defects is collected and categorized.

2. An attempt is made to trace each defect to its underlying cause (e.g., non-conformance to specifications, design error, violation of standards, poor communication with the customer).

3. Using the Pareto principle (80 percent of the defects can be traced to 20 percent of all possible causes), isolate the 20 percent (the "vital few").

4. Once the vital few causes have been identified, move to correct the problems that have caused the defects.

This relatively simple concept represents an important step towards the creation o: an adaptive software engineering process in which changes are made to improve those elements of the process that introduce error.

Statistical quality assurance techniques for software have been shown to provide substantial quality improvement . In some cases, software organizations have achieved a 50 percent reduction per year in defects after applying these techniques

Manipulation and Regular Expressions of Strings

The String class provides a host of methods for comparing, searching, and manipulating strings.

Method or property	Explanation
Chars	Property that returns the string indexer
Compare()	Overloaded public static method that compares two strings
Copy()	Public static method that creates a new string by copying another
Equals()	Overloaded public static and instance method that determines if two strings have the same value
Format()	Overloaded public static method that formats a string using a format specification
Length	Property that returns the number of characters in the instance
PadLeft()	Right-aligns the characters in the string, padding to the left with spaces or a specified character
PadRight()	Left-aligns the characters in the string, padding to the right with spaces or a specified character
Remove()	Deletes the specified number of characters
Split()	Divides a string, returning the substrings delimited by the specified characters
StartsWith()	Indicates if the string starts with the specified characters
Substring()	Retrieves a substring
ToCharArray()	Copies the characters from the string to a character array
ToLower()	Returns a copy of the string in lowercase
ToUpper()	Returns a copy of the string in uppercase
Trim()	Removes all occurrences of a set of specified characters from beginning and end of the string
TrimEnd()	Behaves like Trim(), but only at the end
TrimStart()	Behaves like Trim(), but only at the start

Comparing Strings

The Compare() method is overloaded. The first version takes two strings and returns a negative number if the first string is alphabetically before the second, a positive number if the first string is alphabetically after the second, and zero if they are equal. The second version works just like the first but is case-insensitive.

Regular Expressions

Regular expressions are a powerful language for describing and manipulating text. Underlying regular expressions is a technique called pattern matching, which involves comparing one string to another, or comparing a series of wildcards that represent a type of string to a literal string. A regular expression is applied to a string — that is, to a set of characters. Often that string is an entire text document.

The result of applying a regular expression to a string is either to return a substring or to return a new string representing a modification of some part of the original string. (Remember that string objects are immutable and so cannot be changed by the regular expression.)

By applying a properly constructed regular expression to the following string:

One,Two,Three Liberty Associates, Inc.

you can return any or all of its substrings (e.g., Liberty or One) or modified versions of its substrings (e.g., LIBeRtY or OnE). What the regular expression does is determined by the syntax of the regular expression itself.

A regular expression consists of two types of characters: literals and metacharacters. A literal is a character you want to match in the target string. A metacharacter is a special symbol that acts as a command to the regular expression parser. The parser is the engine responsible for understanding the regular expression. For example, if you create a regular expression:

^(From|To|Subject|Date):

this will match any substring with the letters "From", "To", "Subject", or "Date" so long as those letters start a new line (^) and end with a colon (:).

The caret (^) indicates to the regular expression parser that the string you're searching for must begin a new line. The letters "From" and "To" are literals, and the metacharacters left and right parentheses ( (, ) ) and vertical bar (|) are all used to group sets of literals and indicate that any of the choices should match. Thus you would read the following line as "match any string that begins a new line, followed by any of the four literal strings From, To, Subject, or Date, and followed by a colon":

^(From|To|Subject|Date):

17.3

RELATED POST

STRING CREATION IN C SHARP

Strings Creation in C Sharp

C# treats strings as if they were built-in types. C# strings are flexible, powerful, and easy to use.

In .NET, each string object is an immutable sequence of Unicode characters. In other words, methods that appear to change the string actually return a modified copy; the original string remains intact.

The declaration of the System.String class is:

public sealed class String :

IComparable, ICloneablee, IConvertible, IEnumerable

This declaration reveals that the class is sealed, meaning that it is not possible to derive from the String class. The class also implements four system interfaces — IComparable, ICloneable, IConvertible, and IEnumerable — which dictate functionality that System.String shares with other classes in the .NET Framework.

The IComparable interface is implemented by types that can be sorted. Strings, for example, can be alphabetized; any given string can be compared with another string to determine which should come first in an ordered list. IComparable classes implement the CompareTo() method.

ICloneable objects can create new instances with the same value as the original instance. In this case, it is possible to clone a string to produce a new string with the same values (characters) as the original. ICloneable classes implement the Clone() method.

IConvertible classes provide methods to facilitate conversion to other primitive types; these methods include ToInt32(), ToDouble(), and ToDecimal().

String Literals

The most common way to create a string is to assign a quoted string of characters, known as a string literal, to a user-defined variable of type string. The following code declares a string called newString that contains the phrase This is a string literal.

string newString = "This is a string literal";

Verbatim Strings

Strings can also be created using verbatim string literals, which start with the (@) symbol. This tells the String constructor that the string should be used verbatim, even if it spans multiple lines or includes escape characters. In a verbatim string literal, backslashes and the characters that follow them are simply considered additional characters of the string.

In the first line, a nonverbatim string literal is used, and so the backslash character (\) must be escaped, which means it must be preceded by a second backslash character. In the second, a verbatim literal string is used, so the extra backslash is not needed. A second example illustrates two ways to specify multiline verbatim strings. The first definition uses a nonverbatim string with a newline escape character (\n) to signal the line break.

Again, these declarations are interchangeable. Which one you use is a matter of convenience and personal style.

The ToString() Method

Another common way to create a string is to call the ToString() method on an object and assign the result to a string variable. All the built-in types override this method to simplify the task of converting a value (often a numeric value) to a string representation of that value.

Software reviews

Review Reporting and Record Keeping

During the FTR, a reviewer (the recorder) actively records all issues that have been raised. These are summarized at the end of the review meeting and a review issues list is produced. In addition, a formal technical review summary report is completed. A review summary report answers three questions:

1. What was reviewed?

2. Who reviewed it?

3. What were the findings and conclusions?

The review summary report is a single page form (with possible attachments). It becomes part of the project historical record and may be distributed to the project leader and other interested parties.

The review issues list serves two purposes:

(1) to identify problem areas within the product and

(2) to serve as an action item checklist that guides the producer as corrections are made. An issues list is normally attached to the summary report.

It is important to establish a follow-up procedure to ensure that items on the issues list have been properly corrected. Unless this is done, it is possible that issues raised can "fall between the cracks." One approach is to assign the responsibility for follow-up to the review leader.

Review Guidelines

Guidelines for the conduct of formal technical reviews must be established in advance, distributed to all reviewers, agreed upon, and then followed. A review that is uncontrolled can often be worse that no review at all. The following represents a minimum set of guidelines for formal technical reviews:

1. Review the product, not the producer. An FTR involves people and egos. Conducted properly, the FTR should leave all participants with a warm feeling of accomplishment. Conducted improperly, the FTR can take on the aura of an inquisition. Errors should be pointed out gently; the tone of the meeting should be loose and constructive; the intent should not be to embarrass or belittle. The review leader should conduct the review meeting to ensure that the proper tone and attitude are maintained and should immediately halt a review that has gotten out of control.

2. Set an agenda and maintain it. One of the key maladies of meetings of all types is drift. An FTR must be kept on track and on schedule. The review leader is chartered with the responsibility for maintaining the meeting schedule and should not be afraid to nudge people when drift sets in.

3. Limit debate and rebuttal. When an issue is raised by a reviewer, there may not be universal agreement on its impact. Rather than spending time debating the question, the issue should be recorded for further discussion off-line.

4. Enunciate problem areas, but don't attempt to solve every problem noted. A review is not a problem-solving session. The solution of a problem can often be accomplished by the producer alone or with the help of only one other individual. Problem solving should be postponed until after the review

meeting.

5. Take written notes. It is sometimes a good idea for the recorder to make notes on a wall board, so that wording and priorities can be assessed by other reviewers as information is recorded.

6. Limit the number of participants and insist upon advance preparation. Two heads are better than one, but 14 are not necessarily better than 4. Keep the number of people involved to the necessary minimum. However, all review team members must prepare in advance. Written comments should be solicited by the review leader (providing an indication that the reviewer has reviewed the material).

7. Develop a checklist for each product that is likely to be reviewed. A checklist helps the review leader to structure the FTR meeting and helps each reviewer to focus on important issues. Checklists should be developed for analysis, design, code, and even test documents.

8. Allocate resources and schedule time for FTRs. For reviews to be effective, they should be scheduled as a task during the software engineering process. In addition, time should be scheduled for the inevitable modifications that will occur as the result of an FTR.

9. Conduct meaningful training for all reviewers. To be effective all review participants should receive some formal training. The training should stress both process-related issues and the human psychological side of reviews. Freed-man and Weinberg estimate a one-month learning curve for every 20 people who are to participate effectively in reviews.

10. Review your early reviews. Debriefing can be beneficial in uncovering problems with the review process itself. The very first product to be reviewed should be the review guidelines themselves.

Because many variables (e.g., number of participants, type of work products, timing and length, specific review approach) have an impact on a successful review, a software organization should experiment to determine what approach works best in a local context. Porter and his colleagues provide excellent guidance for this type of experimentation.

Defects-Removal-software testing

A defect amplification model can be used to illustrate the generation and detection of errors during the preliminary design, detail design, and coding steps of the software engineering process.It represents a software development step. During the step, errors may be inadvertently generated.

Review may fail to uncover newly generated errors and errors from previous steps, resulting in some number of errors that are passed through. In some cases, errors passed through from previous steps are amplified (amplification factor, x) by current work. The box subdivisions represent each of these characteristics and the percent of efficiency for detecting errors, a function of the thoroughness of the review.

FORMAL TECHNICAL REVIEWS

A formal technical review is a software quality assurance activity performed by software engineers (and others).

The objectives of the FTR are

(1) to uncover errors in function, logic, or implementation for any representation of the software;

(2) to verify that the software under review meets its requirements;

(3) to ensure that the software has been represented according to predefined standards;

(4) to achieve software that is developed in a uniform manner; and

(5) to make projects more manageable. In addition, the FTR serves as a training ground, enabling junior engineers to observe different approaches to software analysis, design, and implementation. The FTR also serves to promote backup and continuity because a number of people become familiar with parts of the software that they may not have otherwise seen.

The FTR is actually a class of reviews that includes walkthroughs, inspections, round-robin reviews and other small group technical assessments of software.

Each FTR is conducted as a meeting and will be successful only if it is properly planned, controlled, and attended.

The Review Meeting

Regardless of the FTR format that is chosen, every review meeting should abide by the following constraints:

• Between three and five people (typically) should be involved in the review.

• Advance preparation should occur but should require no more than two hours of work for each person.

• The duration of the review meeting should be less than two hours.

Given these constraints, it should be obvious that an FTR focuses on a specific (and small) part of the overall software. For example, rather than attempting to review an entire design, walkthroughs are

conducted for each component or small group of components. By narrowing focus, the FTR has a higher likelihood of uncovering errors.

The focus of the FTR is on a work product (e.g., a portion of a requirements specification, a detailed component design, a source code listing for a component). The individual who has developed the work product—the producer—informs the project leader that the work product is complete and that a review is required.

The project leader contacts a review leader, who evaluates the product for readiness, generates copies of product materials, and distributes them to two or three reviewers for advance preparation. Each reviewer is expected to spend between one and two hours reviewing the product, making notes, and otherwise becoming familiar with the work. Concurrently, the review leader also reviews the product and establishes an agenda for the review meeting, which is typically scheduled for the next day.

The review meeting is attended by the review leader, all reviewers, and the producer. One of the reviewers takes on the role of the recorder; that is, the individual who records (in writing) all important issues raised during the review.

The FTR begins with an introduction of the agenda and a brief introduction by the producer. The producer then proceeds to "walk through" the work product, explaining the material, while reviewers raise issues based on their advance preparation. When valid problems or errors are discovered, the recorder notes each.

At the end of the review, all attendees of the FTR must decide whether to

(1) accept the product without further modification,

(2) reject the product due to severe errors (once corrected, another review must be performed), or

(3) accept the product provisionally (minor errors have been encountered and must be corrected, but no additional review will be required).

The decision made, all FTR attendees complete a sign-off, indicating their participation in the review and their concurrence with the review team's findings.

Collection Interfaces and c sharp

Every collection has certain shared characteristics, which are captured by the collection interfaces. The .NET Framework provides standard interfaces for enumerating, comparing, and creating collections.

By implementing the collection interfaces, your custom class provides the same semantics as the collection classes available through the .NET Framework.

IEnumerable	Enumerates through a collection using a `foreach` statement
IEnumerator	Iterates over a collection and supports the `foreach` loop
ICollection	Implemented by all collections
IComparer	Compares two objects; used for sorting
IList	Used by collections that can be indexed
IDictionary	For key/value-based collections such as Hashtable and SortedList
IDictionaryEnumerator	Allows enumeration with `foreach` of a collection that supports IDictionary

Now focus on the IEnumerable interface, using it to demonstrate how you can implement the collection interfaces in your own classes to allow clients to treat your custom classes as if they were collections. For example, you might create a custom class named ListBoxTest. Your ListBoxTest will have a set of strings to be displayed. You can implement the collection interfaces in your ListBoxTest class to allow clients to treat your ListBoxTest as if it were a collection. This allows clients to add to the ListBoxTest using the index operator (e.g., myListBox[5] = "New String"), to sort the ListBoxTest, to enumerate the elements of the ListBoxTest, and so forth.

The IEnumerable Interface

IThe foreach statement will work with any class that implements the IEnumerable interface. Classes that implement the IEnumerable interface have a single method, GetEnumerator(), that returns an object that implements a second interface, IEnumerator.

The entire job of the IEnumerable interface is to define the GetEnumerator() method. The job of the GetEnumerator() method is to generate an enumerator — that is, an instance of a class that implements the IEnumerator interface.

By implementing the IEnumerable interface, your ListBoxTest class is saying "you can enumerate my members, just ask me for my enumerator." The client asks the ListBoxTest for its enumerator by calling the GetEnumerator() method. What it gets back is an instance of a class that knows how to iterate over a list box. That class, ListBoxEnumerator, will implement the IEnumerator interface.

This gets a bit confusing, so let's use an example. When you implement the IEnumerable interface for ListBoxTest, you are promising potential clients that ListBoxTest will support enumeration. That allows clients of your ListBoxTest class to write code like this:

foreach (string s in ListBoxTest) { //... }

You implement IEnumerable by providing the GetEnumerator() method, which returns an implementation of IEnumerator. In this case, you'll return an instance of ListBoxEnumerator, and ListBoxEnumerator will implement the IEnumerator interface:

 public IEnumerator GetEnumerator()

{

 return (IEnumerator) new ListBoxEnumerator(this);

The ListBoxEnumerator is a specialized instance of IEnumerator that knows how to enumerate the contents of your ListBoxTest class. Notice two things about this implementation. First, the constructor for ListBoxEnumerator takes a single argument, and you pass in the this reference. Doing so passes in a reference to the current ListBoxTest object, which is the object that will be enumerated. Second, notice that the ListBoxEnumerator is cast to an IEnumerator before it is returned. This cast is safe because the ListBoxEnumerator class implements the IEnumerator interface.

An alternative to creating a specialized class to implement IEnumerator is to have the enumerable class (ListBoxTest) implement IEnumerator itself. In that case, the IEnumerator returned by GetEnumerator would be the ListBoxTest object, cast to IEnumerator.

Putting the enumeration responsibility into a dedicated class that implements IEnumerator (ListBoxEnumerator) is generally preferred to the alternative of letting the collection class (ListBoxTest) know how to enumerate itself. The specialized enumeration class encapsulates the responsibility of enumeration and the collection class (ListBoxTest) is not cluttered with a lot of enumeration code.

RELATED POST

VISUAL STUDIO INTRODUCTION

C SHARP INTRODUCTION

C SHARP OUT LOOK

DOT NET AND C SHARP

C SHARP APPLICATION STRICTURE

OOPS INTRODUCTION

OOPS AND C SHARP 

IDE AND C SHARP

INSTANTIATING OBJECTS IN C SHARP

CLASSES AND OBJECTS IN C SHARP

OPERATORS IN C SHARP

SWITCH AND ITERATION IN  C SHARP

BRANCHING IN C SHARP

CONSTANTS AND STRING

Multidimensional Arrays and c sharp

You can think of arrays as long rows of slots into which values can be placed. Once you have a picture of a row of slots, imagine five rows, one on top of another. This is the classic two-dimensional array of rows and columns. The rows run across the array and the columns run up and down the array.

A third dimension is possible but somewhat harder to picture. Imagine making your arrays three-dimensional, with new rows stacked atop the old two-dimensional array. OK, now imagine four dimensions. Now imagine ten.

Those of you who are not string-theory physicists have probably given up, as have I. Multidimensional arrays are useful, however, even if you can't quite picture what they would look like. You might, for example, use a four-dimensional array to track movement in three dimensions (x,y,z) over time.

C# supports two types of multidimensional arrays: rectangular and jagged. In a rectangular array, every row is the same length. In a jagged array, however, each row can be a different length. In fact, you can think of each row in a jagged array as an array unto itself. Thus, a jagged array is actually an array of arrays.

Rectangular Arrays

A rectangular array is an array of two (or more) dimensions. In the classic two-dimensional array, the first dimension is the number of rows and the second dimension is the number of columns.

To declare a two-dimensional array, use the following syntax:

type  [,]  array-name

A jagged array is an array of arrays. Specifically, a jagged array is a type of multi-dimensional array in which each row can be a different size from all the other rows. Thus, a graphical representation of the array has a "jagged" appearance.

You can think of each row in a jagged array as a one-dimensional array unto itself. Thus, technically speaking, a jagged array is an array of arrays. When you create a jagged array, you declare the number of rows in your array. Each row holds a one-dimensional array, and each row can be of any length. To declare a jagged array, use the following syntax, where the number of brackets indicates the number of dimensions of the array:

type [] []...

For example, you would declare a two-dimensional jagged array of integers named myJaggedArray as follows:

int [] [] myJaggedArray;

Address the elements in the array as follows: the array name then the offset into the array of arrays (the row), and then the offset into the chosen array (the column within the chosen row). That is, to access the fifth element of the third array, write:

myJaggedArray[2][4]

Remember that all arrays are zero-based. The third element is at offset 2, and the fifth element is at offset 4.

SOFTWARE QUALITY ASSURANCE AND CONTROL

SOFTWARE QUALITY AND COST ASPECT

STABLE PROCESS OF SOFTWARE TESTING

STABLE PROCESS OF SOFTWARE TESTING PART TWO

DEFECTS IN SOFTWARE TESTING

REDUCTION OF DEFECTS IN SOFTWARE TESTING

SOFTWARE TESTING AND EFFECTING FACTORS

SCOPE OF SOFTWARE TESTING

TESTING LIFE CYCLE PART ONE

TESTING LIFE CYCLE PART TWO

TESTING LIFE CYCLE PART THREE

SOFTWARE TESTING AND CONSTRAINTS WITH IN IT

TESTING CONSTRAINTS PART TWO

LIFE CYCLE TESTING

TEST METRICS

Independent Software Testing

Test Process

Testing verification and validation

Functional and structural testing

Static and dynamic testing

V model testing

Eleven steps of V model testing

Structural testing

Execution testing technique

Recovery Testing technique

Operation testing technique

Compliance software testing technique

Security testing technique
Here i am adding the further topics list on software testing subject and the topics may be scattered and you can find under different groups.

MAJOR SYSTEM FAILURES IN THE HISTORY

WHAT IS A SOFTWARE BUG ?

ROLE OF A TESTER

SOFTWARE TESTING INTRODUCTION PART ONE

TESTING INTRODUCTION PART TWO

TESTING INTRODUCTION PART THREE

TESTING INTRODUCTIONS PART FOUR

SOFTWARE TESTING FUNDAMENTALS

SOFTWARE TESTING FUNDAMENTALS PART TWO

SOFTWARE TESTING FUNDAMENTALS PART THREE

Arrays and c sharp

Array is an indexed collection of objects, all of the same type (e.g., all ints, all strings, etc.).

When you declare an array, you actually create an instance of the Array class in the System namespace (System.Array). Arrays in C# thus provide you with the best of both worlds: easy-to-use syntax built into the language, underpinned with an actual class definition so that instances of an array have access to the methods and properties of System.Array.

Once you declare an array, you must also instantiate it using the new keyword. For example, the following declaration sets aside memory for an array holding five integers:

myIntArray = new int[5];

It is important to distinguish between the array itself (which is a collection of elements) and the elements within the array. myIntArray is the array; its elements are the five integers it holds.

Understanding Default Values

When you create an array of value types, each element initially contains the default value for the type stored in the array. The following declaration creates an array of five integers, each of whose value is initialized to 0, the default value for integer types:

myIntArray = new int[5];

With an array of reference types, the elements are not initialized to their default values. Instead, they are initialized to null. If you attempt to access any of the elements in an array of reference types before you specifically initialize them, you will generate an exception .

Assume you have created a Button class. Declare an array of Button objects (thus reference types) with the following statement:

Button[] myButtonArray;

and instantiate the actual array, to hold three Buttons, like this:

myButtonArray = new Button[3];

Note that you can combine the two steps and write:

Button myButtonArray = new Button[3];

In either case, unlike with the earlier integer example, this statement does not create an array with references to three Button objects. Since Button objects are reference types, this creates the array myButtonArray with three null references.

To use this array, you must first construct and assign a Button object for each reference in the array. This is called populating the array. You can construct the objects in a loop that adds them one by one to the array.

Accessing Array Elements

Arrays are zero-based, which means that the index of the first element is always zero — in this case, myArray[0]. The second element is element 1. The numeric value is called the index, or the offset. Index 3 indicates the element offset from the beginning of the array by 3 elements, that is, the fourth element in the array. You access element 3 using the index operator [].

Because arrays are objects, they have properties. One of the more useful properties of the Array class is Length, which tells you how many objects are in an array. Array objects can be indexed from 0 to Length-1. That is, if there are five elements in an array, their indices are 0,1,2,3,4.

15.1.3

Programming Portal

Top Tabs