Re: Template Problems
Re: Template Problems
- Subject: Re: Template Problems
- From: Jim Ingham <email@hidden>
- Date: Thu, 4 Aug 2005 14:55:13 -0700
Mike,
On Aug 4, 2005, at 2:36 PM, Mike Jackson wrote:
I had turned off Zero Link on all my projects but I will check again.
You are right about not breaking in Printer<double>::print. SO if I
do:
int main (int argc, char * const argv[]) {
Printer<double>::print(10.5);
Printer<int>::print(10);
Printer<double>::print(10.5);
std::cout << "DONE" << std::endl;
return 0;
}
then I will successfully break on Printer<double>::print(10.5);
both times, but will fly past Printer<int>::print(10);...
So.. when are those patches going to be available?
Dunno. The last time the patches were posted they were pretty
rough. This is a pretty big change, since there are a lot of
assumptions that crept in about "a breakpoint has only one address..."
Jim
Mike Jackson
On Aug 4, 2005, at 5:26 PM, Jim Ingham wrote:
There are a couple of things that might be confusing this. First
of all, it looks like there's something about ZeroLink and
templates that's confusing the debugger. So if I set a breakpoint
on FindLoops.h:5 in Xcode with ZeroLink ON, I never stop. But if
I turn ZeroLink off, then I will stop in the Printer<int>::print
function, but not in Printer<double>::print...
There are patches floating around to fix this problem, but they
haven't been formally submitted to the FSF gdb yet.
It may be that you stopped in one template function and declared
victory. Make sure you really did stop in all the
instantiations. If you did, I don't know how they managed to pull
this off.
It would be interesting to do:
break FindLoops.h:5
in the gdb that came with Eclipse and see if that sets one or many
breakpoints...
Jim
On Aug 4, 2005, at 2:16 PM, Mike Jackson wrote:
So why did this work in Eclipse if the problem is in GDB? AFAIK
Eclipse is using GDB also.
Mike
On Aug 4, 2005, at 5:12 PM, Jim Ingham wrote:
The problem here is that the gdb's "break" command assumes that
there is a 1-1 correspondence between the break expression and
the code address implementing it. This is obviously not true
for templates. It's on our list of things to fix, but we
haven't fixed it yet.
You can work around it for breaking on functions in the gdb
command-line by using the "rbreak" command:
(gdb) rbreak Printer.*print
That will break on all the versions of the print method of the
Printer template class.
You can also do set breakpoints on the individual
instantiations, for instance:
(gdb) break Printer<int>::print
will only break on the int version... You can do this second
bit by adding "Symbolic Breakpoints" in the Xcode Breakpoint
window. The one trick I noticed is that if you use ZeroLink, we
bail out too early and don't set the breakpoint... So you need
to turn off ZeroLink to get this to work.
Jim
On Aug 4, 2005, at 12:20 PM, Mike Jackson wrote:
OK,
I can reproduce the problem very simply. Create a new C++
Tool project. Add a new file called FindLoops.h
Put the following in the file.
#include <iostream>
template <class T> class Printer {
public:
static void print(const T&t) {
std::cout << t << std::endl;
}
};
In main.cpp put the following:
#include <iostream>
#include "FindLoops.h"
int main (int argc, char * const argv[]) {
std::cout << "Hello, World!\n";
Printer<int>::print(10);
Printer<double>::print(10.5);
std::cout << "DONE" << std::endl;
return 0;
}
Check the compile settings to have FULL debug symbols. Set a
breakpoint in the "FindLoops.h" file at the line that does the
cout. Run the debugger. Xcode flys right past the break point.
Now, if I put the template in the main.cpp file, then the
debugger will hit the breakpoint.
I am new to C++ and all this, so can some one explain what
might be happening (**cough _apple_ cough **) ;-)
Mike Jackson
On Aug 4, 2005, at 2:25 PM, Mike Jackson wrote:
I went back through all my projects and set the debug symbols
to "ALL". Still no luck stopping at a breakpoint.
Mike
On Aug 4, 2005, at 1:54 PM, Mike Jackson wrote:
I tried the following in a "test" project: In main.cpp
#include <iostream>
template <class T> class Printer {
public:
static void print(const T&t) {
std::cout << t << std::endl;
}
};
int main (int argc, char * const argv[]) {
// insert code here...
std::cout << "Hello, World!\n";
Printer<int>::print(10);
Printer<double>::print(10.5);
return 0;
}
The debugger will stop in the template just fine. In my case,
the template code is in _another_ project that is referenced
by the current project, and the template code is in a .h
file. Don't know if this makes a difference or not. I am
still too new to C++/Xcode to know. I did double check that
Optimization is OFF in all the projects, although I will
double check that.
Mike Jackson
On Aug 4, 2005, at 10:28 AM, Andreas Grosam wrote:
On 04.08.2005, at 15:38, Wade Girard wrote:
First this to do is to verify that you are generating debug
symbols, the second is to verify that optimizing is OFF.
Note that setting it to none -o0 is not off.
according the doc, -O0 optimization is indeed off and is the
default. But -O isn't off, did you mean this?
My experience is, that there are (still) a lot of troubles
with the debugger especially with templates - not only
regarding synchronizing with the source.
What may confuse source synchronizing (even with -O0):
Long comments at arbitrary positions in the file
Macros, multi line
templates
static inline functions
breakpoints in member initializer lists
Although it is better than it was in XCode 1.5, this *may*
happen frquently - not always and it is not always
reproducible. I have no workaround for this problem.
If it happens, i try several other things to solve my
original problem - typically loosing a lot of time and
getting disappointed and annoyed.
When having templates, I also recommend to close the
assembly window, since there might occure more troubles: if
this happens, the debugger just refuses to work at all.
Furthermore, it is a bit faster, so one step only takes 2
seconds instead of 3.
Andreas
The only way that I know of to do this is to use a xcconfig
file and have/add the following two lines
GCC_DEBUGGING_SYMBOLS = full
GCC_OPTIMIZATION_LEVEL =
On Aug 4, 2005, at 7:47 AM, Mike Jackson wrote:
I'll try again.
The debugger is ignoring breakpoints set inside a template
function. How do I get the debugger to actually stop at those
breakpoints?
Stats: Xcode 2.1. OS X 10.4.2. PB 1.67/1.5GB RAM
Thanks for any Help
---
Mike Jackson
mike _at_ bluequartz dot net
This email sent to email@hidden
This email sent to email@hidden
---
Mike Jackson
mike _at_ bluequartz dot net
_______________________________________________
---
Mike Jackson
mike _at_ bluequartz dot net
---
Mike Jackson
mike _at_ bluequartz dot net
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40apple.com
This email sent to email@hidden
---
Mike Jackson
mike _at_ bluequartz dot net
---
Mike Jackson
mike _at_ bluequartz dot net
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden