|
There is to my knowledge no MFC etc function available to do this. But, hey, you effectively rolled your own parser! That means that you have to write all functions to deal with stuff that XML can throw at it. If you leave something out, you will sooner or later become a cropper. The writing of a function to convert the simple escapes you mentioned appears to me to be a relatively minor issue in the greater scheme of things you are taking on.
regards,
Bram van Kampen
|
|
|
|
|
shpid3r wrote: to be honest I`m not sure I know exactly what`s the difference between encodings
If your going to parse XML from a windows box and attempt to do something with the data, you will need to understand the differences between UTF-8, UTF-16, UCS-2, and code pages if your compiling for MBCS. There is no compromise on this if you want your parser to work and your results to display correctly, without corruption in your Visual C++ program.
Even from my little experience in XML processing, it is obvious based on your post that you are attempting to tackle a non-trivial subject with a trivial approach thats likely to end in frustration. Do yourself a favor and use an already existing and well supported XML parser. You will still likely need to understand encodings anyway, but it will save you a lot of headaches early on.
|
|
|
|
|
ON_COMMAND_RANGE(IDC_RELAY1, IDC_RELAY8, ChangePin)
hi there,
the Above code will call the function ChangePin() when checkbox's in the range IDC_RELAY1 to IDC_RELAY8 are changed, can anybody tell me what kind of message is sent when a user clicks one of the checkbox's?
i am trying to progmaticaly send the "BN_CLICKED" message to trigger the ChangePin function from my code without having to physicaly use the mouse to heck the checkbox.
thanks chris
|
|
|
|
|
try simply checking the checkbox programatically and see.
AFAIK that should automatically call the associated function.
good luck.
--------------------------------------------
Suggestion to the members:
Please prefix your main thread subject with [SOLVED] if it is solved.
thanks.
chandu.
|
|
|
|
|
i tried checking the checkbox,by setting its value to TRUE,and then Updating the dialog using UpdateData(false); sure enough the checkbox checked but it failed to call the ChangePin function.
any other idieas?
thanks
chris
|
|
|
|
|
You can always use SetCheck() to change the check state of the
checkbx then call ChangePin direcly, passing the id of the checkbox.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Hello everyone,
I want to confirm that on a 32-bit machine,
1. compare the value of two byte to see whether they are equal or not;
2. compare the value of two integer (4-byte) to see whether they are equal or not.
(1) and (2) should have the same performance, right? I am using x86 32bit Windows machine to develop native unmanaged C++ application.
thanks in advance,
George
|
|
|
|
|
Depends a bit on allignment,and on the precise processor on the target machine, but the difference should be insignificant for most purposes.
regards
Bram van Kampen
|
|
|
|
|
Hi Bram,
I am interested to learn what do you mean alignment. Could you provide more information please?
regards,
George
|
|
|
|
|
Allignment
I thought this was a quite Basic, Simple and well understood topic, but I must admit, cannot find any articles about it. Must write a short one myself to fill this void. Watch this space, and I get something together soon.
Regards,
Bram van Kampen
|
|
|
|
|
Hi Bram van Kampen,
I am not saying that I do not understand what is memory alignment.
My question is I do not know why you mentioned memory alignment matters to the performance of equal comparison in my question. Could you provide more information please?
regards,
George
|
|
|
|
|
If the item being compared is less than the natural word size in the CPU, the item may need to be shifted before the comparison takes place. That takes more time than if the item falls on a natural word boundary.
Judy
|
|
|
|
|
Thanks Judy,
I do not know why if loading one byte, other than 4-bytes (32-bit), the system needs additional efforts to do alignment? For one byte, the system can load the continuous 4 bytes from memory which contains the one byte and could meet with 32-bit alignment requirement, and in this way, only one CPU cycle is needed, and no additional cycle is needed to do alignment for 4-byte (32-bit) data, right?
Please correct me if there are anything wrong with my statements above.
regards,
George
|
|
|
|
|
Read Bram's post again more carefully. The difference comes in if the item to be compared is not one byte long and is not stored on a 4-word boundary. If the item is 4 bytes long but is not aligned on the boundary, the CPU must do two fetches to get the item in its entirety before it can compare.
Judy
|
|
|
|
|
Thanks, At least You Understand what I'm trying to explain. You confirmed I'm Not writing gibberish afterall. Trying to close the tread , without success sofar.
We were all learners once.
Regards and thanks
Bram van Kampen
|
|
|
|
|
Hi Judy,
In my original question, I am comparing one byte with another one byte. So, I do not think there is any alignment issues. Bram is talking about if a WORD or something is put across the alignment boundary, so we need to 2 CPU cycles to fetch -- it is another case. I am talking about a byte, not a WORD.
Please feel free to correct me if I am wrong.
If we need any additional alignment operations for one byte (not one WORD or DWORD), please also correct and I would be willing to learn.
regards,
George
|
|
|
|
|
You are correct for a byte. Your original post way back when also mentioned an int which is not one byte so you got the long discussion on alignment. This statement concerns me:
George_George wrote: If we need any additional alignment operations for one byte (not one WORD or DWORD), please also correct and I would be willing to learn.
You do not do anything to deal with alignment with respect to the CPU, it handles that itself. You asked a pretty low level performance question about the comparison of two one-byte numbers versus the comparison of two four-byte numbers. You got a low-level answer on how the CPU handles these comparisons which is where the answer to your original performance question lies.
The alignment Bram and I have been talking about is not the same as the "struture member alignment" option you can specify in the compiler options and override with #pragma pack. Two completely different beasts.
The first answer when dealing with a question about low-level performance should always be: code it in a sane and reasonable manner without trying to optimize performance and see how it actually performs before tinkering with the code. Nine times out of ten, it performs fine. In the one case where it doesn't, do some profiling and see where the bottlenecks actually are. They are usually not where you were worrying about in the first place.
Judy
|
|
|
|
|
Thanks Judy!
I think my question is answered. I appreciate your help and patience all the time.
regards,
George
|
|
|
|
|
Thanx for your Support. You understood what I Tried to explain.
Sent the Following to George_George to Close the Subject:-
May the tread continue in virtual heaven, May those humans who contributed and have expired since the thread started, go to their respective heavens, Those that are still in the land of the living. for, all those who contributed, did not break new boundaries, but merely covered points which first year University Courses should have covered.
Claim Bonus Points for Your respective heavens, whatever their religion.
Bottom Line: Education should not concentrate only on the virtual experience of how a compiler compiles, It should keep the new bucks down a bit by also teaching programming in assy language and Basic principles and a basic understanding of how an I86, or whatever chip works!
Bram van Kampen
|
|
|
|
|
The processor only loads data at 4 byte boundaries. If the allignment is off, it transparently carries out internal shifts,
and loads the 32 bits in two goes.
If you compare Bytes, Words or Dwords alligned on a 4 byte boundary, there is in all cases one 32 bit wide fetch cycle for each operand. The Compare cycle is also identical, it generates all three possible results in the one go. The difference between them is which result gets stored in the Flag Register.
Now if you have a DWORD stored on a 2 byte boundary, that takes 2 fetch cycles. whereas a WORD stored on a 2 byte boundary takes only One fetch cycle. That means that a DWORD comparison can be slower than a WORD comparison, depending on allignment. You can fill in the rest yourself for the situation with Bytes.
BTW.
This is more a significant issue when you do things like RF.digital signal processing. If I were to do something like that, I would definitely not start with a pentium chip. Horses for Courses as they say.
It has never cropped up anywhere in my experience as an issue of major importance when writing CPP Windows/MFC Code, which is what this forum is about.
Then again, There's nothing wrong with being curious.
Regards,
Bram van Kampen
|
|
|
|
|
Thanks Bram,
I agree memory is aligned on 32-bit if the machine is 32-bit. But I do not know why alignment needs additional efforts.
For one byte, the system can load the continuous 4 bytes from memory which contains the one byte and could meet with 32-bit alignment requirement, and in this way, only one CPU cycle is needed, and no additional cycle is needed to do alignment for 4-byte (32-bit) data, right?
Please correct me if there are anything wrong with my statements above.
regards,
George
|
|
|
|
|
|
Hi Bram,
Sorry for any inconvenience. In my original question, I am comparing one byte with another one byte (with the performance comparison of one 32-bit integer and another 32-bit integer). So, I do not think there is any alignment issues for a byte. I think you are talking about if a WORD or something is put across the alignment boundary, so we need to 2 CPU cycles to fetch -- it is another case. I am talking about a byte, not a WORD or a DWORD.
Please feel free to correct me if I am wrong.
If we need any additional alignment operations for one byte (not one WORD or DWORD), please also correct and I would be willing to learn.
regards,
George
|
|
|
|
|
Please re-read what I wrote in the past. You seem to have some block of imagination between what you write in your file, and how it's used after being compiled. Please explain further why these timing issues are so important. As I Tried to explain before, but I'll now spel it out:-
The idea of writing in windows and MFC is, that whatever platform you write for, In Escence your Code will work. Believe it or not, if written prudently, your code will work on a MAC, on Windows 2000, or, Windows NT. Things work, because the type of question you ask here in how long does it take to perform a Core Operation, like a Compare, or the differerence therein by size of operant, does not come into the equasion, and is largely insignificant in most cases, because of the nature of the User Interface.
Please let me know WHY it is so important to know these timing differences.
Regards
Bram van Kampen
|
|
|
|
|
Thanks Bram,
It is my pure technical interest to learn how internal things work, like compare. I appreciate your help all the time.
regards,
George
|
|
|
|
|