C / C++ / MFC

Re: bitwise command & MFC

12-Mar-02 13:24

Other than the "this" issue (which in many cases can improve speed given that it is passed around in ECX instead of on the stack and if you don't run out of registers during optimization), I have to agree that C++ can gernerally slow things down.

In some cases it is sloppy code such as using the C3dVector + operator between two vectors when all you really need to do is add a single value to one of the coordinates.

But I have also seen other performance problems usually involving templates. (Hint, those STL algorithms that some people love and adore can be drastically slower than hand-written loops. And I am not talking about hand optimized loops either.)

Tim Smith

I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?

SilverShalkin12-Mar-02 11:11

SilverShalkin

12-Mar-02 11:11

When i say engine, i mean, i use it to build the game "I know you know that." like use it to build a 2D game. its not a first person shootup or anything, "i would use c++ to do that"

So,.. your opinion on, should i use MFC or not, i think i should "personaly"

Thanks

~SilverShalkin

Rose | [Rose]

Cant think Frown | :(

bad when it comes to learning Smile | :)

Re: bitwise command & MFC

alex.barylski12-Mar-02 12:52

alex.barylski

12-Mar-02 12:52

If your game is just a single window I would avoid MFC, because it's not really nessecary and still carries quite a bit of overhead.

I imagine you save a bit of time avoiding the
CDC, CString etc...classes and just use SDK handles and such without much more effort on your part.

Cheers!

"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr

SDK

SilverShalkin12-Mar-02 15:31

SilverShalkin

12-Mar-02 15:31

HockeyDude wrote:
I imagine you save a bit of time avoiding the
CDC, CString etc...classes and just use SDK handles and such without much more effort on your part.

Confused | :confused:

What exactly is the SDK? "I am new, not stupid, just havent learned it yet"
But if you could tell me, i can look it up and learn how,

Thanks!

~SilverShalkin

Rose | [Rose]

The color swirl black on blue Rose | [Rose]

Tips of white, like angels hue Rose | [Rose]

touch is soft and full of life Rose | [Rose]

The Rose lay still, on thee ice Rose | [Rose]

Dustin Tigner Rose | [Rose]

Re: SDK

Rick York12-Mar-02 15:35

Rick York

12-Mar-02 15:35

It stands for System (or Software) Developer's Kit. In this context, it refers to the native API (Application Programming Interface) handles (like HDC, HPEN, etc.) and functions.

Re: SDK

alex.barylski12-Mar-02 16:13

alex.barylski

12-Mar-02 16:13

SDK-Software development kit

It's ummm basically the generic windows functions stored in the user32/gdi32/kernel dll's (i think).

Using C and the SDK will allow more direct control over what goes on around you. One abstraction level lower than what MFC provides (I think is how you would describe it) someone will coreect me if i'm wrong.

MFC is slower and clunky because it does it's own tests and such before calling the windows API(SDK) functions.

Once you understand what MFC is and how to use it...it makes sense in most cases, but for single window apps...I would say go will C/SDK programming. However if all you've done is use Classwizard and tools, creating your message pump and handler function and class registration might be a little more verbose than what your used to.

Try looking for simple SDK examples and you'll see what I mean.

"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr

Re: bitwise command

Merle Pittman12-Mar-02 5:00

Merle Pittman

12-Mar-02 5:00

very important for working with 'non-uniform' variable sizes through your code. For instance, if you want to combine two 8 bit chars into a 16 bit int you could use the MAKEWORD (a,b) macro provided in win32. But if you look at the source for this macro it uses bitwise operators to do so (actually uses a SHIFT and an OR):

WORD MAKEWORD(
  BYTE bLow,  // low-order byte of short value
  BYTE bHigh  // high-order byte of short value
);

MAKEWORD(a, b) \ 
    ((WORD) (((BYTE) (a)) | ((WORD) ((BYTE) (b))) << 8))

And many many other important uses.

- Merle

Getting focus to Activex control

Atila12-Mar-02 4:21

Atila

12-Mar-02 4:21

I can't make the my Activex control get focus in Word/Excel while using Normal view. When I turn view mode to design view it works.
Any suggestions ?

Re: multiple .cpp sharing same .h

Tomasz Sowinski12-Mar-02 4:04

Tomasz Sowinski

12-Mar-02 4:04

It's time to use 'extern' keyword:

// in .h file:
extern int x;

// in one of .cpp files:
int x;

Tomasz Sowinski -- http://www.shooltz.com

Re: multiple .cpp sharing same .h

567890123412-Mar-02 4:13

5678901234

12-Mar-02 4:13

Declare variable once in .cpp file:
int g_Var;
and define it in h-file:
extern int g_Var;
Variable will be available in the file where it is declared and in all .cpp files where h-file is included.
If you include h-file with extern definition to .cpp file with the same variable, it's OK for compiler:
extern int g_Var;
int g_Var;

The same with functions:
// .cpp file:
void MyFunction()
{
// ...
}

// .h file:
extern void MyFunction();

writing contents of a deque to a file

Merle Pittman12-Mar-02 3:44

Merle Pittman

12-Mar-02 3:44

Hi all,

I am attempting to use a deque as a frame buffer reading data from a serial port. When the entire frame is received, I want to use the frame buffer (the deque) to write the contents of the deque to a file, enpty the deque and start collecting data for the next frame.

The problem I am having is in writing the contents of the deque to a file. I have some experience writing to files, but I am unsure how to do this using a deque. How do I write the contents of the deque to a file??

If anyone has done this before (which I'm sure many have) could you give me a few hints.

Thanks

Merle

Joaquín M López Muñoz12-Mar-02 6:33

12-Mar-02 6:33

This writes a deque of ints to a file, one int per line. The extension to other types is straightworward (define the corresponding operator <<):

deque<int> dq;
...
ofstream ofs("whatever.out");
for(deque<int>::const_iterator it=dq.begin();it!=dq.end();++it){
  ofs<<(*it)<<endl;
}

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

PS: There are other, more STL-intensive ways to do this, involving inserters and stuff like that. I hope Christian will cover these subjects in his upcoming STL tutorials.

Nemanja Trifunovic12-Mar-02 7:05

Nemanja Trifunovic

12-Mar-02 7:05

Or, you can use copy

ostream_iterator <int> OsIt(ofs, " ");
copy (dq.begin(), dq.end(), OsIt);

I vote pro drink Beer | [beer]

Joaquín M López Muñoz12-Mar-02 8:04

12-Mar-02 8:04

so nice!

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

Nemanja Trifunovic12-Mar-02 8:43

Nemanja Trifunovic

12-Mar-02 8:43

Thanks.

Actually, whenever a loop is involved with STL, chances are that there is a generic alghoritm that would do the job.

I vote pro drink Beer | [beer]

Tim Smith12-Mar-02 12:01

12-Mar-02 12:01

Heh, just being annoying Smile | :)

FILE *fp = fopen ("whatever.out", "w");
for (deque<int>::const_iterator it=dq.begin();it!=dq.end();++it)
    fprintf (fp, "%d\n", *(it));
fclose (fp);

Tim Smith

I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?

Joaquín M López Muñoz12-Mar-02 19:50

12-Mar-02 19:50

Heh, just being annoying

You never are Smile | :)

