C / C++ / MFC

8-Aug-05 19:46

HexEncoder doesn't provide a direct conversion to char* or CString. It only offers the possibility to output its content to an std::ostream. You could use an stringstream for that and then extract the string from it.

On the other hand, OCTETSTR is just a typedef for std::vector<unsigned char>, so you could iterate through each element and convert it to hexadecimal notation using sprintf like this:

// [UPDATE]
// void OctetStrToHexString(OCTETSTR str, CString& sResult)
void OctetStrToHexString(const OCTETSTR& v, CString& sResult)
{
   // [update] some minor errors corrected
   LPTSTR p = sResult.GetBuffer(v.size()*2);
   for (OCTETSTR::size_type i = 0; i < v.size(); i++)
      p += _stprintf(p, _T("%02X"), (int)v[i]);
   *p = _T('\0');
   sResult.ReleaseBuffer(v.size()*2);
}

Then your code could be written as follows:

   OCTETSTR str;
   CString sBuffer;
   OctetStrToHexString(str, sBuffer);
   poEdit->SetWindowText(sBuffer);

Note I haven't actually compiled nor tested the code shown above, so it may contain errors.

--
jlr
http://jlamas.blogspot.com/[^]

Re: type conversion

Member 20725789-Aug-05 6:16

Member 2072578

9-Aug-05 6:16

Ive used this code but the compiler gives v as undeclared identifier.whas v??
Thanx for ur help

Re: type conversion

Jose Lamas Rios9-Aug-05 6:48

9-Aug-05 6:48

Oops! v was meant to be the OCTETSTR parm, sorry. Change the function header to this:

void OctetStrToHexString(OCTETSTR v, CString& sResult)

--
jlr
http://jlamas.blogspot.com/[^]

Weird Memory Issues

LighthouseJ8-Aug-05 17:39

8-Aug-05 17:39

I'm trying to rewrite a console application with more efficiency and I am getting nailed by memory assertions. The biggest difference is that I'm deriving my own objects from CObject and my own list from CObList but that's not where I'm having a problem. I wrote my own iterator but something is calling it's destructor and goes down in flames. I have this now:

<br />
Iterator * iterator = new Iterator();<br />
<br />
for (iterator->Clear(); (!(iterator->MaximumValueReached())); (*iterator)++) {<br />
... does work ...<br />
}<br />

The iterator code works fine in the previous version of the code and I didn't touch it since then. Execution happens once through then goes back up to the for, it iterates fine, exits to the above for loop and immediately enters the destructor. The only time I delete this iterator (on purpose) is in the destructor of the class member this code is in and that's much later.

Also, in the iterator I have a pointer to a struct. The struct exists by using 'new' and it crashes when I 'delete' it.

To note: I was having problems by an assertion being thrown because _CrtCheckMemory returns false which I found out means that there is some counter that counts my mallocs and when it hits 1023, it throws the assertion. This problem mentioned at the beginning of this message started occuring before this assertion so I don't have access to that problem but the two might be related. I might start by changing my old malloc/free statements to new/delete.

Any help to this would be much appreciated. I don't know why I'm getting memory issues just by a couple class derivation rewrites, hopefully you can help me.

Christian Graus8-Aug-05 17:56

Christian Graus

8-Aug-05 17:56

Why are you reinventing the wheel like this ?

Christian Graus - Microsoft MVP - C++

LighthouseJ9-Aug-05 4:19

9-Aug-05 4:19

Well,
1. I used to use a 64-bit integer to do this earlier but that would limit me not only by size but by portability.
2. I also wanted to try out overloading operators because I've never done that.
3. Lastly, I need it to do a lot more than a simple single variable does and placing all the extra functionality with the iterator is very convenient for me.

Jose Lamas Rios8-Aug-05 18:25

8-Aug-05 18:25

Some suggestions:

- Set a breakpoint at the Iterator destructor and check the call stack to see why and from where it's being destructed. If the debugger breaks too often because you have many other iterators, which also get destructed, you may qualify the breakpoint with a condition (e.g.: this==[iterator of interest]) so that the debugger will only break when that particular Iterator is being destructed.

- Just a hunch, but check if somewhere in your code (in particular, in the body of that for loop), you aren't unintentionally assigning the iterator to another pointer on which you later call delete. For example, if you write something like if (anotherIterator = iterator) instead of if (anotherIterator == iterator).

--
jlr
http://jlamas.blogspot.com/[^]

LighthouseJ9-Aug-05 4:27

9-Aug-05 4:27

- I did set a breakpoint and the call stack is going from the line and file of the for loop I mentioned and directly to the destructor.

- That iterator is never touched anywhere else except through a single function called Test which simply reports a sequence of bitwise AND operations with the iterator data and another smaller for loop index variable.

Thanks for your reply. I do have a feeling the problem is with something dumb I did but I keep saying to myself "there is no way this code is wrong".

Jose Lamas Rios9-Aug-05 4:49

9-Aug-05 4:49

Is the for loop exactly like the one you posted? Or did you post a simplified version? If so, post the actual code, and maybe the entire function in which it's enclosed (unless it's very big). Someone may have more luck at spotting a problem.

--
jlr
http://jlamas.blogspot.com/[^]

LighthouseJ9-Aug-05 4:54

9-Aug-05 4:54

That loop is exactly as you see it (minus changing the increment from pre-increment to post-increment), but the entire function is too big to post it all.

Re: Weird Memory Issues (solved this, another problem though)

John R. Shaw8-Aug-05 18:59

John R. Shaw

8-Aug-05 18:59

LighthouseJ wrote:
(!(iterator->MaximumValueReached()));

