std namespace

[REH]

This is probably a dumb question, but...

I have a code file in which I cannot use a using directive to pull in
std (because it conflicts with a library I have to pull in). So, how
to I handle names that can be macros, but may not be (such as errno)?
Is there a simpler way than (for example):

#ifdef errno
errno = 0;
#else
std::errno = 0;
#endif


REH

 

[Alf P. Steinbach]

* REH:

This is probably a dumb question, but...

I have a code file in which I cannot use a using directive to pull in
std (because it conflicts with a library I have to pull in).

All right.

So, how
to I handle names that can be macros, but may not be

That's an unrelated question, but OK.

The answer is to just use them.

(such as errno)?

'errno' is a macro that expands to a modifiable lvalue; it's not anything but a
macro.

Is there a simpler way than (for example):

#ifdef errno
errno = 0;
#else
std::errno = 0;
#endif

'errno' is from the C library so just

#include <errno.h>

then

errno = 0;



Cheers & hth.,

- Alf

 

[REH]

That's an unrelated question, but OK.

No, you misunderstood the question.

'errno' is a macro that expands to a modifiable lvalue; it's not anything but a
macro.

Ah, I didn't know that. I believe the C standard allows it to be
either a macro or an int. I didn't realize the C++ standard was
different. That make it easier.

Thanks.

 

[REH]

"Pulling in std" with a using-directive is usually a bad idea, anyway.

I agree it's bad in header files. I do not agree for code files.

REH

 

[Juha Nieminen]

I agree it's bad in header files. I do not agree for code files.

I stopped using "using namespace std;" when I realized that my source
files actually became *easier* to read and understand when I had to
specify the proper namespace prefixes, rather than the contrary.

Some people still struggle against that idea, though.

(And no, this does not mean I never use "using" at all. I'm talking
about the std namespace here. There are other situations where it might
be handier to pull something out of a namespace, especially if there are
nested namespace with long names.)

 

[REH]

  Some people still struggle against that idea, though.

I don't "struggle" against the idea, nor do I have an issue with it. I
do the same in Ada. I also do it with other namespaces in C++. I just
prefer not to do so with the std namespace in a code file. I also
don't explicitly use the "Standard" package in Ada. Just my preference
I guess...

REH

 

[James Kanze]

This is probably a dumb question, but...

I have a code file in which I cannot use a using directive to
pull in std (because it conflicts with a library I have to
pull in). So, how to I handle names that can be macros, but
may not be (such as errno)?

errno is required to be a macro. In fact, there are no names
which might be a macro, but aren't required to be.

 

[James Kanze]

If you include a C header where errno is defined using the .h
notation, you should be all set. I.e. don't include, say,
<cstdio>, instead include <stdio.h>.

The C++ standard fully defines the contents of both <cstdio> and
<stdio.h>. And there are no symbols which "might be macros": a
symbol is either guaranteed to be a macro, or it is guaranteed
not to be a macro. (Basically, if, like errno, it's guaranteed
to be a macro in C, it's guaranteed to be a macro in C++.
Otherwise, it's guaranteed not to be a macro---putchar, for
example, may not be a macro in C++, even though it usually is
one in C.)

 

[James Kanze]

That's an unrelated question, but OK.

No, you misunderstood the question.

Ah, I didn't know that. I believe the C standard allows it to be
either a macro or an int. I didn't realize the C++ standard was
different.

C++ is not different. The C standard requires errno to be a
macro.

The difference is for things like putchar(); the C standard
allows them to be macros, as long as there is also a function
definition that can be unhidden (by using the symbol without the
following (, or by #undef). C++ does NOT allow these to be
macros, even in <stdio.h>.

 

[James Kanze]

The extent to which it's evil in a cc file probably varies
with the size of the file (or enclosing scope) and the number
of people who collectively maintain it.

More generally, the extent to which "using namespace" is evil in
a source file also depends on the size of the namespace being
pulled in, and the number of people working on that. And std::
is pretty big, with a lot of people working on it.

I choose to stay away from using-directives altogether,
because (1) I'm tired of getting bitten by them, and (2) I
like having a path from each name back to its source
namespace; e.g., if I see list<foo> in vim, I like to hit gd
and be immediately shown the using-declaration for std::list.

I don't find them to be too much of a problem for restricted
namespaces in restricted contexts. I'll use a namespace
MyClassPrivate, for example, if for any reason the
implementation has to span more than one file (often the case),
and I find a using namespace MyClassPrivate acceptable in the
implementation files of MyClass.

Other than that, however, I more or less agree with you.