What's the point of your code? This solution doesn't extend naturally to user-defined types. The iostream approach, on the other hand, could even be cast into a template function.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

Tim Smith13-Mar-02 2:03

13-Mar-02 2:03

Why should it?

You are only needing to serialize integers, not the world.

Use the right tool for the job.

Tim Smith

I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?

Joaquín M López Muñoz13-Mar-02 2:36

13-Mar-02 2:36

You are only needing to serialize integers, not the world.

I meant to use integers just as an exmple. The guy didn't specify which kind of data he's trying to serialize. As far as I know, his "frames" could be modelled by some user-defined type.

Use the right tool for the job.

I completely agree with you. But if you're accostumed to iostream library, printf-style functions add hardly any value or ease of use. Plus, they're more inefficient.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

Tim Smith13-Mar-02 4:13

13-Mar-02 4:13

Doh, you are right. You were the one who started talking about integers, not him.

But, he never said he wanted to use iostreams either. I use STL, but have never used iostreams because I have yet to see the benefits. I see the problem they are trying to correct with iostreams, but you tend to just trade one set of problems for another set.

As far as speed, iostreams are just a bit faster than fprintfs (1512ms compared to 1402ms). At least that is using the copy version. You can chop another 50ms off the iostream version by using a hand-written loop. However, if you don't use fprintf and just use a temporary scratch buffer formatting with itol, the time it takes to do it using fwrite drops to 781ms. Much faster than iostreams. Now, if you use the same trick with iostreams and pre-format the number into a temp buffer, the iostreams version only takes 591ms. Now, we are getting down to measuring each methods underlying performance. It seems that iostreams might have a better buffering system. Or is it. If you change the code slightly and print each integer on one line using endl and include an fflush in the fwrite version to be fair, the fwrite version now takes 3956ms where the iostreams version takes 17595ms.

