>Disclaimer: This library is not related to the MISRA C standard or guidelines. The name "MisraStdC" comes from the author's name, Siddharth Mishra, who is commonly known as "Misra" among friends.
Why include the letters Std then? This seems like a purposeful typo-squatting effort and definitely makes me suspicious.
yep, glad you pointed that out. To explain a bit more : MisraStdC is 3 parts : Misra + Std + C - Misra is derived from my name. That's why I needed to specify that the repo is not related to the MISRA standard.
Did you really take the name mishra and make it into misra.h then call your library MisraStdC and expect people to believe the confusion isn't intentional? This whole thing feels incredibly dishonest.
Ok I'm saying this for the last time so I'll over-explain so everyone can follow the idea properly.
Not all people can pronounce names correctly. In a language some names are easier to pronounce if you take away a few letters. Some may find using Sid as short form for Siddharth, because it's just easier.
Now from my childhood, some friends used to pronounce my name differently. I noticed that they don't use the 'h' in Mishra, so I started using 'Misra' instead. They found it easier to pronounce and I felt connected more. Those who could pronounce it correctly, still used Misra because it's just easier and sounds more personal. Friends and loved ones do that. It's also sometimes called as a nickname, where you give other names to a loved one.
Now, it also just happens that my native language has the same root word for Misra and Mishra aaaand they mean the same! It essentially means a mixture of different things.
Now even if all this this reason does not sound good to you, just ignore it. It is my project, my name. I can pronounce however I want, with whatever spelling I want. A project is named by it's maintainer. I can name it exactly MISRA and still be happy with it because it's my project, I'm the maintainer.
I did mention that this is not related to the MISRA standard because I felt like users should know and not confuse it with my library.
I tried to ignore this matter but people over internet just keep poking you saying you're dishonest. Please don't bother yourself with the name of things, just use it if you need it otherwise ignore it. It's an advice for life. Name of things does not matter, it's what they do and achieve. I've put honest work into this library and I won't accept someone sitting behind a screen just say that I'm dishonest, I'm purposefully choosing this name. It is my name, I chose it, names clash in this world at least. Two entities can have same name but of different origin and use case.
I'd say "mostly C11": it uses __VA_OPT__ that's been standardized only in C23.
The "foreach" macros need a lot of refinement: passing the body in the parameters is asking for troubles, for example. And using a non-unique default name for the index prevents nested loops.
To overcome the issues with generic and qualified types, have you considered using typeof_unqual?
Yea the FMT trick uses VA_OPT. I consider myself a noob with C official specification, so you're probably right about that.
I do kinda like how foreach is implemented right now. This allows me to perform some strict checking for easy loop iteration based bugs and also it kinda looks cool.
This is the first time I came across typeof_unqual. I'll look into it, thanks .
I spent a lot of time making this work across all three compilers (especially MSVC). I'm glad MSVC has VA_OPT support.
> I do kinda like how foreach is implemented right now. This allows me to perform some strict checking for easy loop iteration based bugs and also it kinda looks cool.
Yes but the body in the parameters really is a show stopper. What if the body has a unprotected comma? Like
VecForeach(&v, e, {
int x, y;
...
});
Better to expand the macro into one or two "for" and let the body follow. For example:
#define VecForeachIdx(v, var, idx)\
for (size idx=0,_d=1; ValidateVec(v),_d; _d--)\
for (VEC_DATATYPE(v) var={}; idx<(v)->length && (var=VecAt(v,idx),1); idx++)
How would you implement 'var = ...' while respecting that 'VecAt(...)' could return 0?
I am currently working on a similar problem and can't seem do seem figure out how to handle these for-loops and setting the iterator properly.
That sounds like a better idea. I'll test it. Debugging with my existing macros is a PITA, but if your suggestion works then it'll work well with debuggers as well!
Thanks :)
I especially am in love with how my formatted printer works. It's not a completely new solution and I think people have already done that. I'll also say that it's not very mature but it makes life a lot easier in some cases.
What disturbs me is the need to Init() everything. In the Vec type (the only one I've analyzed, actually) all it does is to fill everything with zeros and add a "magic" field certifying that the initialization happened. So why don't simply fill everything with zeros, which can be achieved with ={} if you're super modern or ={0} if you're not, and then drop the check for the magic field? Of course that wouldn't detect a missing intialization, but neither is it detected for any standard type.
It is a bit crazy but forcing this kinda makes a habit. That way, a habitual user will tend to initialize other variable types as well.
That's why I call it a standard, because the library has its own coding style. Take the ownership semantics explained in concepts section of README for example. I provide a way to very clearly specify ownership.
Also the init() instantly detects bugs related to uninitialized struts. When they do happen, sometimes very deep in the code they take a lot of time.
This is also one of the reasons why there are so many ValidateX checks in implementation code. Try to catch bugs faster.
I agree, C++ code compilation is generally slower compared to C. But the compiler itself isn't particularity slower (under the hood it's the same compiler), but compiling C++ code with a lot of templates is slow.
For me personally compilation slowdown is just a price, which I am ready to pay for more language features, including better abstractions and type safety.
>Disclaimer: This library is not related to the MISRA C standard or guidelines. The name "MisraStdC" comes from the author's name, Siddharth Mishra, who is commonly known as "Misra" among friends.
Why include the letters Std then? This seems like a purposeful typo-squatting effort and definitely makes me suspicious.
Wow! Thanks for pointing that out, so misleading…
yep, glad you pointed that out. To explain a bit more : MisraStdC is 3 parts : Misra + Std + C - Misra is derived from my name. That's why I needed to specify that the repo is not related to the MISRA standard.
How does MisraStdC = Siddharth Mishra?
Misra and not Mishra? You randomly drop the h? And it just so happens dropping the H makes it a typo squat basically.
Siddharth has a T after the D. So std should be sdt.. at best.
Just be honest lol
Std is short for standard :-) It's pretty std.
That doesn't explain the worst part though. Why drop a random H?
You do understand people's concern here though right?
Because it seems like you're being purposefully obtuse at this point.
Thanks for the clarification but it makes zero sense
because it's my personal standard. I use it more than I use standard C utils.
Did you really take the name mishra and make it into misra.h then call your library MisraStdC and expect people to believe the confusion isn't intentional? This whole thing feels incredibly dishonest.
Ok I'm saying this for the last time so I'll over-explain so everyone can follow the idea properly.
Not all people can pronounce names correctly. In a language some names are easier to pronounce if you take away a few letters. Some may find using Sid as short form for Siddharth, because it's just easier.
Now from my childhood, some friends used to pronounce my name differently. I noticed that they don't use the 'h' in Mishra, so I started using 'Misra' instead. They found it easier to pronounce and I felt connected more. Those who could pronounce it correctly, still used Misra because it's just easier and sounds more personal. Friends and loved ones do that. It's also sometimes called as a nickname, where you give other names to a loved one.
Now, it also just happens that my native language has the same root word for Misra and Mishra aaaand they mean the same! It essentially means a mixture of different things.
Now even if all this this reason does not sound good to you, just ignore it. It is my project, my name. I can pronounce however I want, with whatever spelling I want. A project is named by it's maintainer. I can name it exactly MISRA and still be happy with it because it's my project, I'm the maintainer.
I did mention that this is not related to the MISRA standard because I felt like users should know and not confuse it with my library.
I tried to ignore this matter but people over internet just keep poking you saying you're dishonest. Please don't bother yourself with the name of things, just use it if you need it otherwise ignore it. It's an advice for life. Name of things does not matter, it's what they do and achieve. I've put honest work into this library and I won't accept someone sitting behind a screen just say that I'm dishonest, I'm purposefully choosing this name. It is my name, I chose it, names clash in this world at least. Two entities can have same name but of different origin and use case.
Thanks for reading this if you read it till here.
I tried to ignore this matter but people over internet just keep poking
Did you really think naming something MisraStdC, then posting it to the internet, then rationalizing it wouldn't be noticed?
It's not even your name or a standard.
It really looks like you are trying to name it something that people would find from searches then somehow walk it back and come with a story after.
While I do think there might be some squatting here, I have to defend that dropping the h is also a common spelling of that name.
> A modern C11 library
I'd say "mostly C11": it uses __VA_OPT__ that's been standardized only in C23.
The "foreach" macros need a lot of refinement: passing the body in the parameters is asking for troubles, for example. And using a non-unique default name for the index prevents nested loops.
To overcome the issues with generic and qualified types, have you considered using typeof_unqual?
Yea the FMT trick uses VA_OPT. I consider myself a noob with C official specification, so you're probably right about that.
I do kinda like how foreach is implemented right now. This allows me to perform some strict checking for easy loop iteration based bugs and also it kinda looks cool.
This is the first time I came across typeof_unqual. I'll look into it, thanks .
I spent a lot of time making this work across all three compilers (especially MSVC). I'm glad MSVC has VA_OPT support.
> I do kinda like how foreach is implemented right now. This allows me to perform some strict checking for easy loop iteration based bugs and also it kinda looks cool.
Yes but the body in the parameters really is a show stopper. What if the body has a unprotected comma? Like
Better to expand the macro into one or two "for" and let the body follow. For example: Please note that I haven't tested it.How would you implement 'var = ...' while respecting that 'VecAt(...)' could return 0? I am currently working on a similar problem and can't seem do seem figure out how to handle these for-loops and setting the iterator properly.
The ",1" ignores var and keeps 1.
That sounds like a better idea. I'll test it. Debugging with my existing macros is a PITA, but if your suggestion works then it'll work well with debuggers as well! Thanks :)
> brightprogrammer
There can be only one.
That’s what I was thinking seeing the username =)
It's an honor to have you comment here .
Thank you for the kind words!
been working on this for some time. has some usable features. i keep adding as i feel the need. try to well document everything and maintain it.
I especially am in love with how my formatted printer works. It's not a completely new solution and I think people have already done that. I'll also say that it's not very mature but it makes life a lot easier in some cases.
One example is me parsing HTTP headers: https://github.com/brightprogrammer/beam/blob/master/Source%...
What disturbs me is the need to Init() everything. In the Vec type (the only one I've analyzed, actually) all it does is to fill everything with zeros and add a "magic" field certifying that the initialization happened. So why don't simply fill everything with zeros, which can be achieved with ={} if you're super modern or ={0} if you're not, and then drop the check for the magic field? Of course that wouldn't detect a missing intialization, but neither is it detected for any standard type.
It is a bit crazy but forcing this kinda makes a habit. That way, a habitual user will tend to initialize other variable types as well.
That's why I call it a standard, because the library has its own coding style. Take the ownership semantics explained in concepts section of README for example. I provide a way to very clearly specify ownership.
Also the init() instantly detects bugs related to uninitialized struts. When they do happen, sometimes very deep in the code they take a lot of time.
This is also one of the reasons why there are so many ValidateX checks in implementation code. Try to catch bugs faster.
Why do people do such wired projects? Why not just using C++ instead of pure C?
Maybe because one is working on a legacy C program, and for various reasons adding C++ to said program is too risky or expensive?
Because I just don't like it as much and I wanted to see how much farther can we go by just using macro tricks.
Ok, it's fine, if you just wanted to experiment with macros. This seems to be a legit reason to use pure C.
It also compilers way faster than C++ code if that interests you :-)
I agree, C++ code compilation is generally slower compared to C. But the compiler itself isn't particularity slower (under the hood it's the same compiler), but compiling C++ code with a lot of templates is slow.
For me personally compilation slowdown is just a price, which I am ready to pay for more language features, including better abstractions and type safety.