Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
User name:
Password:
Save Password
Forgot your password?

 All Forums
 Visual Assist
 Technical Support
 1533: goto definition issues with 'using'
 New Topic  Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  

.oisyn
Tomato Guru

153 Posts

Posted - Aug 28 2006 :  09:52:51 AM  Show Profile  Reply with Quote
VA X doesn't seem to be able to find the implementations of class functions if those functions aren't defined in the namespace in which they are declared. The implementations need to be enclosed in namespace blocks rather than using a using directive ('using namespace foo') or declaration ('using foo::bar') for the 'goto definition' to be able to work.

For example:
namespace bla
{
    struct Foo
    {
        void Bar();  // #1
    };

    void Foo::Bar()  // #2
    {
    }
}

If I place the cursor on Bar in #2, VA X recognizes the method and says bla.Foo.Bar in it's context pulldown. If I place the cursor on Bar in #1 and issue a goto definition command, it goes to the implementation. This is correct behaviour.

However, if I do this (note that this is in fact legal C++):
namespace bla
{
    struct Foo
    {
        void Bar();  // #1
    }
}

using namespace bla;
// this would also be applicable: using bla::Foo;

void Foo::Bar()      // #2
{
}


Again, on #2 it shows bla.Foo.Bar as the context. However, from #1 it can't find the definition of Foo::Bar. Also, it can't provide a list of members when I type 'this->' or access one of it's members.

.oisyn
Tomato Guru

153 Posts

Posted - Aug 28 2006 :  09:54:28 AM  Show Profile  Reply with Quote
Hmm, this also seems to apply with typedefs (even without namespaces):
struct Bar
{
    void Foo();
};

typedef Bar Baz;

void Baz::Foo()
{
}
Go to Top of Page

jpizzi
Tomato Guru

USA
642 Posts

Posted - Aug 29 2006 :  01:39:24 AM  Show Profile  Reply with Quote
Does the typedef example work (compile)? I wouldn't have expected a typedef to cover a method definition. Declaring a instance, yes, but defining a method?

Joe Pizzi
Go to Top of Page

.oisyn
Tomato Guru

153 Posts

Posted - Aug 29 2006 :  08:50:32 AM  Show Profile  Reply with Quote
It's perfectly legal ISO C++, and VC++ is ok with it as well. You can substitute a typename with a typedef to that typename everywhere, also for method implementations. Even if the typename is in another namespace:

namespace a
{
    struct Bar
    {
        void Foo();
    };
}

namespace b
{
    typedef a::Bar Baz;
}

void b::Baz::Foo()  // actually implements a::Bar::Foo
{
}



Of course, I have never seen this counter-intuitive syntax in production work ;), but it's actually very similar to my first post in this thread. Type aliases should be mapped to their original typenames when parsing the code.

Edited by - .oisyn on Aug 29 2006 08:58:04 AM
Go to Top of Page

jpizzi
Tomato Guru

USA
642 Posts

Posted - Aug 30 2006 :  11:47:21 AM  Show Profile  Reply with Quote
Unless one of the other support people beat me to it, I will look into this further (give me 12-18 hours).

Joe Pizzi
Go to Top of Page

jpizzi
Tomato Guru

USA
642 Posts

Posted - Aug 31 2006 :  12:54:19 AM  Show Profile  Reply with Quote
Got it.

case=2303

Joe Pizzi
Go to Top of Page

.oisyn
Tomato Guru

153 Posts

Posted - Oct 21 2006 :  9:08:08 PM  Show Profile  Reply with Quote
Sorry for the kick, but will this be addressed soon? Apparently it's still not fixed in 1539. It's very annoying I can't do a 'goto definition' from my header files to my source files, since my sourcefiles use a 'using namespace X; C::C() { }' instead of a 'X::C::C()'

Edited by - .oisyn on Oct 21 2006 9:08:23 PM
Go to Top of Page

jpizzi
Tomato Guru

USA
642 Posts

Posted - Oct 22 2006 :  11:36:35 PM  Show Profile  Reply with Quote
No problem for the kick. This one seems to be related to several other bugs (or are different manifestations of the same bug). The developers have been working on it, but no estimate of a resolution. Maybe a tough cookie to tackle.

Joe Pizzi
Go to Top of Page

.oisyn
Tomato Guru

153 Posts

Posted - Oct 23 2006 :  06:18:33 AM  Show Profile  Reply with Quote
Ok, thanks for the heads-up.
Go to Top of Page

sean
Whole Tomato Software

USA
2817 Posts

Posted - Dec 19 2006 :  9:13:30 PM  Show Profile  Reply with Quote
case=2303 is fixed in build 1543
Go to Top of Page

sean
Whole Tomato Software

USA
2817 Posts

Posted - Dec 19 2006 :  9:28:21 PM  Show Profile  Reply with Quote
case=2303 is fixed in build 1543
Go to Top of Page

.oisyn
Tomato Guru

153 Posts

Posted - May 24 2007 :  06:37:48 AM  Show Profile  Reply with Quote
You said it's fixed in 1543, but it's still not working in 1555

// test.h
namespace foo
{
    class Bar
    {
        void f(); // #1
    };
}

// test.cpp
#include "test.h"
using namespace foo;

void Bar::f()  // #2
{
}


GotoImplementation doesn't work on #1. It works on #2 though, it jumps to the function declaration in the class definition in the header file.

Edited by - .oisyn on May 24 2007 06:38:46 AM
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
17256 Posts