So, how do the two methods compare? With the fprintf version, half your time is taken up with that fancy formatting string parsing and deciding how to format the value. In the case of iostreams there still seems to be an excessive amount of overhead just deciding how to format the value. When you compare the two, the extra overhead of parsing the fprintf format string is significant. Next, with the iostream version, it turns out those fancy STL algorithm bite us in the butt when it comes to performance. In this case we took around a 3-4% hit using them. This is consistent with other cases I have seen.

When you take all the fancy formatting out of the picture and just write raw strings to the file, performance for both the fprintf/fwrite version and the iostream version jumps significantly. However, the iostream version is still beating the fprintf/fwrite version. Or is it? It is important to remember that iostreams and fwrite operate slightly differently. If you have a case where you want to make sure the output is displayed on the screen, you have to use some type of flush (i.e. endl) with iostreams. Doing so incurs a huge hit in performance.

So, which one is faster? Neither. Depending on your application, fprintf/fwrite can be a bit slower or significantly faster. But it is also important to remember that in a real world application, the speed of the disk IO will greatly overshadow any differences in these two implementations. That is unless you do a lot of endls in iostreams when you really just need a CR. That flush can be a nasty killer.

Tim Smith

I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?

Joaquín M López Muñoz13-Mar-02 11:59

13-Mar-02 11:59

Hi Tim! Excuse me for not answering before, this message didn't make it to my mailbox. You've done a pretty impressive analysis to which I have little to add. Just two comments:

I've (overmerrily as it turns out) added the performance thing as the icing on the cake. The real benefit of the iostream library is type safeness. This can save hours of a programmer's precious debugging time.
That endl is an unforgivable mistake from me. Of course I should have used '\n' instead.

Regards.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

Tim Smith13-Mar-02 12:20

13-Mar-02 12:20

I got a failure notice on the email.

1. I would agree with this. But to be perfectly honest, when I goof up my printfs, it is usually quick to fix. But I would attribute that more to experience. That old CString in a printf bug can sink someone who has never see it for a LONG LONG time. Smile | :)

2. I was actually very very very shocked and a little suspect of the endl performance (or lack there of). There might be something else going on that isn't the fault of STL. Just as an FYI, I opened "NUL:" as my output file. I had to add ::app as an open flag with the output stream to get it to open. If it wasn't for that one small problem, it is a slam dunk that iostreams is faster. As is, iostreams are faster as long as you are careful.

One day people will learn to never mention that X is faster than Y around me. Because I will test it. I don't care who turns out to be wrong or right, I want solid figures.

Tim Smith

I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?

Nemanja Trifunovic13-Mar-02 12:31

Nemanja Trifunovic

13-Mar-02 12:31

Tim Smith wrote:
One day people will learn to never mention that X is faster than Y around me

And what do you think about this interesting article?

I vote pro drink Beer | [beer]

Tim Smith13-Mar-02 13:16