...because I seem to be completely useless with pointers...VORx_IDENTITY returns a pointer to a string with the five-letter ID code. If you do an sprintf(nav1_ident.string,"%s", nav1_ident.var_value.p);no problem - it comes up in the MAKE_STRING macro. The problem I have is that I want to put the contents of the ident into a local string for use later. I have spent a long time chasing tutorials on pointers but - and here's the rub - everybody who writes tutorials on pointers always talks about integers! AAARGHH! Can anyone help on how to pass the contents of nav1_ident.var_value.p into a local string called nav_ident?I'll put the answer into sd2gau so that no-one else suffers the same frustration.MTIA.-Dai

VORx_IDENTITY returns a pointer to a string with the five-letter ID code. If you do an sprintf(nav1_ident.string,"%s", nav1_ident.var_value.p);no problem - it comes up in the MAKE_STRING macro. The problem I have is that I want to put the contents of the ident into a local string for use later. I have spent a long time chasing tutorials on pointers but - and here's the rub - everybody who writes tutorials on pointers always talks about integers! AAARGHH! Can anyone help on how to pass the contents of nav1_ident.var_value.p into a local string called nav_ident?I'll put the answer into sd2gau so that no-one else suffers the same frustration.

Dai -just taking a quick guess here since I'm not convinced I know what you are trying to achieve. :rolleyes:As far as I understand it you want to get your .p value to a string. A quick test renders this to be working for me:

char buf[256]; // gimme a string herewsprintf (buf, "%s", pelement->source_var[0].var_value.p); // print the .p member to the buffer// assuming a MAKE_STRING here with VOR1_IDENTITY as source_var[0]

Later on in the code, I can use this to print the buffer to my MAKE_STRING no problem:

wsprintf (pelement->string, "buf: %s", buf);

As far as the pointers go, yes they are all integers, no matter if it's a pointer to int, pointer to char or a pointer to your custom class instance. Simply because they point to some address within memory, which is a mere number (the .p member is a generic void * pointer as can be seen in gauges.h). So if you pass a pointer you pass the address of a certain object. buf or also &buf[0] should contain the address of the first element of the string, whereas buf[0] will return the actual content, that is the character, at that very address. So if you pass a char array to somewhere it will pass the address of the first char (so the memory address is a 32-bit int while the thing it actually points to is an 8-bit char in this case), if I'm not mistaken. Just like in the wsprintf and similar functions.It's a tough topic sometimes and while I probably haven't grasped half of it so far I learn new things every once in a while as well. :Applause:Let me know if this helps in any way.RegardsEtienneEdit and PS: Substitute 'nav_ident' for 'buf'!

