Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

C++ Programming

ANSI C++ Namespaces


Hi, the following code behaves differently for GCC/MSC and Borland C++
5.6.

The question was, what order does symbol lookup happen in?

1. declared symbols, including using'd symbols.
2. parent namespace (nested)
3. using'd namespaces.

The above order is used by GCC and MSC, but Borland C++ 5.6 has (2)
and (3) flipped so that the following code is capable of detecting
your compiler:

What does ANSI C++ say about this?

Since it depends on compilers, shouldn't gcc be generating a warning?
Or does GCC have it right and is Borland C++ what's wrong?

If you could please run this program on an Intel C++ compiler or other
compilers, I am interested in the outcome. What does it say when you
run it on your compiler (besides GCC, MSC, and BCC?)

Thanks in advance,
Willow

---
#include <stdio.h>

namespace NSX
{
        int a;

}

namespace NS1
{
        int a;
        namespace NS2
        {
                using namespace NSX;
                // parent (nested) NS2 'and' using'd namespace NSX have a.
                int &b = a;
        }

}

int main()
{
        if(&NS1::NS2::b == &NSX::a)
                printf("BCC detected.\n");
        else
        if(&NS1::NS2::b == &NS1::a)
                printf("GCC/MSC detected.\n");
        else
                printf("Error.\n");
        return 0;

On Jun 6, 1:08 am, wschlan@gmail.com wrote:

> Hi, the following code behaves differently for GCC/MSC and Borland C++
> 5.6.
> The question was, what order does symbol lookup happen in?
> 1. declared symbols, including using'd symbols.
> 2. parent namespace (nested)
> 3. using'd namespaces.
> The above order is used by GCC and MSC, but Borland C++ 5.6 has (2)
> and (3) flipped so that the following code is capable of detecting
> your compiler:
> What does ANSI C++ say about this?

The ISO C++ standard says: "During unqualified name lookup
(3.4.1), the names appear as if they were declared in the
nearest enclosing namespace which contains both the
using-directive and the nominated namespace."  There's no
"order" specific to the namespace, it is "as if" the names were
declared in a specific namespace.

> Since it depends on compilers, shouldn't gcc be generating a warning?
> Or does GCC have it right and is Borland C++ what's wrong?

In your example, at least, I think that g++ has it right.

The issue is subtle enough, however, that I would avoid writing
such code.  Even if the compiler gets it right, will it be clear
to the reader?

> If you could please run this program on an Intel C++ compiler or other
> compilers, I am interested in the outcome. What does it say when you
> run it on your compiler (besides GCC, MSC, and BCC?)

Sun CC agrees with g++ here.

> ---
> #include <stdio.h>
> namespace NSX
> {
>         int a;
> }
> namespace NS1
> {
>         int a;
>         namespace NS2
>         {
>                 using namespace NSX;
>                 // parent (nested) NS2 'and' using'd namespace NSX have a.

This makes symbols in NSX available "as if" they had been
declared in global namespace (the nearest enclosing namespace
which contains both this using directive AND the nominated
namespace NSX).  The symbol NS1::a should be found before the
global namespace is searched, so it will hide any symbol a made
available by the namespace directive above.

>                 int &b = a;
>         }
> }

--
James Kanze (GABI Software)             email:james.ka@gmail.com
Conseils en informatique oriente objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place Smard, 78210 St.-Cyr-l'cole, France, +33 (0)1 30 23 00 34
Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc