>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.
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++)
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.
Readit News
Why include the letters Std then? This seems like a purposeful typo-squatting effort and definitely makes me suspicious.
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?
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.
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.There can be only one.
Deleted Comment
One example is me parsing HTTP headers: https://github.com/brightprogrammer/beam/blob/master/Source%...
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.
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.
Deleted Comment