Okay, I am able to get variables in the watches window now.
(1) Complaint #1:
class dvec
{
double *data;
int size;
...
};
Is it possible to see the contents of data? I am able to see only the address. Clicking on the "raw data" button gives gives me only the address again. All choices in the context menu are grayed, both in the watches window and in the raw data window. No chance to see *data as an array of doubles. No chance, really?
Complaint #2:
Okay, dvec is not as stupid as it seems to be and it can use user supplied buffer as its data. This could provide the values, at least for now, because the array of doubles can be dereferenced. Tracing though the testing program again, something seems to be wrong. Tracing once more and more carefully:
dvec rv;
...
bool bb = rv.alloc(5);
Returns true. Strange. Okay, I know the address of rv. Tracing into alloc(), this should be the same address but it is not, at least in the watches window. The dvec allocates correctly, sets its size but, on return, the size of rv is wrong in the watches window as well as the buffer address. Note: I have reloaded rv into the watches, so that it is not a problem of oudated data in the window.
Being completely desperate, I wrote a dump() routine:
void dump( const dvec& vec )
{
double *d = vec.data();
printf("%5.1f %5.1f %5.1f %5.1f %5.1f\n",d[0],d[1],d[2],d[3],d[4]);
}
I inserted dump() into the code and traced again. The output is as expected and it is correct so that this is not a gdb problem. Aye, aye, what I am doing wrong now? Debian, Gnome, svn 7932.
#include <dvec.hpp>
#include <stdio.h>
int main()
{
double dd1[] = { 0.0, 1.0, -2.0, 3.0, -4.0 };
double dd2[] = { 1.0, -2.0, 3.0, -4.0, 5.0 };
double dd3[] = { 0.0, 0.0, 0.0, 0.0, 0.0 };
double dd;
dvec a,b,c;
dvec::el e;
bool bb;
bb = a.mkview(dd1,5); // use dd1 for a data buffer of a, size = 5
bb = b.mkview(dd2,5); // use dd2 for a data buffer of b, size = 5
bb = c.mkview(dd3,5); // use dd3 for a data buffer of c, size = 5
c = a + b;
...
Debug and watch dd3. On the line c = a + b; dd3 should change, but it does not. When watching c.data, the c.data does change as expected. In the meantime, I have met the dreaded "incomplete type" - when I compiled the library as release. Even if the test program is compiled as debug and even if the header dvec.hpp is available, dvec is now "incomplete type" and "there is no member named c.data". Does it mean that I must use either debug compiled and unoptimized libraries or I cannot debug because I won't see any library-defined data? I understand that with a release build I cannot trace into the library (or I get the assembler window) but I should see the data described in headers. Is the gdb API so rudimental? Complaint #3 ;D