namespaces purposes in DLL

[chiwing]

http://www.cplusplus.com/doc/tutorial/namespaces/

it say "Namespaces allow to group entities like classes, objects and functions under a name. This way the global scope can be divided in "sub-scopes", each one with its own name."

using namespace exit ;
happy string __stdcall ETT(double    ,double     ,string        ,string [] );
happy string __stdcall ETT(double bid,double openprice,string comment,string Order_ID[ ] )
{  
   bid += openprice ;
}

1)
someone tell me the purpose of namespac is helping you not need to type so much--> you can omit the statment of declare directory(i.e. line 2), does he correct?~ ~

2)
what is the meaning of "std"?

thanks

[jsmith]

Namespaces are not there to reduce your typing; in fact, they make you type more.

Namespaces were invented because of a need to solve the following problem.

Suppose I'm writing a program, and I need to use two libraries, each of which was written by
different people. It just so happens that the first library has a symbol called "foo" which is a
function, say: void foo( int x ). But the second library has a symbol called "foo" which is an
enum value, say: enum junk { foo, foobar, baz };

In this case, the problem is that I cannot include the headers that define both versions of foo
in any source file, because the compiler will complain about "foo" being re-defined.

A second problem exists where "foo" is a function in both cases that happens to take the
same arguments. Now, the linker will complain about two different versions of "foo".

Namespaces avoid this problem by allowing programmers to put all of their symbols into
a logical grouping called a "namespace". It disambiguates the code.

std is the namespace that the C++ library uses to declare all of its publicly accessible) symbols.

[chiwing]

it really help me to know deeply of namespaces, std , thanks a lot to your paragragh, jsmith

[Duthomhas]

There is another, more insiduous need for namespaces.

Suppose vender A produces a library defining the symbol "foo" as one of its internal objects.

Then vender B produces another, unrelated library defining the symbol "foo" as one of its internal objects.

JRH finds both libraries and says, "Sweet. I can do flobbitz and quux at the same time! (No reinventing any wheels!)" But when he compiles and links his application, he discovers that said application has random crashes. JRH may at some point reorder the link list when compiling, and produce a perplexing new version with random crashes that behave entirely differently than the last build (the one he had been trying to debug for a week).

The problem is that the choice of symbol to use is whichever the linker happens to like best at the moment, since it really has no way to distinguish "foo" from "foo".

Moral

If you are writing a library, always always always wrap everything in a unique namespace.

Heh...

[chiwing]

thanks, Huoas

it's about 2 identical function name, it's a obvious problem~ ~