Quick Tips On Using Whole Program Optimization

If you’re writing native C++ code, you can typically speed up your optimized code by about another 3-4% by adding the /GL flag to your compiles. This flag tells the compiler to defer code generation until you link your program. Then at link time the linker calls back to the compiler to finish compilation. If you compile all your sources this way, the compiler optimizes your program as a whole rather than one source file at a time. For users building with the IDE, this option is found under the C/C++ optimization settings, and is already on by default for retail builds in new projects.

Using Whole Program Optimization provides the optimizer with a number of extra optimization opportunities, but I’ll give just one example. Many people are already familiar with the benefits of inlining a called function into the caller. We can only do inlining when we are generating code for both the calling function and the called function at the same time. With Link Time Code Gen we can inline functions from one source file into callers defined in another source file, as long as both source files were compiled with /GL.

If you do use /GL, here are four caveats to keep in mind:

1. When building from the command line or via makefiles, you need to add the /LTCG switch to the link command line to tell the linker to expect to see one or more object files that were compiled with /GL. If you don’t, some build time will be wasted because the linker will have to start over when it gets to the module compiled with /GL. If you build through the IDE this is in your project configuration settings on the Linker optimization page.

2. Using /GL reduces your compile times, but your link time will increase, because work is being moved to during the link. Overall build time might increase a little, but shouldn’t increase a lot.

3. Don’t compile managed code with /GL. Link time code gen provides little or no benefit to managed code, and this option combination (/GL /clr) is being removed in the next compiler release, so you can future-proof your build by using link time code generation only for native code. If you’re building managed code using the IDE, the default setting is to use /GL in release builds, and I recommend you disable it for managed code. For mixed managed and native code, compiling only the native code with /GL and linking with /LTCG gives best results.

4. Never use /GL for code you intend to put in a library and ship to your customers. Doing so means that your customers will be doing the code gen for your library when they link their application. Since some of your customers could have different versions of the compiler, shipping a lib built this way could cause various maintenance problems for you. If your customer’s compiler is from a prior release, their link may fail. If their version is newer than yours, the code they generate won’t be exactly equal to what you’ve tested, and could behave differently for them than when you tested it. In VS 2008, the IDE default for the class library template release configuration is to build using /GL, and I strongly encourage everyone to reset that.

Here are links for more information on this topic:

The /GL compiler switch (http://msdn.microsoft.com/en-us/library/0zza0de8.aspx)

The /LTCG linker switch (http://msdn.microsoft.com/en-us/library/xbf3tbeh.aspx)

A detailed article about Link Time Code Generation (http://msdn.microsoft.com/en-us/magazine/cc301698.aspx)

Just simple guess game

Free-submit.co.cc - FREE SUBMIT YOUR BLOG AND GET HIGH TRAFFIC


In this posting, I will show you about a simple guess game.
This is the code.

#include
int main()
{
int myBirthday = 13;
int guess;

cout << "Please guess the day of my birth, from 1 to 31"<<< "Enter your guess please"; cin >> guess;

if (guess < else="" if="" guess="">31)
{
cout << "Pretty long month, genius!!" <<< "Incredible,, you are right. Congratulations.."<< else="" cout=""><< "Lower" <<>

Essentials of System Analysis and Design or Expert C Programming

Expert C Programming

Author: Peter van der Linden

This is a very different book on the C language! In an easy, conversational style, Peter van der Linden, of Sun's compiler and OS kernel group, presents dozens of astonishing examples drawn from practical experience, including:

• Software that blew up the space probe to Venus
• The C bug that shut down the entire AT&T phone system
• C programmer job interview secrets
• Why programmers can't tell Halloween from Christmas day
• The C code for a complete BASIC interpreter

Expert C Programming reveals the coding techniques used by the best C programmers. It relates C to other languages, and includes an introduction to C++ that can be understood by an programmer without weeks of mind-bending study. Covering both the IBM PC and UNIX systems, it is an entertaining and educational romp through C showing how experts really use it. Expert C Programming is a must read for anyone who wants to learn more about the implementation, practical use, and folklore of C.

"Not just clearly written, but fun to read. The tone and style of this text should make this a popular book with professional programmers. However, the tone of this book will make it very popular with undergraduates. Appendix A alone would make the purchase of this book a must. It's filled with great advice."

—Professor Jack Beidler, Chairman, Department of Computer Science, University of Scranton

"So that's why extern char *cp isn't the same as extern char cp. I knew that it didn't work despite their superficial equivalence, but I didn't know why. I also love the job interview test questions on C."

—David S.Platt, Rolling Thunder Computing

"In Expert C Programming, Peter van der Linden combines C language expertise and a subtle sense of humor to deliver a C programming book that stands out from the pack. In a genre too often known for windy, lifeless prose, van der Linden's crisp language, tongue-in-cheek attitude, and real-world examples engage and instruct."

—John Barry, author of Sunburst, Technobabble, and other books

Table of Contents:

	Preface
	Acknowledgments
	Introduction
1	C Through the Mists of Time	1
2	It's Not a Bug, It's a Language Feature	31
3	Unscrambling Declarations in C	63
4	The Shocking Truth: C Arrays and Pointers Are NOT the Same!	95
5	Thinking of Linking	109
6	Poetry in Motion: Runtime Data Structures	137
7	Thanks for the Memory	165
8	Why Programmers Can't Tell Halloween from Christmas Day	201
9	More about Arrays	239
10	More About Pointers	263
11	You Know C, So C++ is Easy!	293
	Appendix: Secrets of Programmer Job Interviews	333
	Index	349

Nested Classes

Classes can be defined inside other classes. Classes that are defined inside other classes are called nested classes. Nested classes are used in situations where the nested class has a close conceptual relationship to its surrounding class. For example, with the class string a type string::iterator is available which will provide all characters that are stored in the string. This string::iterator type could be defined as an object iterator, defined as nested class in the class string.

A class can be nested in every part of the surrounding class: in the public, protected or private section. Such a nested class can be considered a member of the surrounding class. The normal access and rules in classes apply to nested classes. If a class is nested in the public section of a class, it is visible outside the surrounding class. If it is nested in the protected section it is visible in subclasses, derived from the surrounding class , if it is nested in the private section, it is only visible for the members of the surrounding class.

The surrounding class has no special privileges with respect to the nested class. So, the nested class still has full control over the accessibility of its members by the surrounding class. For example, consider the following class definition:

    class Surround
   {
       public:
           class FirstWithin
           {
               int d_variable;

               public:
                   FirstWithin();
                   int var() const;
           };
       private:
           class SecondWithin
           {
               int d_variable;

               public:
                   SecondWithin();
                   int var() const;
           };
   };
   inline int Surround::FirstWithin::var() const
   {
       return d_variable;
   }
   inline int Surround::SecondWithin::var() const
   {
       return d_variable;
   }

In this definition access to the members is defined as follows:

• The class FirstWithin is visible both outside and inside Surround. The class FirstWithin therefore has global scope.
• The constructor FirstWithin() and the member function var() of the class FirstWithin are also globally visible.
• The int d_variable datamember is only visible to the members of the class FirstWithin. Neither the members of Surround nor the members of SecondWithin can access d_variable of the class FirstWithin directly.
• The class SecondWithin is only visible inside Surround. The public members of the class SecondWithin can also be used by the members of the class FirstWithin, as nested classes can be considered members of their surrounding class.
• The constructor SecondWithin() and the member function var() of the class SecondWithin can also only be reached by the members of Surround (and by the members of its nested classes).
• The int d_variable datamember of the class SecondWithin is only visible to the members of the class SecondWithin. Neither the members of Surround nor the members of FirstWithin can access d_variable of the class SecondWithin directly.
• As always, an object of the class type is required before its members can be called. This also holds true for nested classes.

If the surrounding class should have access rights to the private members of its nested classes or if nested classes should have access rights to the private members of the surrounding class, the classes can be defined as friend classes.

The nested classes can be considered members of the surrounding class, but the members of nested classes are not members of the surrounding class. So, a member of the class Surround may not access FirstWithin::var() directly. This is understandable considering the fact that a Surround object is not also a FirstWithin or SecondWithin object. In fact, nested classes are just typenames. It is not implied that objects of such classes automatically exist in the surrounding class. If a member of the surrounding class should use a (non-static) member of a nested class then the surrounding class must define a nested class object, which can thereupon be used by the members of the surrounding class to use members of the nested class.

For example, in the following class definition there is a surrounding class Outer and a nested class Inner. The class Outer contains a member function caller() which uses the inner object that is composed in Outer to call the infunction() member function of Inner:

    class Outer
   {
       public:
           void caller();

       private:
           class Inner
           {
               public:
                   void infunction();
           };
           Inner d_inner;      // class Inner must be known
   };
   void Outer::caller()
   {
       d_inner.infunction();
   }

The mentioned function Inner::infunction() can be called as part of the inline definition of Outer::caller(), even though the definition of the class Inner is yet to be seen by the compiler. On the other hand, the compiler must have seen the definition of the class Inner before a data member of that class can be defined.

Intel releases updated concurrent C/C++ tools

Intel Corp. has announced version 0.3.0 of its Concurrent Collections for C/C++, downloadable from the company's site.

Among the new and updated features Release 0.3.0 includes are: steps that can now be specified with different priorities to improve performance; support for garbage collection by ref-counting to reduce memory usage.

The collections provide the tools for constructing C++ programs that execute in parallel while allowing application developers to ignore issues of parallelism such as low-level threading constructs or the scheduling and distribution of computations.

The model lets programmers specify high-level computational steps including inputs and outputs without imposing unnecessary ordering on their execution. Code within the computational steps is written using standard serial constructs of the C++ language.

Data is either local to a computational step or it is explicitly produced and consumed by them. An application in this programming model supports multiple styles of parallelism (e.g., data, task, pipeline parallel).

While the interface between the computational steps and the runtime system remains unchanged, a wide range of runtime systems may target different architectures (e.g., shared memory, distributed) or support different scheduling methodologies (e.g., static or dynamic).

Intel is also providing a runtime system for shared memory systems that supports parallel execution although it is not yet highly optimised.

The birth of C++

In the coming two years after C was released, the code written in C began to suffer from a problem. As the programmers harnessed the power of Personal Computer, the software grew more complex, and the C programs have gotten longer and longer. This meant that these programs were also harder to maintain. Some functions needed to communicate with other functions, but there was no standard way of thinking about data organization. In long programs, the code was practically infested with functions in the global scope. One of the few ways to separate data was by using separate C header (.h) and C source (.c) files. Other than that, the language's features that would help organize the code to ensure readability of large programs were simply missing.

There had to be a solution. In 1983, Bjarne Stroustrup developed such a solution, and named it the C++ programming language. He drew inspiration from some of the previous languages that allowed object-oriented programming. One of those languages was Simula67. It can be said that one of the greatest addition to C's supset, the C++ language, was that C++ introduced programmers to the concept of an object. An object is an abstraction of a problem. Not only does the use of the concept of objects in a programming language reduce the size of the program, it also makes the program much more readable and compact. The notion of objects gave the origin to the concept of Object-Oriented programming which I discuss in my Introduction to Object-Oriented Programming.

Why was it named C++?

Initially the C++ language was named "C with Classes" because you could still write C-like programs in C++ but you could also use what we call classes. I will be sure to talk about classes and other object-oriented C++ concepts in the following tutorials. You might ask, why a successor to C is called C++ and what is this double plus sign business all about? If you were writing a program in C and you wanted to add two numbers together such as 1 + 1, in the listing (or source code) of your program, you would write it just that way as: 1 + 1. Notice that in computer programming, the plus sign is called an operator, it directs the compiler to add two values together. Plenty of times programmers need to add the digit 1 to another digit stored in what is called a variable. Because of the frequent use of these simple arithmetics in general computer programs, a new operator called postfix increment (represented by a double plus sequence: ++) may be used to simply add 1 to the existing value, thus avoiding the redundancy of typing: 1 + 1. It just makes the program code look cleaner and easier to read. Therefore, you can see that the expression C++ actually has a meaning. It is C incremented by 1, or in other words, a version of C programming language that contains additional features. You may also think of C++ as an augmented version of C.

On the other hand, the reason the C programming language is called C, is that it is a successor to the language called B. Simple isn't it? Strange as it is, there was never a programming language called A. Or as far as we know, if there was a language called A, it never saw the light of success or popularity. If you are interested in learning about how C++ falls into the history of computer programming languages, you may want to look at the chart of evolution of computer languages. This hierarchy shows where each computer language came from. As you can see the Assembly Language (which is a low-level programming language) on this chart is located in the upper left corner because it is one of the first languages ever designed and can be considered the grand-father of all computer programming languages. Additionally you may be able to gain an insight from the list of programming languages by date that lists languages in chronological order.