everywhere, i need to use std::

[drdoubt]

[1] using namespace std

In my C++ program, even after applying [1], I need to use the std
namespace with the scope resolution operator, like, std::cout,
std::vector. This I found a little bit cumbersome to always include
std.

I somewhere found a trick to overcome this problem. By using

using std::cout;
using std::vector;

rather than using [1].

is it always done like this or is there any other concept that I still
do not know.

regards,
vijay.

 

[EventHelix.com]

You can just add the statement:

using std;

Then you can use cout, vector etc. directly.

Deepa

 

[Ioannis Vranos]

[1] using namespace std

using namespace std;

In my C++ program, even after applying [1], I need to use the std
namespace with the scope resolution operator, like, std::cout,
std::vector. This I found a little bit cumbersome to always include
std.

I somewhere found a trick to overcome this problem. By using

using std::cout;
using std::vector;

rather than using [1].

is it always done like this or is there any other concept that I still
do not know.

If you place using namespace std; in the beginning of a scope, there is
no use for explicit scope resolution in that scope.


For example the following should compile successfully with your compiler:


#include <iostream>


int main()
{
using namespace std;

cout<<"Hello world!\n";
}

 

[Ioannis Vranos]

You can just add the statement:

using std;

Then you can use cout, vector etc. directly.

using namespace std;

 

[Pan Jiaming]

You can just add the statement:

using std;

A little mistake, should be
using namespace std;

 

[vijay]

[1] using namespace std

But here we need to [1] in every other function where cout, vector may
be used. The problem is that it then becomes a little bit redundant
because we either have to use scope resolution or place [1] in every
function definition.

I just wanted to know whether I can just place [1] in the beginning of
the file and not use scope resolution anywhere else in the program.

regards,
vijay.

 

[Ioannis Vranos]

[1] using namespace std

But here we need to [1] in every other function where cout, vector may
be used. The problem is that it then becomes a little bit redundant
because we either have to use scope resolution or place [1] in every
function definition.

I just wanted to know whether I can just place [1] in the beginning of
the file and not use scope resolution anywhere else in the program.

You mean to place it in the global scope and thus bring everything
defined in namespace std in the global namespace.


Well, namespace mechanism exists so as to be able to use different
facilities from various libraries.


Suppose you have another library or platform providing some other string
type with the name "string".


If you have not such concerns, then I guess you may place the facilities
you want in the global namespace, however you must keep in mind what the
namespace mechanism exists to offer and what problems may arise in the
future.

 

[Ioannis Vranos]

If you have not such concerns, then I guess you may place the facilities
you want in the global namespace, however you must keep in mind what the
namespace mechanism exists to offer and what problems may arise in the
future.

The preferred method however is to use the using namespace std; and
using std::some_facility; in as a small scope as possible, for example:



#include <iostream>
#include <ostream>
#include <vector>




void printfunc(const std::vector<int> &someVec)
{
using namespace std;

for(vector<int>::size_type i=0; i<someVec.size(); ++i)
cout<<someVec<<endl;
}


int main()
{
using std::vector;

vector<int> vec(10,2);

printfunc(vec);
}

 

[Chris Croughton]

[1] using namespace std

But here we need to [1] in every other function where cout, vector may
be used. The problem is that it then becomes a little bit redundant
because we either have to use scope resolution or place [1] in every
function definition.

I just wanted to know whether I can just place [1] in the beginning of
the file and not use scope resolution anywhere else in the program.

You certainly can, it's just the same as declaring something extern.
That's what I do, I see no point in hiding the std namespace (doing so
makes the code unreadable with std:: in front of everything). You can
do the same with other namespaces if you want as well.

Chris C

 

[Chris Croughton]

Suppose you have another library or platform providing some other string
type with the name "string".

Then you have a problem if you want to use std::string as well. I would
do using na,espace std; globally and get the individual things I needed
from the library separately, probably doing

typedef otherlib::string OtherStringT;

to get at the one in the other library.

If you have not such concerns, then I guess you may place the facilities
you want in the global namespace, however you must keep in mind what the
namespace mechanism exists to offer and what problems may arise in the
future.