Ahhh! Go back to studying the basics of C++. I've never seen any body allocate an iterator before (makes no since). Also, what guarantees that the iterator is still valid (at the above point).

All I see in your example, is code that is guaranteed to crash.

INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen

LighthouseJ9-Aug-05 4:55

Re: Weird Memory Issues (solved this, another problem though)

9-Aug-05 4:55

This class is more of just an iterator embedded in a class with members in it. That function, MaximumValueReached() does work in my earlier project. About those guarantees, I did some checking and found out when it finishes the iterator, the data in it gets corrupted. I have a pre-increment and post-increment operator and here's the code that did it:

Iterator& Iterator::operator++ () {<br />
... does iteration here ...<br />
	return *this;<br />
}<br />
<br />
// post-increment<br />
Iterator Iterator::operator++ (int) {<br />
	Iterator temp = *this;<br />
	++(*this);<br />
	return temp;<br />
}

In my for loop, I was calling the post-increment operator which in turn calls the pre-increment operator. I think VC knows how to shape the machine code to increment before or after. What was happening is that the code would get to '++(*this);' and go into the pre-increment and work fine then exit back to the post-increment operator. Before the 'return temp;' statement, the iterator is fine, but after it ran the return statement, it's corrupted and I don't know how it became corrupted or deleted since it's running it's own destructor.

I did switch the for statement to the pre-increment iterator and it works until I hit the debug assertion

_ASSERTE(_CrtCheckMemory());

which I said in my first post that I was receiving before. I've read on some sites like MSDN that says it "Confirms the integrity of the memory blocks allocated in the debug heap (debug version only).". I also read that every time you malloc, it adds one to a counter and when that counter is 1 less than 1024 it asserts. I read what this assertion does but it (and web sites) offer no solution to fix it that I can find.

Jose Lamas Rios9-Aug-05 5:31

Re: Weird Memory Issues (solved this, another problem though)

9-Aug-05 5:31

LighthouseJ wrote:
// post-increment
Iterator Iterator::operator++ (int) {
Iterator temp = *this;
++(*this);
return temp;
}

There are two copy of Iterator operations there, one when you do temp = *this and another when you return temp. Does Iterator have a copy constructor or operator=?

You mentioned before that Iterator contains a pointer to a heap-allocated structure, which it deletes in the Iterator destructor. How are these structures copied when you copy one Iterator to another? If it's only copying the pointer (instead of allocating a new structure based on the original), the destructor of the local variable temp would do a delete on the structure, and that would be the same one pointed to by the Iterator you are returning and also the same one pointed by the original Iterator...

--
jlr
http://jlamas.blogspot.com/[^]

LighthouseJ9-Aug-05 10:28

9-Aug-05 10:28

I see what you and John R Shaw mention in the next message that I am making a new iterator and when it's created, the data isn't carried forth. No, I only overloaded the 2 increment operators because that's all I want the iterator to do, it's never compared with another, nor will I be decrementing. Doing pre- or post- really doesn't change the function of the programming controlling the iterator, I just incorporated the source from a site and went on from there. I am currently looking into the copy constructor now in hopes I can understand that new concept as well.

I believe I now have a handle on this problem and that the other problem about the _CrtCheckMemory assertion is still plaguing me. As I mentioned before, I read what the function does but I don't understand what causes the assertion, or as some sites mention, what causes the heap to be corrupted. At the time of assertion, the call stack leaves my program at the point where I add an item to a CObList. The added item is valid when it leaves my code, the CObList it's added to is valid but empty at the moment, it's adding the first item to the list. My program creates a class I made derived from CObList. The constructor creates a new CObList, things are added, work is done and if the results pass a test, it's kept and the old is deleted. The destructor removes all items from that list and deletes the CObList itself then ends. Where am I going wrong here? I can paste some code or further explain something if clarification is needed.

Found What I Needed

LighthouseJ9-Aug-05 13:59

Re: Weird Memory Issues (solved this, another problem though)

9-Aug-05 13:59

I was looking on the web and I found a replacement memory manager that basically does what VC does but it records a log of every allocation and deallocation (or reallocation). If there's a memory allocation/deallocation mismatch or a memory leak, it creates a log file so you can inspect the problem further. It tells you the line that each item is allocated or deallocated.

If you're interested in checking it out, go to fluidstudios.com and download their Memory Manager aka MMGR, put the files into your project, compile and run. If there's a memory problem, it will cause a breakpoint, if the problem is minor like a memory leak, it will let the execution complete but write out a text file log describing the memory leak.

John R. Shaw9-Aug-05 9:20

John R. Shaw

9-Aug-05 9:20

I see Jose Lamas Rios already gave a reasonable answer. Even without the automatic destuction in the post-increment code it is still possible for your code to increment passed the end (off into la la land). A normal interator does basicaly that, except it has a specific (invalid) ending point that you can check to see if you are done.

As for pre-increment and post-increment operator: You are not correct about what the compiler can do. A compiler can shape the code on known types such as int, double, ect..; it is incapable of determining how to convert a post-increment to a pre-increment for user defined types. Therefore, you should make using a pre-increment a habit or you'll constantly be making (hidden) temporary copies of what ever you are incrementing.

INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen

cmk9-Aug-05 1:03

cmk

9-Aug-05 1:03

Without knowing how Iterator was written it's hard to say what's wrong.

The (*iterator)++ looks weird on an object pointer - i hope Iterator overloads operator ++ () and/or operator ++ (int).

...cmk

Save the whales - collect the whole set

LighthouseJ9-Aug-05 5:06