|
I think that the conversion to char* is OK. Because integer is converted to an array of chars (with appropriate length), no information is scratched.
But for storing and loading basic data types you could use operators >> and << instead of write() and read(). It's more readable 
I know, that these paragraphs probably don't solve all of your problem. So write us, what does your corruption mean? It causes an error message or the read data are different from the written data?
Robert-Antonio
"A piece of paper is an ink-lined plane.
An inclined plane is slope up.
A slow pup is a lazy dog.
Q.E.D.: A piece of paper is a lazy dog."
|
|
|
|
|
Robert A. T. Káldy wrote:
I think that the conversion to char* is OK. Because integer is converted to an array of chars (with appropriate length), no information is scratched.
Unfortunately I fail to see the reason of why this would be correct ? I'm not saying it is wrong, but I just don't know how it could work ?
The way I see it is that the pointer received by the write function specifies the starting point, and the size parameter tells how many bytes are supposed to be copied. Afterall, a char basic type is of size 1 byte on the Microsoft C++ environment.
So, the function starts from the beginning address to copy data into the file on a byte-by-byte basis. It reads one byte of data, and writes it down. An integer is already 4 bytes long, so this won't pose a problem if the integer is in limit of 1 byte dimension. But any number greater than 128 or smaller than -127 (unsigned char) is considered out-of-bounds, and the context of the integer is undoubtly broken, thus corrupting the data. This would require testing, I know, but at this point, it seems more than a useless debate
However, the dumping operators << and >> might provide a better solution, like you have stated. I forgotted them first, thinking that they were only available when using serialization. But, yes, they should work very well, too. I believe they even check the type of source data so no corruption should occur.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
Antti Keskinen wrote:
So, the function starts from the beginning address to copy data into the file on a byte-by-byte basis. It reads one byte of data, and writes it down. An integer is already 4 bytes long, so this won't pose a problem if the integer is in limit of 1 byte dimension
Are you saying that if an int has a vlaue of 128 to -127 it only occupies 1 byte?
An integer is always 4 bytes long regardless of its content. (in this C++/compiler implementation)
Roger Allen - Sonork 100.10016
Strong Sad:
Clever I am? Next to no one.
Undiscovered and soggy.
Look up. Look down. They're around.
Probably laughing. Still, bright, watery.
Listed among the top. Ten.
Nine. Late night. Early morn.
Early mourn. Now I sleep.
|
|
|
|
|
Basically, yes, though I might have presented it in an obscure manner.
An integer that is under the first 255 numbers from zero (0-255 or +128/-127) uses the last byte to designate it's value. All other bytes are zero. So, on writing this integer into a file, there will be three zero-bytes and one "data" byte.
Hence the saying "the integer is in limit of 1-byte dimension", meaning, that one byte is enough to represent the actual integer, though 4 bytes are always used, like you said.
Considering that an integer is "always" 4 bytes long in the memory (or in a file), it's representation in the file, whether it was one or more bytes long, should always show up correctly in memory as well, as memory-wise copying is done on byte-by-byte basis by the reading/writing functions. Or, this is how I have understood that they work..
This means that if the data becomes corrupted while doing this, there might be a compiler optimization command responsible that links the adjacent bytes to each other. Like, could it be that the 'size' optimization command decreases the memory requirement of an integer if it doesn't require all four bytes to represent itself ?
If the integer only requires two bytes to represent itself, the compiler, when executing with an optimization, actually caps the integer's length into two bytes ? I know this doesn't sound logical at all, but well, I'm quite outta ideas on why the data might get corrupted, as it does
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
The function ostream::write(E* buf, streamsize n) writes n elements of (templated) type E, starting at position pointed by buf. In our case it will write four chars, that covers the 4-byte memory block, in which the integer is stored. What is wrong?
I don't know about any optimization, which compresses intergers to smaller sizes. 4 bytes is the default length of integer on all 32bit platforms.
Robert-Antonio
"I launched Norton Commander and saw, drive C: on the left, drive C: on the
right...Damn, why I need two drives C:??? So I formatted one..."
|
|
|
|
|
Nothing should be wrong, but according to the original poster, the data gets corrupted in random positions during the writing. This means that something is wrong with the routine, and I was just curious to find out what this reason is..
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
Hello all,
I have some questions about inline function, if I have something like this
<br />
class myClass<br />
{<br />
protected:<br />
int i;<br />
<br />
public:<br />
inline Set_I(int val)<br />
{i = val;};<br />
}<br />
<br />
int main()<br />
{<br />
myClass c;<br />
c.Set_I(10);<br />
}<br />
I want to know what will actually happen. Since Set_I() is an inline function, the compiler will replcae the definition of the function in where the function has been invoked. However, in this case the inline is actually accessing the protected member of the class, so what will happen??
Thanks!
Nachi
|
|
|
|
|
nachilau wrote:
However, in this case the inline is actually accessing the protected member of the class, so what will happen??
Exactly the same thing. The protected keyword tells the compiler that the i variable can be accessed by members of myClass or its derivatives. This condition is still true. Whether or not the compiler inlines the member functions makes no difference at all. It is still the same function accessing the same variable.
Hope this helps,
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
|
nachilau wrote:
compiler will replcae the definition of the function in where the function has been invoked.
No. inline is a suggestion to the compiler, it can choose to ignore it.
Christian
I have drunk the cool-aid and found it wan and bitter. - Chris Maunder
|
|
|
|
|
inline is an important keyword, but it must be used as:
1. in h file, but not inside class scope(if so, it is ignored)
2. not in cpp file (if so, it is ignored)
example is
//MyClass.h
class MyClass
{
public int Get();
};
inline
int MyClass::Get(){return 1;}
advantage of inline function is
1.(at least books say) it is faster than normal function.
2.in case of you need to put your code on head file (e.g. craete library)
includeh10
|
|
|
|
|
includeh10 wrote:
public int Get();
};
inline
int MyClass::Get(){return 1;}
2.in case of you need to put your code on head file (e.g. craete library)
In fact, the compiler is trying to inline any function defined in the *.h-file. Regardless of inline or not.
If you want to suggest to inline a function with a body in the *.cpp-file, you add inline before the declaration in the header file.
In any case, you are only giving a suggestion, you can not force the compiler to do the inlining.
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation."
-- Caius Petronius, Roman Consul, 66 A.D.
|
|
|
|
|
i think u never use inline before.
code above can not be compiled if no keyword inline.
includeh10
|
|
|
|
|
I am just trying to test this API function on Outlooks
SysListView32 control.
ListView_GetItemCount works fine but ListView_GetItemText
crashes Outlook.
void testListView(HWND listView)
{
int count = ListView_GetItemCount(listView);
printf("%d", count);
printf("\r\n");
char text[25];
//LVITEM item;
//memset(&item, 0, sizeof(item));
//item.mask=LVIF_TEXT;
//item.iSubItem=0;
//item.pszText=text;
//item.cchTextMax=25;
//item.iItem=1;
//SendMessage(listView, LVM_GETITEMTEXT, 1, (LPARAM)&item);
ListView_GetItemText(listView, 1, 0, text, 25);
printf(text);
printf("\r\n");
}
jp
|
|
|
|
|
Are you calling this from another application, or from an Outlook addin? It won't work from another application because Outlook will try to write to an area of memory that does not belong to it, causing an access violation.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Yes, from another application.
Is there any way to do it?
I don't want to go the AddIn route.
thanks
|
|
|
|
|
Also, why can I return a RECT successfully?
What is the difference?
GetItemRect works ok??
|
|
|
|
|
Guys,
yet another question.
How do I use global varibales across multiple files.
and where exactly do I define the "extern int count;" ?
lets suppose I have the following
myclass.h
myclass.cpp
mymain.cpp -> this is where the main() program exists.
basically I want my class to update a global variable everytime its called, and then I want to be able to read that variable from my main as well ?
any suggestions? I m trying the "extern" but getting some LINK error saying I have unsolved external symbols.
pls help
Thanks
|
|
|
|
|
A better way to go would be to make a function such as UpdateGlobalVariable that all of the modules can access. It would reside in mymain.cpp and update a variable that is declared there.
a two cent stamp short of going postal.
|
|
|
|
|
Global variables are evil. If you must, then declare it in stdafx.cpp and put your extern in stdafx.h.
Christian
I have drunk the cool-aid and found it wan and bitter. - Chris Maunder
|
|
|
|
|
In 99.9999% cases you can avoid global variables. For example, you should declare it in CWinApp class or in MainFrame class. Both of them, have only one instance in the program, so you can access it by AfxGetApp()->theVariable or AfxGetMainWnd()->theVariable.
Robert-Antonio
It's a good luck, when you meet a real fink. Then you get a respect to
normal, mid-honest people."
|
|
|
|
|
True, but you still have the global variable. All you are really doing is moving the global variable around so it isn't a traditional global variable. However, functionally, it still acts like a global variable and thus has most of the exact same problems associated with it.
I think it was Christian that said wrap the global variable in a global function. The good thing about this approach is that it makes it much easier to add some form of locking to the variable.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
int count = 0;
void someFunc1()
{
count++;
}
extern int count;
void someFunc2()
{
count++;
}
By the way, does anyone know how to get codeproject to retain indentation?
|
|
|
|
|
Hello, everyone,
In my project, I used CStaticLink class to change the static text to url style text. It works fine in different dialog boxes. But it is not working good in a CPropertyPage dialog box. The text is not changed to blue color and not underscored, but the link is still working good. I think the problem is from the second parameter *CWnd (in my code, I used "this"), but I cannot figure out what should it be.
What do I need to do to make it work?
Thanks a lot in advance.
Bin
|
|
|
|
|
Hi all!
In my application I'm reading from a console and what is read is written in an edit box, but I need to append the new text so the prior text does not disappear. I normally write
<br />
m_strText=read_text;<br />
but this erases prior text in the Edit Box.
Any ideas?
Thank you in advance!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
