i believe the struct returning behavior is compiler dependent (OS dependent?). some will return the struct in a register, if the struct is small enough, or on the stack. some compilers are smart enough to use the caller's struct directly so as to avoid making a copy.
that struct i showed is sizeof(int *) + sizeof(int). so, 8 or 12 bytes. nothing to worry about.
I believe that's implementation defined. With my linux box I can use ulimit to set the size of the stack. By default it seems to be 8MB, but I can modify that upwards more or less as needed (obviously within memory limits of the system).
I seem to recall that early C implementations were limited to returning basic types (e.g. int, double, char *, etc). gcc-5.2 still has a warning flag for aggregate returns - which suggests that other C compilers might still adhere to that.
Method 0 is the one I observe most of the time (and use myself more frequently). Even Windows API use it.
Sentinel method has its usages (k5054 already pointed out its drawbacks).
I won't use method 2, I mean I won't choose a linked list instead of an array just in order to avoid the extra parameter in my function.
The sentinel method worked well in this case, but then Chris Losinger suggested method 3 -- using a container*. So I'm using that now. This technique has the added benefit that I can store the number of items allocated as well as the number of items in use -- sort of like how a List works in .net. I can add items up to the limit (I have no need to expand the array; I know how many items I need up front).
* Didn't we used to call that a Control Block? A simple way to avoid having bullions and bullions of function parameters?
Didn't we used to call that a Control Block? A simple way to avoid having bullions and bullions of function parameters?
Of course I am aware of the general technique (pass a struct instead of tons of parameters, again Windows API docet), however it is the very first time I hear the term 'Control Block' used with such a meaning.
PIEBALD whips out his trusty "MS-DOS Programmer's Reference" (1993, "covers through version 6"!)... and it just says "structure", e.g. RWBLOCK structure.
And VMS uses "descriptors" which are similar.
Classic C programming uses pointers to various structures, including null-terminated strings; ASCIZ strings. These are used within the OpenVMS standard C library, though most OpenVMS interfaces use descriptors. An OpenVMS construct that will be entirely new to even experienced C programmers is the string descriptor. This is typically a small data structure, containing the data length, data type, descriptor class, and data address for a chunk of data.
" -- http://labs.hoffmanlabs.com/node/273[^]
But I'm sure we used the term "Control Block" where I worked. Maybe it's from the UNIX culture? :shrug:
A good place to look for the actual data/commands sent using the various protocols is in the microcontroller community. The Arduino/8501 forums/libraries have plenty of code available.
I once setup an arduino to record the incoming pulses from a remote. I then swapped the IR receiver module for a cheap 1mw laser - I can control the IR equipment from over 100m away now.
Unfortunately, the code's on a machine I dont have access to now and I've long since forgotten where I got the info from, sorry.
"When I was 5 years old, my mother always told me that happiness was the key to life. When I went to school, they asked me what I wanted to be when I grew up. I wrote down 'happy'. They told me I didn't understand the assignment, and I told them they didn't understand life." - John Lennon
Access violation reading location. Just before this exception, if I debug the application, I see that member variables of this object dont show and Error reading characters of string shows up instead, in the intellisense.
It does not look like you are reading the string, you are actually assigning values. It seems the exception is from somewhere else.. Is this the complete code you are debugging ?? Could you please share the full code if possible ?
I am still struggling with pointers arithmetic.
Here is my crude test code.
I want to use pointers to access ( double - need triple eventually) the array of characters and do not get two things.
Problem #1 is probably how does the LCD class do the "print" and I can figure that one by myself. I do not expect this forum to be familiar with Arduino "library".
Problem # 2
I can print single characters in simple array by incrementing the pointer, but I cannot figure out why I cannot use same method on double array.
I really do not understand what is this error telling me
"error lvalue required as increment operand" - what is "lvalue" ?
Please keep in mind that English is not my native language so go easy on
" pointers to array..." "array of pointers" etc.
As always , I appreciate your help.
OK, I did some more reading about how the array is initialized and how the NAME of the array cannot be used the way I did try it.
So I did this - it "works" , but I am still not sure if it is correct or just a fluke.
char *pointer = stringTable;
lcd_i2c.print((char*) pointer++); // prints entire line
lcd_i2c.print((char*) pointer); // prints entire line starting with second character - expected that
Original post code starts here
char line[MAX_LINE] = "A TEST B";
int ncharacters = strlen(line);
char *sptr; // pointer to memory block returned by malloc
char *stringTable[NLINES]; // array of pointers to string
int i = 0;
sptr = (char*) malloc((unsigned) strlen(line) + 1);
lcd_i2c.print(sptr); // problem #1 prints the entire line - not really a problem here
strcpy(sptr, line); // copy line to pointed memory
lcd_i2c.print(sptr); // TOK prints pointer value ?
// copy pointer to first table array
stringTable = sptr;
i = 0;
// TOK prints first character from stringTable
lcd_i2c.print((char) * (*stringTable)); // problem #1 prints only the first character - why it would be nice to print the entire line using pointers!
} while (*(*++stringTable)); error lvalue required as increment operand
-- modified 26-Jul-15 11:18am.
Last Visit: 18-Feb-20 12:28 Last Update: 18-Feb-20 12:28