This all boils down to requirements, and nothing has been offered by the OP except for "I need to write it fast." There is nothing to do with hardware here - it might be another requirement.
What spun off this sub-thread of the discussion was
Joe Woodbury wrote:
If the data needs to be future proofed, consider serializing using RapidJSON (which is a very fast C++ JSON library), compressing the result with LZ4 and then writing that.
"Future proof" was not stated as a requirement, but now that Joe Woodbury presented what is - in my eyes - a rather naive approach to future proofing, I chose to point out that if you want future proofing, it takes a lot more than just using a basic structure encoding that is currently fashonable.
It seems quite obvious that Joe Woodbury has never been working in the area of long time information preservation. I have a few years of experience. I know that it is not a trivial issue. When someone makes a statement that suggests "Just use JSON and LZ4, and the information is safe for the future", I think that this is so naive that it crosses the border to "fake news", and I want to correct it.
However, Joe Woodbury is not willing to accept anything that can affect the validity of his claim, calling my comments a "rant", "senseless and unproductive", that I am "mixing up" things by pointing to other important elements, that I am "just repeating the obvious".
I wrote "Be preparered for some information loss during each move". When Joe Woodbury stated "JSON is one step above key/value pairs--how would you lose information?", I went on to provide examples. Then he comes back with "You also shifted your argument; you went from you will lose information to you can lose information", and concludes "Your straw man collection is now complete!"
I don't think anything valuable will come out of a further discussion with Joe Woodbury. So I let it rest.
What regards "just document it": I have seen guides seriously suggesting a URL to visit if you have problems connecting to the Internet. I have seen document format descriptions stored electronically in the format that is described. I have seen format "documentation" that is hopelessly inadequate - having worked with the format for a long time gives the documentation some value, but often you need access to the format designer to have him explain it. I have format descriptions on 5.25" floppies. Are you able to imagine that there could be a complete breakdown of the Internet? How much of the format descriptions would then be inaccessible?
Documenting the format is a neccesary, but not sufficient provision for the data to be accessible in the future: The documentation must unconditionally be available to the person who needs to decode some data. That takes a lot more than just JSON or something similar; it takes a full storage stack all the way down to the physical medium. That could be a physical printout, on acid free paper. How many format specifications do you currently have in a printed format on acid free paper? I've got a couple printed ones, but I am not sure that the paper will survive that many years.
One of the format descriptions I have in print is for a 30+ year old format; the manufacturer went bankrupt 28 years ago and the format description was only available internally. The format was used for tens or hundreds of thousands of documents that are still residing in old archives around the contry. If someone need to access one of these documents, how would they know that they could come to me for the format descriptions? I have asked a few of my co-workers from the early 1980s if they have kept the specification document; I haven't met one that has. It could be that my copy is the last one in existence (at least in an immediately available format - the electronic version of the format was written in its own format).
So your requirement about documenting the format is satisfied. When you need to decode a document file in that format, just come to me. Problem solved. Or...?
Without testing it, I'd say it won't time out. Some value has to be used as INFINITE, and the maximum unsigned value is a good choice. Writing the code so that it never expires isn't difficult; it's not like something is going to wake up and decrement it every millisecond.
0xFFFF is a value which is literally NOT "passed". That is, it's something like a zero ("0") used in the BIOS that a user can select/type as input which, under advanced CPU settings for example, signals that "ALL" cores are to be used (say there are 16 cores). Which is not to say that 1, 2, 3, 4, etc cores can take zero's place in the control for the specific input value.
It seems contrary to common sense use that a real value can be used to represent a ceiling or a floor as such but when it is the case, generally there's a typed message/note to the substitution next to such a control.
Supose two matrices are there a and b we scanned the element in a matrix and b is the transpose of former . NOW
when we write a code to assign the values we use
but when we do b[j][i]=a[i][j] it gives a wrong result why? since in both the cases all assigning cases are same.
This should be very easy to trace in a debugger. You don't even tell in which way the result is wrong, and you do not show the declaration to fhe two matrices, so there is really not much information to make a qualified guess.
So you wanted to print the value of b[i][j] after you updated b[j][i]?
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
I have an existing MFC application in which there are many tags that changes continuously.
I have to show the value of 2 tags which changes dynamically. I have to plot an XY plot for the tags in a separate dialog or window in the existing MFC application.
Please suggest me some easiest or quickest ways of doing the above task.
There are many good articles about drawing in mfc - which is really pretty much Win32. Rather than have that magical moment where you get it running and it flickers constantly, make sure to look into double buffering with a bitmap.
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759