It's normally safe to include namespace std in a module, as long as you
don't also globally include another namespace as well.

Chris C

 

[Ioannis Vranos]

Then you have a problem if you want to use std::string as well. I would
do using na,espace std; globally and get the individual things I needed
from the library separately, probably doing

typedef otherlib::string OtherStringT;

to get at the one in the other library.


It's normally safe to include namespace std in a module, as long as you
don't also globally include another namespace as well.

Consider a situation like this. An extern library/framework providing
its own version of vector separately from std::vector. I have one real
example in mind, VC++ 2005 which will provide managed versions of STL
facilities probably in namespace stdcli. And let's say you decide to use
in some parts of code stdcli::vector and in some others std::vector

(stdcli::vector inherits from some other .NET interfaces too -
IEnumerator, IList, and ICollection - so as to be also a derived class
from them, and thus be usable from the other .NET languages that have
only those interfaces.

As we said, after C++/CLI and VS 2005, C++ becomes the most powerful
language of .NET with the most abilities and facilities - for example
C++ with C++/CLI has both run-time generics and compile-time templates
while the other languages only run-time generics).


So let's suppose:


// Completely managed and verifiable
void someMFunc(const stdcli::vector<int> %mVec)
{
using namespace stdcli;

// ...
}


// Unmanaged
// Or void someUFunc(const std::vector<int> %mVec)
// % - tracking reference - works for both
void someUFunc(const std::vector<int> &mVec)
{
using namespace std;

// ...
}

 

[Chris Croughton]

Consider a situation like this. An extern library/framework providing
its own version of vector separately from std::vector. I have one real
example in mind, VC++ 2005 which will provide managed versions of STL
facilities probably in namespace stdcli. And let's say you decide to use
in some parts of code stdcli::vector and in some others std::vector

That sounds like a maintenance nightmare waiting to happen. I've seen
too many of those. If I had to use both, I'd probably decide to not use
using namespace at all and explicitly prefix everything with std:: or
stdcli:: as needed, to make it obvious which one is being used.

(stdcli::vector inherits from some other .NET interfaces too -
IEnumerator, IList, and ICollection - so as to be also a derived class
from them, and thus be usable from the other .NET languages that have
only those interfaces.

Well, if you will use non-standard and non-portable stuff I guess you
deserve it...

As we said, after C++/CLI and VS 2005, C++ becomes the most powerful
language of .NET with the most abilities and facilities - for example
C++ with C++/CLI has both run-time generics and compile-time templates
while the other languages only run-time generics).

It's not exactly Standard C++, though, is it?

So let's suppose:

// Completely managed and verifiable
void someMFunc(const stdcli::vector<int> %mVec)

Invalid operator '%'. This newsgroup uses Standard C++. But let's
assume it's a normal reference &...

{
using namespace stdcli;

// ...
}

// Unmanaged
// Or void someUFunc(const std::vector<int> %mVec)
// % - tracking reference - works for both
void someUFunc(const std::vector<int> &mVec)
{
using namespace std;

// ...
}

And? I don't see the problem, or how it applies. Try, for instance:

#include <vector>
#include <stdcli> // or whatever it is

using namespace std;

void someMFunc(const stdcli::vector<int> &mVec)
{
using namespace stdcli;
// stuff
}

// Everything else uses std:: by default

void someUFunc(const vector<int> &mVec)
{
// stuff
}

The local using namespace overrides the global one in the first case (so
if you wanted to use identifiers from std overridden by ones in stdcli
you need to add std:: in front).

Even better, stick the functions in different compilation units, then
one can use stdcli and the other std and you don't need the local
overrides at all.

Chris C

 

[Ioannis Vranos]

That sounds like a maintenance nightmare waiting to happen. I've seen
too many of those. If I had to use both, I'd probably decide to not use
using namespace at all and explicitly prefix everything with std:: or
stdcli:: as needed, to make it obvious which one is being used.

I think in small scopes (that should always be the case), "using"
statements are obvious too.

