Well your code remains unclear. However, if m_pFont is a pointer, then you are going to have problems unless you also serialize the object that it is pointing at. Deserializing a pointer without the underlying object means that it will be pointing to some random portion of memory.
This point is treated by the MFC CArchive::ReadObject and CArchive::WriteObject methods which are automatically called by the >> or << operator. They are able to detecte or serialize the associated RuntimeClass.
The example code is very close to the actual code and the problem is that sometimes, depending on the computer, because of the operator >> to deserialize the style m_pFont, several m_pFont pointed to the same memory area.
I studied the problem with a minimal grid ... and finally realized that in my application I was not using this m_pFont. I modified my code so that I would no longer use it at all, destroy it and set it to NULL which definitively resolved my problem.
If I don't fully explain the phenomenon, I think it comes from the fact that these m_pFont contained the same data and that the operators << consider the pointer had already been serialized as explained in the TN002: Persistent Object Data Format | Microsoft Docs ... Maybe ...
Other application can print out without problem ? Have tried to print to another printer ? Or, have you tried to run that command on another machine ? You can find more if you do some debugging on your code ...
<l>I am trying to learn c++ programming language and am still an amateur at it. I have a problem with "passing arrays in a function" and all am asking is what would be the easiest way to handle this problem?
*sometimes*. And it may very well depend on the platform.
I have a communications system that transmits data using tags and a parser. I have upwards of 500 data elements that can go back and forth. The initial implementation used a simple linear search for finding a passed tag. As time passed, the tag set became larger and larger.
Hey, this is a good place for a mapped data set, allowing me to find the tag quickly I thought. The map turned out to be 3 times slower than the linear search. Never did figure out why. Showed the sample code to someone who loves the STL and has a lot more experience than I do. No idea. Someday I'll get back to it.
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
constexprint Indices = 4096;
constexprint Size = 512;
externconst string tag [Size];
int linear_search(const string & s )
for (int n = 0; n<Size; ++n)
if ( s == tag[n]) return n;
constexprint Iterations = 1000000;
std::map<string, int> mtag;
for (int n=0; n<Size; ++n)
int sum = 0;
for (int n=0; n<Iterations; ++n)
int i = idx[n % Indices];
const string & s = tag[i];
k = linear_search( s );
auto it = mtag.find(s);
k = it->second;
cout <<"sum "<< sum << endl;
tag is an array of 512 randomly generated strings (having length betwween 4 and 12)
idx is an array of 4096 randomly generated indices (for quickly gatering a candidate)
g++ -D LINEAR_SEARCH -Wall lookup.cpp -o lookup_linear_search
g++ -Wall lookup.cpp -o lookup_map
Last Visit: 31-Dec-99 18:00 Last Update: 23-May-22 17:35