非常重要的5个函数

[windows平台]
(1)mainCRTStartup或者wmainCRTStartup                                    [main()函数的变体----------console]
(2)WinMainCRTStartup或者wWinMainCRTStartup                    [WinMain()函数的变体----Windows]
(3)_DllMainCRTStartup                                                     [DLL的入口函数变体------DLL]

之所以，你必须清楚的记忆它们，是因为：如果你建立工程的类型的时候，指定错了的情况下，不必重新建立工程，只需要把你的main()换成WinMain()并指定：C Complier编译时按照“多线程”进行，然后，指定LINKER在连接时查找"WinMainCRTStartup"或者UNICODE版本的入口点函数就可以了。
反之亦然！同样使用DLL的情况，当然你还要把你源文件中的main()换成WinMain()

===========================================================

CRTStartup表示的意思：C   Run-Time Startup

C Run-Time Libraries

The following table lists the release versions of the C run-time library files, along with their associated compiler options and environment variables. Prior to Visual C++ 4.2, the C run-time libraries contained the iostream library functions. In Visual C++ 4.2 and later, the old iostream library functions have been removed from LIBC.LIB, LIBCMT.LIB, and MSVCRT.LIB. (This change was made because the Standard C++ library has been added to Visual C++, and it contains a new set of iostream libraries. Thus, two sets of iostream functions are now included in Visual C++.) The old iostream functions now exist in their own libraries: LIBCI.LIB, LIBCIMT.LIB, and MSVCIRT.LIB. The new iostream functions, as well as many other new functions, exist in theStandard C++ libraries(SCL>STL=80%*SCL): LIBCP.LIB, LIBCPMT.LIB, and MSVCPRT.LIB.

(1) VC版本<=Visual C++ 4.2 的： LIBC.LIB, LIBCMT.LIB和MSVCRT.LIB                              [common]
(2) VC版本>=Visual C++ 4.2的： LIBCI.LIB, LIBCIMT.LIB, 和 MSVCIRT.LIB.                     [common+I]
(3) 新的io函数和其他一些函数：LIBCP.LIB, LIBCPMT.LIB, 和 MSVCPRT.LIB                    [common+P]

Note that headers from the Standard C++ library and the old iostream library cannot be mixed.

Headers determine whether a Standard C++ library, an old iostream library, or neither will be linked.
Compiler options determine which of the libraries to be linked is the default (single-threaded, multithreaded, or DLL).
When a specific library compiler option is defined, that library is considered to be the default and its environment variables are automatically defined.

C Run-Time Library (without iostream)	Characteristics	Option	Defined
LIBC.LIB	Single threaded, static link	/ML
LIBCMT.LIB	Multithreaded, static link	/MT	_MT
MSVCRT.LIB	Multithreaded, dynamic link (import library for MSVCRT.DLL)	/MD	_MT, _DLL

Standard C++ Library	Characteristics	Option	Defined
LIBCP.LIB	Single threaded, static link	/ML
LIBCPMT.LIB	Multithreaded, static link	/MT	_MT
MSVCPRT.LIB	Multithreaded, dynamic link (import library for MSVCRT.DLL)	/MD	_MT, _DLL

Old Iostream Library	Characteristics	Option	Defined
LIBCI.LIB	Single threaded, static link	/ML
LIBCIMT.LIB	Multithreaded, static link	/MT	_MT
MSVCIRT.LIB	Multithreaded, dynamic link (import library for MSVCIRT.DLL)	/MD	_MT, _DLL

================================================================================
namespace std {
    extern istream cin;
    extern ostream cout;
    extern ostream cerr;
    extern ostream clog;
    extern wistream wcin;
    extern wostream wcout;
    extern wostream wcerr;
    extern wostream wclog;
    };

对上面的8个“标识符”：cin/cout/cerr/clog/wcin/wcout/wcerr/wclog，你可以不使用：using namesapce std;
但是，你需要使用前面加上“std::”，这样不会引入库(M$的MSDN中如是说)，但是，这顶什么用？
麻烦不说，连“endl”都使用不了，所以说：还是使用 using namesapce std;来的方便
===========================================================================
<cstdlib>

