|
You can also use an union:
#include <iostream>
using namespace std;
union Char2int
{
unsigned char tempChar[8];
unsigned int tempInt[2];
};
int _tmain(int argc, _TCHAR* argv[])
{
Char2int c2i;
c2i.tempChar[0] = 0x33;
c2i.tempChar[1] = 0x22;
c2i.tempChar[2] = 0x11;
c2i.tempChar[3] = 0x00;
c2i.tempChar[4] = 0x77;
c2i.tempChar[5] = 0x66;
c2i.tempChar[6] = 0x55;
c2i.tempChar[7] = 0x44;
for (int i = 0; i < 2; ++i)
wcout << std::hex << c2i.tempInt[i] << endl;
return 0;
}
"We make a living by what we get, we make a life by what we give." --Winston Churchill
-- modified at 11:45 Wednesday 31st October, 2007
|
|
|
|
|
Thanks George and everyone else for their help....this is exactly what I was looking for in order to save processing time.
|
|
|
|
|
As I interpret your initial post, you may not get what you want with the proposed union solution.
NYTSX wrote:
tempChar[0] = 0x00;
tempChar[1] = 0x11;
tempChar[2] = 0x22;
tempChar[3] = 0x33;
tempChar[4] = 0x44;
tempChar[5] = 0x55;
tempChar[6] = 0x66;
tempChar[7] = 0x77;
This would in all systems, regardless of byte ordering, generate the following memory contents:
00 11 22 33 44 55 66 77
If you convert the memory contents above to two adjacent 32-bit integers you will, on a little-endian system like most systems running windows, get 0x33221100 and 0x77665544.
NYTSX wrote: how do I get
tempInt[0] = 0x00112233;
tempInt[1] = 0x44556677;
My point is that the union solution will work on a big-endian system, but not on a little-endian system in terms of how I interpret your question.
To make a portable solution you would have to walk through the char array, one element at a time, and shift the integer value like Nelek suggested.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote "High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Remember that the code above is not portable, and you should comment your code that it is so!
"We make a living by what we get, we make a life by what we give." --Winston Churchill
|
|
|
|
|
George L. Jackson wrote: Remember that the code above is not portable...
But since this forum is for VC++ code, and nothing was even remotely mentioned about portability, does it matter?
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Your right. The poster is happy. I am happy he is happy. So, don't worry. Be happy!
"We make a living by what we get, we make a life by what we give." --Winston Churchill
|
|
|
|
|
A simple casting should do the trick:
int* tempInt = (int*)tempChar;
But be carefull with byte ordering ! As the bytes are stored in an inverted way in memory. It means that if you have those bytes in memory:
0x00 0x00 0x00 0x01
And you interprete those bytes as an integer (like you will do with the cast), the resulting integer value won't be one (but 0x01000000).
|
|
|
|
|
Cedric Moonen wrote: As the bytes are stored in an inverted way in memory
partially right. all depends of the system.
but one should always care about bytes order anyway
|
|
|
|
|
union is the best, because you can save some processin time the shift operator would consume...
|
|
|
|
|
int *tip;
tip = (int *) tempChar;
|
|
|
|
|
I a CDialog based application which has approx 30 CBitmapButtons and 30 CStatic text boxes. I'm receiving data at about 20hz which is causing the screen to flicker badly when these are getting repopulated. I've looked at the usual ways of stopping/reducing the flicker (overloading OnEraseBkgnd, using InvalidateRect ( rect, FALSE ), Invalidate (FALSE), etc...) with no luck. Does anyone have any ideas how I can overcome this? One idea I've had is buffering the entire dialog before painting it, however I can only find examples on how to do this with bitmap controls rather than an entire dialog with controls.
TIA,
Andy
|
|
|
|
|
I would look into updating the controls without redrawing the entire dialog
(especially its background) every time data is updated.
Also limiting the update region(s) to just areas that change helps alot.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Hi Thanks for your reply. I've delved further into this now and have found that the flickering is due (or at least appears to be due) to the fact that I have controls on top of each other, an example is that I will have a Group Box with a CEdit control inside of it, when they are seperate they don't flicker when combined they do. I'm using the Group box to provide a border effect to the CEdit control as none of the built in border styles are suitable, so if I can get an identicle border in another way then my problem may be sorted! Do you have any ideas on how to do this?
cheers,
Andy
|
|
|
|
|
well sort of the answer, further to my above post, I've got rid of the group boxes and changed the style of the CEdit controls to have the Border, Modal Frame and Static Edge set to TRUE. Although this border is thicker than I wanted it is better to look at than a flickering screen!
Any suggestions on how to make this border thinner would be great
Andy,
|
|
|
|
|
mcsherry wrote: Any suggestions...
No
I'm still wondering why the groupbox causes flicker. Is it just a Z-order thing?
If you set the tab order, the groupbox should be before any controls "inside" it.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
i have two 8 bit 256 color images, they have different color palette, i want to replace some pixels of one image with other image's pixels. how can i do it since they have different palette?
or i can describe the question with another way: also with the two images, i want to splice them together, how can do it with VC++?
thanks
|
|
|
|
|
if you don't or can't change the palette of the destination image, you'll have to use a method to take the color from the source image and find the closest color in the destination palette.
or, you could covert them all to RGB-24, combine the images, then use a color quantization and dithering function convert the result back to the palette you need.
splicing images depends on the format of the pixels in memory.
your best bet is to use one of the many image processing toolkits that are available.
|
|
|
|
|
thanks Chris Losinger, you have given me a big help!
|
|
|
|
|
Hello,
I have made an easy appliction using MFC, i sent only executable application to my friend, but the application is not working for him, and i found out that He doesnt have installed Visual c++ on his computer.
Does he have to install visual c++? or he need only mfc dll files, if so, which dll files?
thanks
|
|
|
|
|
Which version of Visual Studio did you use for the development ?
|
|
|
|
|
|
He'll need the MFC dlls plus any others that your program uses. There's a Visual Studio tool called 'depends.exe' which will tell you the Dlls that are loaded up automagically when the application starts (like msvcrt.dll for example) For any others you'll need to look for LoadLibrary calls in your code. Remember he'll already have most of those in your list as part of Windows so don't go overwriting vital items on his machine
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Please refer here[^].
Regards,
Paresh.
|
|
|
|
|
Hello,
I just made simple application using MFC database classes, so, then i have to move every MFC dll files, that is crazy, because my application is 500 kb, it will be 15 mb with MFC dlls, why every do i have to move the dlls?
what would u recommend me?
thanks
|
|
|
|
|
Gofur Halmurat wrote: why every do i have to move the dlls?
Because you're using code inside those DLLs by virtue of using an MFC database class. The code has to exist somewhere. By dynamically linking to MFC, the code is in the DLL which must be present on the executing machine. If you statically link, the code is pulled into your EXE and comes along for the ride when you move the executable to the executing machine.
Judy
|
|
|
|