|
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
|
|
|
|
|
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.
|
|
|
|
|
Or, you can use copy
ostream_iterator <int> OsIt(ofs, " ");
copy (dq.begin(), dq.end(), OsIt);
I vote pro drink ![Beer | [beer]](https://www.codeproject.com/script/Forums/Images/beer.gif)
|
|
|
|
|
so nice! 
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
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
|
|
|
|
|
Heh, just being annoying
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?
|
|
|
|
|
Heh, just being annoying
You never are
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
|
|
|
|
|
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?
|
|
|
|
|
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
|
|
|
|
|
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?
|
|
|
|
|
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
|
|
|
|
|
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.
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?
|
|
|
|
|
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
|
|
|
|
|
Without reading it, my first thought is that without some hard numbers, it is really hard to say what performs well and what doesn't. When I have a chance I will read it.
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?
|
|
|
|
|
Oh dear god, I just read some of the code and the guy has made some huge mistakes already (i.e. since when does a constructor allocate memory for itself).
I just read more. It makes me wonder what sucky ass compiler he is using. A lot of the stuff he talks about doesn't even apply to VC. For example, VC uses ECX to pass around the this pointer. Thus, as long as you are calling methods within the same class instance, you get a performance boost since you aren't having to push 'this' around. However, if register allocation gets a little tight, you might see this stuck in ESI, EDI, or event on the stack as a local variable (probably any register will be used, I just see ESI and EDI used a lot).
Another example is his v-table. VC uses thunking to get around the multiple inheritence problem. So, when you don't have multiple inheritence, there isn't any performance hit over and above the fetching of the routine address from the v-table. Also, there isn't a performance hit if you are invoking a method for the first base class in the list. All the thunk code it a test for this == NULL, if not, then it is adjust by an offset and then a simple JMP to the real routine.
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?
|
|
|
|
|
Hi,
it´s my recording session again  : I need the accelerator character of a toolbar button.
Does anyone know how to retrieve the character if you only have the button id?
Regards,
Amar Bouchibane
|
|
|
|
|
If in a doc/view app, GetParentFrame()->m_hAccelTable is a HACEL handle to the current accelerator table. Use <a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/CommCtls/winui/keybacel_5r39.asp">CopyAcceleratorTable</a> to dump this table into an array of ACCELs structures and look for the accelerator you're after.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Thanks, Joaquín!
But when I try this...
CFrameWnd* pFrWnd = pToolbar->GetParentFrame();
HACCEL hAccl = pFrWnd->m_hAccelTable;
...
pFrWnd is null. What I´m doing wrong?
(pToolbar is a pointer to a CToolBarCtrl)
|
|
|
|
|
Ummm... Please try AfxGetMainWnd instead.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
AfxGetMainWnd() returns always NULL.
Does only the frame window holds the pointer to the active accelerator table?
Or is there any other place where I can find the HACCEL handle?
For you to remind... I have to program a windows recorder, that is I need information about all the accelerator hotkeys of the foreground window where my recorder´s embedded in.
Best regards,
Amar
|
|
|
|
|
I have a number of MFC applications that use form views to enter data into a database. These all use static lib MFC.
I have a number of forms that are needed in more than one application. What is the best way of sharing resources and their associated CFormView derived classes across projects.
In the past I've used MFC Extension DLLs but keeping the resource id's in different ranges became a pain.
Would one resource DLL for all the applications be a good idea (The apps are all part of one product)?
Suggestions?
Michael 
|
|
|
|
|
There's an additional option that (IMHO) simplifies things further. Why not have resources and its additional CDlg-derived classes inside a regular MFC DLL and export a high-level C API along this line:
int PersonalDataDialog(PERSONA_DATA_STRUCT *pPersonalData); If you can follow this scheme, I'd say it is the most easily maintainable approach.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Michael P Butler wrote:
In the past I've used MFC Extension DLLs but keeping the resource id's in different ranges became a pain.
There's a tool created by Andy Metcalfe called Resource Organizer.
Michael P Butler wrote:
Would one resource DLL for all the applications be a good idea (The apps are all part of one product)?
This has the advantage when you plan to have multiple language versions of your product.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
I do that when work with diferent languages.
I put the resource into dlls, and share it from the dll....
Regards
Carlos Antollini.
Sonork ID 100.10529 cantollini
|
|
|
|
|
I'm sure this is a basic interface mistake, but if anyone could shed some light on it I'd be very grateful.
I've got an existing dialog with 5 radio buttons on it, I need to put on a sixth radio button, but when I do I can have the new one selected with one of the others selected (instead of only one as intended). Can anyone let me know how to get this new radio button to be part of the group that the others are in?
TIA
Dylan Kenneally
London,UK
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
