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.
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.
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++)
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 :)
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.
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.
reply