Hi EtienneThat did it - thank you very much. I never thought to look at the (x)printf commands, yet as you point out, the answer is in front of me in the MAKE_STRING macro information. Stupid boy... :( -Dai

As far as the pointers go, yes they are all integers, no matter if it's a pointer to int, pointer to char or a pointer to your custom class instance.

That's a dangerous statement.My copy of K&R (1978) has a section titled 5.6 Pointers are not Integers.

That's a dangerous statement.My copy of K&R (1978) has a section titled 5.6 Pointers are not Integers.

Yes, no... maybe. Depends on how argumentative one desires to be. K&R isn't very relevant in today's C++ world.The only difference between a pointer and an integer: pointers are unsigned... integers are signed by default. However, an unsigned int and a pointer are exactly the same data type and size. You can add/subtract with pointers, you can add/subtract with integers. You probably shouldn't multiply/divide with pointers, but you can with integers.Low-level data-wise... they are identical... 32-bits of data representing either a pointer to something in memory or a physical value residing in memory.If you have a variable defined as thus:char str[40];And you pass this variable to a function declared as thus:void some_func(char* in_str)You can do this:some_func(str);And the C++ compiler automatically converts char str[40] to a pointer to the very first character in the array. Which in turn looks identical to a 32-bit unsigned integer.update: I had typoed that integers were unsigned by default... rather, they're signed by default.

My copy of K&R (1978) has a section titled 5.6 Pointers are not Integers.

Then I'd certainly like to know what else it says they should be... :(

The only difference between a pointer and an integer: pointers are unsigned... integers are not signed by default. However, an unsigned int and a pointer are exactly the same data type and size. You can add/subtract with pointers, you can add/subtract with integers. You probably shouldn't multiply/divide with pointers, but you can with integers.Low-level data-wise... they are identical... 32-bits of data representing either a pointer to something in memory or a physical value residing in memory.

Thanks for the additional explaining. :Applause:Oh, and btw glad to help, Dai.

K&R is still as applicable as it ever was - C++ is a superset of C and the same basic principles apply. Pointers are no more integers than floats or doubles are. They are their own types. treating them as integers is an example of "Classic Bad Programming". Not my words but see below.It is not generally the case that "Low-level data-wise... they are identical... 32-bits of data representing either a pointer to something in memory or a physical value residing in memory" That is only true for 32 bit operating systems. Pointers have been 16 bits with 16 bit operating systems, 32 bits with 32 bit operating systems, and 64 bits with 64 bit operating systems. The length of an int in C/C++ is independent of the operating systems at 32 bits.Those of us who struggled with near, far and huge pointer when writing in C/C++ on 8086-based systems knew near pointers were only 16 bit. Similary, now, those porting code to 64 bit operating systems know pointers are now 64 bits. In both case integers were 32 bits, as they are for 32 bit operating sstems.

LONG userdata = (LONG) &max_coordinate; This works for 32-bit Windows^â because a LONG and a pointer are both 32 bits. But in 64-bit Windows^â, pointers grow to 64 bits while LONG remains 32 bits. So if you compile for 64-bit Windows^â, this code truncates the 64-bit pointer which is probably not the intended behavior. This kind of “Classic Bad Programming” will be flagged by the /Wp64 compile flag,

http://www.google.co...ql=&oq=&gs_rfai=(incidentally, probably not the intended behavior is an understatement because getting pointers wrong is likely to crash the system.)Pointers are also not integers because they point to variables and objects of specific types and so contain more information than just a location. char *p; and int *q; means that p is a pointer to a char of 1 byte and q is a pointer to an integer of 4 bytes. As a result, arithmetic operations on them, are different. For example, ++p; adds 1 (1 byte) to p, but ++q; adds 4 (4 bytes to q.C/C++ defines str to be a pointer to the first character in the array. str[]. In the example *char is passed to a function argument which is also a *char. No integer is involved.If a pointer is an integer then the following snippet should compile and run.

void some_func (char  *in_str){}int main(int argc, char* argv[]){char str[40] = "qwerty";int i;i = str;                                 // Assign a pointer to an integersome_func(str);return 0;}

I challenge you to obtain a 64-bit pointer in a 32-bit application. In fact, I double-dog dare you. Do not do what soooo many non-programmers do... confuse a 64-bit OS as meaning an application is 64-bit.Since FSX is 32-bit, all gauges are also 32-bit... and thus there is no such thing as a 64-bit pointer. There's a reason FSX can run out of memory, even with a 64-bit OS.Regarding this:

void some_func (char  *in_str) { }  int main(int argc, char* argv[]) { char str[40] = "qwerty"; int i;  i = str;                                 // Assign a pointer to an integer  some_func(str);  return 0; }

This: char str[40] = "querty"; is not a pointer. It's an array of char.

There's also this method to retrieve the station name, thanks to some code that Ed gave me a while back:-

char* nav_str = NULL;char nav_name[5];nav_str = (char*)NAVIdent(1);//------// NAV station ident as string - XML versionPVOID NAVIdent(int radio){  PCSTRINGZ nav_name=NULL;  if(radio==1)execute_calculator_code("(A:NAV IDENT:1,String)",NULL,NULL,&nav_name);  if(radio==2)execute_calculator_code("(A:NAV IDENT:2,String)",NULL,NULL,&nav_name);  return (PVOID)nav_name;}

-Dai

For some reason I don't know I feel the execute_calc_code functs might be slower than just using a TokenVar. Whenever possible I prefer using the TokenVars, just because I think parsing that string will take longer, but this is completely without evidence and I haven't measured it neither would I know how to. :( Still thanks for the welcome addition, always good to know multiple ways to achieve a certain thing. :(

That execute_calc_code is getting the variable in the same method as what an XML gauge would... so if it's slow, XML gauges would also be slow.

Deleted for editng

EDIT TO INCLUDE CORRECT IMAGEAn integer is 32 bits. A pointer can be 16, 32, 64 and possibly in the future 128 bits. A pointer cannot be the same as an integer.Of course char str[40] is an array of char because that's how it was declared. Those who understand C known that str is a pointer to the first character in the array. It's that pointer the snippet assigns to an integer. Try the following snippet

 char str{40] = =qwerty";char c;c = *str;

c becomes 'q'The proof that pointers are not integers run the following snippet. It does compile and run.

# include <iostream.h>int main(int argc, char* argv[]){int *i; // i is a pointer to intcout << "i     = " << i << endl << endl;  // output ii = i + 1;   // add 1 to icout << "i + 1 = "<< i<< endl << endl; // output i againchar c; cin >> c; // to keep console window openreturn 0;}

If i were an integer i = i +1; would increment i by 1. Because its a pointer it increments it by 4 - the number of bytes in an integer.As I said in my first post. My copy of K&R (1978) has a section titled 5.6 Pointers are not Integers. That is still the case.