And? I don't see the problem, or how it applies. Try, for instance:

#include <vector>
#include <stdcli> // or whatever it is

using namespace std;

void someMFunc(const stdcli::vector<int> &mVec)
{
using namespace stdcli;

vector name collision. For example:


for (vector<int>::size_type i=0; i<mVec.size(); ++i)
//...

// stuff
}

// Everything else uses std:: by default

void someUFunc(const vector<int> &mVec)
{
// stuff
}

The local using namespace overrides the global one in the first case (so
if you wanted to use identifiers from std overridden by ones in stdcli
you need to add std:: in front).

No, you get name collision. Try this example with your compiler:


#include <vector>


namespace test
{
template<class T>
class vector{};
}


using namespace std;


int main()
{
using namespace test;

vector<int> vec;
}

 

[Chris Croughton]

I think in small scopes (that should always be the case), "using"
statements are obvious too.

For a /very/ small scope. But for a small scope there is little need to
do using namespace anyway, just the bits you need.

But what I was referring to was not the use of "using namespace" but the
idea of overloading a standard identifier, and in particular using both
in the same program (and worse in the same module). One of the big
points of namespaces is that code can be split across modules without
polluting the global namespace, down to having one function per module
if wanted (especially useful for libraries so that only needed code is
linked), so there should never be a need to use both together except in
a few conversion functions (which have to differentiate them using the
namespace:: syntax anyway).

vector name collision. For example:

for (vector<int>::size_type i=0; i<mVec.size(); ++i)
//...

Hmm, what I tried worked with gcc 3.3.4, but it wasn't quite the same.
See below.

No, you get name collision. Try this example with your compiler:

So you do. However, you /can/ use a using declaration to disambiguate
it. You can even use a using directive to get most of the symbols from
the local namespace and use a using directive to get the ones which
clash:

#include <vector>

namespace test
{
int fred;
template<class T>
class vector{};
}

using namespace std;

void func()
{
vector<int> vec1; // std::vector<int>
test::vector<int> vec2; // test::vector<int>
}

int main()
{
using namespace test;
using test::vector;

fred = 0; // test::fred
vector<int> vec1; // test::vector<int>
std::vector<int> vec2; // std::vector<int>

return 0;
}

Having to insert a using declaration, or use the namespace:: prefix,
makes it obvious to the maintainer that there is some code which needs
particular attention.

(In general, the only namespaces I would use with using directives
globally are ones with project-wide scope, like std or a project
namespace, and those should be easy enough to avoid name clashes. If I
really needed to override certain identifiers in std I would use
specific using declarations to make it obvious what was changed.)

Chris C

 

[Ioannis Vranos]

For a /very/ small scope. But for a small scope there is little need to
do using namespace anyway, just the bits you need.

But what I was referring to was not the use of "using namespace" but the
idea of overloading a standard identifier, and in particular using both
in the same program (and worse in the same module). One of the big
points of namespaces is that code can be split across modules without
polluting the global namespace, down to having one function per module
if wanted (especially useful for libraries so that only needed code is
linked), so there should never be a need to use both together except in
a few conversion functions (which have to differentiate them using the
namespace:: syntax anyway).

In this case one may use the native .NET containers instead, but what if
I want a vector of Buttons? The .NET STL versions have definitions that
take managed types under consideration (handles ^ and tracking
references %) and also inherit from the aforementioned interfaces for
interoperability with the other languages.

For example instead of returning an IList ^ explicitly by making the
necessary conversions or using it since the beginning, one C++
programmer can just return a stdcli::vector<int> ^ and the C# fellow can
use it as a IList ^.


The bottom line is we have a system-dependent .NET vector version and
the std::vector. Also one may want (and even nowadays use) a third party
native C++ library like Boost with a function or method that returns
an std::vector, together with managed code, in mixed mode (in fact I
guess all C++ programmers in .NET work that way, myself for example
prefer to use std::wstring instead of System::StringBuilder today), so
as to have and utilise all C++ facilities out there.


