| T O P I C R E V I E W |
| Frunobulax |
Posted - May 13 2008 : 04:01:41 AM
Hi,
I have two different libraries using different namespaces (say foo and bar). There is one class with a certain name (say C) in both namespaces.
I added a member C::doSomething() in namespace foo and used create implementation. However, the implementation ended up in the source file belonging to library bar, even though it was correctly declared as foo::C::doSomething().
This may seem a trivial problem, but unfortunately it completely messed up our last nightly build - the active project linked both libraries, while several other projects use only foo and consequently failed.
Regards, tv
|
| 23 L A T E S T R E P L I E S (Newest First) |
| support |
Posted - Sep 13 2008 : 01:10:21 AM
case=16702 is fixed in build 1649 |
| Frunobulax |
Posted - Aug 01 2008 : 2:24:55 PM
Sure, I will try that version.
quote:
Project properties -> C/C++ -> General -> Additional Include Directories
Yes, that's the way we do it. In 1446 VAX wouldn't find some symbols that were declared in such headers, even though the project would compile.
Let's see how the new version works.
Regards, Thomas
|
| feline |
Posted - Aug 01 2008 : 09:03:32 AM
VA 1647 has now been posted:
http://www.wholetomato.com/downloads/default.asp
Can you try this version please and see how it works?
You said you had problems with symbols that are in custom include paths, what do you mean by this? How are you specifying these custom include paths?
VA should not have any problems with directories specified via:
Project properties -> C/C++ -> General -> Additional Include Directories
|
| feline |
Posted - Jul 31 2008 : 1:27:42 PM
We are hoping to post a new build in the next day or two with a fix for an alt-g problem. I will try and update this thread then that build is posted.
Instead of re-trying 1646 can you go straight to that version and see what results you get? |
| Frunobulax |
Posted - Jul 30 2008 : 4:10:40 PM
Right now we're pretty busy, but sure, let me know what you want me to do and I'll try to find the time.
Regards, tv
|
| feline |
Posted - Jul 30 2008 : 09:26:47 AM
I am not aware of any regressions / changes since VA 1640 that would explain the new problems you are seeing.
Would you have time to install VA 1646 and try to help me find out what is going wrong with alt-g and autocomplete? |
| Frunobulax |
Posted - Jul 29 2008 : 3:56:18 PM
Nope, the structure of the projects hasn't changed.
Regards, tv |
| feline |
Posted - Jul 29 2008 : 11:14:55 AM
Does your solution contain directories that use extended / Unicode characters? There is a known problem with alt-g and Unicode characters in directory names. I am wondering if this is a factor in what you are seeing. |
| Frunobulax |
Posted - Jul 29 2008 : 04:28:53 AM
The sample code works fine.
There must be something else going on, autocompletion and Alt-G works significantly worse in 1445 and 1446 (compared to 1440) for me. It can't find symbols that are in custom include paths (and not in namespaces) - I have to add the project containing the include files to make Alt-G and autocompletion work.
And yes, VA View gives me a long list of symbols - not one is actually part of the open solution (the test solution, and no other visual studio is open). I'm switching back to 1440 now...
Regards, Thomas |
| feline |
Posted - Jul 26 2008 : 10:48:12 AM
Did Sean's work around, posted Jun 24, help with the smart pointer problem? This is case=16702 and has not been fixed in VA 1646, but we are hoping for a fix in the next build.
For the Create Implementation problem, can you please download and open this VS2005 C++ console project? This is the simple test project I created from your description. Alt-o and Create Implementation are both working correctly for me, using VS2005 and VA 1646:
http://forum.wholetomato.com/colin/forumimages/7722_cpp_alt_o_console.zip
So I am curious to see if they work for you. |
| Frunobulax |
Posted - Jul 26 2008 : 04:56:59 AM
Both :-(
Regards, Thomas
|
| feline |
Posted - Jul 25 2008 : 1:17:38 PM
Which problem are you seeing? The problem with smart pointers, or the wrong file being used? |
| Frunobulax |
Posted - Jul 25 2008 : 08:46:34 AM
I'm afraid the issue is not fixed, since I just experienced the bug again (with 1446). Cache etc. was cleared after the VAX update.
Regards, Thomas
|
| support |
Posted - Jul 14 2008 : 2:32:11 PM
case=16697 is fixed in build 1645 |
| sean |
Posted - Jun 24 2008 : 10:42:00 PM
Not a substitute for a proper fix, but a workaround for the VA bug is to namespace qualify the typename in the shared_ptr typedef:
typedef boost::shared_ptr<GpGrafik::_Gleisabschnitt> Gleisabschnitt;
|
| Frunobulax |
Posted - May 14 2008 : 1:51:06 PM
quote:
Originally posted by feline
I am seeing the same problem with alt-o.
That's good news - I was afraid that this would be a problem that is hard to reproduce :-)
Regards, tv
|
| feline |
Posted - May 14 2008 : 1:09:38 PM
I am seeing the same problem with alt-o. I have created a very simple test here, added these files, and it shows up. That is most unexpected:
case=16697
The problem with the smart pointers, something is going on here. I am seeing a problem, but there seems to be a random element to the problem I am seeing. I have put in a bug report describing what I am seeing, hopefully our developers can pin it down a bit better:
case=16702 |
| Frunobulax |
Posted - May 14 2008 : 09:19:39 AM
quote:
Originally posted by feline
Yes, OFIW is the Open File dialog.
Can you post the full paths and file names of the 4 files VA is having problems with please? Since all 4 files are listed VA knows about them, so this should be working correctly. I am guessing that VA is unable to work out that there are really two pairs of files here, but I don't know why that is happening.
It is namespace GP in
[Root]\\gpgraflib\\gpgraflib.vcproj
[Root]\\gpgraflib\\inc\\Gleisabschnitt.h
[Root]\\gpgraflib\\src\\Gleisabschnitt.cpp
and namespace GpGrafik in
[Root]\\gpagraflib\\gpagraflib.vcproj
[Root]\\gpagraflib\\inc\\Gleisabschnitt.h
[Root]\\gpagraflib\\src\\Gleisabschnitt.cpp
and namespace [GP|GpGrafik] {
class _Gleisabschnitt { [...] };
typedef boost::shared_ptr<_Gleisabschnitt> Gleisabschnitt;
}
The behaviour is consistent with some autocompletion trouble - if I use both classes (or rather shared pointers) in one source file then VAX will always suggest the member functions from the GpGrafik variant. This does not depend on the root directory and does not go away after rebuilding the database.
Regards, tv
|
| feline |
Posted - May 14 2008 : 08:57:09 AM
Yes, OFIW is the Open File dialog.
Can you post the full paths and file names of the 4 files VA is having problems with please? Since all 4 files are listed VA knows about them, so this should be working correctly. I am guessing that VA is unable to work out that there are really two pairs of files here, but I don't know why that is happening. |
| Frunobulax |
Posted - May 14 2008 : 05:23:33 AM
quote:
Originally posted by feline
Can you make sure all 4 files are closed, and then look in the OFIW dialog please. Are all 4 files listed?
You mean "Open file in solution"? Yes, all 4 files are listed with the correct directories.
Regards, tv
|
| feline |
Posted - May 13 2008 : 12:43:58 PM
We need to focus on the alt-o part of the problem first. I am 99% sure that once this is fixed the problem with Create Implementation will also be fixed.
Can you make sure all 4 files are closed, and then look in the OFIW dialog please. Are all 4 files listed? If only 2 or 3 of the files are listed then this will cause this problem, since VA will not know they come in matching pairs. |
| Frunobulax |
Posted - May 13 2008 : 11:55:59 AM
The implementations are stored in different files (and different directories).
The problem is reproducable, even after a VAX database rebuild.
The project structure is as follows:
There is a lib (VS project) libfoo, containing C.h and C.cpp, and a lib libbar containing C.h and C.cpp. Both libraries have their own private directory.
C.h in libfoo is
namespace foo {
class C {...}
};
and C.h in libbar is similar.
If I go to foo/C.h and type Alt-O, then I get to choose between foo/C.cpp, bar/foo.h and bar/foo.cpp.
Regards, tv
|
| feline |
Posted - May 13 2008 : 08:50:20 AM
Are the classes foo::C and bar::C stored in the same files? Or are they stored in different files?
If you have:
foo_classC.cpp, foo_classC.h
bar_classC.cpp, bar_classC.h
then VA should know which cpp file is matched to which header file. Can you try alt-o and see if it is working correct, or if it is jumping to the wrong file?
If you trigger Create Implementation a second time do you get the problem again? Or was this a one off problem you cannot reproduce? |