Posted - May 24 2007 :  08:20:32 AM  Show Profile  Reply with Quote
Which IDE are you using? I have just double checked this using VS2005 and VA 1555, on several different tests, and alt-g is working perfectly for me on all of these tests.

Do the cpp and .h you are using have the same name? Does alt-o work?
If you close the cpp file - so it is not open in the IDE - is it listed in OFIW?

I am wondering if the problem is because VA does not know about the cpp file.

zen is the art of being at one with the two'ness
Go to Top of Page

.oisyn
Tomato Guru

153 Posts

Posted - May 30 2007 :  10:03:49 AM  Show Profile  Reply with Quote
Ok this is weird. When creating a small test-case, it *does* work (on both 2003 and 2005). But in our real-life project, it doesn't (VS 2003).

Header- and sourcefiles both have the same name, and they both show in the OFIW dialog (even if they're closed). Alt-o works as expected. Funny thing is, when doing FSIW, it finds two versions: the one with the namespace in front (e.g., cdc.CubeMapCamera.SetCamToPosition) that points to the declaration in the header file, and one without the namespace (CubeMapCamera.SetCamToPosition), that points to the definition in the sourcefile. If I do a similar FSIW on my small testcase, it finds only one entry (the one with the namespace), that points to the sourcefile. However, in both situations, it *does* show the namespace in the context dropdown when the cursor is on the method name in the sourcefile.

.edit: ah, I now see the cullprit. It appears that the sourcefile in question doesn't have the 'using namespace cdc;' directive - it is introduced in one of the headers it includes. I think it's debatable about whether VA X should be able to handle that since that probably requires parsing of headers in the context as they are oncluded in each sourcefile, rather than as stand-alone files, which I think is pretty undoable, but I'll leave that up to you (besides, using declarations and directives in the global namespace inside a header is bad coding practice in my book anyway). Adding the directive to the sourcefile worked. Sorry for the confusion

Edited by - .oisyn on May 30 2007 10:06:33 AM
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
17256 Posts

Posted - May 30 2007 :  2:34:04 PM  Show Profile  Reply with Quote
These things happen I am glad you have gotten to the bottom of this problem.

Personally I really dislike the idea of trying to pick up using namespace lines from header files. To start with, how deep do you need to go? 1 header? 20 headers? 50 headers?

zen is the art of being at one with the two'ness
Go to Top of Page

.oisyn
Tomato Guru

153 Posts

Posted - Jun 18 2007 :  08:48:48 AM  Show Profile  Reply with Quote
Btw, it is in fact not working for using declarations, only for using directives

namespace a
{
    struct Foo
    {
        void func();
    };
}

using a::Foo;

void Foo::func() // VAX doesn't recognize this
{
}


And also not for nested namespaces with the using directive
namespace a
{
    namespace b
    {
        struct Foo
        {
            void func();
        };
    }
}

using namespace a::b;

void Foo::func() // VAX doesn't recognize this
{
}


And with typedefs it is even worse. While in the previous situations you can still jump from definition to declaration (but not the other way around), if you use a typedef it doesn't understand it at all
struct Foo
{
    void func();
}

typedef Foo Bar;
void Bar::func()  // ????
{
}

Edited by - .oisyn on Jun 18 2007 09:28:47 AM
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
17256 Posts

Posted - Jun 18 2007 :  12:30:58 PM  Show Profile  Reply with Quote
I am seeing the same effect here. Thank you for the clear description.

case=7148

zen is the art of being at one with the two'ness
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
17256 Posts

Posted - Jun 18 2007 :  12:52:30 PM  Show Profile  Reply with Quote
Which version of VA are you using? My reply was to your original post, I had not realised you had edited it when I posted.

I am not seeing any problems with:

using namespace a::b;

using VS2005 and VA 1557.

The typedef case, I am not surprised VA is confused by this. Do you actually have code like this? It seems an odd thing to do.

zen is the art of being at one with the two'ness
Go to Top of Page

.oisyn
Tomato Guru

153 Posts

Posted - Jun 19 2007 :  5:59:45 PM  Show Profile  Reply with Quote
Sorry, VS 2005 and VA 1555. I haven't had the chance to test it with 1557 yet.

I do in fact never use the typedef, I just included it for completeness' sake since it's very similar to the namespaces. I had a class inside a nested namespace that I wanted to implement without opening or using the whole namespace (so I did "using a::b::Foo;"). But as that didn't work, I tried to use the whole namespace as a workaround ("using namespace a::b;"), but that didn't work either.

I had no other option than to open up the whole namespace ("namespace a { namespace b {"), but since the functions of Foo in this particular case had some extern variable declarations inside the function definitions, it resulted in linker errors as the variables actually resided in the global namespace. (Because of the namespaces around the function definition they were wrongly declared inside a::b. Foo was a legacy class that used to reside in the global namespace itself, but I was moving it to a new namespace)
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
17256 Posts

Posted - Jun 20 2007 :  07:00:49 AM  Show Profile  Reply with Quote
That was rather unhelpful. Upgrading to VA 1557 should fix this problem for you, based on my tests.

http://www.wholetomato.com/downloads/default.asp

zen is the art of being at one with the two'ness
Go to Top of Page

support
Whole Tomato Software

5566 Posts

Posted - Jun 03 2013 :  2:02:16 PM  Show Profile  Reply with Quote
case=7148 is fixed in build 1940
Go to Top of Page
  Previous Topic Topic Next Topic  
 New Topic  Reply to Topic
 Printer Friendly
Jump To:
© 2019 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000