And stdcli::vector is a different type from std::vector, since it
inherits from these interfaces and thus not implicitly interchangeable
between them (perhaps stdcli::vector may have an assignment operator and
copy constructor taking std::vector, I do not know, but this does not
change things), so we have two types named vector inside the same code.


If things were simpler we would not have namespaces after all.

So you do. However, you /can/ use a using declaration to disambiguate
it. You can even use a using directive to get most of the symbols from
the local namespace and use a using directive to get the ones which
clash:

#include <vector>

namespace test
{
int fred;
template<class T>
class vector{};
}

using namespace std;

void func()
{
vector<int> vec1; // std::vector<int>
test::vector<int> vec2; // test::vector<int>
}

int main()
{
using namespace test;
using test::vector;

fred = 0; // test::fred
vector<int> vec1; // test::vector<int>
std::vector<int> vec2; // std::vector<int>

return 0;
}

Well, you prefer this approach, I prefer another. We have got in a habit
issue here and I do not think we can reach an agreement.

It is like void foo() {

vs void foo
{


In any case I am bored to type std::vector all the time.

 

[Chris Croughton]

In this case one may use the native .NET containers instead, but what if
I want a vector of Buttons? The .NET STL versions have definitions that
take managed types under consideration (handles ^ and tracking
references %) and also inherit from the aforementioned interfaces for
interoperability with the other languages.

I don't know what these 'managed' types and 'handles' are, but they
aren't C++. They may be in some proprietary language but that is
off-topic in comp.lang.c++. I know nothing of .NET and have no interest
either, the next language I'm learning will be Java because it's likely
to be required in my job...

For example instead of returning an IList ^ explicitly by making the
necessary conversions or using it since the beginning, one C++
programmer can just return a stdcli::vector<int> ^ and the C# fellow can
use it as a IList ^.

In which case it gets an error because IList ^ is invalid C++. C# is
also off-topic in comp.lang.c++.

The bottom line is we have a system-dependent .NET vector version and
the std::vector. Also one may want (and even nowadays use) a third party
native C++ library like Boost with a function or method that returns
an std::vector, together with managed code, in mixed mode (in fact I
guess all C++ programmers in .NET work that way, myself for example
prefer to use std::wstring instead of System::StringBuilder today), so
as to have and utilise all C++ facilities out there.

So you need to distinguish them, and the only way to do that is to use
the std:: or stdcli:: or whatever prefixes to at least one of the types.
The same applies just as much whether you have used using namespace at
file scope or function scope, if you need to mix them then you need to
disambiguate specific cases.

And stdcli::vector is a different type from std::vector, since it
inherits from these interfaces and thus not implicitly interchangeable
between them (perhaps stdcli::vector may have an assignment operator and
copy constructor taking std::vector, I do not know, but this does not
change things), so we have two types named vector inside the same code.

Yup. One is named std::vector and the other is named stdcli::vector.
What's the problem?

If things were simpler we would not have namespaces after all.

There are plenty of simpler situations for which namespaces are useful.
One major one is having multi-module libraries with shared identifiers
which are 'global' (in the sense of being visible to the linker) but
which are not visible to the user, without having to do explicit name
prefixes (mylib_func1(), mylib_func2() etc. gets clumsy, much easier for
each module to reside in namespace mylib and call them whatever the
implementor likes). The anonymous namescape also removes the need for
the horribly overloaded 'static' keyword by providing a file scope
namespace.

Well, you prefer this approach, I prefer another. We have got in a habit
issue here and I do not think we can reach an agreement.

If you mean it's a style issue, perhaps it largely is, which is my
point, there is nothing intrinsically better about your style because it
can run into exactly the same problems.

It is like void foo() {

vs void foo
{

The latter is not valid C++, if you want to define a function you must
have at least an empty pair of parentheses.

In any case I am bored to type std::vector all the time.

If you are mixing two namespaces with vector in each then you have to
disambiguate it somehow. Or just don't use broken proprietary libraries
which have identifiers which look like ones in namespace std but act
differently.

I too don't like typing std:: all over the place, which is why I
generally do using namespace std; at file scope at the top...

Chris C