namespace std {#include <stdlib.h> };  
 





//你可以定义你自己的namespace company.modeleType.Author{..........};     [C#风格][C++换成“_”]

//还有其它的因素要考虑：你的namespace够不够彪悍，是不是“近乎完美”等等因素都要考虑


//起码的“结对的”oparator+/operator-等等的内容是必须要实现的
//friend...template...inline....const....重载...等等都是要考虑的内容
//friend就是是漂浮在Class Library空间中的“幽灵”一样，基本的规则是：private+friend class
//public+friend function的组合，除非你的思维清晰到(public或protected或private)+(friend class或
//friend function=>6种形式，然后再加上“子子孙孙无穷尽也的device class层次”)，
//你可以达到吗，你能达到，你的库的使用者也能够达到你的水平吗？？否则你还是等它近乎完美了再说
//有最完美的吗？没有！！所以，什么是你需要的最基本的，才是你的构造原则！！

Include the standard header <cstdlib> to effectively include the standard header <stdlib.h> within the std namespace.
===========================================================================
《C++primer》中关于namespace的几个例子
An Array by Any Other Name
One of the difficulties of distributing our code to sites other than those in which we program is that we cannot know what effect, if any, our global names may have. For example, if someone at Intel has written
class Array { ... };
then that site cannot use both that Array class and the one we've implemented in the same program. The visibility of the names makes the two implementations mutually exclusive.
The conventional way of solving this problem before Standard C++ was to prefix the globally visible names with some lexically
unique string. For example, we might release our Array as
class Cplusplus_Primer_Third_Edition_Array { ... };
Although that name is certainly likely to be unique (we cannot guarantee that, however), it is also something of a handful to write.
The Standard C++ namespace mechanism is a language-level solution to this problem.
The namespace mechanism allows us to encapsulate names that otherwise pollute the global namespace. In general, we use
namespaces only when we expect our code to be used in external software sites. For example, here is how we might encapsulate our
Array class:
namespace Cplusplus_Primer_3E {
template <class elemType>
class Array { ... };
// ...
}
The name following the namespace keyword identifies a namespace separate from the global namespace within which we can place entities we wish to declare outside a function or class. The namespace does not change the meaning of the declarations within it; it changes only their visibility. Before continuing, let's extend our set of available namespaces:
namespace IBM_Canada_Laboratory {
template <class elemType>
class Array { ... };
class Matrix { ... };
// ...
}
namespace Disney_Feature_Animation {
class Point { ... };
template <class elemType, int size>
class Array { ... };
// ...
}
If the declarations within a namespace are not immediately visible to the program, how do we access them? We use a qualified name notation of the form
namespace_identifier::entity_name;
as in
Cplusplus_Primer_3E::Array<string> text;
IBM_Canada_Laboratory::Matrix mat;
Disney_Feature_Animation::Point origin( 5000, 5000 );
Although Disney_Feature_Animation, IBM_Canada_Laboratory, and Cplusplus_Primer_3E uniquely identify each respective
namespace, they are somewhat cumbersome to use often within our programs. Using namespace identifiers such as P3E, DFA, or
IBM_CL is more convenient, but it conveys considerably less information and increases the possibility of name collision. To provide for both meaningful namespace identifiers and programmer convenience in accessing the entities declared within the namespace, an alias facility is provided.
A namespace alias allows us to associate an alternative, shorter or generic name with an existing namespace. For example:
// provide a generic alias
namespace LIB = IBM_Canada_Laboratory;
// simply provide a shorter alias
namespace DFA = Disney_Feature_Animation;
This alias can then be used as a synonym to the original namespace. For example:
#include "IBM_Canada.h"
namespace LIB = IBM_Canada_Laboratory;
int main()
{
LIB::Array<int> ia(1024);
// ...
}
Potentially, an alias can also serve to encapsulate the actual namespace being used. In this scenario, for example, by changing the namespace assigned to the alias, we change the set of declarations we use without having to change the actual code accessing those declarations through the alias. For example:
namespace LIB = Cplusplus_Primer_3E;
int main()
{
// in this case, this declaration need not change
LIB::Array<int> ia(1024);
// ...
}
For this technique to work in practice, however, the declarations within the two namespaces must provide the exact interface. For
example, the following does not work because the Disney Array class wants both a type and a size parameter for its Array class:
namespace LIB = Disney_Feature_Animation;
int main()
{
// no longer a valid declaration
LIB::Array<int> ia(1024);
// ...
}
More often, programmers would prefer unqualified access to the names declared within a namespace. Even with the ability to
provide a shorter alias for a namespace identifier, it can often prove cumbersome to qualify every access of every name declared
within a namespace. The using directive makes the declarations within a namespace visible so that they can be referred to without qualification. For example:
#include "IBM_Canada_Laboratory.h"
// makes all names visible
using namespace IBM_Canada_Laboratory;
int main()
{
// ok: IBM_Canada_Laboratory::Matrix
Matrix mat( 4,4 );
// ok: IBM_Canada_Laboratory::Array
Array<int> ia( 1024 );
// ...
}
Both using and namespace are keywords. The namespace referred to must already have been declared, or a compile-time error
results.The using declaration provides a more selective name visibility mechanism. It allows for a single declaration within a namespace to be made visible. For example:
#include "IBM_Canada_Laboratory.h"
// only makes Matrix visible
using IBM_Canada_Laboratory::Matrix;
int main()
{
// ok: IBM_Canada_Laboratory::Matrix
Matrix mat(4,4);
// error: IBM_Canada_Laboratory::Array not visible
Array<int> ia( 1024 );
// ...
}
To prevent the components of the C++ standard library from polluting the global namespace of users' programs, all the components of the C++ standard library are declared within a namespace called namespace std. As we mentioned in Chapter 1, even though we include a C++ library header file in a program text file, the components declared within that header file are not automatically visible in the text file. For example, under Standard C++, the following code sample does not compile properly:
#include <string>
// error: string is not visible
string current_chapter = "A Tour of C++";
All the declarations in the <string> header file are enclosed in namespace std. As mentioned in Chapter 1, we can use a using
directive following the #include preprocessor directive to make the components of namespace std declared in the C++ header file <string> visible in the text file:
#include <string>
using namespace std;
// ok: string is visible
string current_chapter = "A Tour of C++";
A using directive is usually seen as a poor choice for making the names declared in namespace std visible in our programs. In the example, the using directive makes all the components of namespace std declared in the header file <string> visible in the program text file. This brings back the global namespace pollution problem that namespace std tries to avoid in the first place and increases the chance that names of the C++ standard library components will collide with some of the global names declared in our program.
Now that we have seen a little bit more about the namespace mechanism, we know that two other mechanisms can be used instead of a using directive to refer to the name string hidden in namespace std. We can use the qualified name, as follows:
#include <string>
// ok: use qualified name
std::string current_chapter = "A Tour of C++";
Or we can use a using declaration as follows:
#include <string>
using std::string;
// ok: using declaration makes string visible
string current_chapter = "A Tour of C++";
To use names declared in namespace std, we recommend the use of the more selective using declarations instead of using directives.
This is another reason that no using directives appear in the code examples of this book. Ideally, a code example should have a using declaration for each library component it uses. To limit the size of the examples and also because many of the examples in this book were compiled with implementations not supporting namespaces, the using declarations are not shown. Section 8.6 discusses further how using declarations are used for the components of the C++ standard library.