|
While binary format described by you is interesting it's not what I asked about.
I'll try creating one in the future nevertheless.
|
|
|
|
|
XML is very verbose and JSON doesn't have extendable types.
|
|
|
|
|
XML existed before JSON.
And data interchange formats benefit from being verbose. Due to readability; it's not a binary format.
Come to the point please.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
How does "XML existed before JSON" relate to either "XML is very verbose" or "JSON doesn't have extendable types"?
In which ways do "data interchange formats benefit from being verbose"?
Most users today do not read the raw data interchange format directly, as-is - they process it by software that e.g. highlights labels, closing tag etc, and allow collapsing of substrucures. When you pass it through software anyway, what impact on readability does the format of the input to this display processor have? With semantically identical information, but binary coded, as input to the display processor, why would the readabilty be better with a character encoding of the information rather than by a binary encoding?
|
|
|
|
|
Semantical bullshit, aka wordsmithing. I been on that train before.
You trying to do as if binary is the solution to formats; it's not. Anything, text or date, is stored as bits, and is thus in binary. ASCII is a representation of that, UTF is a better form of ASCII. Dates are stored as floats.
I don't care what university. You can either learn or be rediculed. And damn right I will, at every opportunity.
And yes, being "kind"
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
If you really want me to explain to you the difference between storing an integer, say, as a 32 bit binary number vs. storing it as a series of digit characters, bedayse "ASCII is bits, hence digital", then I give up. Sorry.
|
|
|
|
|
Member 7989122 wrote: If you really want me to explain to you the difference between storing an integer, say, as a 32 bit binary number vs. storing it as a series of digit characters I didn't say that; and not going to explain either. I've no need to, nor any desire.
Member 7989122 wrote: then I give up. Sorry.
Good timing. And please do.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
They are not good enough so I won't use it.
|
|
|
|
|
They might not be efficient to you; but lots of us use them, both, where appropriate.
Try to explain why XML isn't good enough, and to how many floppy-discs you're limited to that you need that optimization.
Do elaborate, please.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
You have several times in this thread more or less insisted on relating to (7-bit) ASCII and floppy disks. Noone else her care about either of those. If they are your frame of reference, then refer your experience to them. I don't care to. And I don't think it the effort to explain why not will be justified.
I am not (and I guess there are a few others agreeing) are not demanding of you that you critically assess you choice of data formats and other solutions. You may go on as you please, with the formats that pleases you, with or without any critical evaluation. You are welcome.
|
|
|
|
|
Not with or without critical evaluation, but an education.
One expects that a developer knows the different text-formats (and encodings, which is the same to you), data-formats, and date-formats. One who mixes those in a semantical bullshit argument gets called out.
So damn right I will. Either play your cards or fold.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I don't mean that I won't use XML/JSON. I think they are not good enough so I still want to create my data notation. It's just me saying that this is off topic (I used stackexchange sites before) and I just don't want to discuss it any farther (as it doesn't bring anything to my first question).
|
|
|
|
|
What does that have to do with anything? I merely pointed out that there are two existing, well tried and widely supported systems for data interchange. You can use them or not as you choose.
|
|
|
|
|
Well, pointing XML/JSON was off topic as well.
|
|
|
|
|
nedzadarek wrote: I want to create data notation (like JSON is used). So your mention of JSON in your original question was off topic?
|
|
|
|
|
I don't want to waste time on your trolling.
|
|
|
|
|
How is that trolling? As I said i made a couple of suggestions which you were free to ignore. I get the distinct impression (reading your other threads above) that you only came here for a fight.
|
|
|
|
|
Are you looking for something like protobuf?
Protocol buffers are a language-neutral, platform-neutral extensible mechanism for serializing structured data.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
How extensible are they? As far I can see they are at a "structure level" (I'm not sure if there is proper term for it; by "structure level" I mean extending some language with structures like in C in place of a type (joining few types together), for example (pseudocode): `qux: struct {foo: string, baz: integer}; qux new-variable = struct {foo: "***", baz: 42}`) or are they extensible at deeper level (parsing types, e.g. `new-type: <integer><"-"><integer>; new-type new-variable = 2-3)?
|
|
|
|
|
You having trouble extending a text-format?
Whatever uni you represent, I'll come take a piss on them. I'll even pay for it myself.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy. You're Dutch, not German, so you have no business paying for scat fetishes.
|
|
|
|
|
Living @500 m from Germany, dating German.
Scat fetishes? The hospital threaneted with a transplant.
So wanna talk sh*t? I got one of her books
--edit
I do. If I could, I'd sh*t on ya all day.
Chaoshit: Amazon.co.uk: Shitonya: 9789048400065: Books[^]
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Dating a German? Say no more! Like going to the doctor: "Open your mouth and say ahhh"
|
|
|
|
|
I am working with several products that communicate with each other through registers and when a new firmware release is made in any of the products, registers could have been added or discontinued. I was thinking of having something like this:
h-file:
#ifndef DONT_KNOW_IF_REG_IS_STILL_SUPPORTED_YOU_HAVE_TO_ASK
#define DONT_KNOW_IF_REG_IS_STILL_SUPPORTED_YOU_HAVE_TO_ASK (0xFF)
#endif
#ifndef REG_IS_NO_LONGER_SUPPORTED
#define REG_IS_NO_LONGER_SUPPORTED (0)
#endif
#ifndef REG_IS_STILL_SUPPORTED
#define REG_IS_STILL_SUPPORTED (1)
#endif
typedef struct __attribute__((__packed__)) {
uint8_t versionMajorFunc;
uint8_t versionMinorFunc;
uint8_t versionMajorBug;
uint8_t versionMinorBug;
uint8_t variant;
} versionAndVariant_s;
typedef struct __attribute__((__packed__)) {
uint32_t addr;
uint8_t versionMajorFuncRegWasIntroduced;
uint8_t versionMinorFuncRegWasIntroduced;
uint8_t versionMajorBugRegWasIntroduced;
uint8_t versionMinorBugRegWasIntroduced;
uint32_t supportedVariantsMask;
uint8_t isRegStillSupported;
} regSpec_s;
#ifndef IS_REG_COMPATIBLE
#define IS_REG_COMPATIBLE(__FW_VERSION_AND_VARIANT_PTR__,__REG_SPEC_PTR__) \
((((((uint32_t)(__REG_SPEC_PTR__)->versionMajorFunc) << 24) | \
(((uint32_t)(__REG_SPEC_PTR__)->versionMinorFunc) << 16) | \
(((uint32_t)(__REG_SPEC_PTR__)->versionMajorBug) << 8) | \
(((uint32_t)(__REG_SPEC_PTR__)->versionMinorBug) << 0)) <= \
((((uint32_t)(__FW_VERSION_AND_VARIANT_PTR__)->versionMajorFunc) << 24) | \
(((uint32_t)(__FW_VERSION_AND_VARIANT_PTR__)->versionMinorFunc) << 16) | \
(((uint32_t)(__FW_VERSION_AND_VARIANT_PTR__)->versionMajorBug) << 8) | \
(((uint32_t)(__FW_VERSION_AND_VARIANT_PTR__)->versionMinorBug) << 0))) && \
(0 < ((__REG_SPEC_PTR__)->supportedVariantsMask & VARIANT_TO_VARIANT_MASK((__FW_VERSION_AND_VARIANT_PTR__)->variant))) && \
(!(((__FW_VERSION_AND_VARIANT_PTR__)->versionMajorFunc == 0xFF) && \
((__FW_VERSION_AND_VARIANT_PTR__)->versionMinorFunc == 0xFF) && \
((__FW_VERSION_AND_VARIANT_PTR__)->versionMajorBug == 0xFF) && \
((__FW_VERSION_AND_VARIANT_PTR__)->versionMinorBug == 0xFF))))
#endif
extern const regSpec_s MY_REG_1;
extern const regSpec_s MY_REG_2; C-file:
const regSpec_s MY_REG_1 = {1000, 0, 0, 0, 4, ALL_VARIANTS_MASK, DONT_KNOW_IF_REG_IS_STILL_SUPPORTED_YOU_HAVE_TO_ASK};
const regSpec_s MY_REG_2 = {1002, 0, 0, 0, 4, ALL_VARIANTS_MASK, DONT_KNOW_IF_REG_IS_STILL_SUPPORTED_YOU_HAVE_TO_ASK};
In my code I would then first query the firmware version of the product I want to communicate with and then I can determine whether the register exists or not:
versionAndVariant_s* versionAndVariantOfOtherProduct = getVersionAndVariant(otherProduct);
if (!IS_REG_COMPATIBLE(versionAndVariantOfOtherProduct, &MY_REG_1)) {
return FALSE; }
if (MY_REG_1.isRegStillSupported == DONT_KNOW_IF_REG_IS_STILL_SUPPORTED_YOU_HAVE_TO_ASK) {
MY_REG_1.isRegStillSupported = isRegStillSupported(otherProduct, MY_REG_1.addr);
}
if (MY_REG_1.isRegStillSupported == REG_IS_NO_LONGER_SUPPORTED) {
return FALSE; } Any suggestions for improvements on this?
modified 13-May-20 6:57am.
|
|
|
|
|
I have 4 microcontrollers, A, B, D and E, that can communicate through registers that are exposed in h-files that reside inside Git submodules. A and B reside in the same box and can't be disconnected from each other so from a black box perspective they look like a combination of A and B that we can call C. D and E can be connected/disconnected during runtime from B, but they can also access A through B. E can also be connected/disconnected during runtime to D, which can then see B and A through D. Does anybody have suggestions on how many h-files I should have and what they should contain, in order to have an as clean design as possible?
modified 13-May-20 6:02am.
|
|
|
|