ReadFile() WriteFile()
in [Win32 API]
|
Prev: SymEnumSymbols is getting failed even GetLastError returns 0
Next: How to know function name by module version and logical address?
From: Leslie Milburn on 26 Mar 2010 05:54 "David Schwartz" <davids(a)webmaster.com> wrote in message news:9eff16ee-2cd6-4625-8d18-2fe7b9f78dc0(a)l40g2000pro.googlegroups.com... > > No, I said you did. You equated relying on guarantees in the language > with relying on things that specifically not guaranteed. Left to right versus right to left is NOT guaranteed, I have seen both. Neither is the view you hold that byte order might change in a different (even version) of a compiler. > > The problem does exist now. That your code relies on something that is > > not guaranteed is a failure -- and it's a failure *right* *now*. No it does not. The fact that the the format of the binary data would be fixed is not a problem. It is fixed and that *IS* guaranteed and thats all. > How do you know the OP isn't about to change compilers? You gave him > this advice with *no* warnings whatsoever. Do I dare refer to this as an assumption, yes I think so. Creating panic where there is none is a waste of time. Even if he is about to change compilers the byte order may or may not reverse - you are again assuming something unknown to be true. > I am being pragmatic. There is *no* advantage to your suggested method > and huge disadvantages. There is no disadvantage to having a fixed file format, other than it is fixed. Again, That is all. I strongly think you have not been around for as long as you claim, your attitude is one I would expect from a far less experienced programmer. > Suggesting it is as pragmatic as giving a chainsaw to 7 year old. Yet another overreaction. Surely you are joking here, then again your track record for overreactions is 100% as it stands. > I really hope the people who build bridges and design buildings take > their job responsibilities more seriously than you do. Probably more so than you. I would hate to be working with you, the stress would be amazing. How hard must life be for you to always feel that you have to come up with the ultimate perfect solution solving all known problems plus all those unknown problems to come at any possible time in the future. I hope 10 years ago your code was Windows 7 compliant, No ? Really ! Well what a surprise! Get off your high horse !! > Obviously, you will continue to write sucky software and give bad > advice no matter what I say. So long as you continue to do so, I'll > continue to warn people not to listen to you. BTW: The original advice was not mine - did you even check that, No I didn't think so ? So let me state clearly - there is no problem writing binary data to a file with a fixed format. It can always be retrieved because its format *IS* known, thats the point. As to writing buggy software, really, you think so - or is this another assumption, Yes I think so yet again. > And it would take the same amount of time to do it in text or lift a > good configuration library. My god, talk about using a hammer to crack an egg. You are out of touch. > It doesn't take any longer or cost any more to do it the right way. How arrogant, so your way is the right way and everyone else is wrong, yes ? What garbage ! > All it takes is the good sense to realize that what you are saying is > simply *wrong*. It is wrong to rely on behavior that is not guaranteed > -- we do it where we have no other reasonable choice and we *document* > that decision *every* *place* we make it. What behaviour am I relying upon that is not guaranteed. A defined fixed file format *IS* guaranteed. I do not know how much clearer I can state this fact. > And even if you had, you wouldn't have listed to what I said anyway. Even here we disagree. I would listen to you and (in this case) tell you why you are wrong, that you are a panic merchant, that you are wasting the project budget and would suggest you have a nice lie down and have a think. There is nothing more to add here, other than to state yet again there is no problem with fixed format data files. The contents are in a *guaranteed* format and can be retrieved *trivially.* You are simply wrong !!!!!!!!
From: David Schwartz on 26 Mar 2010 06:41 On Mar 26, 2:37 am, "Alf P. Steinbach" <al...(a)start.no> wrote: > Sorry, no, that's incorrect (in context): basic data representation is not a > problem for a given OS such as Windows, which is what this group is about.. Really? So there have never been Windows versions that used different byte orders? And there has never been Windows code that was difficult to port to newer Windows platforms? Really? > It's the OS' API that determines int representation etc., not the language. If you use types that are not used in the OS API, they can change with the language and/or compiler. That's why Microsoft created types like DWORD and LARGE_INTEGER -- they had defined byte representations and were part of the OS API. In any event, it's completely foolish to gratuitously use types that don't have defined byte representations when there are trivially available types that do. DS
From: Alf P. Steinbach on 26 Mar 2010 06:46 * David Schwartz: > On Mar 26, 2:37 am, "Alf P. Steinbach" <al...(a)start.no> wrote: > >> Sorry, no, that's incorrect (in context): basic data representation is not a >> problem for a given OS such as Windows, which is what this group is about. > > Really? So there have never been Windows versions that used different > byte orders? And there has never been Windows code that was difficult > to port to newer Windows platforms? Really? Demonstrate how that, in your opinion, is (1) relevant, and (2) a problem. Post the explanation to yourself. I'm sorry but you're just articulating nonsense. >> It's the OS' API that determines int representation etc., not the language. > > If you use types that are not used in the OS API, they can change with > the language and/or compiler. That's why Microsoft created types like > DWORD and LARGE_INTEGER -- they had defined byte representations and > were part of the OS API. > > In any event, it's completely foolish to gratuitously use types that > don't have defined byte representations when there are trivially > available types that do. Again, that's utter nonsense, sorry. Cheers & hth., - Alf
From: Piranha on 26 Mar 2010 09:39 On 26 Mrz., 10:54, "Leslie Milburn" <CD...(a)NOSPAM.bigpond.com> wrote: > "David Schwartz" <dav...(a)webmaster.com> wrote in message > > news:9eff16ee-2cd6-4625-8d18-2fe7b9f78dc0(a)l40g2000pro.googlegroups.com... > > > > > No, I said you did. You equated relying on guarantees in the language > > with relying on things that specifically not guaranteed. > > Left to right versus right to left is NOT guaranteed, I have seen both. > Neither is the view you hold that byte order might change in a different > (even version) of a compiler. > > > > The problem does exist now. That your code relies on something that is > > > not guaranteed is a failure -- and it's a failure *right* *now*. > > No it does not. The fact that the the format of the binary data would be > fixed is not a problem. It is fixed and that *IS* guaranteed and thats all. > > > How do you know the OP isn't about to change compilers? You gave him > > this advice with *no* warnings whatsoever. > > Do I dare refer to this as an assumption, yes I think so. Creating panic > where there is none is a waste of time. Even if he is about to change > compilers the byte order may or may not reverse - you are again assuming > something unknown to be true. > > > I am being pragmatic. There is *no* advantage to your suggested method > > and huge disadvantages. > > There is no disadvantage to having a fixed file format, other than it is > fixed. Again, That is all. I strongly think you have not been around for as > long as you claim, your attitude is one I would expect from a far less > experienced programmer. > > > Suggesting it is as pragmatic as giving a chainsaw to 7 year old. > > Yet another overreaction. Surely you are joking here, then again your track > record for overreactions is 100% as it stands. > > > I really hope the people who build bridges and design buildings take > > their job responsibilities more seriously than you do. > > Probably more so than you. I would hate to be working with you, the stress > would be amazing. How hard must life be for you to always feel that you have > to come up with the ultimate perfect solution solving all known problems > plus all those unknown problems to come at any possible time in the future. > I hope 10 years ago your code was Windows 7 compliant, No ? Really ! Well > what a surprise! Get off your high horse !! > > > Obviously, you will continue to write sucky software and give bad > > advice no matter what I say. So long as you continue to do so, I'll > > continue to warn people not to listen to you. > > BTW: The original advice was not mine - did you even check that, No I didn't > think so ? So let me state clearly - there is no problem writing binary data > to a file with a fixed format. It can always be retrieved because its format > *IS* known, thats the point. > > As to writing buggy software, really, you think so - or is this another > assumption, Yes I think so yet again. > > > And it would take the same amount of time to do it in text or lift a > > good configuration library. > > My god, talk about using a hammer to crack an egg. You are out of touch. > > > It doesn't take any longer or cost any more to do it the right way. > > How arrogant, so your way is the right way and everyone else is wrong, yes ? > What garbage ! > > > All it takes is the good sense to realize that what you are saying is > > simply *wrong*. It is wrong to rely on behavior that is not guaranteed > > -- we do it where we have no other reasonable choice and we *document* > > that decision *every* *place* we make it. > > What behaviour am I relying upon that is not guaranteed. A defined fixed > file format *IS* guaranteed. I do not know how much clearer I can state this > fact. > > > And even if you had, you wouldn't have listed to what I said anyway. > > Even here we disagree. I would listen to you and (in this case) tell you why > you are wrong, that you are a panic merchant, that you are wasting the > project budget and would suggest you have a nice lie down and have a think. > > There is nothing more to add here, other than to state yet again there is no > problem with fixed format data files. The contents are in a *guaranteed* > format and can be retrieved *trivially.* > > You are simply wrong !!!!!!!! Wow, I didn´t mean to cause such an argument here. If it helps anyone, my whole purpose of asking was to make a first step into something new, which in this case is binary data, or better mixing text and binary. I ment to figure out, how to read and write data to a file or how to exchange data between applications, without being restricted to text, where my original idea was converting everything to text, while I learned here that binary is the better choice. There is no porting or anything, there isn´t even an application using it, other than a test project, where I´m messing around for no further purpose than learning how it works. I apreciate all the input, I apreciate hints to possible problems in case I wanted to make portable code out of it, I´ll keep it in mind for the future, but as of right now, I´m fully satisfied with the weakest possible solution, all that matters in the first step of learning is, a piece of code that doesn´t produce a ton of compiler errors. So thanks to everyone for the useful help, and you may all calm down now ;-)
From: Jag on 27 Mar 2010 20:57
Hi, You could also use Boost's Serialization classes to serialize arbitrary objects. UNT, Jag |