|
Just like a one-dimensional, but you declare the two dimensions. Think of it as a block of items having some number of rows and columns. so you could have something like:
#define MAXROW 10
#define MAXCOL 5
ChartNode Chart[MAXROW][MAXCOL];
ChartNode NodeCoord(int row, int column)
{
if (row > 0 && row < MAXROW && column > 0 && column < MAXCOL) {
return Chart[row, column]; }
else
{
return NULL; }
}
All of these features are well documented in the C/C++ documentation and the various tutorials on the language.
|
|
|
|
|
the two dimensional array seems like something too good to be true  The compiler is definitely doing something suspicious behind the courtain.
Thanks.
modified 3-May-20 6:31am.
|
|
|
|
|
I think you could do with studying all the features of C (or C++ if that is what you are using). Trying to learn a language by posting questions here will take ten times as long, and you will still miss most of it.
|
|
|
|
|
Internally it's just continuous memory that is allocated for a 2 dimensional array (For any no. of dimensions for that matter).
The compiler uses the specified dimensions to calculate the offset into the memory to fetch.
For instance, offset of Chart[2][3] could be calculated as -
(sizeof(ChartNode) * MAXROW * 2) + (sizeof(ChartNode) * 3)
«_Superman_»
I love work. It gives me something to do between weekends.
Microsoft MVP (Visual C++) (October 2009 - September 2013) Polymorphism in C
|
|
|
|
|
Often I edit my posts/replies shortly after making them, I can`t organise myself in a single swing.
|
|
|
|
|
I have a shipping piece of software, that uses property sheets for Tools/Options. For almost all my customers everything is perfect, but for just 2 or 3 the property sheets appear as though the dialog units are too large. The fonts, edit boxes, and all controls are about 1/3 too large, but with the same 0,0 origin. Even so, the containing dialog size is unchanged, so the result is that some of the controls on the right and bottom are either clipped or not visible at all.
We only use property sheets in two places, and for customers with this problem, both instances are affected identically. This only happens with Property sheets, and not with normal dialogs.
The resources are defined in the .rc file like:
DLG_PREF7 DIALOG 10, 91, 300, 179
STYLE DS_ABSALIGN | DS_SETFONT | DS_MODALFRAME | DS_3DLOOK | DS_CENTER | WS_POPUP | WS_CAPTION | WS_SYSMENU
CAPTION "Font"
FONT 8, "MS Sans Serif"
BEGIN
LTEXT "Fixed-width font",79,7,7,119,12,SS_CENTERIMAGE
COMBOBOX 80,131,7,126,300,CBS_DROPDOWNLIST | CBS_SORT | WS_VSCROLL | WS_GROUP | WS_TABSTOP
LTEXT "Proportional font",87,7,25,119,12,SS_CENTERIMAGE
COMBOBOX 88,131,25,126,300,CBS_DROPDOWNLIST | CBS_SORT | WS_VSCROLL | WS_GROUP | WS_TABSTOP
LTEXT "Font size",-1,7,43,119,12,SS_CENTERIMAGE
EDITTEXT 705,131,43,20,12,ES_RIGHT | ES_NUMBER | WS_GROUP | WS_TABSTOP
END
A picture would be worth a thousand words, but I can't post a picture. Imagine if you could have used ctrl/mouse-wheel to increase the size of the contents of just this dialog.
I am stumped. Does anyone have an idea of what might be happening?
|
|
|
|
|
It seems to be a one of the property pages displayed in the property sheet.
How do other pages look like (I mean in the resources)?
|
|
|
|
|
I have run your dialog and tried various changes to see if it affects it but nothing seems to go wrong. It may be worth checking the versions of Windows that the clients are running to see if that is a common factor.
|
|
|
|
|
I am trying to convert a C Linux library to Windows. And I've met something weird. I have a variable:
struct dir_struct
{
void* display;
char directory[DIR_NAME_LEN];
...
....
but when I listed this variable on my debugger:
TRACE("\n=>%s\n", dir_struct->directory);
Result:
=>/Wise Registry Cleaner/Oe©*Bº cE«Mòצ£š{@Q—Y|†Š˜ b!
k3©‘ø¼/´4þ"Ðõ÷düJ¤ $èû8©KªõÝ5ø³/ ò|"Áæpç5V—{?*õ;øœÎj¬þ‹.Ý‚Ä/AÆ]Gݨ ïk<br />
‚¥¡C©…º/GÏ/^×ÒÇ\b/`£ç£×9ʼn_9ßÛ8}añˆ g–¿§<êZøM[ÈCø`ƒ "ö~J÷ L4/Lè¶Î¸G¢Êèojµ¶/–ãÛx ÌZÀ## qǸ=//Y⢠¶LÉKºëÈš"Êã!"Ìd#vŽM-Gþ}?<br />
H’ƒÿidÔ’£lÖ#S///Híz<nÉ(BîU’{t0////i&e.ÆF|S.`[íbd6Óôà…ŸÝÂw+{[0//ÈÎû,ðŠ$Èí7ƒr«¨/,"–ZHfã w<br />
f¡
' †SZPÔoärEÁ/@«Ô<br />
³$,©ÀÙ‚ ø//í*‚Þ!ÍÙÉ4ÅZw6(bÚxZž†"ŠÊl…¡Ã//Ö¢HÄ£:vÄ,)‰²/UˆÂÔU±´Íüêp//Ÿ°ÖÏe¢ªHÝXaÍ///mÐw1 粪6r*n//r šT3fÞ:cùÇz<br />
/€à1UK_îˆ]Xj//ôÁ½ÓR¦ÍO?)Ë>Ø£á€MÃ=¿U"œ*CÜFeR//ˆ¹5»mŠ€€†Â#øD/×c|ÔÂq,’X`t¸I//TÁ ½w¢u,¸ ß÷ìÔ¶‚Ô„ ;% ÀÔI¯¤w¡"lï ÌC8ñÅÿ/ùê‡ ŒmŸ‹àúÚÃÓÍ3ãµ+TG¯@qܾA¬t´+vÛutô|‰Ä~:žÞHÏê6'9B~o½/þŒ#ƒ-©¶Ô"÷³'£//"Ù³{R"DLUDz] œ<br />
1 ½&{ÙòMÇ–_o™ºEí /ôež…°Û¬"¢ ¿‚yÚÊ£Cýñ:(×N±/’z¹ >eV®
Þ¦)ûªÝvlleŽ/xØB¡RÚ_Ò^6y¿w`žs¤‘øÂÂO{;ªqûN/0€È#@–ñyøq½nç
Why I have this garbage ? Because my folder is Wise Registry Cleaner only ... If I would understand it, maybe I can get rid of it ...
|
|
|
|
|
It's showing all that garbage because the character array is obviously not NULL terminated.
You'll have to look at the documentation to see how to know the proper length of the string.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Thank you. I have seek it \0 char in that string, but I didn't found it ...
|
|
|
|
|
There might be some other way that the library determines the length of the string. Is there any documentation?
Otherwise you can try adding this line of code before printing the string:
dir_struct->directory[DIR_NAME_LEN - 1] = 0; <<======================This line of code
TRACE("\n=>%s\n", dir_struct->directory);
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
What is the complete definition of the dir_struct structure? In Linux the information provided by the readdir(3) - Linux manual page[^] system call provides a properly null terminated string.
|
|
|
|
|
So in my case (in Windows) I am not getting that null on ending string (\0) ?
|
|
|
|
|
How do you obtain the file name from Windows? Which API function call are you using? If the documentation for that API function call specifies that the name is null terminated, then you should not be getting the garbage. But some old file systems set off a fixed length buffer for the file name - even in Unix! The original Unix directory was 16 bytes per entry: two bytes inode, 14 chars filename. The orginal FAT had room for 8 char file name, 3 char extension. If the field was filled with a maximum length file name (in either Unix or FAT), there was no room for a terminating nul. If you reach the end of the field before finding a null, it is nevertheless the end of the field!
Remember that nul terminated strings is an idea conceived for the C language. It directoy conflicts with the ISO character set standard, whether ISO 646, 8859 or other variants. Other languages have used other solutions, e.g. in Pascal, a string is (at least in most implementations) represented by a length field associated with the string buffer (so the ISO NUL character can be used in the ISO standard way!). Many other languages to the same.
DOS was developed before C and Unix. Windows was developed before Unix had become very important, at least in the market segments Windows was aimed at. So you should not take for granted that all sorts of C / Unix conventions have been adopeted in every other segment.
|
|
|
|
|
Obviously not. But you need to look into the original source code to see why.
|
|
|
|
|
#define DIR_NAME_LEN 2048
struct dir_struct
{
void* display;
char directory[DIR_NAME_LEN];
...
....
I have followed the way of how this variable is handled:
dir_struct_t dir_struct;
TRACE(_T("Directory - %s\n"), dir_struct.directory); -> _CrtDbgReport: String too long or IO Error
strncpy(dir_struct->directory, "/", sizeof(dir_struct->directory));
TRACE(_T("Directory - %s\n"), dir_struct->directory); -> /
strcat(dir_struct->directory, current_file->name);
TRACE(_T("Directory - %s\n"), dir_struct->directory); -> _CrtDbgReport: String too long or IO Error
And if I look into VS debugger when I got "_CrtDbgReport: String too long or IO Error" from TRACE macro, I see the following result: see image.[^] and Untitled2 — Postimage.org[^]
The line strcat(dir_struct->directory, current_file->name); is not quite correct ? I mean, correct for Windows, even if is correct for Linux ...
|
|
|
|
|
You are making a wrong assumption. The sizeof(dir_struct->directory) operator will return 2048. But what if the string in that table is less than that? You need an actual count of the number of valid characters in the directory field (assuming that it is correctly null terminated).
You are also mixing the dot (.) and arrow (->) operators on your struct reference.
But all this is largely irrelevant. You need to go back a stage to the code that fills the directory structure in the first place, as that is where the problem is most likely to be found.
|
|
|
|
|
"You are also mixing the dot (.) and arrow (->) operators on your struct reference."
Yes, you are right, I taken those lines of codes from different function (in one of them was reference, in other was pointer), that why those mixing are there.
modified 29-Apr-20 15:24pm.
|
|
|
|
|
Well you should not be doing so, since the reference in both cases is a structure, not a pointer. The dot operator is the correct one.
But more importantly you have still not shown or explained when and where this structure gets initialised, and the directory name copied in. Until you give us that information anything we pass on is pure guesswork.
|
|
|
|
|
You have actually identified your problem, you just haven't realized it.
strncpy(dir_strut->directory, "/", sizeof(dir_struct_directory)); strcat(dir_struct->directory, current_file->name);
It would seem that current_file->name is not a null terminated C string. You have not given us the details of current_file, or how it is instantiated, so we can't further diagnose the problem at the moment. Perhaps current_file has a member that tells you how long the name member is, in which case you should use that and strncat to append the file name to the directory name.
Keep Calm and Carry On
|
|
|
|
|
Yes, indeed, from this point strcat(dir_struct->current_directory, current_file->name);, my dir_struct.directory seem to go crazy.
current_file->name is coming from:
const file_info* current_file = AnotherFunction();
and file_info is a struct defined like this:
typedef struct
{
char* name;
.....
unsigned int status;
}file_info;
Here is the steps:
strncpy(dir_struct->directory, "/", sizeof(dir_struct->directory));
TRACE(_T("Directory - %s\n"), dir_struct->directory); -> Directory - /
Untitled — Postimage.org[^]
const file_info* current_file = AnotherFunction();
TRACE("\n===>>>%s\n", current_file->name); ->===>>>Unbroken
Untitled2 — Postimage.org[^]
TRACE(_T("Directory - %s\n"), dir_struct->directory); -> _CrtDbgReport: String too long or IO Error
Untitled — Postimage.org[^]
Untitled — Postimage.org[^]
|
|
|
|
|
The AnotherFunction itself or the way you are using it seems to be a reason of your problem... 
|
|
|
|
|
Yes Victor, you had right, from AnotherFunction is coming sometime a value like this: Oe©*Bº cE«Mòצ£š{@Q—Y|†Š˜ b!
And this AnotherFunction is list_entry_const() ... is coming from Linux, and to reproduced in a test project is quite difficult ...
Now I have to see where is the starting point for that strange chars ...
modified 3-May-20 10:01am.
|
|
|
|
|
It looks like this function returns some local variable that goes out of scope after returning. However, better would be looking in its sorce code.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
