C string array problems (again)
in [Visual Basic]
|
Prev: VB6 vs DirectX
Next: VB6 - Vista - Mouse wheel
From: Jim Mack on 9 Feb 2007 11:05 Ralph wrote: > > **var and *var[], ( and var[][] for completness )are functionally > equivalent in a declaration, as ... > > *var == &var[0], thus *var == var Whuh? I freely admit that I don't write C, but to say that *var == var seems bizarre. It seems reasonable (always a danger, I know) that var is what VB would call a "byval" parameter, and *var a "byref" parameter. Why even have the form *var if it doesn't meant anything more than var? Did you mean that *var = var[]? Because that I do get. Just for completeness, how would C represent a parameter that was an array of pointers to strings? That's how VB treats a string array, as an array of 4-byte pointers to strings. It seems as if there's no good way to tell in C if a function is expecting a double-null-terminated string containing one or more null-terminated strings. Since this is so common in C and the API (as Jerry says, a la GetOpenFileName), you'd think there would be an unambiguous way of indicating that. As it is, *char or **char seems to be all you get, and you have to use the docs to find out that multiple strings are OK. -- Jim > > Or to muddy the waters even further ... > char var[i] == *(var + (sizeof (char) * i)) > thus > var[i][j] == *(var[i] + (sizeof(char) + j)), or > *( *(var + (sizeof(char) * i)) + (sizeof(char) * j)) > > It is just instructions to the compiler on how to stomp around on the > buffer. > > Whenever strings appear to be mysteriously 'chopped' in C it is most > often caused by embedded nuls. > > -ralph
From: mayayana on 10 Feb 2007 00:18 I got this working finally, but I gave up on the char ** var approach. I think that one problem may have been an odd quirk in the MS code: They had declared a char [256] string inside a loop and I assumed that meant it was going out of scope and being re-initialized with each loop. Not so! Characters copied to the string in one iteration were still there in the next. I needed to clear the variable with nulls on each iteration. So why did they declare it inside the loop? I don't know. What I ended up doing was to just send a long, pipe-delimited string of file paths to the DLL function, along with an array of longs that indicates the length of each path. The loop can then just go through the string, copying one path at a time to send to the cabinet.dll function.
From: Ralph on 10 Feb 2007 09:24 "Jim Mack" <jmack(a)mdxi.nospam.com> wrote in message news:uwUIXQGTHHA.1636(a)TK2MSFTNGP02.phx.gbl... Ralph wrote: > > **var and *var[], ( and var[][] for completness )are functionally > equivalent in a declaration, as ... > > *var == &var[0], thus *var == var > Whuh? I freely admit that I don't write C, but to say that > *var == var seems bizarre. It seems reasonable (always a > danger, I know) that var is what VB would call a "byval" > parameter, and *var a "byref" parameter. Why even have > the form *var if it doesn't meant anything more than var? Yeah, I screwed up. I originally started down a road to explaining something about pointer variables containing addresses and array names evaluating to an address and thus "ptrCh == var". Changed my mind and didn't delete enough. Incidently, while the concept of "references" started with C. Everything in C is passed by value. Period. C++ introduced an actual 'Reference Variable'. > Did you mean that *var = var[]? Because that I do get. > Just for completeness, how would C represent a parameter that > was an array of pointers to strings? That's how VB treats a > string array, as an array of 4-byte pointers to strings. Either way. Which is the point. All you generally do in C is Provide an 'starting Address' and then assemble your instructions on how to start counting from there. char** assumes a 'static' block of chars, ie char var[][]. char* var[] assumes an array of pointers to char. But you could always change your mind. Either way it doesn't matter as all you are passing is an address. (There are no string or array thingys in C.) C++ would be a bit more pissy - you'll find char *var[] will be easier to work with. > It seems as if there's no good way to tell in C if a function > is expecting a double-null-terminated string containing one or > more null-terminated strings. Since this is so common in C and > the API (as Jerry says, a la GetOpenFileName), you'd think there > would be an unambiguous way of indicating that. As it is, *char > or **char seems to be all you get, and you have to use the docs > to find out that multiple strings are OK. All C cares about, and all C++ cares about outside References, is the address and how to keep count as you stomp your way about. <g> >> Jim -ralph
From: Ralph on 10 Feb 2007 09:36 "mayayana" <mayayana1a(a)mindspring.com> wrote in message news:fAczh.20451$pQ3.19559(a)newsread4.news.pas.earthlink.net... > I got this working finally, but I gave up > on the char ** var approach. I think that > one problem may have been an odd > quirk in the MS code: They had declared > a char [256] string inside a loop and I > assumed that meant it was going out of > scope and being re-initialized with each loop. > Not so! Characters copied to the string in > one iteration were still there in the next. > I needed to clear the variable with nulls on > each iteration. So why did they declare it > inside the loop? I don't know. > "loops" in C are blocks. Anything declared in a block is not valid outside the block. It looks like 'scope', but is slightly different. The variable would never be "automatically" anything - little in C ever is. <g> Would have to take a look a the original code to see what was meant. > What I ended up doing was to just send > a long, pipe-delimited string of file paths > to the DLL function, along with an array of > longs that indicates the length of each path. > The loop can then just go through the string, > copying one path at a time to send to the > cabinet.dll function. > Glad to see you got it working. -ralph
From: mayayana on 10 Feb 2007 11:55
> > I got this working finally, but I gave up > > on the char ** var approach. I think that > > one problem may have been an odd > > quirk in the MS code: They had declared > > a char [256] string inside a loop and I > > assumed that meant it was going out of > > scope and being re-initialized with each loop. > > Not so! Characters copied to the string in > > one iteration were still there in the next. > > I needed to clear the variable with nulls on > > each iteration. So why did they declare it > > inside the loop? I don't know. > > > > "loops" in C are blocks. Anything declared in a block is not valid outside > the block. It looks like 'scope', but is slightly different. The variable > would never be "automatically" anything - little in C ever is. <g> > > Would have to take a look a the original code to see what was meant. > I don't want to wander off too far into a C++ discussion, but this has me curious. The code goes like this: for (i = 0; i < num_files; i++) { char stripped_name[256]; char spath[256]; strset(stripped_name, 0); strset(spath, 0); strncpy(spath, sPathsIn + i2, sizes[i]); i2 += sizes[i]; i2++; MessageBox(NULL, spath, "spath op", MB_OK | MB_ICONINFORMATION); ------------ When I first ran the code, before adding the strset lines to clear the char variables, the cab creation failed, unable to find a file. The message box showed first file: C:\........wed1-31.txt second file: C:\........fri2-2.txtt Then it failed. I realized that the second path had overwritten the first path, even though the declare of spath is inside the "For block". Since the second path was one character shorter, it had a "t" appended. The Microsoft code had the declare for stripped_name inside the "For block", so I assumed they did that because the variable would clear with each iteration. (The spath declare is mine.) |